Has anyone tested the interoperability of Muse with other Web Service
stacks (e.g. Axis, .Net, etc)?  I have serious doubts about how Muse
will playw ith others, which is troubling considering one of the chief
resons for using a WS stack is interoperability between disparate
platforms.  For example, I wrote a WSDL operation that accepts an int
array as a parameter.  Here is the SOAP that Muse generated:

 

<soap:Body>

  <pfx0:PutArray xmlns:pfx0="http://ws.disco.xerox.com/ComplexTypes";>

    <pfx0:intArray>

    <pfx0:intArray>0</pfx0:intArray>

    <pfx0:intArray>1</pfx0:intArray>

    <pfx0:intArray>2</pfx0:intArray>

    <pfx0:intArray>3</pfx0:intArray>

    <pfx0:intArray>4</pfx0:intArray>

    <pfx0:intArray>5</pfx0:intArray>

    <pfx0:intArray>4</pfx0:intArray>

    <pfx0:intArray>3</pfx0:intArray>

    <pfx0:intArray>2</pfx0:intArray>

    <pfx0:intArray>1</pfx0:intArray>

    </pfx0:intArray>

  </pfx0:PutArray>

</soap:Body>

 

Now I am by no means a SOAP expert (I have just started playing with
Muse recently) but what little reading I have done has lead me to
believe that arrays should look more like this:

 

<intArray 
  xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/";  
  xsi:type="ns2:Array" 
  ns2:arrayType="xsd:string[10]">
    <item xsi:type="xsd:int">0</item>
    <item xsi:type="xsd:int">1</item>
    <item xsi:type="xsd:int">2</item>
    <item xsi:type="xsd:int">3</item>
    <item xsi:type="xsd:int">4</item>
    <item xsi:type="xsd:int">5</item>
    <item xsi:type="xsd:int">4</item>
    <item xsi:type="xsd:int">3</item>
    <item xsi:type="xsd:int">2</item>
    <item xsi:type="xsd:int">1</item>
</intArray>
 
I also wrote a simple method that returns an int array, the Java
signature of which looks like this:
 
public int[] reverseArray( int[] intArray )
 
I am troubled by the fact that, in order to specify an int return type,
I need to define an element like this in my WSDL:
 
<xsd:element name="ReverseArrayResponse" type="xsd:int" minOccurs="0"
maxOccurs="unbounded"/>
 
And my schema validator warns me that "minOccurs" and "maxOccurs" are
not valid attributes.
 
Also, when calling the method I found that, again, Muse returned SOAP
that did not look as I would have expected:
 

<soap:Body>

  <muse-op:ReverseArrayResponse
xmlns:muse-op="http://ws.disco.xerox.com/ComplexTypes";>

    <muse-op:ReverseArrayResponse>1</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>2</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>3</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>4</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>5</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>4</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>3</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>2</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>1</muse-op:ReverseArrayResponse>

    <muse-op:ReverseArrayResponse>0</muse-op:ReverseArrayResponse>

  </muse-op:ReverseArrayResponse>

</soap:Body>
 
And to make matters even worse, when the Muse client crashed when trying
to handle the return value!  While parsing the SOAP it seemed to extract
only a single integer value, and the client crashed when the proxy tried
to cast the lone int into an int[].  I found similar errors when I tried
to return an xsd:long; the Muse client parsed the return value as an
int, and crashed trying to cast the int into a long.
 
If anyone has experimented with interoperability between muse and other
WS platforms (particularly Axis and .Net) I would appreciate hearing
about your experiences.
 
Thanks,
Bob
 
 

 

Reply via email to