You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by V D <st...@drexel.edu> on 2004/12/05 02:57:17 UTC
Quality of Axis with respect to document and literal style
I am not sure this is my own case, or it's general to other people.
I got Axis to work well with rpc/encoding style. However, since
switching to document/literal style, I have all kind of problems.
Problem with Java2Wsdl generating wrong wsdl file, problem with requests
works and fail randomly, problem with some parameters within a request
being sent, and some not, and problem with some request does not work at
all.
It's strange to me that Axis 1.2 is at RC2, and I am still having these
problems. Because RPC is the default mode of Axis, I think that's why
it's working with in this mode.
How was your experience with Axis handling document/literal style?
Thanks,
vh.
Re: Quality of Axis with respect to document and literal style
Posted by V D <st...@drexel.edu>.
The following is not a problem of Axis.
> When sending back an array from the server, the array's element order
> appeared to be changed. Looking at the xml data sending back, the
> array's element is already changed here.
I am sorry for this mistake. This was my fault. I changed the order of
the items and I forgot.
Re: Quality of Axis with respect to document and literal style
Posted by V D <st...@drexel.edu>.
The problem below probably has something to do with the attachment.
This is really serious. When looking at the xml data sending back and
forth, the request to the server from client send the attachment comming
back from previous call. The problem is that this function call does
not have any attachment signature (DataHandler) to it at all (input or
output). Only normal data type. There are 2 calls involved here. The
first call is a request from the client to the server that receives an
attachment. The 2nd call is another function that receives other data.
>>I still have spotty stability and I don't know what's going on.
There's a function call from a client that sometimes work, sometimes it
takes a long time before time out. There is no load on the server when
doing this. I wonder if this has something to do with the attachment
problem I mentioned before in other thread (data was sent for a request
function that has no parameter). However, the difference here is that
this function call does not have attachment part while the other one has
a return attachment.
Re: Quality of Axis with respect to document and literal style
Posted by V D <st...@drexel.edu>.
Investigating this further, I found out the reason for one of the
problems above. When sending back an array from the server, the array's
element order appeared to be changed. Looking at the xml data sending
back, the array's element is already changed here. So it has something
to do with the server's serializing the array's data.
For the other problem that I encountered is that when sending in (IN
parameter) 2 parameters. 1st parameter is an array of a bean wrapped in
a class:
class ArrayOfMyClass{
MyClass [] item;
....
}
2nd parameter is a Java String.
The 1st parameter is deserialized correctly, however the 2nd param is
always null on the server. Look at the xml data sent to the server,
data appears to be fine. So, it's the server that couldn't parse the
data correctly.
I still have spotty stability and I don't know what's going on. There's
a function call from a client that sometimes work, sometimes it takes a
long time before time out. There is no load on the server when doing
this. I wonder if this has something to do with the attachment problem
I mentioned before in other thread (data was sent for a request function
that has no parameter). However, the difference here is that this
function call does not have attachment part while the other one has a
return attachment.
Re: Quality of Axis with respect to document and literal style
Posted by V D <st...@drexel.edu>.
Here's my summary of what's going on:
1) Using Java2Wsdl to generate wsdl for RPC/encode and then using
Wsdl2Java to generate all stubs and skeletons works fine. However,
switching this to document/literal does not work. Some API are changed
such as Arrays are wrapped in a class, and if I manually wrap it, then
it will again wrap the member of the wrapped class (which is the array)
again. Some API just does not get generated correctly (such as return a
String array becomes a single String). Using gSoap, I have no problem
at all, and the code compile without a problem (using the same original
wsdl, just change the generated .h file to have doc/literal). This
causes alot of code change all over places, and also manual change of
the wsdl. I think the right way would be somehow generate the same api
so that implementation code would not have to be changed for this to work.
2) The data received from one attachment get sent in the same or another
function that has no attachment as an in parameter, also causing
stability problem (sometimes it pauses for a long time before timeout).
3) In a successfully call (no exception), a function with 2 in
parameters (1 is an array of custom objects, another is a string), the
string is always null when received by the server, however the xml data
sent by client is correct with all data. (I can provide example code for
this). Some functions with complex data structure work fine without any
problem.
4) Just in this particular computer, identical code with other computer,
using gSoap client to hit the Axis server, single thread, continously,
and the server will be out of business after couple thousand calls.
Even you quit the server, you can not use the same port (there's a
process to kill, after that, it'll work with that same port). This is
under Windows XP. This is a very serious problem with Axis, because
with this problem it cannot be used in a production environment.
(I can provide example code for this, and also exception generated after
it's out).
Re: Quality of Axis with respect to document and literal style
Posted by Lyndon Tiu <lt...@alumni.sfu.ca>.
On December 5, 2004 04:23 pm, Michael Schuerig wrote:
> On Sunday 05 December 2004 22:11, Lyndon Tiu wrote:
> > On December 5, 2004 12:50 pm, Michael Schuerig wrote:
> > > Does this result in sensible XML being transferred over the net? By
> > > that I mostly mean XML that's not just usable between the two
> > > applications you can control, but that makes interoperability
> > > possible. If not, you might get cleaner results with custom
> > > de/serializers.
> >
> > In our case, we control both ends of the wire so our "object to array
> > to object" code is a mirror - what one does the other undoes.
>
> Obviously I don't know your situation, but I'm curious why you are using
> SOAP at all. If you control both ends of the communications channel --
> and assuming that both are written in Java -- why not just use RMI?
>
Yes! Why bother with SOAP!
That's the question I ask myself but unfortunately, the marketing department
wants it for the "wow" factor. Web services is hot so everyone is into it,
doesn't matter if the technology is appropriate. What the client wants the
client gets, in this case.
Kinda like what Java was back in the mid-90's when everyone jumped into it and
started writing spreadsheets with Java Applets : >
> > But I also read that axis's complex data types are not compatible
> > with .Net and the only sure way for interoperability are simple
> > String arrays.
>
> I don't want to suggest that you're doing anything wrong, I'm still very
> much of a web services newbie. Still (or because of that), I don't see
> why there has to be a problem. My understanding is that one of the keys
> to interoperability is to start out with a WSDL definition of the
> offered service. From there, get the servlet engine to produce
> conforming XML on the wire. If Axis, in this case, doesn't do it
> correctly all by itself, then give it a hand with custom serializers
> and deserializers. In terms of architecture, this nicely keeps code
> that deals with data formats localized.
>
I find I have to hand-code wsdl's to make .Net talk to Axis.
> In my own case, I've used this approach to serialize a JDBC ResultSet
> into exactly the kind of XML I want. On the client I deserialize it to
> my own domain objects with the help of a Commons Digester. (Regarding
> my above admonitions on using RMI, this was for a proof of concept
> only.) It works nicely.
>
OK. Thank you. Will keep that in mind.
--
Lyndon Tiu
Re: Quality of Axis with respect to document and literal style
Posted by Michael Schuerig <mi...@schuerig.de>.
On Sunday 05 December 2004 22:11, Lyndon Tiu wrote:
> On December 5, 2004 12:50 pm, Michael Schuerig wrote:
> > Does this result in sensible XML being transferred over the net? By
> > that I mostly mean XML that's not just usable between the two
> > applications you can control, but that makes interoperability
> > possible. If not, you might get cleaner results with custom
> > de/serializers.
>
> In our case, we control both ends of the wire so our "object to array
> to object" code is a mirror - what one does the other undoes.
Obviously I don't know your situation, but I'm curious why you are using
SOAP at all. If you control both ends of the communications channel --
and assuming that both are written in Java -- why not just use RMI?
> But I also read that axis's complex data types are not compatible
> with .Net and the only sure way for interoperability are simple
> String arrays.
I don't want to suggest that you're doing anything wrong, I'm still very
much of a web services newbie. Still (or because of that), I don't see
why there has to be a problem. My understanding is that one of the keys
to interoperability is to start out with a WSDL definition of the
offered service. From there, get the servlet engine to produce
conforming XML on the wire. If Axis, in this case, doesn't do it
correctly all by itself, then give it a hand with custom serializers
and deserializers. In terms of architecture, this nicely keeps code
that deals with data formats localized.
In my own case, I've used this approach to serialize a JDBC ResultSet
into exactly the kind of XML I want. On the client I deserialize it to
my own domain objects with the help of a Commons Digester. (Regarding
my above admonitions on using RMI, this was for a proof of concept
only.) It works nicely.
Michael
--
Michael Schuerig The more it stays the same,
mailto:michael@schuerig.de The less it changes!
http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock
Re: Quality of Axis with respect to document and literal style
Posted by Lyndon Tiu <lt...@alumni.sfu.ca>.
On December 5, 2004 12:50 pm, Michael Schuerig wrote:
> On Sunday 05 December 2004 21:37, Lyndon Tiu wrote:
> > With doc/lit, we found that we need to pass data structures back and
> > forth in String array form. We cannot pass anything more complex
> > (like Hashmaps of Hashmaps or ArrayLists of custom objects). So if we
> > need to pass complex data structures, we "serialize" it into a few
> > arrays containing all the information in the complex data structure,
> > then put it into a custom object containing just all arrays, then we
> > "de-serialize" it back into the actual complex data structure on the
> > other end.
>
> Does this result in sensible XML being transferred over the net? By that
> I mostly mean XML that's not just usable between the two applications
> you can control, but that makes interoperability possible. If not, you
> might get cleaner results with custom de/serializers.
>
In our case, we control both ends of the wire so our "object to array to
object" code is a mirror - what one does the other undoes.
But I also read that axis's complex data types are not compatible with .Net
and the only sure way for interoperability are simple String arrays.
I've worked on axis and .Net on either ends of the wire and it is almost
easier to deal with raw XML directly rather than try to pass object back and
forth cause web services is not as platform independent as it is marketed to
be unfortunately. We would get weird errors and wsdl incompatibilities.
--
Lyndon Tiu
Re: Quality of Axis with respect to document and literal style
Posted by Michael Schuerig <mi...@schuerig.de>.
On Sunday 05 December 2004 21:37, Lyndon Tiu wrote:
> With doc/lit, we found that we need to pass data structures back and
> forth in String array form. We cannot pass anything more complex
> (like Hashmaps of Hashmaps or ArrayLists of custom objects). So if we
> need to pass complex data structures, we "serialize" it into a few
> arrays containing all the information in the complex data structure,
> then put it into a custom object containing just all arrays, then we
> "de-serialize" it back into the actual complex data structure on the
> other end.
Does this result in sensible XML being transferred over the net? By that
I mostly mean XML that's not just usable between the two applications
you can control, but that makes interoperability possible. If not, you
might get cleaner results with custom de/serializers.
Michael
--
Michael Schuerig The more it stays the same,
mailto:michael@schuerig.de The less it changes!
http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock
Re: Quality of Axis with respect to document and literal style
Posted by Lyndon Tiu <lt...@alumni.sfu.ca>.
On December 4, 2004 05:57 pm, V D wrote:
> I am not sure this is my own case, or it's general to other people.
>
> I got Axis to work well with rpc/encoding style. However, since
> switching to document/literal style, I have all kind of problems.
> Problem with Java2Wsdl generating wrong wsdl file, problem with requests
> works and fail randomly, problem with some parameters within a request
> being sent, and some not, and problem with some request does not work at
> all.
>
> It's strange to me that Axis 1.2 is at RC2, and I am still having these
> problems. Because RPC is the default mode of Axis, I think that's why
> it's working with in this mode.
>
> How was your experience with Axis handling document/literal style?
>
With doc/lit, we found that we need to pass data structures back and forth in
String array form. We cannot pass anything more complex (like Hashmaps of
Hashmaps or ArrayLists of custom objects). So if we need to pass complex data
structures, we "serialize" it into a few arrays containing all the
information in the complex data structure, then put it into a custom object
containing just all arrays, then we "de-serialize" it back into the actual
complex data structure on the other end.
We however do not experience random error as you described.
I would like to suggest you keep things simple when using doc/lit as doc/lit
is not a complete part of axis and can have a lot of undefined behavior.
I am wondering why axis still insists on use rpc as default as it does not
scale well and is effectively useless in production environments with more
than one concurrent hit?
--
Lyndon Tiu