- Posted by: Gediminas Aleknavicius
- Posted on: April 11 2005 05:17 EDT
the project I'm going to work on will be developed using Hibernate and Web Services (most likely Axis). We are thinking to return detached persistant objects and more complicated object structures from the server to clients through the web service. Has anyone tried this approach? Is it going to work?
Although I could not say I got into the details of the Axis webservices implementation, I did try it a little bit with hibernate, and yes, it worked :).
The main problems I've met and I could share with you:
1. Java web services DOES support complex persistent object structures with some limitations:
- aggregating collections should be limited to basic java arrays in order to ensure complete interoperability (I built a java web service with a .NET C# client but although some JaxRpc implementation (maybe axis too) support list collections, the C# client will not be able to "understand" that there is a list involved and can't provide any operation for the collection field)
- the operations that are NOT properties specific (getters and setters) will not be available for the client (as much as i've seen while using Axis), which is quite normal when you think that the service exposing classes should provide these "business" operations; even if i did declare some public methods for the "beans" or "pojos" these methods were not visible for the client in my implementation, and as i said i think this is quite ok.
2. The data types supported by the Java webservices specification are generally available, although some implementaions might not offer collections support for example, but the specific documentaion of the implementation you are using should provide you these kind of informations. As much as i've seen all the basic Java types and aggregated "bean" types are supported as fields for your persistent objects. This means that class A having the field b of class B is ALWAYS going to be supported for xml serialization if A's and B's fields are simple Java types (int , String, etc). Generally they don't necessarly have to implement Serializable.
The key that shaped how our Web Services Interface turned out was interoperability. If you want your Web Services to be consumed by as many types of clients as possible, then you need to design a WSDL (plus Schema) first and then test to see if it will work with all the client technologies. A good test for a Web Services client that is fairly dumb is the Microsoft Office XP Web Services Toolkit 2.0. Using this you can get Web Services data into MS Officle Documents.
Also you will need to decide whether to use XML-RPC or Document Literal Style WS. Which you use will, again, influence your interoperability.
Read up about about interoperability, i think the IBM Developer Works site has some good articles about this.
If your clients are only Java, then it might be easier to just use Hessian/Burlap. But if your clients are "all over the place", then you need to focus on interoperability to make sure your data doesnt loose itegrity.
Hope this helps.
- Web Services in 15 Minutes -