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.
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?
Joined: Aug 19, 2005
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.
Joined: Aug 21, 2004
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?
Joined: Aug 19, 2005
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
Joined: Aug 21, 2004
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