This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
It seems like things are not entirely clear on your part, so:
1. Data binding alternatives, such as ADB, JiBX, JAXB etc. are responsible for both marshalling and unmarshalling, that is creating an XML representation from one or more Java beans and also creating one or more Java beans from an XML representation.
2. Java2WSDL is used to create a WSDL when you are doing code-first web service development in Java.
3. WSDL2Java is used to create stubs, data beans etc. when you are doing WSDL-first development.
The above two are thus only used at development time, not at runtime.
Ivan is absolutely right! I do not understand why you want to dynamically change your WSDL by updating the XSD for different complex types. Maybe you can explain this. I believe this is not a good idea. Because the WSDL should be stable so people can rely on your service and service interface(s).
The only reason i could imagine is, your clients want to send object types which you do not know to your service. But in this case you should rather define a meta model for these objects and declare this in your WSDL. I do not know how complex your objects are, but i could think of some meta model like this:
But i do not know if this applies to your use case.
Rahul P Kumar
Joined: Sep 26, 2009
No, I don't want to change WSDL format at runtime or anytime. My java application has done some processing and I want this to be sent back to client as response. Java2Wsdl needs to be run each time to convert java objects to wsdl objects, or that is what I assume (correct me). So, I want thta once application finsihes processing , these java objects should be converted to xsd type by any means, afterwards those xsd types can be send easily through response.
Joined: Oct 04, 2006
There seems to be a little misunderstanding on your part, as far as I understand.
A WSDL defines the structure of the data sent in requests to a web service and received in the responses from the web service.
The marshalling and unmarshalling of XML <-> Java objects is taken care of by the web service stack based on the information in the WSDL. This is nothing that you normally should have to care for. So, as a conclusion, from your web service method you only need to return regular Java objects - the marshalling will, as before, be taken care of by the web service stack.
This is not the entire truth, but I do not want to confuse you, or anyone else, with special cases at the moment.
Java2WSDL is a tool that is used to generate artifacts (for instance WSDL, deployment descriptors, etc etc) from annotated Java code that the web service stack needs when deploying a service. It is simply a convenience, instead of you writing all those things by hand each time. This tool is used by the developer and is NOT responsible for marshalling or unmarshalling.
Hope things have become more clear!
Rahul P Kumar
Joined: Sep 26, 2009
Ivan Krizsan wrote:
The marshalling and unmarshalling of XML <-> Java objects is taken care of by the web service stack based on the information in the WSDL. This is nothing that you normally should have to care for.
I am using axis2. In my application, I am converting all those xsd types to corresponding java types myself. So, after UnMarshalling takes place, I am converting xsd objects to appropriate type of java. Similarly, before marshalling back to user, one way I am seeing is to reconvert all java type to xsd type and then let axis do the marshalling.
N.B.- [Let me be clear that here, marshalling and unmarshalling terms are used from my end. So, marshalling means I am sending the response and unmarshalling means, I am getting the inputs from the request.]
Now, you said that I don't have to take care of marshalling unmarshalling, that is true, but what about the type of objects axis requires to perform those operations. Without converting axis2 throws ClassCast Exception