Forums Register Login
Going crazy with webservices and Hibernate
I have trying night and day to get this to work. It doesn't

I have created two Hibernate annotated pojos. A Weather class and a Hepp class. Just to test for a much bigger project. The Weather class has many Hepp classes and the Hepp class has a Weather.

When running test without using webservices everything works fine.

When trying to call a webservice it works fine as long as I don't get it from Hibernate or use hepp.setWeather( weather ). Then it all hangs

Here is the RPCClient

And here is the service

If I do this in the getWeather it works fine as long as I don't call setWeather( weather ) for the Hepp class

Please give me some advise.
Just a guess - but you are creating a cyclical object relationship and ultimately that may cause an infinite loop.
Object graphs can contain cycles - XML cannot represent cycles!

Ultimately XML doesn�t need the backward reference because if a Weather element contains a sequence of Hepps elements it is clear which Weather element the Hepp Element belongs to. So ultimately you may have to create alternate object representations (essentially Data Transfer Objects (DTOs)) WeatherDto/HeppDto
for the web services interface which eliminate these cycles and then you have to convert between Weather/Hepp and WeatherDto/HeppDto representations.

Hibernate may have helped you with the Object Relational Impedance Mismatch but it doesn't cover the Relational/Object/XML (ROX) impedance mismatch.
[ September 06, 2007: Message edited by: Peer Reynders ]

It would be duplicating code won't it? Do you have any suggestions on how to implement this the best way?

What do a java programmer normaly do when they need to expose objects over webservices and persist these objects when created in client?

Originally posted by Mathias Nilsson:
What do a java programmer normaly do when they need to expose objects over webservices

I usually try to stop them from "trying to expose objects over web services" - which isn't usually well received. Your are sending and receiving messages - period.

The easy way out is to create those DTOs in Java and let Axis deal with the rest. However the XML representation of the data that is sent over HTTP may not be necessarily something that non-Java or even non-Axis clients find easy do deal with.

Current best practices suggest that you design (in XML Schema) the representations of the data you are sending or receiving as an XML document. You have chosen to expose your data through a SOAP RPC/Literal web service. If you have an XML document you might as well go to Document/literal. The next step is to include that XML document in the WSDL that describes your web service and then use WSDL2Java to generate the Java objects for you. Then you simply convert the WeatherGen/HeppGen objects to your Weather/Hepp objects and vice versa.

You also have the option of simply having a servlet serve your data as "Plain Old XML" (POX) over HTTP - not as fancy as SOAP but it sometimes serves a purpose. Similarly you could expose your data over a RESTful web service. The design procedures for resource based web services are described in RESTful Web Services (amazon US)); the Restlet framework supports the implementation of RESTful web services.

With both "POX over HTTP" and REST you can use JAXB to turn your XML Documents into Java Objects (and vice versa). You can configure JAXB to generate Java classes with certain characteristics but I suspect that the cyclical reference will prevent you from directly mapping XML to and from your Weather/Hepp objects - so you would still have to do some WeatherBind/HeppBind <-> Weather/Hepp conversions.

Axis2 may support JAXB in the future - currently it only supports xmlbeans, adb, and jibx.
So I should not use RPCServiceClient for calling the service? Seems that I have little time of changing this. Is it really bad design to use RPCServiceClient?

Originally posted by Mathias Nilsson:
So I should not use RPCServiceClient for calling the service? Seems that I have little time of changing this. Is it really bad design to use RPCServiceClient?

As I said before given your time constraints you could go the DTO route and stick with what you have got.

From the design perspective however the web services interface isn't part of your object model. The interface is part of the services model (which includes the service clients). The services model tends to be on a higher level and coarser granularity than your object models. Between objects you design the object collaborations; between services you design the request and response messages (independently of any object models that may be present inside the service or client applications).

Then I was merely pointing out that in many cases you don't have to personally "duplicate code". In your current situation you have to write your own DTO's. I was describing scenarios where you could use code generation (through WSDL2Java or JAXB xjc) to create the equivalent structures/objects for you which would minimize manual duplication - you would then only have to write the mapping code.

Furthermore you never elaborated who is going to be a client to your web service. If you know that all clients are Java and will be using Axis 2 to generate their client stubs then there is nothing to worry about. If however your expect to service a broad range of client applications written on diverse platforms in languages like Perl, Ruby, JavaScript, other proprietary, possibly non-object oriented languages, etc. then more care needs to be taken to ensure that the services interface is suitable for these types of clients - in which case simpler is better.

Web services are about messaging (or the exchange of resource representations). Using web services for RPC tends to trade off against objectives like loose coupling (the flipside is that messaging has been accused of being a degenerate form of RPC).

Tim Ewald: I finally get REST. Wow.
It's depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again. I know SOAP is really an XML messaging protocol, you can do oneway async stuff, etc, etc, but let's face it. The tools make the technology and the tools (and the examples and the advice you get) point at RPC. And we know what the problems with RPC are. If you want to build something that is genuinely loosely-coupled, RPC is a pretty hard path to take.

SOAP has been designed with a lot of flexibility (which made the WS* standards possible). However there has been the growing realization that this flexibility injects a lot of complexity that isn't used in the majority of cases where the technology is applied.
WS* vs. REST / Intelligence vs. Wisdom
Thank you very much for your respond. I'm working on my Hibernate POJOs and DAOs right know and after that I'm building some dto to work in applet. The service also needs to be called from php but I hope this is doable.

All this is quit new for me and we can't afford to get it wrong as it's often the case. Biggest problem is that I'm developing this myself and have no one to ask for advice so I thank you on this topic.

I've tried the wsdl2java generator by Apache and the code was VERY long so thats why I started to look at RPCServiceClient. A stub code is almost 1000 rows long and with a RPCClient you could do the same with 30-50 lines.

Anyway, I'll stick with the RPC, DTO mapper and perhaps it's time to do some reading about JAXB and other api's

This thread has been viewed 9052 times.

All times above are in ranch (not your local) time.
The current ranch time is
Oct 22, 2018 21:35:17.