axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dino Chiesa" <>
Subject RE: rpc/literal vs document/literal, and returning a list of objects
Date Thu, 17 Feb 2005 04:13:20 GMT
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]:
    <param1> foo</param1>
or as [Example 2]
    <param1> foo</param1>
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: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:complexType name="ArrayOfString">
      <s:element minOccurs="0" maxOccurs="unbounded" name="param2"
type="s:string" />

... 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:element minOccurs="1" maxOccurs="1" name="param1" nillable="true"
type="s:string" /> 
    <s:element minOccurs="0" maxOccurs="unbounded" name="param2"
type="s:string" /> 

...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


From: Bill Keese [] 
Sent: Wednesday, February 16, 2005 9:18 PM
Subject: Re: rpc/literal vs document/literal, and returning a list of

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:

  <field1>hi there</field1>
  <field2 SOAPENC:arrayType="xsd:string[2]">

whereas if isEncoded is false, we now get:

  <field1>hi there</field1>


1) Figure out how to get encodingStyle for real
2) Implement deserializing from arrays encoded like this

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
	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.)
	Dino Chiesa wrote: 

		Returning arrays from AXIS to .NET?  
		Using AXIS v1.1 server, and .NET v1.1 -  it works for
		Here's a working sample with code. 
		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 [] 
		Sent: Tuesday, February 15, 2005 3:32 PM
		To:; Anne Thomas Manes
		Subject: Re: rpc/literal vs document/literal, and
returning a list of
		But what about the doc/literal issues related to
returning array of
		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.
		----- Original Message -----
		From: "Anne Thomas Manes" <>
		To: <>
		Sent: Tuesday, February 15, 2005 12:47 PM
		Subject: Re: rpc/literal vs document/literal, and
returning a list of

			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.
			On Tue, 15 Feb 2005 16:55:36 +0000, Tom Oinn
<> <>  wrote:

				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


View raw message