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).
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.
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.
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.
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?
2. Should we be using WSDL2Java and/or Java2WSDL?
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.
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?
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?
Thanks, Mike
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
