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

RE: [soapbuilders] Additional SOAP 1.2 tests redux

Expand Messages
  • 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 1 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 2 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 3 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.