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

8957RE: [soapbuilders] Additional SOAP 1.2 tests redux

Expand Messages
  • Bob Cunnings
    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.


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