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.
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.
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.
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
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