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
