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

7250RE: [soapbuilders] rpc/literal and wrapped doc-lit

Expand Messages
  • Alex DeJarnatt
    Mar 1, 2002
    • 0 Attachment

      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.
    • Show all 7 messages in this topic