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

rpc/literal and wrapped doc-lit

Expand Messages
  • wes_moulder
    So, on the plane trip back home, I started wondering about two great mysteries that came up at the soapbuilders conference. As the title suggests, this is
    Message 1 of 7 , Feb 28, 2002
      So, on the plane trip back home, I started wondering about two great
      mysteries that came up at the soapbuilders conference. As the title
      suggests, this is about rpc/literal and wrapped doc-lit. Since we've
      got an unknown style/use combination, why are we overloading doc/lit
      to support the idea of a method call with the wrapped/bare semantics?
      My understanding of rpc is that it's supposed to declare that the
      message in the body is in fact a method call. Since this is what
      wrapped does as well, why not merge the ideas there, and declare that
      our interpretation of rpc/literal is indeed wrapped doc/lit?
      Is there any technical reason that this should not be done? (I should
      probably go read the spec to see, but I just got home, and I'm
      exhausted. I'll do it in the morning if there are no replies.)

      Going forward into SOAP 1.2, is it possible to suggest to the SOAP
      working group that this should be the mapping of that combination (if
      they don't just do away with the literal vs encoding semantics)? The
      whole idea here is to eliminate the "parameters" hack to figuring out
      which version of doc/lit you're using.

      --Wes
    • Alex DeJarnatt
      I don t think it s necessary to agree on a mechanism for representing a method call in terms of schema. I think each endpoint should be free to define this
      Message 2 of 7 , Mar 1, 2002
        I don't think it's necessary to agree on a mechanism for representing a
        method call in terms of schema. I think each endpoint should be free to
        define this mapping as it wishes (and if it wishes). Endpoints won't all
        always be able to agree about whether a given message exchange was a
        "method call" or just moving xml documents back and forth, but they'll
        still all be able to interop all the time.

        Just to clarify what ASP.NET web services does with its "wrapped"
        mode... We provide our customers with a method-based programming model
        (a web service is a collection of web methods). By default, we might
        represent the response from a HelloWorld method in schema as follows:
        <element name="HelloWorldResponse">
        <complexType>
        <sequence>
        <element name="result" type="string"/>
        </sequence>
        </complexType>
        </element>

        However, the customer has the option to completely customize this so
        that the same method response might be represented as follows:
        <element name="HelloWorldResponse">
        <complexType>
        <attribute name="result" type="string"/>
        </complexType>
        </element>

        So maybe HelloWorld wasn't such a great example but hopefully you get
        the point... We don't have a single schema representation for the notion
        of a method call. The mapping between the method description and the
        schema is completely flexible and completely up to the customer.

        I think you're getting at a pretty fundamental question for literal
        interop: is it important that your customer see the same programming
        model as mine does when they interop using our tools? (By programming
        model, I mean method calls vs. document passing, typed objects vs.
        untyped objects vs. xml dom vs. whatever else, parameter order, out
        param vs. return value, etc...). If we think it is important, then I
        guess we should all agree on what a method call looks like in WSDL (and
        call it rpc/literal).

        I believe the choice of programming model on either side of the wire
        should have no bearing on literal interop, so I don't see any reason to
        define an rpc/literal mode.

        alex



        -----Original Message-----
        From: wes_moulder [mailto:wes@...]
        Sent: Thursday, February 28, 2002 10:02 PM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] rpc/literal and wrapped doc-lit

        So, on the plane trip back home, I started wondering about two great
        mysteries that came up at the soapbuilders conference. As the title
        suggests, this is about rpc/literal and wrapped doc-lit. Since we've
        got an unknown style/use combination, why are we overloading doc/lit
        to support the idea of a method call with the wrapped/bare semantics?
        My understanding of rpc is that it's supposed to declare that the
        message in the body is in fact a method call. Since this is what
        wrapped does as well, why not merge the ideas there, and declare that
        our interpretation of rpc/literal is indeed wrapped doc/lit?
        Is there any technical reason that this should not be done? (I should
        probably go read the spec to see, but I just got home, and I'm
        exhausted. I'll do it in the morning if there are no replies.)

        Going forward into SOAP 1.2, is it possible to suggest to the SOAP
        working group that this should be the mapping of that combination (if
        they don't just do away with the literal vs encoding semantics)? The
        whole idea here is to eliminate the "parameters" hack to figuring out
        which version of doc/lit you're using.

        --Wes



        -----------------------------------------------------------------
        This group is a forum for builders of SOAP implementations to discuss
        implementation and interoperability issues. Please stay on-topic.

        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/
      • Daniel Kulp
        Speaking for myself (not for IONA for this message. I don t think IONA has an official position on this yet), I have to agree 100%. I REALLY like rpc/literal
        Message 3 of 7 , Mar 1, 2002
          Speaking for myself (not for IONA for this message. I don't think IONA
          has an official position on this yet), I have to agree 100%. I REALLY
          like rpc/literal as a transport for RPC style messaging. It really is
          the best of all worlds in my opinion. Think about it:

          1) The operation name is always part of the soap message. Also, since
          this is literal (no hrefs), the only element in the body is the RPC
          wrapper element. This makes it very easy to dispatch on no matter what
          style parser you use (streaming, sax, dom, etc...) Deterimining the
          operation to call on the server side is trivial. Also, things like
          "echoVoid" can be done easily.

          2) The parameter descriptions are "literal", thus bound by the schema
          descriptions, not the abiguous and sometimes confusing section 5
          encoding.

          3) Since each parameter is placed in the message in the WSDL
          individually, you can do SOAP w/ attachments with RPC/literal. You
          cannot do so with the wrapped doc/literal as there is only 1 part in the
          message, the wrapper element. I don't know how DIME handles this so I
          cannot comment on it, but the MIME extension for WSDL only really allow
          attachments of message parts. If you only have 1 part that is the
          wrapper part, no-attachements are possible.

          4) Since the rpc wrapper element is namespace qualified, the individual
          part elements don't need to be. Since elements directly in the soap:body
          must be ns qualified, with doc/lit you have to qualify them even if their
          schema has them unqualified.

          Anyway, I really like rpc/literal. XMLBus does currently support it
          (both client and server) and I would like to see it more widely used.

          Enjoy!

          --
          J. Daniel Kulp
          Principal Engineer
          IONA
          END 2 ANYWHERE
          P: 781-902-8727 C: 617-513-4582 F:781-902-8001
          daniel.kulp@...

          On Friday 01 March 2002 01:01, wes_moulder wrote:
          > So, on the plane trip back home, I started wondering about two great
          > mysteries that came up at the soapbuilders conference. As the title
          > suggests, this is about rpc/literal and wrapped doc-lit. Since we've
          > got an unknown style/use combination, why are we overloading doc/lit
          > to support the idea of a method call with the wrapped/bare semantics?
          > My understanding of rpc is that it's supposed to declare that the
          > message in the body is in fact a method call. Since this is what
          > wrapped does as well, why not merge the ideas there, and declare that
          > our interpretation of rpc/literal is indeed wrapped doc/lit?
          > Is there any technical reason that this should not be done? (I should
          > probably go read the spec to see, but I just got home, and I'm
          > exhausted. I'll do it in the morning if there are no replies.)
          >
          > Going forward into SOAP 1.2, is it possible to suggest to the SOAP
          > working group that this should be the mapping of that combination (if
          > they don't just do away with the literal vs encoding semantics)? The
          > whole idea here is to eliminate the "parameters" hack to figuring out
          > which version of doc/lit you're using.
        • Wes Moulder
          My question wasn t meant as a let s discuss what the schema should look like , I meant it as a question to foster the idea that perhaps these two problems
          Message 4 of 7 , Mar 1, 2002

            My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

            I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

            I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

             

            --Wes

             

            -----Original Message-----
            From: Alex DeJarnatt [mailto:alexdej@...]
            Sent: Friday, March 01, 2002 2:49 AM
            To: soapbuilders@yahoogroups.com
            Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

             

            I don't think it's necessary to agree on a mechanism for representing a
            method call in terms of schema. I think each endpoint should be free to
            define this mapping as it wishes (and if it wishes). Endpoints won't all
            always be able to agree about whether a given message exchange was a
            "method call" or just moving xml documents back and forth, but they'll
            still all be able to interop all the time.

            Just to clarify what ASP.NET web services does with its "wrapped"
            mode... We provide our customers with a method-based programming model
            (a web service is a collection of web methods). By default, we might
            represent the response from a HelloWorld method in schema as follows:
            <element name="HelloWorldResponse">
            <complexType>
              <sequence>
               <element name="result" type="string"/>
              </sequence>
            </complexType>
            </element>

            However, the customer has the option to completely customize this so
            that the same method response might be represented as follows:
            <element name="HelloWorldResponse">
            <complexType>
              <attribute name="result" type="string"/>
            </complexType>
            </element>

            So maybe HelloWorld wasn't such a great example but hopefully you get
            the point... We don't have a single schema representation for the notion
            of a method call. The mapping between the method description and the
            schema is completely flexible and completely up to the customer.

            I think you're getting at a pretty fundamental question for literal
            interop: is it important that your customer see the same programming
            model as mine does when they interop using our tools? (By programming
            model, I mean method calls vs. document passing, typed objects vs.
            untyped objects vs. xml dom vs. whatever else, parameter order, out
            param vs. return value, etc...). If we think it is important, then I
            guess we should all agree on what a method call looks like in WSDL (and
            call it rpc/literal).

            I believe the choice of programming model on either side of the wire
            should have no bearing on literal interop, so I don't see any reason to
            define an rpc/literal mode.

            alex



            -----Original Message-----
            From: wes_moulder [mailto:wes@...]
            Sent: Thursday, February 28, 2002 10:02 PM
            To: soapbuilders@yahoogroups.com
            Subject: [soapbuilders] rpc/literal and wrapped doc-lit

            So, on the plane trip back home, I started wondering about two great
            mysteries that came up at the soapbuilders conference.  As the title
            suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
            got an unknown style/use combination, why are we overloading doc/lit
            to support the idea of a method call with the wrapped/bare semantics?
            My understanding of rpc is that it's supposed to declare that the
            message in the body is in fact a method call.  Since this is what
            wrapped does as well, why not merge the ideas there, and declare that
            our interpretation of rpc/literal is indeed wrapped doc/lit?
            Is there any technical reason that this should not be done?  (I should
            probably go read the spec to see, but I just got home, and I'm
            exhausted.  I'll do it in the morning if there are no replies.)

            Going forward into SOAP 1.2, is it possible to suggest to the SOAP
            working group that this should be the mapping of that combination (if
            they don't just do away with the literal vs encoding semantics)?  The
            whole idea here is to eliminate the "parameters" hack to figuring out
            which version of doc/lit you're using.

            --Wes



            -----------------------------------------------------------------
            This group is a forum for builders of SOAP implementations to discuss
            implementation and interoperability issues.  Please stay on-topic.

            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/




            -----------------------------------------------------------------
            This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

            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.
          • Alex DeJarnatt
            WSDL is more explicit about representing the parameters as elements (I ve quoted the relevant parts of section 3.5 below). I don t understand your comment we
            Message 5 of 7 , Mar 1, 2002

              WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

               

              I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

               

              I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

              thanks

              alex

               

               

              From section 3.5:

               

              If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

               

              And also:

              If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

               

               

               

              -----Original Message-----
              From: Wes Moulder [mailto:wes@...]
              Sent:
              Friday, March 01, 2002 10:29 AM
              To: soapbuilders@yahoogroups.com
              Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

               

              My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

              I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

              I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

               

              --Wes

               

              -----Original Message-----
              From: Alex DeJarnatt [mailto:alexdej@...]
              Sent: Friday, March 01, 2002 2:49 AM
              To: soapbuilders@yahoogroups.com
              Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

               

              I don't think it's necessary to agree on a mechanism for representing a
              method call in terms of schema. I think each endpoint should be free to
              define this mapping as it wishes (and if it wishes). Endpoints won't all
              always be able to agree about whether a given message exchange was a
              "method call" or just moving xml documents back and forth, but they'll
              still all be able to interop all the time.

              Just to clarify what ASP.NET web services does with its "wrapped"
              mode... We provide our customers with a method-based programming model
              (a web service is a collection of web methods). By default, we might
              represent the response from a HelloWorld method in schema as follows:
              <element name="HelloWorldResponse">
              <complexType>
                <sequence>
                 <element name="result" type="string"/>
                </sequence>
              </complexType>
              </element>

              However, the customer has the option to completely customize this so
              that the same method response might be represented as follows:
              <element name="HelloWorldResponse">
              <complexType>
                <attribute name="result" type="string"/>
              </complexType>
              </element>

              So maybe HelloWorld wasn't such a great example but hopefully you get
              the point... We don't have a single schema representation for the notion
              of a method call. The mapping between the method description and the
              schema is completely flexible and completely up to the customer.

              I think you're getting at a pretty fundamental question for literal
              interop: is it important that your customer see the same programming
              model as mine does when they interop using our tools? (By programming
              model, I mean method calls vs. document passing, typed objects vs.
              untyped objects vs. xml dom vs. whatever else, parameter order, out
              param vs. return value, etc...). If we think it is important, then I
              guess we should all agree on what a method call looks like in WSDL (and
              call it rpc/literal).

              I believe the choice of programming model on either side of the wire
              should have no bearing on literal interop, so I don't see any reason to
              define an rpc/literal mode.

              alex



              -----Original Message-----
              From: wes_moulder [mailto:wes@...]
              Sent: Thursday, February 28, 2002 10:02 PM
              To: soapbuilders@yahoogroups.com
              Subject: [soapbuilders] rpc/literal and wrapped doc-lit

              So, on the plane trip back home, I started wondering about two great
              mysteries that came up at the soapbuilders conference.  As the title
              suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
              got an unknown style/use combination, why are we overloading doc/lit
              to support the idea of a method call with the wrapped/bare semantics?
              My understanding of rpc is that it's supposed to declare that the
              message in the body is in fact a method call.  Since this is what
              wrapped does as well, why not merge the ideas there, and declare that
              our interpretation of rpc/literal is indeed wrapped doc/lit?
              Is there any technical reason that this should not be done?  (I should
              probably go read the spec to see, but I just got home, and I'm
              exhausted.  I'll do it in the morning if there are no replies.)

              Going forward into SOAP 1.2, is it possible to suggest to the SOAP
              working group that this should be the mapping of that combination (if
              they don't just do away with the literal vs encoding semantics)?  The
              whole idea here is to eliminate the "parameters" hack to figuring out
              which version of doc/lit you're using.

              --Wes



              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss
              implementation and interoperability issues.  Please stay on-topic.

              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/




              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

              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.



              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

              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.
            • Wes Moulder
              Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name? While it may not fit
              Message 6 of 7 , Mar 1, 2002

                Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name?  While it may not fit SOAP 1.1, as it seems that 1.1 is too restrictive, it would be nice to separate the concepts explicitly.  It feels like an overloading for doc/lit to me.  (Sending a bare message, you derive the information for dispatching from SOAPAction, or url, or some outside source.  Sending a wrapped message, you derive the information from the root element of the document being sent.  The only way to distinguish between the two types of doc/lit is to look at the name attribute of the message parts, by my understanding. (If I’m wrong here, please correct me, as it will make my life easier.))

                Ideally, the rpc/lit would be wholly driven by schema, with the schema driving the names of the arguments, and their respective locations.  Thus, wrapped mode would stay the same in terms of schema definition, and only the style on the bindings would change to rpc.

                As far as sounding pissy, don’t worry.  It is email, and very hard to express emotions via text.  I hope I don’t sound too argumentative, I am trying to simplify things, and I will admit, I was not quite aware of the explicitness of representing parameters as elements.

                Thanks for helping me clarify this,

                --Wes

                 

                -----Original Message-----
                From: Alex DeJarnatt [mailto:alexdej@...]
                Sent: Friday, March 01, 2002 1:26 PM
                To: soapbuilders@yahoogroups.com
                Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                 

                WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

                 

                I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

                 

                I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

                thanks

                alex

                 

                 

                From section 3.5:

                 

                If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

                 

                And also:

                If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

                 

                 

                 

                -----Original Message-----
                From: Wes Moulder [mailto:wes@...]
                Sent: Friday, March 01, 2002 10:29 AM
                To: soapbuilders@yahoogroups.com
                Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                 

                My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

                I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

                I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

                 

                --Wes

                 

                -----Original Message-----
                From: Alex DeJarnatt [mailto:alexdej@...]
                Sent: Friday, March 01, 2002 2:49 AM
                To: soapbuilders@yahoogroups.com
                Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                 

                I don't think it's necessary to agree on a mechanism for representing a
                method call in terms of schema. I think each endpoint should be free to
                define this mapping as it wishes (and if it wishes). Endpoints won't all
                always be able to agree about whether a given message exchange was a
                "method call" or just moving xml documents back and forth, but they'll
                still all be able to interop all the time.

                Just to clarify what ASP.NET web services does with its "wrapped"
                mode... We provide our customers with a method-based programming model
                (a web service is a collection of web methods). By default, we might
                represent the response from a HelloWorld method in schema as follows:
                <element name="HelloWorldResponse">
                <complexType>
                  <sequence>
                   <element name="result" type="string"/>
                  </sequence>
                </complexType>
                </element>

                However, the customer has the option to completely customize this so
                that the same method response might be represented as follows:
                <element name="HelloWorldResponse">
                <complexType>
                  <attribute name="result" type="string"/>
                </complexType>
                </element>

                So maybe HelloWorld wasn't such a great example but hopefully you get
                the point... We don't have a single schema representation for the notion
                of a method call. The mapping between the method description and the
                schema is completely flexible and completely up to the customer.

                I think you're getting at a pretty fundamental question for literal
                interop: is it important that your customer see the same programming
                model as mine does when they interop using our tools? (By programming
                model, I mean method calls vs. document passing, typed objects vs.
                untyped objects vs. xml dom vs. whatever else, parameter order, out
                param vs. return value, etc...). If we think it is important, then I
                guess we should all agree on what a method call looks like in WSDL (and
                call it rpc/literal).

                I believe the choice of programming model on either side of the wire
                should have no bearing on literal interop, so I don't see any reason to
                define an rpc/literal mode.

                alex



                -----Original Message-----
                From: wes_moulder [mailto:wes@...]
                Sent: Thursday, February 28, 2002 10:02 PM
                To: soapbuilders@yahoogroups.com
                Subject: [soapbuilders] rpc/literal and wrapped doc-lit

                So, on the plane trip back home, I started wondering about two great
                mysteries that came up at the soapbuilders conference.  As the title
                suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
                got an unknown style/use combination, why are we overloading doc/lit
                to support the idea of a method call with the wrapped/bare semantics?
                My understanding of rpc is that it's supposed to declare that the
                message in the body is in fact a method call.  Since this is what
                wrapped does as well, why not merge the ideas there, and declare that
                our interpretation of rpc/literal is indeed wrapped doc/lit?
                Is there any technical reason that this should not be done?  (I should
                probably go read the spec to see, but I just got home, and I'm
                exhausted.  I'll do it in the morning if there are no replies.)

                Going forward into SOAP 1.2, is it possible to suggest to the SOAP
                working group that this should be the mapping of that combination (if
                they don't just do away with the literal vs encoding semantics)?  The
                whole idea here is to eliminate the "parameters" hack to figuring out
                which version of doc/lit you're using.

                --Wes



                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss
                implementation and interoperability issues.  Please stay on-topic.

                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/



                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                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.

                 

                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                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.



                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                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.
              • Alex DeJarnatt
                I agree that what we call doc/lit/wrapped models the input and output of a method as schema, though way more flexibly than is allowed by wsdl for rpc/literal.
                Message 7 of 7 , Mar 1, 2002

                  I agree that what we call doc/lit/wrapped models the input and output of a method as schema, though way more flexibly than is allowed by wsdl for rpc/literal.  However, I do not agree that wrapped is an rpc call, since this implies that both sides of the wire agree that a method is being called.  With our wrapped, the asp.net side can treat the message exchange as a method call and the other side can treat it as anything it wants. 

                   

                  About the routing, I don’t see that the service has to route doc/lit messages differently based on whether they’re “wrapped” or “bare” (at least we don’t).  However, it is necessary to have enough information to do the routing by operation for a given service. If you don’t have enough information in the body of the message (for instance two messages have identical schema), you’d need to rely on some external information such as soap action or a header.  In asp.net web services we can route by soap action or by the qname of the first child of body. The meaning of this name to the service might vary by bare vs. wrapped but how we route doesn’t. 

                   

                  Hope this helps..

                  alex

                   

                  -----Original Message-----
                  From: Wes Moulder [mailto:wes@...]
                  Sent:
                  Friday, March 01, 2002 12:23 PM
                  To: soapbuilders@yahoogroups.com
                  Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                   

                  Would you agree with me that wrapped is essentially an rpc call, where the name of the root of the document fragment is the method name?  While it may not fit SOAP 1.1, as it seems that 1.1 is too restrictive, it would be nice to separate the concepts explicitly.  It feels like an overloading for doc/lit to me.  (Sending a bare message, you derive the information for dispatching from SOAPAction, or url, or some outside source.  Sending a wrapped message, you derive the information from the root element of the document being sent.  The only way to distinguish between the two types of doc/lit is to look at the name attribute of the message parts, by my understanding. (If I’m wrong here, please correct me, as it will make my life easier.))

                  Ideally, the rpc/lit would be wholly driven by schema, with the schema driving the names of the arguments, and their respective locations.  Thus, wrapped mode would stay the same in terms of schema definition, and only the style on the bindings would change to rpc.

                  As far as sounding pissy, don’t worry.  It is email, and very hard to express emotions via text.  I hope I don’t sound too argumentative, I am trying to simplify things, and I will admit, I was not quite aware of the explicitness of representing parameters as elements.

                  Thanks for helping me clarify this,

                  --Wes

                   

                  -----Original Message-----
                  From: Alex DeJarnatt [mailto:alexdej@...]
                  Sent:
                  Friday, March 01, 2002 1:26 PM
                  To: soapbuilders@yahoogroups.com
                  Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                   

                  WSDL is more explicit about representing the parameters as elements (I’ve quoted the relevant parts of section 3.5 below). 

                   

                  I don’t understand your comment “we have this dual use of doc/lit for bare and wrapped”.  Bare *is* doc/lit (multiple message parts described by schema) and wrapped is a subset of that (single message part described by schema).  If you understand doc/lit, you can deal with either fine without ever having heard the terms “bare” and “wrapped”.  With rpc/lit we would need to understand a non-schema-based mechanism for formatting a method call as xml (as described by the parts of the WSDL spec I quoted below).  I don’t see how this would help interop or solve any problems.

                   

                  I hope that didn’t sound pissy.  ;)  This is an interesting discussion…

                  thanks

                  alex

                   

                   

                  From section 3.5:

                   

                  If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

                   

                  And also:

                  If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1.  The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

                   

                   

                   

                  -----Original Message-----
                  From: Wes Moulder [mailto:wes@...]
                  Sent:
                  Friday, March 01, 2002 10:29 AM
                  To: soapbuilders@yahoogroups.com
                  Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                   

                  My question wasn’t meant as a “let’s discuss what the schema should look like”, I meant it as a question to foster the idea that perhaps these two problems should be thought about together.  Basically, as I said before, I see two problems here.  We have this unknown, what does “RPC/literal” mean, and we have this dual use of doc/lit for bare and wrapped.  From what I can tell, wrapped matches rpc/literal in spirit, if not in specification.

                  I gather from section 7.1 that an rpc call must have the parameters to the method call defined by an “accessor”, but my scan through the soap spec didn’t tell me what an “accessor” was, just that it be related by name to one of the method’s parameters.  If I make a great leap of intuition and say that an accessor is explicitly an element, then I see your argument, that you’re already doing more than what RPC in soap defines.  If I make an equally valid assumption that an accessor is just a schema entry, it could be either an attribute or an element.

                  I understand about wanting to reduce the complexity, and not define rpc/literal, as a semantic, but since it already exists as a possibility, and there’s already this rpc style semantic being used in doc/lit, I find it valuable to be able to disambiguate passing a document versus making an rpc call in literal encoding.

                   

                  --Wes

                   

                  -----Original Message-----
                  From: Alex DeJarnatt [mailto:alexdej@...]
                  Sent:
                  Friday, March 01, 2002 2:49 AM
                  To: soapbuilders@yahoogroups.com
                  Subject: RE: [soapbuilders] rpc/literal and wrapped doc-lit

                   

                  I don't think it's necessary to agree on a mechanism for representing a
                  method call in terms of schema. I think each endpoint should be free to
                  define this mapping as it wishes (and if it wishes). Endpoints won't all
                  always be able to agree about whether a given message exchange was a
                  "method call" or just moving xml documents back and forth, but they'll
                  still all be able to interop all the time.

                  Just to clarify what ASP.NET web services does with its "wrapped"
                  mode... We provide our customers with a method-based programming model
                  (a web service is a collection of web methods). By default, we might
                  represent the response from a HelloWorld method in schema as follows:
                  <element name="HelloWorldResponse">
                  <complexType>
                    <sequence>
                     <element name="result" type="string"/>
                    </sequence>
                  </complexType>
                  </element>

                  However, the customer has the option to completely customize this so
                  that the same method response might be represented as follows:
                  <element name="HelloWorldResponse">
                  <complexType>
                    <attribute name="result" type="string"/>
                  </complexType>
                  </element>

                  So maybe HelloWorld wasn't such a great example but hopefully you get
                  the point... We don't have a single schema representation for the notion
                  of a method call. The mapping between the method description and the
                  schema is completely flexible and completely up to the customer.

                  I think you're getting at a pretty fundamental question for literal
                  interop: is it important that your customer see the same programming
                  model as mine does when they interop using our tools? (By programming
                  model, I mean method calls vs. document passing, typed objects vs.
                  untyped objects vs. xml dom vs. whatever else, parameter order, out
                  param vs. return value, etc...). If we think it is important, then I
                  guess we should all agree on what a method call looks like in WSDL (and
                  call it rpc/literal).

                  I believe the choice of programming model on either side of the wire
                  should have no bearing on literal interop, so I don't see any reason to
                  define an rpc/literal mode.

                  alex



                  -----Original Message-----
                  From: wes_moulder [mailto:wes@...]
                  Sent:
                  Thursday, February 28, 2002 10:02 PM
                  To: soapbuilders@yahoogroups.com
                  Subject: [soapbuilders] rpc/literal and wrapped doc-lit

                  So, on the plane trip back home, I started wondering about two great
                  mysteries that came up at the soapbuilders conference.  As the title
                  suggests, this is about rpc/literal and wrapped doc-lit.  Since we've
                  got an unknown style/use combination, why are we overloading doc/lit
                  to support the idea of a method call with the wrapped/bare semantics?
                  My understanding of rpc is that it's supposed to declare that the
                  message in the body is in fact a method call.  Since this is what
                  wrapped does as well, why not merge the ideas there, and declare that
                  our interpretation of rpc/literal is indeed wrapped doc/lit?
                  Is there any technical reason that this should not be done?  (I should
                  probably go read the spec to see, but I just got home, and I'm
                  exhausted.  I'll do it in the morning if there are no replies.)

                  Going forward into SOAP 1.2, is it possible to suggest to the SOAP
                  working group that this should be the mapping of that combination (if
                  they don't just do away with the literal vs encoding semantics)?  The
                  whole idea here is to eliminate the "parameters" hack to figuring out
                  which version of doc/lit you're using.

                  --Wes



                  -----------------------------------------------------------------
                  This group is a forum for builders of SOAP implementations to discuss
                  implementation and interoperability issues.  Please stay on-topic.

                  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/



                  -----------------------------------------------------------------
                  This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                  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.

                   

                  -----------------------------------------------------------------
                  This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                  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.



                  -----------------------------------------------------------------
                  This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                  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.



                  -----------------------------------------------------------------
                  This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

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



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