This message turned out to be long :P Hm. Not sure what you'd like to see exactly. Here are my WSDL definitions:
<wsdl:definitions name="ComplexTypes" targetNamespace="http://ws.disco.xerox.com/ComplexTypes"; xmlns:tns="http://ws.disco.xerox.com/ComplexTypes"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:wsdl-soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:wsa="http://www.w3.org/2005/08/addressing";> And the related type definitions: <wsdl:types> <xsd:schema elementFormDefault="qualified" targetNamespace="http://ws.disco.xerox.com/ComplexTypes";> <xsd:element name="PutArray"> <xsd:complexType> <xsd:sequence> <xsd:element name="intArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="PutArrayResponse" type="xsd:int"/> <xsd:element name="ReverseArray"> <xsd:complexType> <xsd:sequence> <xsd:element name="intArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ReverseArrayResponse" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> </xsd:schema> </wsdl:types> I've defined "PutArray" as a complex type because for some reason if I define it as such: <xsd:element name="PutArray" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/> Muse generates a method with no input parameters; it seems to want a complex type to break down into individual parameters and if it doesn't get one, it ignores the element entirely. Which is particurly odd because if I want to write a method that returns an array, that is exactly what I need to do (as I demonstrate in the "ReverseArrayResponse" element). My schema validator complains that the "minOccurs" and "maxOccurs" attributes are not allowed here, but the Muse documentation says to use them if you want to return an array. That concerns me because, again, I am worried about interoperability if the WSDL contains invalid attributes in some of the tags. The resulting method signature looks something like this: public int[] reverseArray( int[] intArray ); Of course when I do that the server works fine; it accepts the arrays generated by the client (such as the example I gave below), translates to a Java int[] and passes it into the appropriate method. It also translates the int[] I return back into SOAP and returns that to the client, which causes the client to promptly crash with a class cast exception (trying to cast a java.lang.Integer to an int[]). The exception I get is: Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to [I at com.xerox.disco.ws.ComplexTypes.MyServiceProxy.reverseArray(MyServicePro xy.java:32) at com.xerox.disco.ws.ComplexTypes.ComplexTypesClient.main(ComplexTypesClie nt.java:45) And, for what it's worth, here is the body of the method that is causing the exception in MyServiceProxy (generated by the Muse tools): public int[] reverseArray(int[] intArray) throws SoapFault { Object[] params = new Object[1]; params[0] = intArray; ProxyHandler handler = getHandler("reverseArray"); return (int[])invoke(handler, params); } By modifying the last line to do this instead: Object obj = invoke(handler, params); System.out.println( "result: " + obj.getClass() + ":" + obj ); return (int[])obj; I can see that the "invoke" method is actually returning a java.lang.Integer with a value of 1. So it seems that the Muse client is parsing only the first entry in the array, and returning that (which results in the class cast exception). So my concerns are that the SOAP being generated doesn't contain as much information as I would expect to describe the array (such as the content type and the number of elements). This concerns me that other clients will not be able to interpret the SOAP that I return. I'm also curious as to how well the server-side will handle arrays generated by other clients. Additionally, the Muse client seems to be very fragile. I've easily made it crash several times just by doing things like returning arrays or longs (which it again parses as Integers and then tries to cast into a long, which fails). Thanks, Bob -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 1:50 PM To: [email protected] Subject: RE: Muse interoperability? Hi Bob, Can you share your XSD? -Vinh -----Original Message----- From: St Jacques, Robert [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 10:42 AM To: [email protected] Subject: Muse interoperability? 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
