I'm currently building a web service client for an application that soon will be introduced in my company. I've never worked with SOAP before but I figured out that I could generate a WS consumer with JAX-WS using the wsdl file. Now I want to marshal/unmarshal my requests/responses content with JAXB. The content will be everything inside the SOAP:envelope. So I was wondering if there is a way where I can generate Java objects for all the requests/responses I want to use. There are a lot of similarities between the diferent requests/responses but also some differences. Is it possible to create a structure of classes where similarities get reused? Declaring it all by hand seemed like a lot of work. But if there's no way to generate it, I'm affraid I'll have to. Can anybody help me? Or is there another way I can work better with the WS client? Thanks in advance.
Related
I'm searching for a way to consume soap webservices without using wsimport and tools like that. So far, everyting I found requires the wsdl artifacts generation and I want to avoid it because I don't know wich webservices will be used.
The idea is to give the user the possibility to add several WSDL's urls / methods and the program consume them and send it's response to another url.
I'm not looking for out of the box solutions/code or something like that.
What I need is to know if it is possible or not and how to aproach this problem, ideas and things like that.
Thanks!
SOAP mandates a contract between the Client and Server. The contract is that Client will give a request XML is XYZ format and Server will give response in ABC format. Without this, SOAP does not work. This is what is defined in WSDL. So we have to use WSDL.
Tools like wsimport, wsdl4j convert these WSDL files into an object hierarchy and prepares a JAXB wrapper for you, to make life easy!
Now if you do not want to use the tools which automatically convert WSDL to Java Beans or anything of that sort, note SOAP is based on nothing but an XML. If you know how to parse an XML in java, thats pretty much it. You can use a JAX Parser to achieve this and you can read everything that comes in a SOAP request and response.
The problem that you will face is, as the complexity of the SOAP XML grows, it will be difficult for you to parse the XML properly, identify the nodes, values and relations properly. And add to that the problem where in you cannot, without a proper object hierarchy , relate between nodes which are distance apart. Meaning, from line 100 you cannot go back and relate a line 10 node, unless you start maintaining your own objects, relations etc. (which is not what you want, i guess)
Using Java Beans the object hierarchy is maintained and because of that it is easy for you to relate them between different objects at different nodes easily. But JAXB is comparatively slower than JAX.
I am trying to create a RESTful webservice in java, but , as I am new to this, I am not sure
if there is a tool like wsimport (for SOAP based webservices) which can be used to create the Data objects or Entities (resources in REST world).
I searched the net for examples..But all of them seem to be the hello world types with no clear data modeling details.
How do I create the Data objects for a RESTful Webservice from scratch using just a XSD file ?
Any pointers will be helpful!
RESTful webservices do not have a contract like SOAP so automatic code generation for the services is difficult unless the RESTful webservices are using WADL (not very commonly used). If you are using WADL, you can use CXF to generate java code.
However if you have XSD files you can generate java code classes for them using JAXB (xjc is the command). This will work well for the Data model objects, service classes will probably need to be hand coded.
See the accepted answer in this question: How to generate JAXB classes from XSD?
A couple more links that might help:
JAXB XJC tutorial
If you use Intellij, see this
I want to transfer hibernate objects with GWT-RPC to the frontend. Of course i can not transfer the annotated class because the annotations can not be compiled to javascript. So i did the hibernate mapping purely in the ".hbm.xml". This worked fine for very simple objects. But as soon as i add more complex things like a oneToMany relationship realized with e.g. a set, the compiler complains about some serialization issues with the set (But the objects in the set are serializable as well).
I guess it does't work because hibernate creates some kind of special set that can not be interpreted by GWT?
Is there any way to get around this or do i need another approach to get my objects to the frontend?
Edit: It seems that my approach is not possible with RPC because hibernate changes the objects. (see answer from thanos). There is a newer approach from google to transfer objects to the the frontend: The request factory. It looks really good and i will try this now.
Edit2: Request factory works perfectly and is much more convenient than RPC!
This is a quote from GWT documentation. It says that hibernate changes the object from the original form in order to make it persistent.
What this means for GWT RPC is that by the time the object is ready to be transferred over the wire, it actually isn't the same object that the compiler thought was going to be transferred, so when trying to deserialize, the GWT RPC mechanism no longer knows what the type is and refuses to deserialize it.
Unfortunately the only way to implement the solution is by making DTOs and their appropriate converters.
Using Gilead is a cleaner approach (no need for all this DTO code), but DTOs are more ligtweight and thus produce less traffic through the wire.
Anyhow there is also Dozer, that will generate the DTOs for you so there will not be much need for yo to actually write the code.
Either way as mchq08 said the link he provided will solve many of questions.
I would also make another suggestion! Separate the projects. Create a new one as a model for your application and include the jar into the GWT. In this way your GWT project will be almost in its' entirety the GUI and the jar library can be re-used for other projects too.
When I created my RPC to Hibernate I used this example as a framework. I would recommend downloading their source code and reading the section called "Integration Strategies" since I felt the "Basic" section did not justify DTO. One thing this tutorial did not go over as well is the receiving and sending part from the web page(which converts to JS) so thats why I am recommending you downloading their source code and looking at how they send/receive each the DTOs.
Post the stack trace and some code that you believe will be useful to solving this error.
Google's GWT & Hibernate
Reading this (and the source code) can take some time but really helps understands their logic.
I used the next approatch: for each hibernate entity class I had client replica without any hibernate stuff. Also I had mechanism for copy data between client <-> server clases.
This was working, but I belive current GWT version should work with hibernate-annotated classes..
On a client project, I use Moo (which I wrote) to translate Hibernate-enhanced domain objects into DTOs relatively painlessly.
I want to access an external RESTFul Web service via Java, and use an open source package that processes the returned XML or Json result and creates object(s) from this data.
I know that there are many solutions out there for this, and I'd like to get your feedback on which one I should use.
For accessing the web services, I know that I can use packages such as apache HttpClient etc. but I'm sure that there are packages that wrap this and also take care of processing the returned data (i.e. creating java objects from the result).
Thanks,
Nina
Spring is great, but this is one case where there are higher-level libraries out there that make it even easier. See for example the clients that come along with JAX-RS implementations like the Jersey client and the CXF client. Some implementations can even provide clients through dynamic proxying if you have a service interface and resource classes available. This way, you hardly have to write any code at all.
Spring Rest Template is your friend.
Spring MVC has something called "RestTemplate" which can be used exactly for this.
http://aruld.info/resttemplate-the-spring-way-of-accessing-restful-services/
http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/
Im pretty new to Java Web Services, but I cant find a good explanation anywhere.
I have 2 Java web projects within NetBeans.
One as a web service and one as a client for that web service.
I have also created my own class called "Person", which has what you'd expect: name, dob, etc.
I would like to have a web service method called "ListPeople()" that would return an array of "Person" objects.
Do I need to have that class in both projects?
Should I be serializing the object first?
Should I be using JAXB, if so, where do I start?
Sorry for the n00b questions, but im confused.
What is the normal way of accomplishing this?
Thanks in advance
Do I need to have that class in both projects? Yes.
Should I be serializing the object first? No.
Should I be using JAXB, if so, where do I start? I would not. I prefer the javax.oxm interfaces, because I don't care for JAXB, but that's a personal opinion.
My personal preference is to use Spring web services. If you happen to be a Spring user, I think that's the best way to go. If not, perhaps the docs will still help to clarify.
You're experiencing the reason why I don't like your approach: both the service and client and dependent on the class and OXM code. You have to have it in both places, in perfect synchronization. Change one and you have to change both.
I try to minimize dependencies if I can.
And in this case you can if you send XML back and forth. Start with an XSD schema. Let the client and service deal with that instead of Java objects. Your service will be usable for clients that aren't Java that way.
If you take this approach, you only have to worry about OXM on the server side. You take in the XML request and marshal it into the Java object of your choice and pass it to your service layer (note: NOT web service layer) for processing. Turn the response object into XML response stream and Bob's your uncle. Let the client deal with that.