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

26Re: Interoperability lab

Expand Messages
  • W. Matthew Long
    Feb 1, 2001
    • 0 Attachment
      > Hi Tony,
      >
      > What I'm actually looking for is a service that doesn't put in the
      > xsi:type
      > stuff and relies on WSDL/SDL/whatever to get the knowledge of the
      types of
      > parameters of a call. We recently put in support in Apache SOAP
      to handle
      > that and I haven't been able to find any complex type tests. I
      wrote a
      > simpel test to talk to your guidgen server (written in MS SOAP I
      believe)
      > and it works fine.
      >

      Sanjiva,

      We should be releasing the vbSOAP tool set in two weeks. The SOAP
      Processor utilizes the WSDL Processor to ensure the scenario.
      1) If the xsi:type is set in the Request Envelope the xsi:type is
      check against the WSDL document, also the value is check against the
      type specific is the xsi:type(s) match between the request and the
      WSLD document for the service
      2) If the xsi:type is not specified, the SOAP processor utilizes the
      WSDL processor to ensure the part values can be converted into the
      appropriate type.
      3) Finally, we have WSDL interrogator that will generate VBScript
      from a WSDL document for method calls. The Interrogator along with
      our SOAP client will automatically use xsi:type attributes on the
      parts for interoperability purposes, although our SOAP processor does
      not require it.

      We have found that the WSDL Interrogator along with our SOAP client
      is highly interoperable with does take into account the possibility
      of differing XMLSchema, i.e., 1999 and 2000/10, which some
      implementations require.

      All this will be available, along with our WSDL Wizard for COM
      objects after the documentation is completed (which is a mountain of
      documentation)
    • Show all 18 messages in this topic