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

WASP SOAP12 results updated

Expand Messages
  • Tomas Bahnik
    Hi, I have updated Round 2 SOAP 12 results for WASP client. Main problems 1. Axis : content-type text/xml 2. gSOAP - missing rpc:result element as a wrapper
    Message 1 of 7 , Aug 29, 2002
    • 0 Attachment
      Hi,
      I have updated Round 2 SOAP 12 results for WASP client. Main problems

      1. Axis : content-type text/xml
      2. gSOAP - missing rpc:result element as a wrapper for return value, only
      group B echoStructAsSimpleTypes PASSED sinece the simpel types are defined
      in wsdl as out parameters

      Any feedback, comments or questions are highly appreciated

      [1] http://soap.systinet.net/interop/soap/base12.html
      [2] http://soap.systinet.net/interop/soap/groupb12.html
      [3] http://soap.systinet.net/interop/soap/groupc12.html

      Tomas Bahnik
      Systinet Corp
      www.systinet.com
    • Robert van Engelen
      Tomas, The responses are represented as an array, so the rpc:result is not required. - Robert
      Message 2 of 7 , Aug 29, 2002
      • 0 Attachment
        Tomas,

        The responses are represented as an array, so the rpc:result is not required.

        - Robert

        Tomas Bahnik wrote:
        >
        > Hi,
        > I have updated Round 2 SOAP 12 results for WASP client. Main problems
        >
        > 1. Axis : content-type text/xml
        > 2. gSOAP - missing rpc:result element as a wrapper for return value, only
        > group B echoStructAsSimpleTypes PASSED sinece the simpel types are defined
        > in wsdl as out parameters
        >
        > Any feedback, comments or questions are highly appreciated
        >
        > [1] http://soap.systinet.net/interop/soap/base12.html
        > [2] http://soap.systinet.net/interop/soap/groupb12.html
        > [3] http://soap.systinet.net/interop/soap/groupc12.html
        >
        > Tomas Bahnik
        > Systinet Corp
        > www.systinet.com
      • Robert van Engelen
        Bob, Thanks for setting that straight. ... Better: rpc:result is an ambiguous construct and SHOULD be removed from the spec. Some time ago, I mailed an
        Message 3 of 7 , Aug 29, 2002
        • 0 Attachment
          Bob,

          Thanks for setting that straight.

          > Another alternative, of which I suspect there are already examples,
          > is that toolkits will simply not support the "array" representation.

          Better: rpc:result is an ambiguous construct and SHOULD be removed from
          the spec. Some time ago, I mailed an explanation to the WG with a similar
          complaint as yours. When it comes down to an implementation, it creates
          too many (interop) problems. It reminds me of the 'root' attribute
          discussions. The 'root' attribute was eventually dropped.

          - Robert van Engelen
        • Bob Cunnings
          This is going to be a source of constant trouble. I was surprised to see the array type rpc response representation retained in SOAP 1.2. The WM receiver
          Message 4 of 7 , Aug 29, 2002
          • 0 Attachment
            This is going to be a source of constant trouble. I was surprised to
            see the "array" type rpc response representation retained in SOAP
            1.2.

            The WM receiver uses the following algorithm:

            -- if response contains the rpc:result element, process as struct
            style return with non-void return value.

            -- if response does not contain an rpc:result element, determine if
            the first accessor is *not* present in the "parameterOrder" list for
            the operation in the WSDL.

            ---- if this is the case, then process response as "array" type with
            non-void return value, as the return value accessor MUST not be
            present in the parameterOrder list per WSDL 1.1.

            ---- if this is not the case, then process response as having a void
            return value, and treat the first accessor as representing an "out"
            parameter.

            The weakness of this approach is that it relies on the presence of
            the "parameterOrder" list in the WSDL, which is an *optional*
            feature. If it's not present, and there is no other metadata available,
            you can't distinguish between the cases:

            - struct type response without rpc:result element, indicating a void
            response and some number of "out" parameters > 0.
            - array type response with a non-void return.

            during deserialization.

            So if a receiver wishes to support both types of rpc response
            styles, it would help if the metadata was present in the WSDL, as
            one of the terms of the contract. So I propose the following:

            In the next version of WSDL, how about adding an AII
            "rpcResponseFormat" to the soap:operation binding extension with
            values "struct" or "array". Alternatively, the "parameterOrder" AII
            could be made mandatory. Of course both of the options rely upon
            a distinction being drawn between bindings in terms of style="rpc"
            and style="document", and would only apply to style "rpc". This
            distinction exists in WSDL 1.1, but will it persist in the next
            version?

            Another alternative, of which I suspect there are already examples,
            is that toolkits will simply not support the "array" representation.

            If I'm missing something here, please set me straight! Maybe
            Jacek has some words of wisdom.

            RC

            >
            > Tomas,
            >
            > The responses are represented as an array, so the rpc:result is not required.
            >
            > - Robert
            >
            > Tomas Bahnik wrote:
            > >
            > > Hi,
            > > I have updated Round 2 SOAP 12 results for WASP client. Main problems
            > >
            > > 1. Axis : content-type text/xml
            > > 2. gSOAP - missing rpc:result element as a wrapper for return value, only
            > > group B echoStructAsSimpleTypes PASSED sinece the simpel types are defined
            > > in wsdl as out parameters
            > >
            > > Any feedback, comments or questions are highly appreciated
            > >
            > > [1] http://soap.systinet.net/interop/soap/base12.html
            > > [2] http://soap.systinet.net/interop/soap/groupb12.html
            > > [3] http://soap.systinet.net/interop/soap/groupc12.html
            > >
            > > Tomas Bahnik
            > > Systinet Corp
            > > www.systinet.com
            >
            >
            > -----------------------------------------------------------------
            > 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/
            >
          • Jacek Kopecky
            Hi all, 8-) maybe not words of wisdom, but I have some words: First a bit of history: Back last fall when the RPC task force of the XMLP WG was working on RPC
            Message 5 of 7 , Aug 29, 2002
            • 0 Attachment
              Hi all, 8-)
              maybe not words of wisdom, but I have some words:

              First a bit of history:
              Back last fall when the RPC task force of the XMLP WG was
              working on RPC issues, it was noted that it is not a proper
              struct if we talk about "the first accessor".
              A few suggestions came up, the first of them to name the
              accessor somehow. It was deemed insufficient to mandate only the
              local name, therefore we had a soap-rpc:result QName for a while
              (soap-rpc being any prefix for the SOAP RPC namespace).
              Then some people complained that this cannot be easily
              represented in WSDL because you cannot just go and define a
              schema for an element in a W3C namespace. A set of different
              ones, in fact. So, there goes the logical solution.
              Then two alternatives were proposed - get rid of the idea of a
              return value and just have out parameters (people complaining
              about interoperability of different naming conventions by
              different vendors, which I don't think would be a problem; will
              elaborate upon request) - or extend the return structure with an
              accessor typed QName which will point to the real return value.
              WSDL doesn't yet deal with this explicitly, but parameterOrder
              will do.
              And finally the idea that RPC should be representable with
              arrays for the sake of languages with unnamed parameters. This
              made it into the spec, the voices against were not strong enough,
              just of the opinion that this is unnecessary. Now WSDL doesn't
              deal with this explicitly either and I wonder how some toolkits
              do choose between arrays and structs - WASP doesn't produce nor
              consume arrays for RPC (unless by accident the XML is
              indistinguishable).
              Oh, I've also noticed the idea that RPC should be made a
              "generic". Being opposed to the existence of "generics", I cannot
              support this idea.

              Now for the current situation: there are a few last call issues
              regarding the RPC representation, these will have to be dealt
              with by the XMLP WG so it may yet happen that the RPC
              representation is simplified. If not, at least the XMLP WG will
              have to present rationales that will satisfy the issue reporters.
              The XMLP WG is eager to hear soapbuilders' opinions on these
              issues, the right email address is xmlp-comments@....

              To avoid confusion I have to say that I was in the RPC TF, I am
              in the XMLP WG; and I myself, on behalf of Systinet, raised two
              of the RPC last call issues.

              Jacek Kopecky

              Senior Architect, Systinet Corporation
              http://www.systinet.com/



              On Thu, 29 Aug 2002, Bob Cunnings wrote:

              > This is going to be a source of constant trouble. I was surprised to
              > see the "array" type rpc response representation retained in SOAP
              > 1.2.
              >
              > The WM receiver uses the following algorithm:
              >
              > -- if response contains the rpc:result element, process as struct
              > style return with non-void return value.
              >
              > -- if response does not contain an rpc:result element, determine if
              > the first accessor is *not* present in the "parameterOrder" list for
              > the operation in the WSDL.
              >
              > ---- if this is the case, then process response as "array" type with
              > non-void return value, as the return value accessor MUST not be
              > present in the parameterOrder list per WSDL 1.1.
              >
              > ---- if this is not the case, then process response as having a void
              > return value, and treat the first accessor as representing an "out"
              > parameter.
              >
              > The weakness of this approach is that it relies on the presence of
              > the "parameterOrder" list in the WSDL, which is an *optional*
              > feature. If it's not present, and there is no other metadata available,
              > you can't distinguish between the cases:
              >
              > - struct type response without rpc:result element, indicating a void
              > response and some number of "out" parameters > 0.
              > - array type response with a non-void return.
              >
              > during deserialization.
              >
              > So if a receiver wishes to support both types of rpc response
              > styles, it would help if the metadata was present in the WSDL, as
              > one of the terms of the contract. So I propose the following:
              >
              > In the next version of WSDL, how about adding an AII
              > "rpcResponseFormat" to the soap:operation binding extension with
              > values "struct" or "array". Alternatively, the "parameterOrder" AII
              > could be made mandatory. Of course both of the options rely upon
              > a distinction being drawn between bindings in terms of style="rpc"
              > and style="document", and would only apply to style "rpc". This
              > distinction exists in WSDL 1.1, but will it persist in the next
              > version?
              >
              > Another alternative, of which I suspect there are already examples,
              > is that toolkits will simply not support the "array" representation.
              >
              > If I'm missing something here, please set me straight! Maybe
              > Jacek has some words of wisdom.
              >
              > RC
              >
            • Robert van Engelen
              Jacek, Judging from your response the use of rpc:result appears to be fragile and based on the detection of struct or arrays. But are these always
              Message 6 of 7 , Aug 29, 2002
              • 0 Attachment
                Jacek,

                Judging from your response the use of rpc:result appears to be fragile and
                based on the detection of struct or arrays. But are these always
                distinghuishable? Also judging from your response below they might not be!

                > And finally the idea that RPC should be representable with
                > arrays for the sake of languages with unnamed parameters. This
                > made it into the spec, the voices against were not strong enough,
                > just of the opinion that this is unnecessary. Now WSDL doesn't
                > deal with this explicitly either and I wonder how some toolkits
                > do choose between arrays and structs - WASP doesn't produce nor
                > consume arrays for RPC (unless by accident the XML is
                > indistinguishable).

                FYI: WASP claims full SOAP 1.2 interop since June.

                > Oh, I've also noticed the idea that RPC should be made a
                > "generic". Being opposed to the existence of "generics", I cannot
                > support this idea.

                IMHO this SOAP 1.2 RPC design decision seems to be based on personal
                preference rather than technical issues. Struct, arrays, and generics
                are not mutually exclusive. At least one would like to support the
                notion of a variable parameter list (e.g. printf) which requires either
                an array or a generic. I agree that support of parameter arrays for
                languages with unnamed parameters is questionable. Arrays will do the job
                so do generics. Eliminating both kills yet another nicety of SOAP 1.1.

                - Robert van Engelen

                > To avoid confusion I have to say that I was in the RPC TF, I am
                > in the XMLP WG; and I myself, on behalf of Systinet, raised two
                > of the RPC last call issues.
                >
                > Jacek Kopecky
                >
                > Senior Architect, Systinet Corporation
                > http://www.systinet.com/
                >
                >
                >
                > On Thu, 29 Aug 2002, Bob Cunnings wrote:
                >
                > > This is going to be a source of constant trouble. I was surprised to
                > > see the "array" type rpc response representation retained in SOAP
                > > 1.2.
                > >
                > > The WM receiver uses the following algorithm:
                > >
                > > -- if response contains the rpc:result element, process as struct
                > > style return with non-void return value.
                > >
                > > -- if response does not contain an rpc:result element, determine if
                > > the first accessor is *not* present in the "parameterOrder" list for
                > > the operation in the WSDL.
                > >
                > > ---- if this is the case, then process response as "array" type with
                > > non-void return value, as the return value accessor MUST not be
                > > present in the parameterOrder list per WSDL 1.1.
                > >
                > > ---- if this is not the case, then process response as having a void
                > > return value, and treat the first accessor as representing an "out"
                > > parameter.
                > >
                > > The weakness of this approach is that it relies on the presence of
                > > the "parameterOrder" list in the WSDL, which is an *optional*
                > > feature. If it's not present, and there is no other metadata available,
                > > you can't distinguish between the cases:
                > >
                > > - struct type response without rpc:result element, indicating a void
                > > response and some number of "out" parameters > 0.
                > > - array type response with a non-void return.
                > >
                > > during deserialization.
                > >
                > > So if a receiver wishes to support both types of rpc response
                > > styles, it would help if the metadata was present in the WSDL, as
                > > one of the terms of the contract. So I propose the following:
                > >
                > > In the next version of WSDL, how about adding an AII
                > > "rpcResponseFormat" to the soap:operation binding extension with
                > > values "struct" or "array". Alternatively, the "parameterOrder" AII
                > > could be made mandatory. Of course both of the options rely upon
                > > a distinction being drawn between bindings in terms of style="rpc"
                > > and style="document", and would only apply to style "rpc". This
                > > distinction exists in WSDL 1.1, but will it persist in the next
                > > version?
                > >
                > > Another alternative, of which I suspect there are already examples,
                > > is that toolkits will simply not support the "array" representation.
                > >
                > > If I'm missing something here, please set me straight! Maybe
                > > Jacek has some words of wisdom.
                > >
                > > RC
                > >
              • Jacek Kopecky
                Robert, others, please see below. I apologize about not responding earlier, but I was too busy. Jacek Kopecky Senior Architect, Systinet Corporation
                Message 7 of 7 , Sep 4, 2002
                • 0 Attachment
                  Robert, others, please see below.
                  I apologize about not responding earlier, but I was too busy.

                  Jacek Kopecky

                  Senior Architect, Systinet Corporation
                  http://www.systinet.com/


                  On Thu, 2002-08-29 at 21:21, Robert van Engelen wrote:
                  > Jacek,
                  >
                  > Judging from your response the use of rpc:result appears to be fragile and
                  > based on the detection of struct or arrays. But are these always
                  > distinghuishable? Also judging from your response below they might not be!

                  Correct - I think it was expected that the information whether it's
                  arrays or structs should be inside the contract (IOW in the WSDL
                  description of a service). Alas, current WSDL doesn't provide such
                  information (and cannot, predating the SOAP 1.2 LC drafts), that's why
                  we didn't implement the array representation of RPC - we would never use
                  it anyway because WSDL never says RPC is represented as an array. 8-)

                  > > And finally the idea that RPC should be representable with
                  > > arrays for the sake of languages with unnamed parameters. This
                  > > made it into the spec, the voices against were not strong enough,
                  > > just of the opinion that this is unnecessary. Now WSDL doesn't
                  > > deal with this explicitly either and I wonder how some toolkits
                  > > do choose between arrays and structs - WASP doesn't produce nor
                  > > consume arrays for RPC (unless by accident the XML is
                  > > indistinguishable).
                  >
                  > FYI: WASP claims full SOAP 1.2 interop since June.

                  This is a case of internal miscommunication - the PR guys thought we did
                  implement SOAP 1.2 fully and wrote so in the press release - while in
                  fact WASP doesn't implement some features that we either see as
                  unnecessary (like RPC as arrays, encoding generics, upgrade faults) or
                  we lack the necessary support from WSDL (RPC as arrays, HTTP GET etc.)

                  After SOAP 1.2 becomes a Rec and when WSDL provides the necessary
                  support (at least on the level of soapbuilders informal agreement),
                  we'll strive to have a full implementation, of course. We're working on
                  correcting the announcements.

                  > > Oh, I've also noticed the idea that RPC should be made a
                  > > "generic". Being opposed to the existence of "generics", I cannot
                  > > support this idea.
                  >
                  > IMHO this SOAP 1.2 RPC design decision seems to be based on personal
                  > preference rather than technical issues. Struct, arrays, and generics
                  > are not mutually exclusive. At least one would like to support the
                  > notion of a variable parameter list (e.g. printf) which requires either
                  > an array or a generic. I agree that support of parameter arrays for
                  > languages with unnamed parameters is questionable. Arrays will do the job
                  > so do generics. Eliminating both kills yet another nicety of SOAP 1.1.

                  I don't like generics because I don't see any real need for such a
                  structure in a data model aimed for RPC, and also because handling
                  generics is not clear. As I wrote many times before, I thing generics
                  can be translated very simply into arrays of structs or structs
                  containing arrays, depending on whether member names or their positions
                  are used first. One argument against this is the case where the sender
                  and receiver don't treat the structure the same way - I have yet to see
                  how this would be useful.

                  And regarding variable parameter lists: in all languages I know variable
                  parameters are handled as an array of "the rest of parameters", no
                  matter whether the known parameters are named or ordered. Therefore the
                  struct representation of RPC could have one array parameter containing
                  the "rest of the parameters". So even if we remove generics and the
                  array representation of RPC, variable parameter lists will still be
                  doable.

                  I think most of the push for generics comes from the fact that in some
                  cases a "nicer" XML can be produced. But in my opinion the downside is
                  the more complex handling of generics in receivers and senders. When
                  choosing between a nicer XML and a nicer SOAP implementations, I'll
                  choose the latter anytime. Is there anyone who still thinks SOAP is for
                  human production/consumption? 8-)

                  Jacek



                  >
                  > - Robert van Engelen
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.