Hi Mike,
I am currently working on something similar. My response is added below each question.
Cheers,
Tony
-----Original Message-----
From: Mike DuVall [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 25, 2003 11:25 AM
To: [EMAIL PROTECTED]
Subject: Design review and general axis questions
I wanted to share the manner in which my project is currently using Axis and
get general on the overall design, as well as some answers to some specific
questions about areas of difficulty that we are having.
The manner in which we arrived at this design is that we got one of the
sample programs working, and we just evolved from there.
We are currently not using any of the WSDL2Java or Java2WSDL tools. We are
exposing the services of a java class on the server via SOAP, with hand
coded proxies (and/or skeletons, or whatever you want to call them).
>>Good start with what you know works and is simple. Do not spend a lot of time working with
tools just yet. Get the prototype infrastructure working first!
The client side proxy manually builds Call objects, populates the Call
object with the parameters, invokes the Call object, receives the results,
and passes the results back to the caller of the cliend side proxy.
>> Simple. That is the way I started and worked for me. You should consider a standard value object pattern soon.
That is create a simple message object that you can use to pass to and return from the Axis service. Will save plenty
of time later.
The server side proxy(or skeleton?) is what is exposed via SOAP, which then
calls the real service. The reason we need this, rather than just calling
the real service directly, is that we have complex custom exceptions that
need to be returned, and we had terrible problems throwing these custom
exceptions on the server side and having them correctly propagated to the
client side. So what we are doing as a workaround is to basic return
exceptions as return values. We are using a custom return value object
(that we call xxxxResult) that contains fields for both the real return
value as well as an exception. The server side proxy calls the actual
service, catches any exceptions, packages either the exception or the real
return object into our wrapper return object, and returns the whole thing to
the client proxy. The client proxy interrogates the return object and
either returns the real return value or re-throws the exception to the
client proxy caller.
>>Read what I said above. I am using Axis service to pass my objects via RMI to a stand alone service. Makes use of Axis simpler and more flexible.
>>Also might want to consider multiple objects returned in result. Saves performance that way.
Every parameter and return value that we use is either natively serializable
by Axis or is a bean and serialized via the BeanSerializer.
This last item is an error prone high maintenance point because everytime we
add a new bean as a parameter, we have to remember to go update the client
proxy so that it registers the new bean with the BeanSerializer on the
appropriate Call object and we also have to remember to go update the
server-config.wsdd file.
>>Use same object to pass between client and server. That is why I did a message object where I had header attributes and a vector for the actual data object. Works well for me so far.
This process has proven to be error prone, and we often get surprised by
'deserializer for xxx couldn't be found'-like error message because we
forget to tell Axis about a particular bean.
Other than this last issue, things have been working pretty well.
Here are my questions:
1. Any overall thoughts on our design? Are we using Axis in the spirit in
which it was intended?
>> Listed above. In general a good start for version 1.0 of what you are doing.
2. Should we be using WSDL2Java and/or Java2WSDL?
>>Not unless you are at a stage where you are not spending a lot of time putting functionality in.
3. Should I have to jumping through such hoops to get custom exceptions to
work? Posts in the past seems to indicate that others are also having
issues.
>>Depends upon stability of the app and how busy you want your help desk to be.
4. Is there a clean way to get around the high maintenance and error prone
process of having to update both the client proxy code and the server config
files for each new parameter or return bean added to our services?
>>Value object pattern should be used.
5. I seem to recall reading somewhere that a future release of Axis will
automatically try the BeanSerializer if it can't find a serializer for a
particular class, hopefully thus alleviating one of my issues above.
Anybody know anything about if and when this is coming?
>>No idea when.
Thanks,
Mike
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
