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

Additional SOAP 1.2 tests redux

Expand Messages
  • Bob Cunnings
    Hello, The White Mesa SOAP 1.2 endpoint now supports the tests defined at: http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html#addtests with the
    Message 1 of 6 , Jan 1, 2003
    • 0 Attachment
      Hello,

      The White Mesa SOAP 1.2 endpoint now supports the tests defined at:

      http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html#addtests

      with the exception of tests:

      xmlp-7 (echoSenderFault), xmlp-8 (echoReceiverFault):

      SOAP messages representing RPCs result in the invocation of a native
      procedure in its normal runtime environment, outside the world of the SOAP
      processor. It is impossible for such a procedure to cause the generation of
      a SOAP fault other than indirectly. So at least in this implementation,
      these tests can't be supported. It's a different situation for doc/literal
      operations, it would be no problem, as an XML processing app has access to
      the SOAP environment at runtime and can generate any specific SOAP fault it
      wishes to. I hope this makes sense. I wonder if any other implementations
      would have similar problems.

      xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)

      This is similar to the situation above. This is an RPC operation, and the
      native procedure runs outside the SOAP environment, yet the test requires
      that the procedure have access to infoset stuff (types) from the original
      XML representation of the RPC. Of course the procedure is called with the
      parameter data, but it has already been deserialized to native types and XS
      type info is out of reach. Again, if it was a doc/literal operation, no
      problem.

      The usual simple test clients for these additional tests have been added to
      the index at:

      http://www.whitemesa.net/test-soap12/soap12-test-index.htm

      which also has links to the WSDL docs.

      The intermediary tests were made easy by adding a new "pivot" point in the
      message flow, that can be enabled as a diagnostic option for a given service
      URI. This simply shunts the post-processing message instance that is
      normally forwarded to the next node onto the HTTP response stream back to
      the original sender. It isn't possible, at least in this implementation, to
      make this happen in a clean way from the application level. I wonder about
      others.

      RC
    • Henrik Frystyk Nielsen
      Bob, I don t think there is any reason why xmlp-7, 8, and 10 should use RPC convention instead of doc/lit, especially as the former seems to be covered by 60.1
      Message 2 of 6 , Jan 2, 2003
      • 0 Attachment
        Bob,

        I don't think there is any reason why xmlp-7, 8, and 10 should use RPC
        convention instead of doc/lit, especially as the former seems to be
        covered by 60.1 and 60.2 although I suspect that these may cause
        problems as well? If so, could these test cases be handled by having two
        WSDL documents that forced the fault to occur?

        Thanks for the feedback,

        Henrik Frystyk Nielsen
        mailto:henrikn@...

        * * * * *

        xmlp-7 (echoSenderFault), xmlp-8 (echoReceiverFault):

        SOAP messages representing RPCs result in the invocation of a native
        procedure in its normal runtime environment, outside the world of the
        SOAP processor. It is impossible for such a procedure to cause the
        generation of a SOAP fault other than indirectly. So at least in this
        implementation, these tests can't be supported. It's a different
        situation for doc/literal operations, it would be no problem, as an XML
        processing app has access to the SOAP environment at runtime and can
        generate any specific SOAP fault it wishes to. I hope this makes sense.
        I wonder if any other implementations would have similar problems.

        xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)

        This is similar to the situation above. This is an RPC operation, and
        the native procedure runs outside the SOAP environment, yet the test
        requires that the procedure have access to infoset stuff (types) from
        the original XML representation of the RPC. Of course the procedure is
        called with the parameter data, but it has already been deserialized to
        native types and XS type info is out of reach. Again, if it was a
        doc/literal operation, no problem.
      • Bob Cunnings
        AFAICS, 60.1 and 60.2 (xmlp-11 and 12) don t present any problems, and do cover the Sender fault case. By two WSDL documents do you mean defining separate
        Message 3 of 6 , Jan 2, 2003
        • 0 Attachment
          AFAICS, 60.1 and 60.2 (xmlp-11 and 12) don't present any
          problems, and do cover the "Sender" fault case.

          By "two WSDL documents" do you mean defining separate
          document and rpc style operations for these tests? That would be
          possible, or separate ports (and bindings) for the two styles could
          be contained in a single WSDL doc.

          RC

          >
          > Bob,
          >
          > I don't think there is any reason why xmlp-7, 8, and 10 should use RPC
          > convention instead of doc/lit, especially as the former seems to be
          > covered by 60.1 and 60.2 although I suspect that these may cause
          > problems as well? If so, could these test cases be handled by having two
          > WSDL documents that forced the fault to occur?
          >
          > Thanks for the feedback,
          >
          > Henrik Frystyk Nielsen
          > mailto:henrikn@...
          >
          > * * * * *
          >
          > xmlp-7 (echoSenderFault), xmlp-8 (echoReceiverFault):
          >
          > SOAP messages representing RPCs result in the invocation of a native
          > procedure in its normal runtime environment, outside the world of the
          > SOAP processor. It is impossible for such a procedure to cause the
          > generation of a SOAP fault other than indirectly. So at least in this
          > implementation, these tests can't be supported. It's a different
          > situation for doc/literal operations, it would be no problem, as an XML
          > processing app has access to the SOAP environment at runtime and can
          > generate any specific SOAP fault it wishes to. I hope this makes sense.
          > I wonder if any other implementations would have similar problems.
          >
          > xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)
          >
          > This is similar to the situation above. This is an RPC operation, and
          > the native procedure runs outside the SOAP environment, yet the test
          > requires that the procedure have access to infoset stuff (types) from
          > the original XML representation of the RPC. Of course the procedure is
          > called with the parameter data, but it has already been deserialized to
          > native types and XS type info is out of reach. Again, if it was a
          > doc/literal operation, no problem.
          >
          >
        • Glen Daniels
          Hi Bob, all: ... method: echoSenderFault The Node A sends echoSenderFault request to the Node C and the Node C returns a fault with a value env:Sender for Code
          Message 4 of 6 , Jan 3, 2003
          • 0 Attachment
            Hi Bob, all:

            On the SOAP 1.2 implementors conference call today, we discussed your "rpc-specific" issue with xmlp-7. We agreed that the purpose of this test was really to confirm that "env:Sender" matched up with HTTP 400, and that there are other tests to verify that bad arguments in RPC generate the correct subcode. Hence, we've removed the "RPC-ness" from the test as follows:

            -------- new text for xmlp-7 ---------

            method: echoSenderFault

            The Node A sends echoSenderFault request to the Node C and the Node C
            returns a fault with a value env:Sender for Code and an HTTP status
            code with a value of 400 Bad Method.

            An example of the request is:

            <m:echoSenderFault xmlns:m="http://soapinterop.org/"/>

            -------- / new text for xmlp-7 ---------

            (we just removed the part about "rpc:BadArguments")

            We hope this is better / more flexible for you.

            --Glen
          • Bob Cunnings
            Hi, Ok, great, I ve gone ahead and implemented tests xmlp-7 (echoSenderFault) and xmlp-8 (echoReceiverFault) as non-rpc operations. Have you looked at xmlp-10
            Message 5 of 6 , Jan 4, 2003
            • 0 Attachment
              Hi,

              Ok, great, I've gone ahead and implemented tests xmlp-7 (echoSenderFault)
              and xmlp-8 (echoReceiverFault) as non-rpc operations.

              Have you looked at xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)?

              It remains unimplemented here because I think that an operation using the
              rpc convention doesn't make sense. I don't think I explained my misgivings
              very well in my last post, so please allow me to try again.

              I understand that xmlp-10 is testing conformity to SOAP 1.2 part 2 sec.
              3.1.4 and specifically tests the assertion "Implementation supports
              assigning type names to graph nodes." The graph nodes are those of the SOAP
              Data Model and have a type name property that reflects the value of any
              xsi:type AII found in the SOAP-encoded representation of the node.

              The object of the test is that the XS type names of the members of an input
              struct are to be echoed back in the return value. Since this test is using
              the rpc convention, the SOAP encoded rpc invocation struct, once
              deserialized into a SOAP Data Model graph, is then used to set up a
              procedure call. This requires marshalling the input parameter value (a graph
              node with children) into the procedure as a native type. This is the part
              that concerns me... Section 4 of part 2 (SOAP RPC Representation) says that
              the identities and values of arguments are passed to the procedure, but
              there is no mention of XS type information being passed as well. Naturally
              enough, I suppose, as in many environments it not at all possible. Using the
              example of a C function with this signature:

              int foo(char *in);

              invoked using this SOAP rpc struct:

              <m:foo xmlns:m="..."><in xsi:type="xsd:string">hello</in></m:foo>

              Only the name and value of the input parameter are passed in to the
              procedure. If the type name property from the corresponding SOAP Data Model
              node doesn't go in, then of course it can't be passed back out in a return
              value from the function. So it seems to me that test xmlp-10 expects the
              impossible, by requiring that (XS) type names of input parameter graph nodes
              be propagated through the native procedure call, at least for any
              implementation in which XS Schema types need to be mapped to a different
              type system for the purpose of RPC.

              If xmlp-10 was instead an "echoGraph" operation, which used SOAP encoding
              but didn't use the rpc convention, there would be no problem.

              Does this make sense? Please set me straight if I'm missing something here.

              Thanks,

              RC

              >
              > Hi Bob, all:
              >
              > On the SOAP 1.2 implementors conference call today, we discussed your
              "rpc-specific" issue with xmlp-7. We agreed that the purpose of this test
              was really to confirm that "env:Sender" matched up with HTTP 400, and that
              there are other tests to verify that bad arguments in RPC generate the
              correct subcode. Hence, we've removed the "RPC-ness" from the test as
              follows:
              >
              > -------- new text for xmlp-7 ---------
              >
              > method: echoSenderFault
              >
              > The Node A sends echoSenderFault request to the Node C and the Node C
              > returns a fault with a value env:Sender for Code and an HTTP status
              > code with a value of 400 Bad Method.
              >
              > An example of the request is:
              >
              > <m:echoSenderFault xmlns:m="http://soapinterop.org/"/>
              >
              > -------- / new text for xmlp-7 ---------
              >
              > (we just removed the part about "rpc:BadArguments")
              >
              > We hope this is better / more flexible for you.
              >
              > --Glen
              >
            • Henrik Frystyk Nielsen
              Bob, The idea was to have two WSDL files both defining the same port using the same binding but one would take a different parameter than the other, a string
              Message 6 of 6 , Jan 6, 2003
              • 0 Attachment
                Bob,

                The idea was to have two WSDL files both defining the same port using
                the same binding but one would take a different parameter than the
                other, a string vs. an int, say. That way, both the server and the
                client would properly interpret each their WSDL but they wouldn't be
                able to talk to each other.

                Anyway, as the problem seem to have been solved this may not matter
                much.

                Henrik Frystyk Nielsen
                mailto:henrikn@...

                >-----Original Message-----
                >From: Bob Cunnings [mailto:cunnings@...]
                >Sent: Thursday, January 02, 2003 11:48
                >To: soapbuilders@yahoogroups.com
                >
                >AFAICS, 60.1 and 60.2 (xmlp-11 and 12) don't present any
                >problems, and do cover the "Sender" fault case.
                >
                >By "two WSDL documents" do you mean defining separate document
                >and rpc style operations for these tests? That would be
                >possible, or separate ports (and bindings) for the two styles
                >could be contained in a single WSDL doc.
              Your message has been successfully submitted and would be delivered to recipients shortly.