Hello,

I have seen some information on this topic, but I haven't seen the problem I'm having. So, here it goes:

I have a domain object that has a java.util.Set member. The domain object is a persistent object and the Set member value will be a hibernate Set instance (lazy loaded one-to-many). I want send this object to a remote client using SOAP/Axis. Before I send the object from the server to the client, I initialize the Set and check to make sure it is right before I return the object from my web service.

In the Asix wsdd file, I added a bean mapping for the hibernate Set type and on the client side I added a type mapping for the hibernate Set type.

The domain object and hibernate Set transmit fine to the client. However, when I try to use the hibernate Set, I get a Lazy Initialization exception (like it thinks it has not been initialized). Although, I know it was initialized before it was sent out by the web service.

I have a feeling it has to do with the way the hibernate Set is instantiated on the client side by Axis. Maybe, when the hibernate Set is instantiated, it needs to be created by some other object so it can be marked as initialized?

Hibernate version: 2.1.7
Axis version: 1.1

TIA,
-Russ.

I just wanted to post a follow up on what I did about this issue.

After sifting through the Axis and other web service/SOAP forums, it became evident that java collections in general are not very SOAP or WSDL friendly. The basic consensus was to stay away from using java collections in SOAP web services and use arrays of the type of object being stored in the collection. I did read that Axis supports converting some java collections to arrays for the WSDL, but I still ran into problems as others did and was forced to convert to arrays member types. I also read that even though Axis does support java collections, .Net clients sometimes choke.

Once I read this, I generally accepted the fact that I would not be sending collections over the wire with SOAP, much less sending the hibernate Set collection. I’m assuming the lazy initialization problem I reported in my original post is because when hibernate creates the hibernate Set object, it processes it in some way that marks it as initialized. When Axis created the Set object, it just treats it as a JavaBean and calls the empty constructor. I may have been able to write a custom jax-rpc serializer/deserializer for a subclassed version of the hibernate set object that would mark it as initialized. But after reading what the forums had to say, I figured that may be a futile effort.

I had to introduce a DTO layer for the web service interface. The DTO object model is basically the same as my persistent domain objects except that the Set collections (one-to-many relationships with inverse set to true and lazy inited) that my domain objects contain are converted to arrays. The web service basically is just a pass through to a service layer that actually does the application work and deals with the persistent domain objects. The web service layer is the only layer that deals with the DTOs. The web service converts domain objects to DTOs and vice versa for the remote SOAP clients. Lazy initialization had to be dealt with by initializing Sets before conversion to DTOs. I limited conversion to a degree of separation of 1 from the object being converted so that large object tree traversing could be controlled. If there is an object in a Set that contained a Set itself, the client is responsible for initializing that object with a different call. I normally do not like to use DTOs (maintaining parallel object models is a pain), but I was force to in this case because of technical constraints (bummer).

Once I had the DTO layer in place, it worked like a charm. The web service manages the conversion from DTO to domain and vice versa and delegates to the service layer that strictly deals with domain objects. I use hibernate managed versioning so optimistic locking works fine.

-Russ.

mmm - we are doing something very similar in our application (the nasty conversion between Hibernate POJO and SOAP-transportable DTO). It gets even more interesting (i.e., uglier) when these one-to-many collection mappings contain too many entities to be sensibly transported over SOAP !
Satish

Yes, I can imagine so ;-)

Luckily, the application I'm developing is for academic purposes and I will not have really large sets of objects.

One idea about objects that could contain large Sets would be to implement a wrapper object in the DTO that acts like a remote iterator over the Set. When invoked, it could call back to the web service which could take advantage of hibernate's pagination capabilities. You probably wouldn't even have to implement a custom serializer. By doing this, the client wouldn't have take the performance hit up front but could page the set remotely? Could work I suppose...

-Russ.

yep - that's almost exactly what we do !
Bests
Satish

I am working on a very similar project, but one question still remains. I am depending on the cascade "all-delete-orphan" that depends on the hibernate collection. However, all that information is lost during the serialization across axis (converting to arrays).

So, how can you preserve the hibernate collection on the server side and update it properly with your DTO?

Is there any way to inform hibernate of collection changes without using a hibernate collection?

I have tried using the "select-before-update" on the class, but that does not work for detecting orphans. Otherwise, everything is working well.

Thanks in advance!

We use hibernate and SOAP heavily and our needs are pretty identical to your s and we found using java data binding framework is the best option to serialize collections and such like. Go have a play with this: http://www.castor.org. I am sure you will find it very useful.

We have pretty much the same problem, only that we must support both RMI and SOAP. RMI is probably not the problem. For SOAP we still use Apache SOAP (not AXIS). Apparently DTOs become a best practice for this scenario. Are there any publicly available frameworks which address this issue or is this still at a point where everyone reinvents the wheel?

(of course if there was a (good) way to drop the DTOs altogether I would not feel too bad about it)