|
sounds right.
as we discussed previously, .NET can use a
wrapper class in the same way, but doesn't need to.
Yeah, I did add those. Basically, I think this all boils
down to a misunderstanding of how Axis works. What I learned recently is
that, if you have an array-wrapper in your WSDL schema definition, so that the
XML looks like this:
<employee>
<name>Bill</name>
<phoneNumbers>
<item>123-4546</item>
<item>415-3030</item>
</phoneNumbers>
</employee>
... then in the java code
needs a array wrapper class too:
class employee
{
String
name;
ArrayOfPhoneNumbers
phoneNumbers;
}
class
ArrayOfPhoneNumbers{
String[]
numbers;
}
On a similar note, you may want to use that class
for functions that return arrays directly. For
example:
ArrayOfPhoneNumbers getPhoneNumbers()
{ }
(not String[] getPhoneNumbers() )
This confused me
because it seems like unnecessary overhead, and it's not the way .NET
works. On the other hand, I guess that it keeps the alignment
between the java beans and the schema types pure.
Hope I didn't mess up
the explanation; I think I finally understand it though
now.
Bill
Sebastien Mayemba Mbokoso wrote:
Hi Bill,
do u already try to map your array in your WSDD ? Something like that :
<typeMapping
xmlns:ns="urn:MyNS"
qname="ns:Employe"
type="java:bill.keese.Employe"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle=""
/>
<typeMapping
xmlns:ns="urn:MyNS"
qname="ns:ArrayOfEmployee"
type="java:bill.keese.Employe[]"
serializer="org.apache.axis.encoding.ser.ArraySerializerFactory"
deserializer="org.apache.axis.encoding.ser.ArrayDeserializerFactory"
encodingStyle=""
/>
---------------
Sebastien
On Thu, 17 Feb 2005 15:15:17 +0900, Bill Keese
<[EMAIL PROTECTED]> wrote:
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
________________________________
From: Bill Keese [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 16, 2005 9:18 PM
Cc: axis-user@ws.apache.org
Subject: Re: rpc/literal vs document/literal, and returning a list of
objects
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: axis-user@ws.apache.org; 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:
<axis-user@ws.apache.org> 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
|
