You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by "St Jacques, Robert" <Ro...@xerox.com> on 2008/04/17 19:41:41 UTC
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
RE: Muse interoperability?
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
FYI...I sent the zip directly to Robert since the Apache servers don't
seem to like attachments (ie. 12kb zip).
-----Original Message-----
From: Vinh Nguyen (vinguye2)
Sent: Friday, April 18, 2008 5:39 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
Hi Robert,
Attached is a test of your schema using Muse 2.2.0. I ran into a couple
problems:
1) Your schema is probably not doc-literal. The best solution is to use
the "wrapped object" approach. So your input/output schemas should
contains a sequence of element refs. See the SimpleResource.wsdl in the
attached zip which shows modifications to your schemas.
2) Muse seems to have a problem when sending a primitive int[]. The
request has nested xml that doesn't match the schema. I encountered
this problem back in 2.1.0 that was fixed in 2.2.0, but perhaps not
entirely now that I sort of see it again. A response containing an
int[] is fine though. See the test-output.txt in the attached zip.
<pfx0:ReverseArray
xmlns:pfx0="http://ws.disco.xerox.com/ComplexTypes">
<pfx1:intValue
xmlns:pfx1="http://schemas.xmlsoap.org/wsdl/">
<pfx1:intValue>2</pfx1:intValue> <--- These
shouldn't be nested in here!
<pfx1:intValue>3</pfx1:intValue>
<pfx1:intValue>4</pfx1:intValue>
<pfx1:intValue>45</pfx1:intValue>
<pfx1:intValue>56</pfx1:intValue>
</pfx1:intValue>
</pfx0:ReverseArray>
<muse-op:ReverseArrayResponse
xmlns:muse-op="http://ws.disco.xerox.com/ComplexTypes"
xmlns:tns="http://axis2.platform.core.muse.apache.org">
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">2</intValue> <--- This is
correct!
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">3</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">4</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">45</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">56</intValue>
</muse-op:ReverseArrayResponse>
The test was created by modifying the Muse "simple" sample project. You
can load the test files into that project and just run the Ant script to
rebuild.
Hope this helps!
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 12:40 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
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:vinguye2@cisco.com]
Sent: Thursday, April 17, 2008 1:50 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
Hi Bob,
Can you share your XSD?
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 10:42 AM
To: muse-user@ws.apache.org
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Muse interoperability?
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Hi Robert,
Attached is a test of your schema using Muse 2.2.0. I ran into a couple
problems:
1) Your schema is probably not doc-literal. The best solution is to use
the "wrapped object" approach. So your input/output schemas should
contains a sequence of element refs. See the SimpleResource.wsdl in the
attached zip which shows modifications to your schemas.
2) Muse seems to have a problem when sending a primitive int[]. The
request has nested xml that doesn't match the schema. I encountered
this problem back in 2.1.0 that was fixed in 2.2.0, but perhaps not
entirely now that I sort of see it again. A response containing an
int[] is fine though. See the test-output.txt in the attached zip.
<pfx0:ReverseArray
xmlns:pfx0="http://ws.disco.xerox.com/ComplexTypes">
<pfx1:intValue
xmlns:pfx1="http://schemas.xmlsoap.org/wsdl/">
<pfx1:intValue>2</pfx1:intValue> <--- These
shouldn't be nested in here!
<pfx1:intValue>3</pfx1:intValue>
<pfx1:intValue>4</pfx1:intValue>
<pfx1:intValue>45</pfx1:intValue>
<pfx1:intValue>56</pfx1:intValue>
</pfx1:intValue>
</pfx0:ReverseArray>
<muse-op:ReverseArrayResponse
xmlns:muse-op="http://ws.disco.xerox.com/ComplexTypes"
xmlns:tns="http://axis2.platform.core.muse.apache.org">
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">2</intValue> <--- This is
correct!
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">3</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">4</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">45</intValue>
<intValue
xmlns="http://schemas.xmlsoap.org/wsdl/">56</intValue>
</muse-op:ReverseArrayResponse>
The test was created by modifying the Muse "simple" sample project. You
can load the test files into that project and just run the Ant script to
rebuild.
Hope this helps!
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 12:40 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
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:vinguye2@cisco.com]
Sent: Thursday, April 17, 2008 1:50 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
Hi Bob,
Can you share your XSD?
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 10:42 AM
To: muse-user@ws.apache.org
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Muse interoperability?
Posted by "St Jacques, Robert" <Ro...@xerox.com>.
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:vinguye2@cisco.com]
Sent: Thursday, April 17, 2008 1:50 PM
To: muse-user@ws.apache.org
Subject: RE: Muse interoperability?
Hi Bob,
Can you share your XSD?
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 10:42 AM
To: muse-user@ws.apache.org
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: Muse interoperability?
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
Hi Bob,
Can you share your XSD?
-Vinh
-----Original Message-----
From: St Jacques, Robert [mailto:Robert.StJacques@xerox.com]
Sent: Thursday, April 17, 2008 10:42 AM
To: muse-user@ws.apache.org
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org