Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Greetings

Expand Messages
  • Sanjiva Weerawarana
    Hi Dave, ... It was posted sometime ago, but please do feel free to do it again. I agree periodic postings would be a good way to catch new comers and others
    Message 1 of 62 , Mar 23, 2001
    • 0 Attachment
      Hi Dave,

      > Question: has a pointer to this list been posted on various other
      > SOAP-related lists? If SOAP interop is to be inclusive we have to be careful
      > about that.

      It was posted sometime ago, but please do feel free to do it again. I
      agree periodic postings would be a good way to catch "new comers" and
      others who missed it before.

      Sanjiva.
    • Matt Long
      Tony, I think we have similar thoughts on this...see http://discuss.develop.com/archives/wa.exe?A2=ind0102&L=SOAP&P=R10229 I would propose a set of testing
      Message 62 of 62 , Mar 23, 2001
      • 0 Attachment
        Tony,
        I think we have similar thoughts on this...see http://discuss.develop.com/archives/wa.exe?A2=ind0102&L=SOAP&P=R10229
         
         
        I would propose a set of testing criteria be comprised of two separate issues. The server-side and the client-side.  I think it is a legimate argument that clients should be included (albeit separate and independent testing) as they as part of many forth coming business models.  I would offer this highly incomplete document as a starting point.  Notice, my concerns in this document are with testing basics and NOT the committee members.  Being a PM,engineer, and a business-person, I think it is advisable to concern ourselves with the details of testing first, then the we can haggle the political ramifications of the committee only after the testing plan is in place.  I would be more than willing to shepard the testing plan details until we are all satisfied with the criteria, structure, and fairness of such, with the arbiter being consensus.  The testing plan would be then executed by the testing committe.  Additionally, I think it is vital to keep the details in the open forum, least someone be accussed of "slanting", e.g., absolutely no surprises.
         
        Testing Criteria

         Testing goals:

        1) To align the development community behind a minimal set of standards for Soap interoperability.

        2) To determine the state of Soap interoperability in the existing environment.

        3) To achieve greater interoperability between various applications by documentation of results.

        4) To determine the interoperability strengths and weaknesses of existing Soap Clients.

        5) To achieve greater interoperability between Soap servers and Soap Clients.

         

        SOAP Server minimal standards:

        ...Minimal standards go here

         

        SOAP Server testing criteria:

        1) The each implementer is supplied with the required information, exclusive to the actual request envelopes.

        2) The testing committee will attempt to execute the request against each implementation

                    2a) Using xsi:type with parameters

                    2b) Without using xsi:type with parameters

        3) The results will be recorded and supplied to each implementer privately.

        4) Implementers with failed requests will be supplied with the request envelope and may make changes to their implementations and retest.

        5) The testing committee will report.

                    5a) An aggregation of results.

                    5b) Compliant applications and their extent.

                    5c) The committee will not report non-compliant applications.

          

        SOAP Client testing criteria:

        1) Each Soap Client will be supplied to the testing committee and executed by the testing committee.

        2) The committee will conduct initialization testing in conjuncture with the vendors to ensure the clients are functional prior to testing.

        3) The committee transmits to the vendors the request and response envelopes and any other required information

        4) The vendors will formulate the configuration for the committee and transmit to the committee for execution.

        5) The testing committee will execute the client request on as many compliant soap servers as possible.

        6) The testing committee will report:

                    6a) An aggregation of results

                    6b) Usable clients and their extent

                    6c) The committee will not report non-usable clients.

        -----Original Message-----
        From: Tony Hong [mailto:thong@...]
        Sent: Friday, March 23, 2001 5:03 PM
        To: soapbuilders@yahoogroups.com
        Subject: RE: [soapbuilders] Re: "default" encoding style

        <bobs quote>
        My suggestion was only that WSDL might serve as a _vehicle_ for making such
        "envelope standards" know to all for documentation purposes. It would be
        optional whether or not the WSDL was referenced at runtime, or even by
        development tools at design time.
        </bobs quote>
         
        Bob, well put!
         
        <bobs quote>
        But the question remains... Just how would these "envelope standards" be
        communicated? in what format? by whom? how formal would they need to be?
        Wasn't WSDL developed to solve the same sort of  SOAP interop problems?
        That is, to restrict the space of possible SOAP envelopes a service wishes to
        process (among other things)?
        </bobs quote>
         
        I think WSDL is still there to do this job. And for those use cases that fall outside the "standardized contracts", WSDL will still be doing it there. Now, when we start to talk about non-standard cases , we'll run into interop issues too - interop will then be limited to
        a) the ability of one implementation to read the parse the WSDL of the other
        b) the ability for an implementations' envelope formation code to conform to the WSDL of the other.
         
        But what I am saying is that for the MOST BASIC cases, these standard contracts, which may drive both the WSDL and the envelopes,  might save a lot of hassle and potentially an information week article talking about how SOAP was all hype because it's still very balkanized.
         
        IT's the 80/20 rule. Heavy reliance on WSDL for 20% to generate variable nonstandard envelopes,  conformace to a basic contract for the 80% of cases where what we want to do is simple.
         
        With regards to how we arrive at the standards, that's not for me to say - that's what this group is here for.  But, I'll suggest an approach and let you guys tell me why it doesn't work! :-)
         
        a.  First , let's make sure that we have some critical mass of implementors, both independents as well as MS and Apache, who buy off on this concept and are willing to participate in the process, and more importantly.
         
        b.  Let's identify the first use case - simple basic RPC, basic types, HTTP - and walk through the issues matrix ( http://www.xmethods.net/soapbuilders/interop.html ) , point by point, agreeing on what the contract should be.
         
        c.  Let's document the results for the use case. At that point, we should have a pretty tight set of decisions that any implementor can use, and post the results in the files section of this group.
         
        d.  Implementations can then conform to these standards, and then we do something like an interopathon. I think after having gone through a-c, interopathon will be a breeze ! Well, maybe ;-)  I will volunteer to host as many endpoints as it takes, or maintain a table with pointers.
         
        That's super high level, but a starting point. I'm definitely open to other suggestions, of course.
         
        Cheers,
        Tony
         
         
         
         
        -----Original Message-----
        From: Bob Cunnings [mailto:cunnings@...]
        Sent: Friday, March 23, 2001 2:20 PM
        To: soapbuilders@yahoogroups.com
        Subject: RE: [soapbuilders] Re: "default" encoding style


        Hello,

        If I may, let me quote the first paragraph of Tony's post:

        <quote>
        I'm wondering if what's needed to crack the interop issue is a set of
        "envelope standards" (contracts? guidelines? defacto standardization
        across soapbuilders?) , in full compliance with the SOAP spec, but more
        restrictive, to be built around specific use cases. For example , you can
        say for a use case of simple RPC over HTTP, that SOAPAction is treated
        this particular way, Content-Type is done that way, the use of
        "encodingStyle" is mandatory and set to SOAP-ENC, and so on.
        </quote>

        My suggestion was only that WSDL might serve as a _vehicle_ for making such
        "envelope standards" know to all for documentation purposes. It would be
        optional whether or not the WSDL was referenced at runtime, or even by
        development tools at design time.

        But the question remains... Just how would these "envelope standards" be
        communicated? in what format? by whom? how formal would they need to be?
        Wasn't WSDL developed to solve the same sort of  SOAP interop problems?
        That is, to restrict the space of possible SOAP envelopes a service wishes to
        process (among other things)?

        If services are tagged with some sort of "indicator", won't that have to centrally
        managed? Would such an indicator become an input for tools? Would an
        application have to be capable of understanding it a runtime? If it is bad to
        require WSDL for interop, is it bad to require "envelope standard" indications or
        guidelines for interop?

        These are only my thoughts, it's been an interesting discussion.

        RC

        > is WSDL useful for consuming SOAP services, you bet.
        > is WSDL required to get SOAP inter-op, no way.
        >
        >
        > -----Original Message-----
        > From: graham glass [mailto:graham-glass@...]
        > Sent: Friday, March 23, 2001 1:38 PM
        > To: soapbuilders@yahoogroups.com
        > Subject: RE: [soapbuilders] Re: "default" encoding style
        >
        >
        > hi keith,
        >
        > i see what you mean.
        >
        > however, from a pragmatic standpoint, i doubt
        > whether anyone would want to create such a proxy
        > by hand, and there will therefore be a huge
        > incentive for platforms hosting web services to
        > provide WSDL, ideally on an automatic basis.
        >
        > cheers,
        > graham
        >
        > -----Original Message-----
        > From: Keith Ballinger [mailto:keithba@...]
        > Sent: Friday, March 23, 2001 3:24 PM
        > To: soapbuilders@yahoogroups.com
        > Subject: RE: [soapbuilders] Re: "default" encoding style
        >
        >
        > WSDL isn't a requirement so that .NET will be able to consume your
        > service. It is a convenience, albeit a really really nice one that makes
        > the programming model much easier. Here's why:
        >
        > We have a tool (Visual Studio does this as well), called wsdl.exe
        > (original name, huh?) that if given a WSDL file, will create a proxy
        > class. This proxy class wil look like this (shortened for brevity):
        >
        > [System.Web.Services.WebServiceBindingAttribute(Name="SimpleTestSoap",
        > Namespace="http://soapinterop.org")]
        > [System.Xml.Serialization.SoapIncludeAttribute(typeof(Data))]
        > public class SimpleTest :
        > System.Web.Services.Protocols.SoapHttpClientProtocol {
        >
        >     public SimpleTest() {
        >         this.Url = "http://localhost/test/simple.asmx";
        >     }
        >
        > [System.Web.Services.Protocols.SoapMethodAttribute("http://soapinterop.o
        > rg/EchoInt", RequestNamespace="http://soapinterop.org",
        > ResponseNamespace="http://soapinterop.org",
        > MessageStyle=System.Web.Services.Protocols.SoapMessageStyle.Rpc)]
        >     public int EchoInt(int i) {
        >         object[] results = this.Invoke("EchoInt", new object[] {i});
        >         return ((int)(results[0]));
        >     }
        > }
        >
        > This proxy class, when invoked, will generate SOAP that looks like this:
        > SOAPAction: "http://soapinterop.org/EchoInt"
        >
        > <?xml version="1.0" encoding="utf-8"?>
        > <soap:Envelope xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
        > xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
        > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
        > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        >   <soap:Body
        > soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        >     <EchoInt xmlns="http://soapinterop.org">
        >       <i xmlns="">int</i>
        >     </EchoInt>
        >   </soap:Body>
        > </soap:Envelope>
        >
        > Notice that WSDL isn't at all involved at runtime, the metadata
        > attributes provide all the needed info at runtime. Thus, if you had a
        > service that DIDN'T have any WSDL support, someone could still create a
        > proxy class like the one above to generate the right SOAP. It may be
        > harder, but that is a programming model question, not a question of
        > basic support.
        >
        > I believe in WSDL, and I would like to see WSDL interop, but I think it
        > is orthogonal to SOAP interop. Helpful, but orthogonal.
        >
        > -----Original Message-----
        > From: graham glass [mailto:graham-glass@...]
        > Sent: Friday, March 23, 2001 1:00 PM
        > To: soapbuilders@yahoogroups.com
        > Subject: RE: [soapbuilders] Re: "default" encoding style
        >
        > hi guys,
        >
        > i'll elaborate on why i think WSDL is a fundamental thing
        > that should be supported.
        >
        > WSDL describes the characteristics of a service, including
        > where it is, how to bind to it, what type of encoding to use, etc. etc.
        >
        > binding to and invoking a service without using this
        > information is like a shot in the dark, and all the discussion
        > about guessing defaults, etc. is just a short-term solution
        > to avoid having to parse and interpret WSDL IMHO.
        >
        > when i was building GLUE i originally only supported old-style
        > binding, of the form:
        >
        > proxy = Registry.bind( "http://host:port/urn:service" )
        >
        > and made all kinds of assumptions about what the SOAP action should
        > be, what encoding style to use, the endpoint/urn of the service, etc.
        >
        > when i finally bit the bullet and integrated support for WSDL,
        > everything became so much easier, and GLUE no longer had to make
        > any assumptions or guesses about the service's characteristics.
        >
        > so although GLUE still supports the "old way", the prefered
        > way is now:
        >
        > proxy = Registry.bind( "http://host:port/urn:service.wsdl" )
        >
        > where GLUE can read in the WSDL and learn everything it needs
        > to about the service.
        >
        > after this experience, it makes so much sense to me that a client
        > should communicate with a service based on its WSDL description,
        > and that any other approach is doomed to have problems, especially
        > as the WSDL description starts incorporating more information
        > about the service, such as quality, cost, etc.
        >
        > so although it's possible to get by in the short term
        > without WSDL integration, i think it's a dead-end for the
        > medium/long term.
        >
        > b.t.w. GLUE automatically serves up WSDL for any service that
        > it hosts, so a developer never has to actually create any WSDL.
        > in other words, you can achieve WSDL integration without
        > adding any burden to a developer.
        >
        > cheers,
        > graham
        >
        > p.s. by "mainstream" i meant "volume shipments", and did not
        > imply anything regarding quality. platforms like .NET do
        > all of their binding based on WSDL, and they will no doubt
        > ship in the millions of units. so if you want your service
        > to be consumable by .NET, you have to support WSDL. let me
        > know if i'm wrong on this issue!
        >
        >
        > -----Original Message-----
        > From: Dave Winer [mailto:dave@...]
        > Sent: Friday, March 23, 2001 2:40 PM
        > To: soapbuilders@yahoogroups.com
        > Subject: Re: [soapbuilders] Re: "default" encoding style
        >
        >
        > Coool, so we have a clear look at a line of demarkation.
        >
        > There will be others, no doubt -- for example the "rpc head" vs "message
        > head" piece that Keith wrote a few days ago. I saw that crop up in the
        > DevX
        > interview with Charles Fitzgerald where he went out of his way to say
        > that
        > HailStorm is not RPC.
        >
        > I strongly suggest we marshall all the implementations we can find so we
        > can
        > look at what they're actually doing so we can quickly form an estimate
        > of
        > how many different "SOAP"s there actually are. We must not be scared of
        > the
        > truth. Keith's comment highlighted a disconnect, and I know he's looking
        > for
        > them, as am I.
        >
        > BTW, I don't think terms like "mainstream" are very useful. We think our
        > implementations are quite mainstream and there ain't no WSDL in there.
        > ;->
        >
        > Dave
        >
        > ----- Original Message -----
        > From: "graham glass" <graham-glass@...>
        > To: <soapbuilders@yahoogroups.com>
        > Sent: Friday, March 23, 2001 12:41 PM
        > Subject: RE: [soapbuilders] Re: "default" encoding style
        >
        >
        > > i think that supported WSDL is extremely important.
        > >
        > > most mainstream platforms that i know of bind to services
        > > based on their WSDL description, and based on my own
        > > work on web services, this is definitely the way to go.
        > >
        > > so i think +1 on including WSDL in the interop.
        > >
        > > cheers,
        > > graham
        > >
        > > -----Original Message-----
        > > From: Dave Winer [mailto:dave@...]
        > > Sent: Friday, March 23, 2001 2:29 PM
        > > To: soapbuilders@yahoogroups.com
        > > Subject: Re: [soapbuilders] Re: "default" encoding style
        > >
        > >
        > > -1 on WSDL even being mentioned as part of SOAP 1.1 interop.
        > >
        > > Dave
        > >
        > >
        > > ----- Original Message -----
        > > From: "Keith Ballinger" <keithba@...>
        > > To: <soapbuilders@yahoogroups.com>
        > > Sent: Friday, March 23, 2001 12:12 PM
        > > Subject: RE: [soapbuilders] Re: "default" encoding style
        > >
        > >
        > > > I agree. While I think it is nice to support WSDL, that shouldn't be
        > a
        > > > requirement. SOAP stacks should get to choose their level of entry
        > into
        > > > the SOAP world, and requiring WSDL is a little too high.
        > > >
        > > >
        > > >
        > > > -----Original Message-----
        > > > From: David Crowley [mailto:dcrowley@...]
        > > > Sent: Friday, March 23, 2001 12:00 PM
        > > > To: soapbuilders@yahoogroups.com
        > > > Subject: Re: [soapbuilders] Re: "default" encoding style
        > > >
        > > >
        > > >
        > > > At 11:50 AM 3/23/2001 -0800, you wrote:
        > > >
        > > > > From a purely selfish point of view, I'd rather not have to
        > implement
        > > > WSDL
        > > > >support to get to interop. ;->
        > > > >
        > > > >-Jake
        > > >
        > > >
        > > > I absolutely agree.  It would take the Simple right out of SOAP.
        > Every
        > > > implementation of SOAP would be a monumental effort.  No thanks.
        > > > Interop
        > > > should be possible without the complications of WSDL.
        > > >
        > > > David
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > Yahoo! Groups Sponsor
        > > >
        > > > Click Here to Find Software Faster
        > > > Click Here to Find Software Faster
        > > >
        > <http://rd.yahoo.com/M=162801.1342033.2934624.1279955/D=egroupmail/S=170
        > > >
        > 0701014:N/A=599083/*http:/www.knowledgestorm.com/jump_white.html?c=Yahoo
        > > > &n=eLert_ComputersInternet_CommNetworking_WhiteGridTime&t=ad>
        > > >
        > > >
        > > >
        > <http://us.adserver.yahoo.com/l?M=162801.1342033.2934624.1279955/D=egrou
        > > > pmail/S=1700701014:N/A=599083/rand=788494684>
        > > >
        > > >
        > > > To unsubscribe from this group, send an email to:
        > > > soapbuilders-unsubscribe@yahoogroups.com
        > > >
        > > >
        > > >
        > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
        > > > <http://docs.yahoo.com/info/terms/> .
        > > >
        > > >
        > > >
        > > > To unsubscribe from this group, send an email to:
        > > > soapbuilders-unsubscribe@yahoogroups.com
        > > >
        > > >
        > > >
        > > > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        > > >
        > > >
        > >
        > >
        > >
        > > To unsubscribe from this group, send an email to:
        > > soapbuilders-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        > >
        > >
        > >
        > >
        > > To unsubscribe from this group, send an email to:
        > > soapbuilders-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        > >
        > >
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
        > Yahoo! Groups Sponsor
        >
        > Click Here to Find Software Faster
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >

        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > soapbuilders-unsubscribe@yahoogroups.com
        >

        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >




        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      Your message has been successfully submitted and would be delivered to recipients shortly.