Wow, great answer. Thanks! I was actually just asking about issue #2,
wrapped or bare arrays.
I looked over the Axis code again and realized that in
ArraySerializer.java version 1.31, the code I mentioned in my previous
mail was corrected to output wrapped or bare arrays in concordance with
the WSDL file. The problem is that there is still a bug when an
operation returns an array directly, rather than a structure containing
an array (ie, an operation like "Employee[] getEmployees()").
Bill
Dino Chiesa wrote:
I am not clear. Seems there
are two issues,
1. SOAP encoding
(blaaaach!) vs Literal
2. wrapped or bare arrays
Let's stay away from SOAPENC:arrayType since
we all listen to WS-I.
So, on issue
#2, are you asking, does .NET expect arrays embedded in types to be
serialized as [Example 1]:
<Container>
<param1> foo</param1>
<wrapper>
<param2>bar</param2>
<param2>blah</param2>
...
</wrapper>
</Container>
or as [Example 2]
<Container>
<param1> foo</param1>
<param2>bar</param2>
<param2>blah</param2>
...
</Container>
?
The answer is, .NET can go
either way. It takes its cue from the WSDL.
If the WSDL uses a complexType
to wrap an array, such as this:
<s:complexType name="Container">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="param1"
nillable="true" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="wrapper" nillable="true"
type="tns:ArrayOfString" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfString">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="param2"
type="s:string" />
</s:sequence>
</s:complexType>
... then .NET will expect
the XML on the wire to be "wrapped", as in [Example 1] above. If the
WSDL does not use a complexType to wrap the array, but instead uses an
element with maxOccurs != 1, like so:
<s:complexType
name="Container">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="param1"
nillable="true" type="s:string" />
<s:element minOccurs="0" maxOccurs="unbounded" name="param2"
type="s:string" />
</s:sequence>
</s:complexType>
...then .NET will expect XML on
the wire that does not wrap the array in an element, such as in
[Example 2] above.
So you can do whatever.
> what format do people usually use?
I guess it's a matter of style
and taste. From the app programmer's perspective, the generated type
on the .NET side behaves the same. It looks like this:
public class Container {
public string param1;
public string[] param2;
}
The metadata attached to the
type (in the form of inline code attributes) tells the .NET XML
serializer whether to use a wrapper element or not.
So the differences in
on-the-wire serialization don't bubble up to the .NET programmer.
Personally I find the use of "ArrayOfX" to be clunky in the WSDL and
XSD. But it reads more nicely in the serialized XML, and so I
generally prefer it in complex schema. In simple schema, I don't
care.
-D
Dino - question for you. The checkin comment for ArraySerializer
v1.5 is listed below. It implies that .NET *doesn't* want arrays
serialized using the <item> tag. And yet, all the examples I've
seen of .NET services indicate the opposite. Can you shed some light
on this? And if your answer is ".NET clients support either case as
long as the XML response obeys the WSDL file", then, what format do
people usually use?
ArraySerializer v1.5 checkin comment:
Support serializing Arrays in "literal" fashion (a .NET-ism).
We introduce an "isEncoded" flag on the MessageContext for now - this
really wants to get set to the encoding state we're in at present, but I
couldn't figure out how to coax that out of the serialization code yet.
Let's say we have:
class Bean {
public String field1;
public String [] field2;
}
if isEncoded is true (the default), we get XML that looks like:
<bean>
<field1>hi there</field1>
<field2 SOAPENC:arrayType="xsd:string[2]">
<item>1</item>
<item>2</item>
</field2>
</bean>
whereas if isEncoded is false, we now get:
<bean>
<field1>hi there</field1>
<field2>1</field2>
<field2>2</field2>
</bean>
TODOs:
1) Figure out how to get encodingStyle for real
2) Implement deserializing from arrays encoded like this
Bill
Bill Keese wrote:
Hi Dino,
Nice to hear input from someone on the MS side. Anyway, yes, I think
the array issue is specific to Axis v1.2, and it's documented in http://issues.apache.org/jira/browse/AXIS-1547
The patch specified in the bug report seems to fix most people's array
related problems. (It's not in CVS so you have to check out the Axis
code and modify it yourself.)
Bill
Dino Chiesa wrote:
Returning arrays from AXIS to .NET?
Using AXIS v1.1 server, and .NET v1.1 - it works for me.
Here's a working sample with code.
http://dinoch.dyndns.org:7070/axis/AboutBasics.jsp
I know this must be a repeat, but I looked in the archive and did not
see it. . .
Is the arrays issue specific to AXIS v1.2?
-----Original Message-----
From: Praveen Peddi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 15, 2005 3:32 PM
To: [EMAIL PROTECTED]; Anne Thomas Manes
Subject: Re: rpc/literal vs document/literal, and returning a list of
objects
But what about the doc/literal issues related to returning array of
beans.
Wouldn't Dan hit the wall at some point. Atleast I hit the wall when I
tried to move towards doc/literal. We were using rpc/encoded style
before and everything was working great. When I read that rpc/encoded
has permance problems I tried to move to doc/literal style (actually
wrapped/literal) but I was stuck with returning arrays issue. My .NET
client doesn't serialize the beans at all. I read the Eric's thread and
other email threads related to this issue but could not really come up
with a solution.
Praveen
----- Original Message -----
From: "Anne Thomas Manes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 15, 2005 12:47 PM
Subject: Re: rpc/literal vs document/literal, and returning a list of
objects
And just to clarify...
The difference between doc/literal and wrapped/literal is in the way
you invoke the service -- the contents on the wire (the structure of
the SOAP message) will be identical.
In doc/literal, you input an object (javabean), and you return an
object (javabean). In wrapped/literal, you input parameters, and you
return an object. Wrapped/literal is a programming convention that
make doc/literal look like rpc/literal.
Don't use rpc/literal because .NET doesn't support it.
Regards,
Anne
On Tue, 15 Feb 2005 16:55:36 +0000, Tom Oinn <[EMAIL PROTECTED]> wrote:
Dan,
My suggestion would be to use document / literal style. The data
structure you describe is easy to define as an XML schema (by hand if
you must, but I'd use something like XMLSpy). You can then create the
requisite WSDL file referencing this schema, generate the server side
Java classes against this and modify them to call the appropriate
methods on your existing EJB.
If you're using doc/literal style you'll also have to build a (very
simple) XSD type for your three inputs, in this case a simple
sequence with minoccurs and maxoccurs attributes set to 1.
I would definitely start with WSDL in any case, given that the WSDL
defines whether your service is WS-I compliant.
HTH,
Tom
|
