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

RE: [soapbuilders] Interoperability lab

Expand Messages
  • Tony Hong
    Hi Sanjiva, OK, gotcha. Per Simon s previous note, MS Toolkit is limited to simple types. I ll look around for an alternative example, and if I can t find one,
    Message 1 of 18 , Feb 1, 2001
      Hi Sanjiva,
       
      OK, gotcha. Per Simon's previous note, MS Toolkit is limited to simple types. I'll look around for an alternative
      example, and if I can't find one, I try and set one up with .NET B1 or something like that.
       
      Cheers,
      Tony
       
       -----Original Message-----
      From: Sanjiva Weerawarana [mailto:sanjiva@...]
      Sent: Thursday, February 01, 2001 4:12 AM
      To: soapbuilders@yahoogroups.com
      Subject: RE: [soapbuilders] Interoperability lab


      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.

      "Tony Hong" <thong@...> on 01/31/2001 08:17:32 PM

      Please respond to soapbuilders@yahoogroups.com

      To:   <soapbuilders@yahoogroups.com>
      cc:
      Subject:  RE: [soapbuilders] Interoperability lab




      Sanjiva,

      One  other note -  to illustrate the existing struct array test, here is
      the  request/response wiredump. In
      this  example, it's a Apache 2.0 client hitting a SOAPLite server (it works
      successfully) . Let me know if
      this  is what you're thinking about, or if you need something different.
      Thanks

      Tony

      ----------- Apache Requst  -----------------------

      POST  /perl/soaplite.cgi HTTP/1.0
      Host: tony:8080
      Content-Type:  text/xml
      Content- Length: 541
      SOAPAction:  "urn:xmethodsInterop#echoStruct"

      <SOAP-ENV:Envelope  xmlns:SOAP-ENV="
      http://schemas.xmlsoap.org/soap/envelope/"  xmlns:xsi="
      http://www.w3.org/1999/XMLSchema-instance"  xmlns:xsd="
      http://www.w3.org/1999/XMLSchema">
      <SOAP-ENV:Body>
      <ns1:echoStruct  xmlns:ns1="urn:xmethodsInterop"  SOAP-ENV:encodingStyle="
      http://schemas.xmlsoap.org/soap/encoding/">
      <echo  xsi:type="ns1:SOAPStruct">
      <varInt  xsi:type="xsd:int">3</varInt>
      <varFloat  xsi:type="xsd:float">1.2</varFloat>
      <varString  xsi:type="xsd:string">Hello</varString>
      </echo>
      </ns1:echoStruct>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      ------------- SOAPLite  response --------------------------

      HTTP/1.1 200 OK
      Content- Length:  672
      Content-Type: text/xml
      glue-routing: true
      date: Thu, 01 Feb 2001  01:11:21 GMT
      server: Apache/1.3.14 (Unix) PHP/4.0.1pl2
      soapserver:  SOAP::Lite/Perl/0.45

      <?xml version="1.0"  encoding="UTF-8"?><SOAP-ENV:Envelope  xmlns:SOAP-ENC="
      http://schemas.xmlsoap.org/soap/encoding/"  SOAP-ENV:encodingStyle="
      http://schemas.xmlsoap.org/soap/encoding/"  xmlns:xsi="
      http://www.w3.org/1999/XMLSchema-instance"  xmlns:SOAP-ENV="
      http://schemas.xmlsoap.org/soap/envelope/"  xmlns:xsd="
      http://www.w3.org/1999/XMLSchema">
      <SOAP-ENV:Body>
      <namesp1:echoStructResponse  xmlns:namesp1="urn:xmethodsInterop">
      <SOAPStruct  xsi:type="namesp1:SOAPStruct">
      <varFloat  xsi:type="xsd:float">1.2</varFloat>
      <varString  xsi:type="xsd:string">Hello</varString>
      <varInt  xsi:type="xsd:int">3</varInt>
      </SOAPStruct>
      </namesp1:echoStructResponse>
      </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

      -----Original Message-----
      From: Tony  Hong [mailto:thong@...]
      Sent: Wednesday, January 31, 2001  4:57 PM
      To: soapbuilders@yahoogroups.com
      Subject: RE:  [soapbuilders] Interoperability lab


      Hi  Sanjiva,

      Thanks, I'm glad you find the idea  useful!

      The  yahoo group is listed now - I accidently delisted it from their
      directory, but  it's
      visible again. Just search for"soapbuilders"  at groups.yahoo.com and you
      should
      see  it pop up .

      The  testbed as I'vedescribed has an "echoStruct" and "echoStructArray"
      methods -
      I've built this service already for  Apache and SOAP::Lite - for Apache,
      the service uses
      the  Bean serializer to map to/from a simple object. See

      http://www.xmethods.net/detail.html?id=10  for SOAP::Lite
      and
      http://www.xmethods.net/detail.html?id=11   for Apache

      Is  this what you are thinking of?

      As  far as MS or 4s4c, I'm not sure of any other existing services that
      involve
      complex types - Simon, do you know of  any?

      If  you describe the kind of type/structure you'd like to see built as an
      "echo"  , I can make sure its part
      of  the target test set and start the construction in a variety of
      implementations, including the ones
      you  mention.

      Cheers,
      Tony


      -----Original Message-----
      From: Sanjiva Weerawarana  [mailto:sanjiva@...]
      Sent: Wednesday, January 31, 2001 9:42  AM
      To: soapbuilders@yahoogroups.com
      Subject: Re:  [soapbuilders] Interoperability lab


      Hi  Tony,

      I think this is a great idea! Thanks for starting the  work!

      Do u know of a service implemented with MS SOAP, 4S4C, ... etc.  that uses
      complex types and is available on the net? I'm trying to test  the apache
      soap interoperabilty using complex types with non-Apache SOAP  services and
      I can't seem to find interesting services to  try.

      Also, what's the Yahoo group for this? I can't seem to find the  group to
      change my email  address!

      Bye,

      Sanjiva.

      Jacek Kopecky  <jacek@...> on 01/31/2001 10:23:07 AM

      Please respond to  soapbuilders@yahoogroups.com

      To:   Soapbuilders  <soapbuilders@yahoogroups.com>
      cc:
      Subject:  Re:  [soapbuilders] Interoperability lab



      I'd add a circular  structure:

      LinkedList echoLinkedList(LinkedList  linkedList)

      where the definition in Java would be

      public class  LinkedList {
          int x;
          LinkedList  next;
      }

      which means nullable and referenced next part. Sending a  circular list
      through might also help.  8-)

                                   Jacek  Kopecky
                                      Idoox



      On Wed, 31 Jan 2001, Tony Hong wrote:

      > Hi  all
      >
      > I've mentioned to a couple of you that I'm going to  create
      > an interoperability testbed. I'd like to get some  feedback
      > from this group.
      >
      > For each if a number of  different SOAP implemenation, I'm
      > planning to host a service that  exposes these methods
      >
      > String echoString(String  inputString)
      > String[] echoStringArrray(String[]  inputStringArray)
      > Integer echoInteger(Integer inputInteger)
      >  Integer[] echoIntegerArray(Integer[] inputIntegerArray)
      > Float  echoFloat(Float inputFloat)
      > Float[] echoFloatArray(Float[]  inputFloatArray)
      > SOAPStruct echoStruct( SOAPStruct  inputStruct)
      > SOAPStruct[] echoStructArray (SOAPStruct[]  inputStructArray)
      >
      > Where SOAPStruct is a simple structure  with integer, float, and
      > string fields.
      >
      > Other  possibilities include:
      > Hashmap / Associative array , using the  encoding proposed by
      > the Apache folks.
      > XML  Documents
      >
      > This "echo" service does nothing really useful  except
      > illustrate the ability of the service to accept a  clients
      > envelope, deserialize the types correctly, and then
      >  reserialize the respones into something that the client
      > can see if  it understands.
      >
      > I built this service for Apache 2.0 and  SOAP::Lite a few
      > months ago, and I think Paul Kulchenko will agree  that
      > it's been really useful for testing interop  issues.
      >
      >
      > In addition to exposing these services, I  also plan to:
      >
      > * Publish wiredumps of the request and  response envelopes
      > that each implementation uses - ie, each  implementations
      > client
      > * For those implementations that  dynamically generate
      > WSDL, I will publish the WSDL generated for  each of these
      > methods.
      >
      > I think this is a first step  to REALLY filling out those issues
      > lists for SOAP and WSDL  interoperability. It's much easier to
      > see the issues when all this  info is right in front of you.
      >
      > My question here is
      >
      > Does this set of types/methods make sense? Would you  modify
      > this list in any way?
      >
      > Thanks for any  feedback!
      >
      > Tony
      >
      >  ----------------------------------------
      > XMethods Web Services  Listings
      > http://www.xmethods.net
      >
      >
      >  To unsubscribe from this group, send an email to:
      >  soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >



      To  unsubscribe from this group, send an email  to:
      soapbuilders-unsubscribe@yahoogroups.com








      To  unsubscribe from this group, send an email  to:
      soapbuilders-unsubscribe@yahoogroups.com




      To  unsubscribe from this group, send an email  to:
      soapbuilders-unsubscribe@yahoogroups.com



                                                                                 
                                      Yahoo! Groups Sponsor                      
                                                                                 
                                                                                 
                                                                                 
                                                                                 
                                                              [IMAGE]            
                     [IMAGE]                                                     
                                                                                 
                                                                                 
                                                                !                
                                        www. .com                                
                                                                                 
                                                                                 
                                                                                 
                [IMAGE]                                                          
                                                                                 


      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com








      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com


    • W. Matthew Long
      ... types of ... to handle ... wrote a ... believe) ... Sanjiva, We should be releasing the vbSOAP tool set in two weeks. The SOAP Processor utilizes the WSDL
      Message 2 of 18 , Feb 1, 2001
        > 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)
      • Jacek Kopecky
        W. Matthew, I see that you chose the same approach as IdooXoap did, too. We also compare xsi:type against the WSDL, we don t require xsi:type either and we
        Message 3 of 18 , Feb 2, 2001
          W. Matthew, I see that you chose the same approach as IdooXoap did,
          too. We also compare xsi:type against the WSDL, we don't require
          xsi:type either and we also put it in there everywhere.

          What kind of XML Schema representation of SOAP Encoding structures
          do you support? Or do you support any general schema?

          Jacek Kopecky
          Idoox



          On Fri, 2 Feb 2001, W. Matthew Long wrote:

          > > 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)
          >
          >
          >
          >
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@yahoogroups.com
          >
          >
          >
        • Matt Long
          ... We re using 2000/10 as the default of the WSDL Wizard, but it is up to the user to insert the schema for a part(s) where needed, i.e., support xsi:type(s)
          Message 4 of 18 , Feb 2, 2001
            > W. Matthew, I see that you chose the same approach as IdooXoap did,
            > too. We also compare xsi:type against the WSDL, we don't require
            > xsi:type either and we also put it in there everywhere.
            >
            > What kind of XML Schema representation of SOAP Encoding structures
            > do you support? Or do you support any general schema?
            >
            > Jacek Kopecky
            > Idoox


            We're using 2000/10 as the default of the WSDL Wizard, but it is up to the
            user to insert the schema for a part(s) where needed, i.e., support
            xsi:type(s) do not schemas nor does supportted ArrayOfTypes. Our WSDL
            Interrogator can set the xsi and xsd namespaces from the WSDL document for
            our SOAP client if these exist in the WSDL Document (which is needed in some
            implementations). The general rule in our implementation is that if a part
            is not a supportted xsi:type, i.e., xsd:string, xsd:date, xsd:timeInstant,
            xsd:double,.... then it must be properly identified to the <types> element,
            i.e., the schema of the WSDL document.

            Example tns:PurchaseOrder. If this occurs the processor will cut out the
            scoping element and its children of "tns:PurchaseOrder" and pass to the
            method call as a document fragment.

            ...soap arrays can only be one dimension for now and must be in the form
            <SOAP-ENC:Array SOAP-ENC:arrayType="xsd:whatever">
            <part/>
            <part/>
            </SOAP-ENC:Array>
            We choose this for arrays since it is the basic form and *should* interop
            best.

            ...Also, the WSDL Interrogator will inspect the <types> in the WSDL document
            in such a case that a part is a object(i.e., dom document or xml fragment)
            and will display the schema of said part in comments for VBScript. With
            this the service implementor receives the correct schema (specific to the
            WSDL document interrogated) such that the service implementor can correctly
            form the object to pass in the request.






            >
            >
            >
            > On Fri, 2 Feb 2001, W. Matthew Long wrote:
            >
            > > > 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)
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > > To unsubscribe from this group, send an email to:
            > > soapbuilders-unsubscribe@yahoogroups.com
            > >
            > >
            > >
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            > ---------------------~-~>
            > eGroups is now Yahoo! Groups
            > Click here for more details
            > http://click.egroups.com/1/11231/0/_/_/_/981126210/
            > --------------------------------------------------------------
            > -------_->
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@yahoogroups.com
            >
            >
          • Paul Kulchenko
            Hi, Tony! ... Yes, that s true. You may specify (with maptype() method) mappings between types and namespaces. Introduced basically for Apache interoperability
            Message 5 of 18 , Feb 2, 2001
              Hi, Tony!

              > One thing to note: in versions prior to 0.46, the namespace of the
              > generated
              > structure is the same as the method namespace URI (in this case,
              > urn:xmethodsInterop) . I believe in 0.46, this is now configurable.
              Yes, that's true. You may specify (with maptype() method) mappings
              between types and namespaces. Introduced basically for Apache
              interoperability :)).

              Best wishes, Paul.

              --- Tony Hong <thong@...> wrote:
              > Simon, here's a snippet of SOAP::Lite that calls the echoStruct
              > service.
              > Paul, please don't beat me up if the Perl isn't pretty! :-)
              >
              >
              ----------------------------------------------------------------------------
              > -----------------
              >
              > #!/usr/bin/perl
              >
              > use SOAP::Lite;
              >
              > SOAP::Data->import('name');
              >
              > my %hash = (
              > varInt => 5,
              > varString => "test string",
              > varFloat => 6.2
              > );
              >
              > $h=SOAP::Lite
              > -> uri ('urn:xmethodsInterop')
              > ->
              > proxy('http://services.xmethods.com:80/soap/servlet/rpcrouter')
              > -> echoStruct(name("testStruct" => \%hash))
              > ;
              >
              > if($h->faultcode)
              > {print "FAULT CODE --------------------\n";
              > print $h->faultcode. "\n\n";
              > print "FAULT DETAIL--------------------\n";
              > print $h->faultstring. "\n";
              > }
              > else
              > {
              > print "RESULT --------------------\n";
              > foreach $k (keys %{$h->result})
              > {
              > print $k."\t".$h->result->{$k}."\n";
              > }
              > }
              >
              >
              ------------------------------------------------------------------------
              >
              > It generates the following envelope:
              >
              > POST /soap/servlet/rpcrouter HTTP/1.0
              > Host: tony:8080
              > User-Agent: SOAP::Lite/Perl/0.45
              > Content-Length: 662
              > Content-Type: text/xml
              > SOAPAction: "urn:xmethodsInterop#echoStruct"
              >
              > <?xml version="1.0" encoding="UTF-8"?>
              > <SOAP-ENV:Envelope
              > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
              > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
              > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
              > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
              > xmlns:xsd="http://www.w3.org/1999/XMLSchema">
              > <SOAP-ENV:Body>
              > <namesp1:echoStruct xmlns:namesp1="urn:xmethodsInterop">
              > <testStruct xsi:type="namesp1:SOAPStruct">
              > <varFloat xsi:type="xsd:float">6.2</varFloat>
              > <varString xsi:type="xsd:string">test string</varString>
              > <varInt xsi:type="xsd:int">5</varInt></testStruct>
              > </namesp1:echoStruct>
              > </SOAP-ENV:Body>
              > </SOAP-ENV:Envelope>
              >
              > ---------------------------------------------------
              >
              > And when you run it, here's the output bounced off the Apache
              > version
              > echoStruct method:
              >
              > RESULT --------------------
              > varFloat 6.2
              > varString test string
              > varInt 5
              >
              >
              >
              > One thing to note: in versions prior to 0.46, the namespace of the
              > generated
              > structure is the same as the method namespace URI (in this case,
              > urn:xmethodsInterop) . I believe in 0.46, this is now configurable.
              > I'll let
              > Paul comment on that .
              >
              > Cheers,
              > Tony
              > -----Original Message-----
              > From: Simon Fell [mailto:soap@...]
              > Sent: Thursday, February 01, 2001 12:23 AM
              > To: soapbuilders@yahoogroups.com
              > Subject: Re: [soapbuilders] Interoperability lab
              >
              >
              > I've got an implementation of this running, i'll try and get it
              > on a
              > public server tomorrow. I'm testing with SOAP::Lite as a client,
              > can
              > anyone show me how to call the echoStruct method, i'm having
              > trouble
              > getting the values nested in the inputStruct element (my perl
              > skills
              > can only get better from this point <g>)
              >
              > this is what i currently have
              >
              > my @struct = (
              > SOAP::Data->name(varInt => 42),
              > SOAP::Data->name(varFloat => 42.42),
              > SOAP::Data->name(varString => "SOAP::Lite to 4s4c")
              > ) ;
              >
              > my @parameters = (
              > SOAP::Data->name(inputStruct => @struct )
              > ) ;
              >
              > print @{$soap->echoStruct(@parameters)->method}{'outputStruct'} ,
              > "\n"
              > ;
              >
              >
              > For reference here are traces for the call to echoStringArray,
              > one
              > thing i did notice is that SOAP::Lite types the array as
              > namesp2:Array
              > whilst i'm typing it as SOAP-ENC:Array.
              >
              > Cheers
              > Simon
              >
              > ------------------ SOAP::Lite request ---------------------------
              > POST /ilab/soap.asp HTTP/1.0
              > Host: localhost:8080
              > User-Agent: SOAP::Lite/Perl/0.45
              > Content-Type: text/xml
              > SOAPAction: "urn:xmethodsInterop#echoStringArray"
              >
              > <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope
              > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
              >
              > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
              > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
              > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
              > xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP-ENV:Body>
              > <namesp2:echoStringArray xmlns:namesp2="urn:xmethodsInterop">
              > <inputStringArray SOAP-ENC:arrayType="xsd:string[3]"
              > xsi:type="namesp2:Array">
              > <c-gensym9 xsi:type="xsd:string">SOAP::Lite</c-gensym9>
              > <c-gensym9 xsi:type="xsd:string">to</c-gensym9>
              > <c-gensym9 xsi:type="xsd:string">4s4c</c-gensym9>
              > </inputStringArray></namesp2:echoStringArray>
              > </SOAP-ENV:Body></SOAP-ENV:Envelope>
              >
              >
              > ---------------------- 4s4c Response
              > -----------------------------
              > HTTP/1.1 200 OK
              > Server: Microsoft-IIS/5.0
              > Date: Thu, 01 Feb 2001 08:09:24 GMT
              > Connection: Keep-Alive
              > Content-Type: text/xml
              > Expires: Thu, 01 Feb 2001 08:09:24 GMT
              > Set-Cookie: ASPSESSIONIDGGQGQPMO=OOMLALIAMAFPCEFMOJNBNGGN; path=/
              > Cache-control: private
              >
              > <?xml version="1.0"?><SOAP-ENV:Envelope
              > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
              > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
              > xmlns:xsd="http://www.w3.org/1999/XMLSchema"
              > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
              >
              > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
              > <SOAP-ENV:Body><m:echoStringArrayResponse
              > xmlns:m="urn:xmethodsInterop">
              > <outputStringArray xsi:type="SOAP-ENC:Array"
              > SOAP-ENC:arrayType="xsd:string[3]">
              > <item xsi:type="xsd:string">SOAP::Lite</item>
              > <item xsi:type="xsd:string">to</item>
              > <item xsi:type="xsd:string">4s4c</item>
              > </outputStringArray></m:echoStringArrayResponse>
              > </SOAP-ENV:Body></SOAP-ENV:Envelope>
              >
              >
              >
              > On Wed, 31 Jan 2001 17:17:32 -0800, in soap you wrote:
              >
              > >Sanjiva,
              > >
              > >One other note - to illustrate the existing struct array test,
              > here is
              > the
              > >request/response wiredump. In
              > >this example, it's a Apache 2.0 client hitting a SOAPLite server
              > (it
              > works
              > >successfully) . Let me know if
              > >this is what you're thinking about, or if you need something
              > different.
              >
              === message truncated ===


              __________________________________________________
              Get personalized email addresses from Yahoo! Mail - only $35
              a year! http://personal.mail.yahoo.com/
            Your message has been successfully submitted and would be delivered to recipients shortly.