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