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

RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4

Expand Messages
  • Doug Davis
    David, The problem with this is that the spec doesn t say they have to match. I agree that it would be nice if they did match but I don t think they have to.
    Message 1 of 21 , Apr 18, 2001
    • 0 Attachment
      David,
      The problem with this is that the spec doesn't say they have to
      match. I agree that it would be nice if they did match but I
      don't think they have to.
      -Dug


      David Crowley <dcrowley@...> on 04/17/2001 09:10:38 PM

      Please respond to soapbuilders@yahoogroups.com

      To: soapbuilders@yahoogroups.com
      cc:
      Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4




      My interpretation of SOAPAction is that it's not meant to be used for
      dispatching.  It's meant to allow a firewall to easily discern what is in
      the SOAP packet without parsing the XML.  Supposedly, or in the future,
      you're supposed to be able to tell a firewall to only let through SOAP
      packets with a SOAPAction of "MyPublicSOAPMethodNamespace".  If the
      firewall allows it, then the SOAP payload is parsed.  The SOAP layer is
      supposed to make sure that the REAL method request matches the
      SOAPAction.  It has nothing to do with authentication (although as Frank
      said a firewall might let an authenticated user pass packets with more
      namespaces or something).  But you wouldn't want authenticated users
      spoofing a SOAP packet either.   The goal is to prevent packets like this
      from being processed:

      SOAPAction: "MyPublicNamespace"

      <Envelope>
          <Body>
             <EvilMethod:"MyEvilNamespace">
          .
          .
          .
          </Body>
      </Envelope>

      I personally think SOAPAction should be required.  If you don't test the
      SOAPAction against the real method that gets executed then you're defeating
      the whole purpose of it.



      Yahoo! Groups Sponsor









      [IMAGE]
      [IMAGE]


      Search:







      [IMAGE]



      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.
    • Doug Davis
      Then what should indicate the target of the call ? It can t be SOAPAction since HTTP is the only transport that has it. A SOAP envelope (by itself) needs to
      Message 2 of 21 , Apr 18, 2001
      • 0 Attachment
        Then what should indicate the "target of the call"? It
        can't be SOAPAction since HTTP is the only transport
        that has it. A SOAP envelope (by itself) needs to contain
        enough information to be properly dispatched by a SOAP
        engine - that means that all dispatch information needs to
        be in there someplace 'cause the message might have
        gone over a non-HTTP transport to get there.
        -Dug

        "Andrew Layman" <yahoo@...> on 04/17/2001 10:52:03 PM

        Please respond to soapbuilders@yahoogroups.com

        To: <soapbuilders@yahoogroups.com>
        cc:
        Subject: Re: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4



        Actually, the namespace should not be inferred to indicate the "target of
        the call" any more than the method name does.  The namespace simply
        distinguishes the element name from other, similarly named, elements.



        Yahoo! Groups Sponsor

        www.debticated.com

        [IMAGE]



        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.
      • Doug Davis
        Matt, I ve long believed that the exact scenario you describe is not only valid but a hole in the soap spec. There is no clear root in the doc and there is no
        Message 3 of 21 , Apr 18, 2001
        • 0 Attachment
          Matt,
          I've long believed that the exact scenario you describe is
          not only valid but a hole in the soap spec. There is no clear
          root in the doc and there is no clear target for processing
          either. This can be interpreted many different ways:
          - an error
          - the 1st one is the root and ignore the rest - unless they're
          pulled in thru href's
          - treat each one as an independent doc and do multiple invokes.
          Its not clear (from the spec) what the correct answer is.
          -Dug


          "Matt Long" <mlong@...> on 04/18/2001 09:58:43 AM

          Please respond to soapbuilders@yahoogroups.com

          To: <soapbuilders@yahoogroups.com>
          cc:
          Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4



          hi paul,

          I would be nice if either Sanjiva and/or Erik on could way in on this, but
          I
          think since a document is most likely to be literal encoded (imo) it is
          possible to comprise the document as parts with no wrapper element.

          <S:Body>
                <docParti/>
                <docPartn/>
          </S:Body>

          If this is a possible case (I think it is a the wrapper element is not
          mandated in document style messages), then the "root" element vanishes
          making it impossible to guarantee a resolution on that basis or the
          potential namespace contain therein.

          -Matt

          >
          >
          > Hi, Matt!
          >
          > > If that's a concern with RPC, think of how limited the resolution
          > > information is with document style messages.  The only guaranteed
          > > information from a document over HTTP is
          > > 1) SOAPAction
          > > 2) local endpoint URI
          > I would add namespace of method/root element for documents (even if
          > it's xmlns="") and the name of method/root element. Should be enough
          > to dispatch any? call on server side. btw, SOAPAction works not only
          > for HTTP, it definitely might be used for SMTP transport or for any
          > other transport with MIME envelope.
          >
          > Best wishes, Paul.
          >
          > --- Matt Long <mlong@...> wrote:
          > >
          > >
          > > > i am concerned if it a SOAP payload does not carry
          > > > enough information within itself for it to be uniquely
          > > > bound to its target.
          > >
          > > If that's a concern with RPC, think of how limited the resolution
          > > information is with document style messages.  The only guaranteed
          > > information from a document over HTTP is
          > > 1) SOAPAction
          > > 2) local endpoint URI
          > >
          > > remember documents must be in distinct bindings with regard to rpcs
          > > and the
          > > endpoint is the same in many cases...ouch!  If you make the
          > > SOAPAction
          > > equivalent to binding1's documents as to binding2's rpcs on the
          > > same port
          > > then your left with some dubious choices to resolve.  I would like
          > > to think
          > > one would want to enforce the same procedures whether the message
          > > style is
          > > rpc or document in nature...leaving us with SOAPAction playing a
          > > significant
          > > role in WSDL resolution.
          > >
          > > Does GLUE support documents over HTTP resolved to WSDL?  If so, how
          > > can you
          > > resolve it without SOAPAction using the same endpoint?
          > >
          > >
          > >
          > > >
          > > > i can understand it when a SOAPAction essentially
          > > > carries a snippet of the payload (such as a method name)
          > > > in order to help the HTTP layer do some pre-filtering, but
          > > > i would be surprised if the authors of the SOAP
          > > > specification ever expected SOAPAction to carry
          > > > information that was not in the SOAP payload but
          > > > necessary for determining the target of the message.
          > > >
          > > > this would be like addressing an envelope but leaving
          > > > off the number of the house and giving it to the postman instead.
          > > >
          > > > cheers,
          > > > graham
          > > >
          > > > -----Original Message-----
          > > > From: Matt Long [mailto:mlong@...]
          > > > Sent: Tuesday, April 17, 2001 10:15 PM
          > > > To: soapbuilders@yahoogroups.com
          > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
          > > >
          > > >
          > > > Oooops,
          > > >
          > > > this should be
          > > >
          > > >  method1 = soapaction1; binding1 ; portType1; port1; ns1
          > > >  method2 = soapaction2; binding1 ; portType1; port1; ns1
          > > >  method1 = soapaction2; binding2 ; portType2; port1; ns1
          > > >
          > > > > -----Original Message-----
          > > > > From: Matt Long [mailto:mlong@...]
          > > > > Sent: Tuesday, April 17, 2001 10:10 PM
          > > > > To: soapbuilders@yahoogroups.com
          > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
          > > > >
          > > > >
          > > > >
          > > > > First, soapAction is required to rpc (whether is has a value
          > > > > or not) in
          > > > > WSDL.  Given that you can have the following
          > > > >
          > > > > method1 = soapaction1; binding1 ; portType1; port1
          > > > > method2 = soapaction2; binding1 ; portType1; port1
          > > > > method1 = soapaction2; binding2 ; portType2; port1
          > > > >
          > > > > this cannot be resolved by method alone you must introduce
          > > > > soapaction for
          > > > > programmatic resolution.
          > > > >
          > > > > there are also issues regarding document and rpc in the same
          > > > > wsdl document
          > > > > using the same SOAPAction header in HTTP.
          > > > >
          > > > > I suppose that GLUE cannot have a wsdl document written as
          > > > > the one above, if
          > > > > it did how in the world do you know which binding to use
          > > > > without soapaction.
          > > > >
          > > > >
          > > > >
          > > > >
          > > > > >
          > > > > > why is the SOAPAction required for resolution? the target
          > > > > > namespace in the SOAP payload indicates the final target
          > > > > > of the call and the method name is also in the payload.
          > > > > >
          > > > > > also, how do you implement polymorphism based on the
          > > > > > SOAPAction? do you include the method signature as part
          > > > > > of the SOAPAction?
          > > > > >
          > > > > > cheers,
          > > > > > graham
          > > > > >
          > > > > > b.t.w GLUE is 100% oriented around WSDL and doesn't
          > > > > > use SOAPAction for anything.
          > > > > >
          > > > > > -----Original Message-----
          > > > > > From: Matt Long [mailto:mlong@...]
          > > > > > Sent: Tuesday, April 17, 2001 9:04 PM
          > > > > > To: soapbuilders@yahoogroups.com
          > > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC
          > > 1.4
          > > > > >
          > > > > >
          > > > > > Another SOAPAction (why do I care)
          > > > > >
          > > > > > If you are using a WSDL processor alongside your SOAP
          > > > > > processor you care
          > > > > > very much about the value of the SOAPAction header as it is
          > > > > > critical to
          > > > > > resolution (if you don't want to hard code some data at your
          > > > > > endpoint or
          > > > > > bust rpc and document styles into separate WSDL documents)
          > > > > There are
          > > > > > several "caveats" related to programmatic resolvability of
          > > > > WSDL given
          > > > > > certain repeating attribute values in WSDL.  These are not
          > > > > technically
          > > > > > "issues" given one understands the unwritten (and yet
          > > > > > undocumented) rules of
          > > > > > programmatic resolution.
          > > > > >
          > > > > > When there is a 1:1 relationship between
          > > > > > SOAPAction:MethodCall as in one of
          > > > > > the MS implementations (I think) there are true benefits.  I
          > > > > > for one would
          > > > > > like to see this implemented more frequently as it is
          > > > > > provides a very clean
          > > > > > and inexpensive way to resolve the WSDL document from
          > > > > > external interrogation
          > > > > > and requires less processing on the server side from a
          > > resolution
          > > > > > perspective.
          > > > > >
          > > > > > -Matt
          > > > > >
          > > > > >
          > > > > >
          > > > > > > -----Original Message-----
          > > > > > > From: graham glass [mailto:graham-glass@...]
          > > > > > > Sent: Tuesday, April 17, 2001 6:48 PM
          > > > > > > To: soapbuilders@yahoogroups.com
          > > > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC
          > > 1.4
          > > > > > >
          > > > > > >
          > > > > > > out of interest, why do the various SOAP server care much
          > > > > > > about the SOAPAction anyway, since the target namespace
          > > > > > > buried is inside the payload? GLUE couldn't care less what
          > > the
          > > > > > > SOAPAction is, and basically ignores it.
          > > > > > >
          > > > > > > is it to perform filtering? if so, it seems like a nicety,
          > > but
          > > > > > > not something that is truly required.
          > > > > > >
          > > > > > > cheers,
          > > > > > > graham
          > > > > > >
          > > > > > > -----Original Message-----
          > > > > > > From: keithba@... [mailto:keithba@...]
          > > > > > > Sent: Tuesday, April 17, 2001 6:05 PM
          > > > > > > To: soapbuilders@yahoogroups.com
          > > > > > > Subject: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
          > > > > > >
          > > > > > >
          > > > > > > > Currently Frontier does *not* accept a different
          > > > SOAPAction per
          > > > > > > method. I'd
          > > > > > > > flip this question around: Are there any servers that
          > > > > > cannot accept
          > > > > > > the SAME
          > > > > > > > SOAPAction for all methods (for the interop tests)?
          > > > > > >
          > > > > > > .NET Web Services requires different soap actions for
          > > > each method
          > > > > > > when doing rpc style soap.
          > > > > > >
          > > > > > > --- In soapbuilders@y..., Jake Savin <jake@u...> wrote:
          > > > > > > > inline. -Jake
          > > > > > > >
          > > > > > > > on 4/17/01 3:41 PM, Tony Hong at thong@x... wrote:
          > > > > > > >
          > > > > > > > > The main things that I see as potentially a
          > > > stumbling block to
          > > > > > > producing a
          > > > > > > > > single wsdl file consumable by all implementations is:
          > > > > > > > >
          > >
          > === message truncated ===
          >
          >
          > __________________________________________________
          > Do You Yahoo!?
          > Yahoo! Auctions - buy the things you want at great prices
          > http://auctions.yahoo.com/
          >
          > ------------------------ Yahoo! Groups Sponsor
          > ---------------------~-~>
          > Do you have 128-bit SSL encryption server security?
          > Get VeriSign's FREE Guide, "Securing Your
          > Web Site for Business." Get it now!
          > http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/WNqXlB/TM
          > --------------------------------------------------------------
          > -------_->
          >
          > 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

          www.debticated.com

          [IMAGE]



          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.
        • Matt Long
          WSDL and the SOAPAction and be used to solve this problem in terms of a general solution using a unique SOAPAction header on a per document basis. However, in
          Message 4 of 21 , Apr 18, 2001
          • 0 Attachment
            WSDL and the SOAPAction and be used to solve this problem in terms of a
            general solution using a unique SOAPAction header on a per document basis.
            However, in the non-HTTP case SOAPAction is not required. That's actually
            ok (imo) as implementation-A may not require SOAPAction and implementation-B
            may require it (but is all there in the WSDL description of each service
            whether your calling A or B). This is yet another good reason for WSDL to
            be advertised by a service whether or not the SOAP processor is wsdl enabled
            or not.

            Our WSDL processor enforces these rules for generalization purposes...

            1) SOAPAction must be unique on a minimum level of binding for rpc with the
            exception of "null"...this does not mean that you cannot have many unique
            soapactions (i.e., one per operation) only that if you use a single
            soapaction on a binding it must be unique against other bindings.

            2) SOAPAction must be unique on a per document basis, with the exception of
            "null."

            Enforcing this two simple rules allows you to resolve any inbound message
            (rpc or document) in WSDL.

            I think this solution is flexible enough that it should not collide with any
            other implementation.





            >
            >
            > Matt,
            > I've long believed that the exact scenario you describe is
            > not only valid but a hole in the soap spec. There is no clear
            > root in the doc and there is no clear target for processing
            > either. This can be interpreted many different ways:
            > - an error
            > - the 1st one is the root and ignore the rest - unless they're
            > pulled in thru href's
            > - treat each one as an independent doc and do multiple invokes.
            > Its not clear (from the spec) what the correct answer is.
            > -Dug
            >
            >
            > "Matt Long" <mlong@...> on 04/18/2001 09:58:43 AM
            >
            > Please respond to soapbuilders@yahoogroups.com
            >
            > To: <soapbuilders@yahoogroups.com>
            > cc:
            > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
            >
            >
            >
            > hi paul,
            >
            > I would be nice if either Sanjiva and/or Erik on could way in
            > on this, but
            > I
            > think since a document is most likely to be literal encoded
            > (imo) it is
            > possible to comprise the document as parts with no wrapper element.
            >
            > <S:Body>
            > <docParti/>
            > <docPartn/>
            > </S:Body>
            >
            > If this is a possible case (I think it is a the wrapper element is not
            > mandated in document style messages), then the "root" element vanishes
            > making it impossible to guarantee a resolution on that basis or the
            > potential namespace contain therein.
            >
            > -Matt
            >
            > >
            > >
            > > Hi, Matt!
            > >
            > > > If that's a concern with RPC, think of how limited the resolution
            > > > information is with document style messages. The only guaranteed
            > > > information from a document over HTTP is
            > > > 1) SOAPAction
            > > > 2) local endpoint URI
            > > I would add namespace of method/root element for documents (even if
            > > it's xmlns="") and the name of method/root element. Should be enough
            > > to dispatch any? call on server side. btw, SOAPAction works not only
            > > for HTTP, it definitely might be used for SMTP transport or for any
            > > other transport with MIME envelope.
            > >
            > > Best wishes, Paul.
            > >
            > > --- Matt Long <mlong@...> wrote:
            > > >
            > > >
            > > > > i am concerned if it a SOAP payload does not carry
            > > > > enough information within itself for it to be uniquely
            > > > > bound to its target.
            > > >
            > > > If that's a concern with RPC, think of how limited the resolution
            > > > information is with document style messages. The only guaranteed
            > > > information from a document over HTTP is
            > > > 1) SOAPAction
            > > > 2) local endpoint URI
            > > >
            > > > remember documents must be in distinct bindings with
            > regard to rpcs
            > > > and the
            > > > endpoint is the same in many cases...ouch! If you make the
            > > > SOAPAction
            > > > equivalent to binding1's documents as to binding2's rpcs on the
            > > > same port
            > > > then your left with some dubious choices to resolve. I would like
            > > > to think
            > > > one would want to enforce the same procedures whether the message
            > > > style is
            > > > rpc or document in nature...leaving us with SOAPAction playing a
            > > > significant
            > > > role in WSDL resolution.
            > > >
            > > > Does GLUE support documents over HTTP resolved to WSDL?
            > If so, how
            > > > can you
            > > > resolve it without SOAPAction using the same endpoint?
            > > >
            > > >
            > > >
            > > > >
            > > > > i can understand it when a SOAPAction essentially
            > > > > carries a snippet of the payload (such as a method name)
            > > > > in order to help the HTTP layer do some pre-filtering, but
            > > > > i would be surprised if the authors of the SOAP
            > > > > specification ever expected SOAPAction to carry
            > > > > information that was not in the SOAP payload but
            > > > > necessary for determining the target of the message.
            > > > >
            > > > > this would be like addressing an envelope but leaving
            > > > > off the number of the house and giving it to the
            > postman instead.
            > > > >
            > > > > cheers,
            > > > > graham
            > > > >
            > > > > -----Original Message-----
            > > > > From: Matt Long [mailto:mlong@...]
            > > > > Sent: Tuesday, April 17, 2001 10:15 PM
            > > > > To: soapbuilders@yahoogroups.com
            > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
            > > > >
            > > > >
            > > > > Oooops,
            > > > >
            > > > > this should be
            > > > >
            > > > > method1 = soapaction1; binding1 ; portType1; port1; ns1
            > > > > method2 = soapaction2; binding1 ; portType1; port1; ns1
            > > > > method1 = soapaction2; binding2 ; portType2; port1; ns1
            > > > >
            > > > > > -----Original Message-----
            > > > > > From: Matt Long [mailto:mlong@...]
            > > > > > Sent: Tuesday, April 17, 2001 10:10 PM
            > > > > > To: soapbuilders@yahoogroups.com
            > > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa
            > SOAP RPC 1.4
            > > > > >
            > > > > >
            > > > > >
            > > > > > First, soapAction is required to rpc (whether is has a value
            > > > > > or not) in
            > > > > > WSDL. Given that you can have the following
            > > > > >
            > > > > > method1 = soapaction1; binding1 ; portType1; port1
            > > > > > method2 = soapaction2; binding1 ; portType1; port1
            > > > > > method1 = soapaction2; binding2 ; portType2; port1
            > > > > >
            > > > > > this cannot be resolved by method alone you must introduce
            > > > > > soapaction for
            > > > > > programmatic resolution.
            > > > > >
            > > > > > there are also issues regarding document and rpc in the same
            > > > > > wsdl document
            > > > > > using the same SOAPAction header in HTTP.
            > > > > >
            > > > > > I suppose that GLUE cannot have a wsdl document written as
            > > > > > the one above, if
            > > > > > it did how in the world do you know which binding to use
            > > > > > without soapaction.
            > > > > >
            > > > > >
            > > > > >
            > > > > >
            > > > > > >
            > > > > > > why is the SOAPAction required for resolution? the target
            > > > > > > namespace in the SOAP payload indicates the final target
            > > > > > > of the call and the method name is also in the payload.
            > > > > > >
            > > > > > > also, how do you implement polymorphism based on the
            > > > > > > SOAPAction? do you include the method signature as part
            > > > > > > of the SOAPAction?
            > > > > > >
            > > > > > > cheers,
            > > > > > > graham
            > > > > > >
            > > > > > > b.t.w GLUE is 100% oriented around WSDL and doesn't
            > > > > > > use SOAPAction for anything.
            > > > > > >
            > > > > > > -----Original Message-----
            > > > > > > From: Matt Long [mailto:mlong@...]
            > > > > > > Sent: Tuesday, April 17, 2001 9:04 PM
            > > > > > > To: soapbuilders@yahoogroups.com
            > > > > > > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC
            > > > 1.4
            > > > > > >
            > > > > > >
            > > > > > > Another SOAPAction (why do I care)
            > > > > > >
            > > > > > > If you are using a WSDL processor alongside your SOAP
            > > > > > > processor you care
            > > > > > > very much about the value of the SOAPAction header as it is
            > > > > > > critical to
            > > > > > > resolution (if you don't want to hard code some data at your
            > > > > > > endpoint or
            > > > > > > bust rpc and document styles into separate WSDL documents)
            > > > > > There are
            > > > > > > several "caveats" related to programmatic resolvability of
            > > > > > WSDL given
            > > > > > > certain repeating attribute values in WSDL. These are not
            > > > > > technically
            > > > > > > "issues" given one understands the unwritten (and yet
            > > > > > > undocumented) rules of
            > > > > > > programmatic resolution.
            > > > > > >
            > > > > > > When there is a 1:1 relationship between
            > > > > > > SOAPAction:MethodCall as in one of
            > > > > > > the MS implementations (I think) there are true benefits. I
            > > > > > > for one would
            > > > > > > like to see this implemented more frequently as it is
            > > > > > > provides a very clean
            > > > > > > and inexpensive way to resolve the WSDL document from
            > > > > > > external interrogation
            > > > > > > and requires less processing on the server side from a
            > > > resolution
            > > > > > > perspective.
            > > > > > >
            > > > > > > -Matt
            > > > > > >
            > > > > > >
            > > > > > >
            > > > > > > > -----Original Message-----
            > > > > > > > From: graham glass [mailto:graham-glass@...]
            > > > > > > > Sent: Tuesday, April 17, 2001 6:48 PM
            > > > > > > > To: soapbuilders@yahoogroups.com
            > > > > > > > Subject: RE: [soapbuilders] Re: eSoap & White
            > Mesa SOAP RPC
            > > > 1.4
            > > > > > > >
            > > > > > > >
            > > > > > > > out of interest, why do the various SOAP server care much
            > > > > > > > about the SOAPAction anyway, since the target namespace
            > > > > > > > buried is inside the payload? GLUE couldn't care less what
            > > > the
            > > > > > > > SOAPAction is, and basically ignores it.
            > > > > > > >
            > > > > > > > is it to perform filtering? if so, it seems like a nicety,
            > > > but
            > > > > > > > not something that is truly required.
            > > > > > > >
            > > > > > > > cheers,
            > > > > > > > graham
            > > > > > > >
            > > > > > > > -----Original Message-----
            > > > > > > > From: keithba@... [mailto:keithba@...]
            > > > > > > > Sent: Tuesday, April 17, 2001 6:05 PM
            > > > > > > > To: soapbuilders@yahoogroups.com
            > > > > > > > Subject: [soapbuilders] Re: eSoap & White Mesa
            > SOAP RPC 1.4
            > > > > > > >
            > > > > > > >
            > > > > > > > > Currently Frontier does *not* accept a different
            > > > > SOAPAction per
            > > > > > > > method. I'd
            > > > > > > > > flip this question around: Are there any servers that
            > > > > > > cannot accept
            > > > > > > > the SAME
            > > > > > > > > SOAPAction for all methods (for the interop tests)?
            > > > > > > >
            > > > > > > > .NET Web Services requires different soap actions for
            > > > > each method
            > > > > > > > when doing rpc style soap.
            > > > > > > >
            > > > > > > > --- In soapbuilders@y..., Jake Savin <jake@u...> wrote:
            > > > > > > > > inline. -Jake
            > > > > > > > >
            > > > > > > > > on 4/17/01 3:41 PM, Tony Hong at thong@x... wrote:
            > > > > > > > >
            > > > > > > > > > The main things that I see as potentially a
            > > > > stumbling block to
            > > > > > > > producing a
            > > > > > > > > > single wsdl file consumable by all implementations is:
            > > > > > > > > >
            > > >
            > > === message truncated ===
            > >
            > >
            > > __________________________________________________
            > > Do You Yahoo!?
            > > Yahoo! Auctions - buy the things you want at great prices
            > > http://auctions.yahoo.com/
            > >
            > > ------------------------ Yahoo! Groups Sponsor
            > > ---------------------~-~>
            > > Do you have 128-bit SSL encryption server security?
            > > Get VeriSign's FREE Guide, "Securing Your
            > > Web Site for Business." Get it now!
            > > http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/WNqXlB/TM
            > > --------------------------------------------------------------
            > > -------_->
            > >
            > > 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
            >
            >
            >
            > www.debticated.com
            >
            >
            >
            > [IMAGE]
            >
            >
            >
            >
            >
            > 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.
            >
            >
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            > ---------------------~-~>
            > Secure your servers with 128-bit SSL encryption!
            > Grab your copy of VeriSign's FREE Guide,
            > "Securing Your Web site for Business." Get it now!
            > http://us.click.yahoo.com/4cW4jC/e.WCAA/bT0EAA/WNqXlB/TM
            > --------------------------------------------------------------
            > -------_->
            >
            > 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/
          • Glen Daniels
            ... I m not sure that s true, Doug, because there is ALWAYS going to be some out-of-band information (even if it s as simple as who you hand the message to).
            Message 5 of 21 , Apr 18, 2001
            • 0 Attachment
              > Then what should indicate the "target of the call"? It
              > can't be SOAPAction since HTTP is the only transport
              > that has it. A SOAP envelope (by itself) needs to contain
              > enough information to be properly dispatched by a SOAP
              > engine - that means that all dispatch information needs to
              > be in there someplace 'cause the message might have
              > gone over a non-HTTP transport to get there.

              I'm not sure that's true, Doug, because there is ALWAYS going to be some
              out-of-band information (even if it's as simple as who you hand the message
              to). A SOAP message sitting on a floppy disk doesn't have any meaning until
              you give it to a server to process. The fact that you give it to a
              particular endpoint is meaningful in and of itself, as is any
              transport-specific information that endpoint uses.

              I might for example hand the message off to an HTTP-based server, and based
              on the HTTP authentication credentials I provide, the server dispatches to a
              real-time SOAP processor or queues the message up to be batch processed by a
              slower server. Dispatch changes, but the message itself doesn't.

              The slightly wider issue here is - if the message moves across multiple
              transports, it's up to the nodes in the path to contract with each other to
              ensure the correct information is represented in whatever way. This might
              mean, for instance, that an RPC request travels across an HTTP connection
              like this:

              <envelope>
              <body><getStockQuote><symbol>IBM</symbol></getStockQuote></body>
              </envelope>

              and then gets sent across an SMTP connection looking like this:

              <env>
              <header>
              <replyTo transport="smtp">inbox@...</replyTo>
              <correlationID>34565</correlationID>
              </header>
              <body><getStockQuote><symbol>IBM</symbol></getStockQuote></body>
              </envelope>

              I.e. since the HTTP connection has implicit req/resp semantics and
              correlation, I don't need any extra info, but once I hit the SMTP link I
              need to put that stuff in the SOAP message. Alternately, I could have used
              SMTP headers for this same information, depending on the particular server
              I'm sending the message to.

              --Glen
            • Doug Davis
              But doesn t that prove my point.You put stuff into the soap envelope. If the message was to then go along an HTTP transport where is the SOAPAction header
              Message 6 of 21 , Apr 18, 2001
              • 0 Attachment
                But doesn't that prove my point.You put stuff into the soap envelope.
                If the message was to then go along an HTTP transport where is
                the SOAPAction header going to come from? The only place it
                really can come from is from inside the soap envelope - not
                necessarily char for char, but there has to be some mechanism
                by which the SOAPHeader was derived. So I think all of the info
                needed for dispatching will end up being someplace in the envelope.
                Some SOAP engines might indeed use the SOAPAction for
                dispatching but I think they will end-up limiting themselves to just
                HTTP if they don't also support other dispatch mechanisms.
                Like you said in a previous note - Axis will support SOAPAction
                as well as namespace (and possible others) - which I think is
                the right answer.
                -Dug

                Glen Daniels <gdaniels@...> on 04/18/2001 11:13:13 AM

                Please respond to soapbuilders@yahoogroups.com

                To: "'soapbuilders@yahoogroups.com'" <soapbuilders@yahoogroups.com>
                cc:
                Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4



                > Then what should indicate the "target of the call"?  It
                > can't be SOAPAction since HTTP is the only transport
                > that has it.  A SOAP envelope (by itself) needs to contain
                > enough information to be properly dispatched by a SOAP
                > engine - that means that all dispatch information needs to
                > be in there someplace 'cause the message might have
                > gone over a non-HTTP transport to get there.

                I'm not sure that's true, Doug, because there is ALWAYS going to be some
                out-of-band information (even if it's as simple as who you hand the message
                to).  A SOAP message sitting on a floppy disk doesn't have any meaning
                until
                you give it to a server to process.  The fact that you give it to a
                particular endpoint is meaningful in and of itself, as is any
                transport-specific information that endpoint uses.

                I might for example hand the message off to an HTTP-based server, and based
                on the HTTP authentication credentials I provide, the server dispatches to
                a
                real-time SOAP processor or queues the message up to be batch processed by
                a
                slower server.  Dispatch changes, but the message itself doesn't.

                The slightly wider issue here is - if the message moves across multiple
                transports, it's up to the nodes in the path to contract with each other to
                ensure the correct information is represented in whatever way.  This might
                mean, for instance, that an RPC request travels across an HTTP connection
                like this:

                <envelope>
                <body><getStockQuote><symbol>IBM</symbol></getStockQuote></body>
                </envelope>

                and then gets sent across an SMTP connection looking like this:

                <env>
                <header>
                  <replyTo transport="smtp">inbox@...</replyTo>
                  <correlationID>34565</correlationID>
                </header>
                <body><getStockQuote><symbol>IBM</symbol></getStockQuote></body>
                </envelope>

                I.e. since the HTTP connection has implicit req/resp semantics and
                correlation, I don't need any extra info, but once I hit the SMTP link I
                need to put that stuff in the SOAP message.  Alternately, I could have used
                SMTP headers for this same information, depending on the particular server
                I'm sending the message to.

                --Glen


                Yahoo! Groups Sponsor




                [IMAGE]
                [IMAGE]







                [IMAGE]



                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.
              • gdaniels@macromedia.com
                ... I disagree. I think this is a matter completely determined by the contract between the two endpoints. My intermediary MAY work by setting the SOAPAction
                Message 7 of 21 , Apr 18, 2001
                • 0 Attachment
                  > But doesn't that prove my point.You put stuff into the soap envelope.
                  > If the message was to then go along an HTTP transport where is
                  > the SOAPAction header going to come from? The only place it
                  > really can come from is from inside the soap envelope - not
                  > necessarily char for char, but there has to be some mechanism
                  > by which the SOAPHeader was derived. So I think all of the info
                  > needed for dispatching will end up being someplace in the envelope.

                  I disagree. I think this is a matter completely determined by the contract
                  between the two endpoints. My intermediary MAY work by setting the
                  SOAPAction to the qName of the 1st body element and then passing the message
                  on, but it also may perfectly well use a static SOAPAction which lets the
                  HTTP server know simply that this is a message from this particular
                  intermediary. Or let's say I accept SMTP messages and send them on to an
                  HTTP server - I may have a simple map of email address -> SOAPAction, so the
                  SOAPAction I send is dependent on how I got the message, not anything in the
                  actual SOAP contents. The contents of such a table would be configured in
                  some unspecified out-of-band way.

                  > Some SOAP engines might indeed use the SOAPAction for
                  > dispatching but I think they will end-up limiting themselves to just
                  > HTTP if they don't also support other dispatch mechanisms.

                  +1

                  > Like you said in a previous note - Axis will support SOAPAction
                  > as well as namespace (and possible others) - which I think is
                  > the right answer.

                  Also +1.

                  --Glen
                • Paul Kulchenko
                  Hi, Glen! I agree with Doug that in most cases information required for dispatch should come from the message itself. Untill now namespace of the first element
                  Message 8 of 21 , Apr 18, 2001
                  • 0 Attachment
                    Hi, Glen!

                    I agree with Doug that in most cases information required for
                    dispatch should come from the message itself. Untill now namespace of
                    the first element [+ method name] was the basic dispatch mechanism
                    for SOAP::Lite. New version is supporting dispatch based on
                    SOAPAction/endpoint address, but it's just an exception that proves
                    rule: envelope should be self-sufficient. :)

                    Best wishes, Paul.

                    --- gdaniels@... wrote:
                    >
                    > > But doesn't that prove my point.You put stuff into the soap
                    > envelope.
                    > > If the message was to then go along an HTTP transport where is
                    > > the SOAPAction header going to come from? The only place it
                    > > really can come from is from inside the soap envelope - not
                    > > necessarily char for char, but there has to be some mechanism
                    > > by which the SOAPHeader was derived. So I think all of the info
                    > > needed for dispatching will end up being someplace in the
                    > envelope.
                    >
                    > I disagree. I think this is a matter completely determined by the
                    > contract
                    > between the two endpoints. My intermediary MAY work by setting the
                    > SOAPAction to the qName of the 1st body element and then passing
                    > the message
                    > on, but it also may perfectly well use a static SOAPAction which
                    > lets the
                    > HTTP server know simply that this is a message from this particular
                    > intermediary. Or let's say I accept SMTP messages and send them on
                    > to an
                    > HTTP server - I may have a simple map of email address ->
                    > SOAPAction, so the
                    > SOAPAction I send is dependent on how I got the message, not
                    > anything in the
                    > actual SOAP contents. The contents of such a table would be
                    > configured in
                    > some unspecified out-of-band way.
                    >
                    > > Some SOAP engines might indeed use the SOAPAction for
                    > > dispatching but I think they will end-up limiting themselves to
                    > just
                    > > HTTP if they don't also support other dispatch mechanisms.
                    >
                    > +1
                    >
                    > > Like you said in a previous note - Axis will support SOAPAction
                    > > as well as namespace (and possible others) - which I think is
                    > > the right answer.
                    >
                    > Also +1.
                    >
                    > --Glen
                    >
                    > ------------------------ Yahoo! Groups Sponsor
                    >
                    > 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/
                    >
                    >


                    __________________________________________________
                    Do You Yahoo!?
                    Yahoo! Auctions - buy the things you want at great prices
                    http://auctions.yahoo.com/
                  • Paul Kulchenko
                    Hi, All! Since it s possible to return Header from server to client also, what should client do if this header has mustUnderstand attribute or wrong actor?
                    Message 9 of 21 , Apr 18, 2001
                    • 0 Attachment
                      Hi, All!

                      Since it's possible to return Header from server to client also, what
                      should client do if this header has mustUnderstand attribute or wrong
                      actor?

                      Best wishes, Paul.


                      __________________________________________________
                      Do You Yahoo!?
                      Yahoo! Auctions - buy the things you want at great prices
                      http://auctions.yahoo.com/
                    • Doug Davis
                      I see 3 choices: 1 - ignore it 2 - fault back to the server 3 - fault back to the client While 2 is probably what should happen, I doubt many will be able to
                      Message 10 of 21 , Apr 18, 2001
                      • 0 Attachment
                        I see 3 choices:
                        1 - ignore it
                        2 - fault back to the server
                        3 - fault back to the client

                        While 2 is probably what "should" happen, I doubt many
                        will be able to support this. 1 seems most likely, but
                        scares me. 3 seems like a nice middle of the road solution.
                        8-)

                        -Dug


                        Paul Kulchenko <paulclinger@...> on 04/18/2001 12:07:23 PM

                        Please respond to soapbuilders@yahoogroups.com

                        To: soapbuilders@yahoogroups.com
                        cc:
                        Subject: [soapbuilders] mustUnderstand on client side



                        Hi, All!

                        Since it's possible to return Header from server to client also, what
                        should client do if this header has mustUnderstand attribute or wrong
                        actor?

                        Best wishes, Paul.


                        __________________________________________________
                        Do You Yahoo!?
                        Yahoo! Auctions - buy the things you want at great prices
                        http://auctions.yahoo.com/


                        Yahoo! Groups Sponsor

                        Click Here!

                        [IMAGE]



                        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.
                      • Glen Daniels
                        Hi Paul: In most cases, it may very well be in the message as you say. I think we ll see what the common patterns are as usage builds over the next year or
                        Message 11 of 21 , Apr 18, 2001
                        • 0 Attachment
                          Hi Paul:

                          In most cases, it may very well be in the message as you say. I think we'll
                          see what the common patterns are as usage builds over the next year or so.
                          What I'm really trying to say is that I think it's a very bad idea to
                          REQUIRE this to be the case, since I doubt we can predict all the possible
                          scenarios, and we don't want to preclude particular optimizations /
                          implementations.

                          --Glen

                          > I agree with Doug that in most cases information required for
                          > dispatch should come from the message itself. Untill now namespace of
                          > the first element [+ method name] was the basic dispatch mechanism
                          > for SOAP::Lite. New version is supporting dispatch based on
                          > SOAPAction/endpoint address, but it's just an exception that proves
                          > rule: envelope should be self-sufficient. :)
                          >
                          > Best wishes, Paul.
                          >
                          > --- gdaniels@... wrote:
                          > >
                          > > > But doesn't that prove my point.You put stuff into the soap
                          > > envelope.
                          > > > If the message was to then go along an HTTP transport where is
                          > > > the SOAPAction header going to come from? The only place it
                          > > > really can come from is from inside the soap envelope - not
                          > > > necessarily char for char, but there has to be some mechanism
                          > > > by which the SOAPHeader was derived. So I think all of the info
                          > > > needed for dispatching will end up being someplace in the
                          > > envelope.
                          > >
                          > > I disagree. I think this is a matter completely determined by the
                          > > contract
                          > > between the two endpoints. My intermediary MAY work by setting the
                          > > SOAPAction to the qName of the 1st body element and then passing
                          > > the message
                          > > on, but it also may perfectly well use a static SOAPAction which
                          > > lets the
                          > > HTTP server know simply that this is a message from this particular
                          > > intermediary. Or let's say I accept SMTP messages and send them on
                          > > to an
                          > > HTTP server - I may have a simple map of email address ->
                          > > SOAPAction, so the
                          > > SOAPAction I send is dependent on how I got the message, not
                          > > anything in the
                          > > actual SOAP contents. The contents of such a table would be
                          > > configured in
                          > > some unspecified out-of-band way.
                          > >
                          > > > Some SOAP engines might indeed use the SOAPAction for
                          > > > dispatching but I think they will end-up limiting themselves to
                          > > just
                          > > > HTTP if they don't also support other dispatch mechanisms.
                          > >
                          > > +1
                          > >
                          > > > Like you said in a previous note - Axis will support SOAPAction
                          > > > as well as namespace (and possible others) - which I think is
                          > > > the right answer.
                          > >
                          > > Also +1.
                          > >
                          > > --Glen
                          > >
                          > > ------------------------ Yahoo! Groups Sponsor
                          > >
                          > > 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/
                          > >
                          > >
                          >
                          >
                          > __________________________________________________
                          > Do You Yahoo!?
                          > Yahoo! Auctions - buy the things you want at great prices
                          > http://auctions.yahoo.com/
                          >
                          > ------------------------ Yahoo! Groups Sponsor
                          > ---------------------~-~>
                          > Do you have 128-bit SSL encryption server security?
                          > Get VeriSign's FREE Guide, "Securing Your
                          > Web Site for Business." Get it now!
                          > http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/WNqXlB/TM
                          > --------------------------------------------------------------
                          > -------_->
                          >
                          > 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/
                        • Dick Brooks
                          ... Actually, SOAPAction can be appended to any MIME envelope, it s not specific to HTTP. For example, ebXML s SMTP binding includes SOAPAction: ebXML . The
                          Message 12 of 21 , Apr 18, 2001
                          • 0 Attachment
                            Dug wrote:

                            > dispatching but I think they will end-up limiting themselves to just
                            > HTTP if they don't also support other dispatch mechanisms.

                            Actually, SOAPAction can be appended to any MIME envelope, it's not specific
                            to HTTP. For example,
                            ebXML's SMTP binding includes SOAPAction: "ebXML".

                            The dispatch function can occur at several layers, including:
                            - the transport layer (e.g. "POST /ImaDispatcher HTTP/1.1", or "To:
                            application@...")
                            - the MIME layer (Content-type: application/pgp-signature, or SOAPAction:
                            "ebXML")
                            - Some deeper layer (<SOAP-ENV:Body><m:UseMeToDispatch ....>)

                            It's likely that implementers will want the flexibility to decide for
                            themselves
                            how to implement dispatch functions by layer. In Group 8760's case our
                            message
                            broker operates at the MIME layer and below.


                            Dick Brooks
                            Group 8760
                            110 12th Street North
                            Birmingham, AL 35203
                            dick@...
                            205-250-8053
                            Fax: 205-250-8057
                            http://www.8760.com/

                            InsideAgent - Empowering e-commerce solutions
                          • Rosimildo daSIlva
                            ... Paul, I agree too. It is pretty clear ( at least to me ), that the Envelope should have everything that it needs. It is the idea of full encapsulation
                            Message 13 of 21 , Apr 18, 2001
                            • 0 Attachment
                              --- Paul Kulchenko <paulclinger@...> wrote:
                              > Hi, Glen!
                              >
                              > I agree with Doug that in most cases information
                              > required for
                              > dispatch should come from the message itself. Untill
                              > now namespace of
                              > the first element [+ method name] was the basic
                              > dispatch mechanism
                              > for SOAP::Lite. New version is supporting dispatch
                              > based on
                              > SOAPAction/endpoint address, but it's just an
                              > exception that proves
                              > rule: envelope should be self-sufficient. :)
                              >

                              Paul,

                              I agree too. It is pretty clear ( at least to me ),
                              that the "Envelope" should have everything that
                              it needs.

                              It is the idea of full "encapsulation" of protocol
                              layers. In my view, HTTP is a lower layer that
                              is used to carry SOAP envelopes. The envelope at
                              some point is passed to higher layer for processing.
                              This higher layer should know nothing about HTTP.
                              The only thing it should know is to process
                              SOAP envelopes.

                              The idea of a SOAP processor to use HTTP headers
                              to do something like dispatching methods, it is
                              *not a smart move*. It certainly breaks the
                              idea of protocol layers.

                              It is like a TCP framework that requires a
                              couple of fields of an IP frame. :-)

                              Rosimildo.













                              __________________________________________________
                              Do You Yahoo!?
                              Yahoo! Auctions - buy the things you want at great prices
                              http://auctions.yahoo.com/
                            • graham glass
                              i 100% agree with you rosimildo! cheers, graham ... From: Rosimildo daSIlva [mailto:rosimildo@yahoo.com] Sent: Wednesday, April 18, 2001 12:47 PM To:
                              Message 14 of 21 , Apr 18, 2001
                              • 0 Attachment
                                i 100% agree with you rosimildo!

                                cheers,
                                graham

                                -----Original Message-----
                                From: Rosimildo daSIlva [mailto:rosimildo@...]
                                Sent: Wednesday, April 18, 2001 12:47 PM
                                To: soapbuilders@yahoogroups.com
                                Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4


                                --- Paul Kulchenko <paulclinger@...> wrote:
                                > Hi, Glen!
                                >
                                > I agree with Doug that in most cases information
                                > required for
                                > dispatch should come from the message itself. Untill
                                > now namespace of
                                > the first element [+ method name] was the basic
                                > dispatch mechanism
                                > for SOAP::Lite. New version is supporting dispatch
                                > based on
                                > SOAPAction/endpoint address, but it's just an
                                > exception that proves
                                > rule: envelope should be self-sufficient. :)
                                >

                                Paul,

                                I agree too. It is pretty clear ( at least to me ),
                                that the "Envelope" should have everything that
                                it needs.

                                It is the idea of full "encapsulation" of protocol
                                layers. In my view, HTTP is a lower layer that
                                is used to carry SOAP envelopes. The envelope at
                                some point is passed to higher layer for processing.
                                This higher layer should know nothing about HTTP.
                                The only thing it should know is to process
                                SOAP envelopes.

                                The idea of a SOAP processor to use HTTP headers
                                to do something like dispatching methods, it is
                                *not a smart move*. It certainly breaks the
                                idea of protocol layers.

                                It is like a TCP framework that requires a
                                couple of fields of an IP frame. :-)

                                Rosimildo.













                                __________________________________________________
                                Do You Yahoo!?
                                Yahoo! Auctions - buy the things you want at great prices
                                http://auctions.yahoo.com/


                                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/
                              • gdaniels@macromedia.com
                                ... In fact, I believe many (most?) TCP implementations do share information with the IP layer for performance reasons. :) --G
                                Message 15 of 21 , Apr 18, 2001
                                • 0 Attachment
                                  > The idea of a SOAP processor to use HTTP headers
                                  > to do something like dispatching methods, it is
                                  > *not a smart move*. It certainly breaks the
                                  > idea of protocol layers.
                                  >
                                  > It is like a TCP framework that requires a
                                  > couple of fields of an IP frame. :-)

                                  In fact, I believe many (most?) TCP implementations do share information
                                  with the IP layer for performance reasons. :)

                                  --G
                                • David Crowley
                                  ... When I said match I should have probably said something like the SOAPAction is appropriate for the given method. Whatever is appropriate varies on the
                                  Message 16 of 21 , Apr 18, 2001
                                  • 0 Attachment
                                    At 04:09 AM 4/18/2001, you wrote:
                                    >David,
                                    > The problem with this is that the spec doesn't say they have to
                                    >match. I agree that it would be nice if they did match but I
                                    >don't think they have to.
                                    >-Dug
                                    >

                                    When I said "match" I should have probably said something like "the
                                    SOAPAction is appropriate for the given method." Whatever is appropriate
                                    varies on the requirements of the method or server. It could be blank,
                                    match the QName of the method, match what is specified in the WSDL, etc.
                                  • Paul Kulchenko
                                    Hi, Glen! SOAP::Lite doesn t. Rosimildo is right, I don t have any other source of information to dispatch my call except namespace+method or endpoint address
                                    Message 17 of 21 , Apr 18, 2001
                                    • 0 Attachment
                                      Hi, Glen!

                                      SOAP::Lite doesn't. Rosimildo is right, I don't have any other source
                                      of information to dispatch my call except namespace+method or
                                      endpoint address (in this case domain:port :)). Dispatch based only
                                      on envelope information it's like common denominator.

                                      Best wishes, Paul.

                                      --- gdaniels@... wrote:
                                      >
                                      > > The idea of a SOAP processor to use HTTP headers
                                      > > to do something like dispatching methods, it is
                                      > > *not a smart move*. It certainly breaks the
                                      > > idea of protocol layers.
                                      > >
                                      > > It is like a TCP framework that requires a
                                      > > couple of fields of an IP frame. :-)
                                      >
                                      > In fact, I believe many (most?) TCP implementations do share
                                      > information
                                      > with the IP layer for performance reasons. :)
                                      >
                                      > --G
                                      >
                                      > ------------------------ Yahoo! Groups Sponsor
                                      >
                                      > 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/
                                      >
                                      >


                                      __________________________________________________
                                      Do You Yahoo!?
                                      Yahoo! Auctions - buy the things you want at great prices
                                      http://auctions.yahoo.com/
                                    • Paul Kulchenko
                                      Hi, Graham! Cool! At the same time SOAPAction is useful, because it allows you to filter messages without looking inside. :)) Agree? Best wishes, Paul. ...
                                      Message 18 of 21 , Apr 18, 2001
                                      • 0 Attachment
                                        Hi, Graham!

                                        Cool! At the same time SOAPAction is useful, because it allows you to
                                        filter messages without looking inside. :)) Agree?

                                        Best wishes, Paul.

                                        --- graham glass <graham-glass@...> wrote:
                                        > i 100% agree with you rosimildo!
                                        >
                                        > cheers,
                                        > graham
                                        >
                                        > -----Original Message-----
                                        > From: Rosimildo daSIlva [mailto:rosimildo@...]
                                        > Sent: Wednesday, April 18, 2001 12:47 PM
                                        > To: soapbuilders@yahoogroups.com
                                        > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
                                        >
                                        >
                                        > --- Paul Kulchenko <paulclinger@...> wrote:
                                        > > Hi, Glen!
                                        > >
                                        > > I agree with Doug that in most cases information
                                        > > required for
                                        > > dispatch should come from the message itself. Untill
                                        > > now namespace of
                                        > > the first element [+ method name] was the basic
                                        > > dispatch mechanism
                                        > > for SOAP::Lite. New version is supporting dispatch
                                        > > based on
                                        > > SOAPAction/endpoint address, but it's just an
                                        > > exception that proves
                                        > > rule: envelope should be self-sufficient. :)
                                        > >
                                        >
                                        > Paul,
                                        >
                                        > I agree too. It is pretty clear ( at least to me ),
                                        > that the "Envelope" should have everything that
                                        > it needs.
                                        >
                                        > It is the idea of full "encapsulation" of protocol
                                        > layers. In my view, HTTP is a lower layer that
                                        > is used to carry SOAP envelopes. The envelope at
                                        > some point is passed to higher layer for processing.
                                        > This higher layer should know nothing about HTTP.
                                        > The only thing it should know is to process
                                        > SOAP envelopes.
                                        >
                                        > The idea of a SOAP processor to use HTTP headers
                                        > to do something like dispatching methods, it is
                                        > *not a smart move*. It certainly breaks the
                                        > idea of protocol layers.
                                        >
                                        > It is like a TCP framework that requires a
                                        > couple of fields of an IP frame. :-)
                                        >
                                        > Rosimildo.
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > __________________________________________________
                                        > Do You Yahoo!?
                                        > Yahoo! Auctions - buy the things you want at great prices
                                        > http://auctions.yahoo.com/
                                        >
                                        >
                                        > 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
                                        >
                                        > 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/
                                        >
                                        >


                                        __________________________________________________
                                        Do You Yahoo!?
                                        Yahoo! Auctions - buy the things you want at great prices
                                        http://auctions.yahoo.com/
                                      • graham glass
                                        exactly. it s a bit like a biological cell which puts bits and pieces of itself into the membrane so that other cells can check it out from the outside.
                                        Message 19 of 21 , Apr 18, 2001
                                        • 0 Attachment
                                          exactly.

                                          it's a bit like a biological cell which puts
                                          bits and pieces of itself into the membrane
                                          so that other cells can check it out from the
                                          outside.

                                          cheers,
                                          graham

                                          -----Original Message-----
                                          From: Paul Kulchenko [mailto:paulclinger@...]
                                          Sent: Wednesday, April 18, 2001 1:54 PM
                                          To: soapbuilders@yahoogroups.com
                                          Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4


                                          Hi, Graham!

                                          Cool! At the same time SOAPAction is useful, because it allows you to
                                          filter messages without looking inside. :)) Agree?

                                          Best wishes, Paul.

                                          --- graham glass <graham-glass@...> wrote:
                                          > i 100% agree with you rosimildo!
                                          >
                                          > cheers,
                                          > graham
                                          >
                                          > -----Original Message-----
                                          > From: Rosimildo daSIlva [mailto:rosimildo@...]
                                          > Sent: Wednesday, April 18, 2001 12:47 PM
                                          > To: soapbuilders@yahoogroups.com
                                          > Subject: RE: [soapbuilders] Re: eSoap & White Mesa SOAP RPC 1.4
                                          >
                                          >
                                          > --- Paul Kulchenko <paulclinger@...> wrote:
                                          > > Hi, Glen!
                                          > >
                                          > > I agree with Doug that in most cases information
                                          > > required for
                                          > > dispatch should come from the message itself. Untill
                                          > > now namespace of
                                          > > the first element [+ method name] was the basic
                                          > > dispatch mechanism
                                          > > for SOAP::Lite. New version is supporting dispatch
                                          > > based on
                                          > > SOAPAction/endpoint address, but it's just an
                                          > > exception that proves
                                          > > rule: envelope should be self-sufficient. :)
                                          > >
                                          >
                                          > Paul,
                                          >
                                          > I agree too. It is pretty clear ( at least to me ),
                                          > that the "Envelope" should have everything that
                                          > it needs.
                                          >
                                          > It is the idea of full "encapsulation" of protocol
                                          > layers. In my view, HTTP is a lower layer that
                                          > is used to carry SOAP envelopes. The envelope at
                                          > some point is passed to higher layer for processing.
                                          > This higher layer should know nothing about HTTP.
                                          > The only thing it should know is to process
                                          > SOAP envelopes.
                                          >
                                          > The idea of a SOAP processor to use HTTP headers
                                          > to do something like dispatching methods, it is
                                          > *not a smart move*. It certainly breaks the
                                          > idea of protocol layers.
                                          >
                                          > It is like a TCP framework that requires a
                                          > couple of fields of an IP frame. :-)
                                          >
                                          > Rosimildo.
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > __________________________________________________
                                          > Do You Yahoo!?
                                          > Yahoo! Auctions - buy the things you want at great prices
                                          > http://auctions.yahoo.com/
                                          >
                                          >
                                          > 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
                                          >
                                          > 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/
                                          >
                                          >


                                          __________________________________________________
                                          Do You Yahoo!?
                                          Yahoo! Auctions - buy the things you want at great prices
                                          http://auctions.yahoo.com/


                                          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/
                                        • Mike Deem
                                          The Microsoft SOAP Toolkit does 1. 3 is also a reasonable solution. An use case that recently came up: the service sends arbitrary session state back to the
                                          Message 20 of 21 , Apr 18, 2001
                                          • 0 Attachment
                                            The Microsoft SOAP Toolkit does 1. 3 is also a reasonable solution.

                                            An use case that recently came up: the service sends arbitrary "session"
                                            state back to the client in an header. The client needs to echo that
                                            header back to the service in future requests or things won't work. It
                                            makes sense for the server to set mustUnderstand="1" and expect the
                                            client to generate a fault for the application should it not understand
                                            this header.

                                            == Mike ==

                                            -----Original Message-----
                                            From: Doug Davis [mailto:dug@...]
                                            Sent: Wednesday, April 18, 2001 9:16 AM
                                            To: soapbuilders@yahoogroups.com
                                            Subject: Re: [soapbuilders] mustUnderstand on client side


                                            I see 3 choices:
                                            1 - ignore it
                                            2 - fault back to the server
                                            3 - fault back to the client

                                            While 2 is probably what "should" happen, I doubt many
                                            will be able to support this. 1 seems most likely, but
                                            scares me. 3 seems like a nice middle of the road solution.
                                            8-)

                                            -Dug


                                            Paul Kulchenko <paulclinger@...> on 04/18/2001 12:07:23 PM

                                            Please respond to soapbuilders@yahoogroups.com

                                            To: soapbuilders@yahoogroups.com
                                            cc:
                                            Subject: [soapbuilders] mustUnderstand on client side



                                            Hi, All!

                                            Since it's possible to return Header from server to client also, what
                                            should client do if this header has mustUnderstand attribute or wrong
                                            actor?

                                            Best wishes, Paul.


                                            __________________________________________________
                                            Do You Yahoo!?
                                            Yahoo! Auctions - buy the things you want at great prices
                                            http://auctions.yahoo.com/



                                            Yahoo! Groups Sponsor



                                            Click Here!



                                            [IMAGE]





                                            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/
                                          • Henrik Frystyk Nielsen
                                            The basic SOAP processing model described in [1] doesn t know about servers or clients but only SOAP processors which is the reason why SOAP in general walks
                                            Message 21 of 21 , Apr 22, 2001
                                            • 0 Attachment
                                              The basic SOAP processing model described in [1] doesn't know about
                                              servers or clients but only "SOAP processors" which is the reason why
                                              SOAP in general walks a fine line when talking about *generating* a
                                              fault vs. *sending* a fault. The latter is only mentioned in the HTTP
                                              binding and the RPC convention as these two talk about "requests" and
                                              "responses". That is, SOAP distinguishes between generating a fault and
                                              sending a fault message somewhere.

                                              Within the context of a request/response model, I think the right thing
                                              for an HTTP client that cannot accept/obey the SOAP message semantics is
                                              to fault the processing or to suggest that the message is saved for
                                              later processing by a more savvy processor. The latter is similar to
                                              what clients do when receiving a response with an unknown media type.

                                              It is important that a SOAP processor doesn't break the processing model
                                              and merely ignores the SOAP rules just because it may not be in a
                                              position where it can notify the sender about the fault.

                                              Henrik

                                              [1] http://www.w3.org/TR/SOAP/#_Toc478383491

                                              Doug Davis wrote:
                                              >
                                              >I see 3 choices:
                                              > 1 - ignore it
                                              > 2 - fault back to the server
                                              > 3 - fault back to the client
                                              >
                                              >While 2 is probably what "should" happen, I doubt many
                                              >will be able to support this. 1 seems most likely, but
                                              >scares me. 3 seems like a nice middle of the road solution.
                                              >8-)
                                              >
                                              >Paul Kulchenko wrote:
                                              >
                                              >Since it's possible to return Header from server to client
                                              >also, what should client do if this header has mustUnderstand
                                              >attribute or wrong actor?
                                            Your message has been successfully submitted and would be delivered to recipients shortly.