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

RE: [soapbuilders] Additional SOAP 1.2 tests redux

Expand Messages
  • 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 1 of 6 , Jan 2, 2003
      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 2 of 6 , Jan 2, 2003
        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 3 of 6 , Jan 3, 2003
          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 4 of 6 , Jan 4, 2003
            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 5 of 6 , Jan 6, 2003
              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.