I need to work with a REST service that has a relatively simple and fixed (meaning predictably not very variant structure), yet I can't find a WADL anywhere on their site. I have previously worked with SOAP services, which had a decent WSDL and I used it to generate my Java classes to which my client app was marshalling the service data using Axiom2.
My question is: is there an easy way to reverse engineer a WADL with which to easily generate corresponding Java classes if the site is lacking one, using some implementation of JAX-RS (e.g. Jersey)? Another way to ask it is: given only a REST service, no WADL, and some form of JAX-RS, what is the easiest way to generate marshalled classes on the client side?
Currently, as the structure is simple, I do it the hard way of using straight DOM from Java SE (org.w3c.dom) to parse the document. It works fine but I do not like all the traversing I have to do within the document structure and I feel like I reinvented the wheel. I am sure there is a more elegant way.
If you're just doing this once why not just do it by hand? If you need to do this regularly then you may be out of luck wrt WADL (as an aside see: https://softwareengineering.stackexchange.com/questions/133145/should-i-use-wadl-to-describe-my-restful-api).
Are you just trying to generate Java classes for the DTOs from the service? In this case you could take some sample XML from the service and use this to generate a possible XSD (maybe using trang). Then use XJC to generate the corresponding Java classes.
If the REST service is implemented in Jersey, Jersey should auto generate the WADL at runtime. The default location is http://server:port/appcontextroot/application.wadl. If the REST service uses other implementation such as RESTEasy, you are out of luck. https://issues.jboss.org/browse/RESTEASY-166
Related
I am working on an application which is built in .NET and Java. The Java component contains the complete Rule base using Redhat BRMS suite. The .NET client (UI and desktop based applications) will be consulting the Java Rule engine and sending/receiving the JSON data. The decision which has been taken is to expose the Rules engine (Redhat BRMS 6.0.0 using Drools) as a REST based API. I have come-up with the following design approaches:
Write a REST controller in Spring framework and service classes for calling BRMS.
Write a simple REST controller using JBOSS proprietary RESTSY or JAXRS.
Write a Camel adapter and wrap the REST calls behind the Camel and let the Camel talk to Drools.
Wrap REST behind SOAP based webservices.
I want to ask which one would be the better approach for designing such as System.
Any other thoughts are welcome.
As might be obvious from https://github.com/gratiartis/sctrcd-payment-validation-web and https://github.com/gratiartis/qzr my general preference is for exposing my Drools business rules using REST APIs in a Spring application.
The only alternative I consider in the above list is 4, where the API is exposed through a SOAP web service. Albeit definitely not wrapping a JSON REST service! A well-designed Spring application can expose functionality through both REST and SOAP APIs with very little effort.
I have usually exposed via SOAP when working with .NET clients. Firstly, the .NET tooling has excellent support for generating proxies based on WSDL that you have defined. Secondly, the WSDL forms a well-defined contract which both you and the client developers must obey. Having a strict contract can be very useful in preventing arguments. Although if your interface is simple, it may not be so much of a benefit.
The other key reason is that the WSDL does not change unless you change it deliberately. A REST JSON API may seem quick to develop, thanks to Jackson generating everything for you. However, it can expose your internal object model (and dependencies!), meaning that unless you are careful, what seems like a trivial change to an internal model can make private data visible and can break clients.
All that said, if you can keep the API reasonably simple and have a good relationship with the .NET devs (perhaps you're one of them), then going with the Spring REST API would be my recommendation. Feel free to steal code from the github repos if it can help you get started!
btw - If you were to consider Camel, it's worth noting that there is a Drools-Camel component which does quite a bit of the work for you.
In my view,
I would go with the option 1. This is the simplest and easiest approach.
Option 2 may be second choice.
Option 3 - Looks like if there are some routing rules you could choose. Again its could make it complex.
And definitely not option 4 to make it complicated with SOAP.
sudzc is a very good online tool to get a bundled API for sending request to a SOAP service and get response from service using WSDL link of that webservice. I want to know is there is anything available like sudzc for java?
I'm also looking for something like this - there seem to be plenty of WSDL-to-Java utilities out there but most are unmaintained or don't support Android. The closest I can find is this Android ksoap2 stub generator. It appears like the perfect thing but I've not had a great deal of success with it (the generated code is very hit-or-miss), but that might be my WSDL files. Hopefully you have more luck with it.
Would SoapUI do what you need? It's very useful as an interactive testing tool, but it also interfaces with different Java libraries (Axis, Jax, etc) to create Web Services Java code.
All
I am looking for some method to show metadata info about RESTful webservice,
e.g. operations, parameters and so on.
Do u know any ?
One popular solution is to use Atom and AtomPub
I hear HTML is popular for representing end point meta data. You have link refs, you have forms for payloads, lots of room for english text to explain things, the format is well documented with a well known processing model.
Some rest endpoints support WADL.
WADL to REST is similar as WSDL to JAX-WS (SOAP).
You can find more about wadl at: http://wadl.java.net/ (including specification link).
Jersey (http://jersey.java.net) is a Oracles JSR-311 Reference implementation and it also have some additional features, like automatic WADL generation, which was recently (version 1.9) improved - it includes XSD schema for transmitted types (that can be used for far better client code generation).
In general, if you want to use some standard, please use WADL and don't reinvent the wheel..
The jax-doclets package can generate javadoc-like documentation from your JAX-RS or JAXB annotations.
http://www.lunatech-labs.com/open-source/jax-doclets
On our projects we currently generate documentation by hand but we are beginning to evaluate this tool.
Now, working with Spring-WS, I sometimes miss the simplicity of working with axis, where you just call a tool on the WSDL and XSD, and it creates the java objects and marshaller configurations, an interface that represents the information in the WSDL, a complete webservice client that implements this interface, and a server stub. Within minutes you can start writing the actual code for the webservice.
With Spring-WS you have much more configuration work to do - you have configure a marshaller, an endpoint, code all the information in the WSDL manually, and using the soap faults from the WSDL in form of java Exceptions seems difficult. Is there any tool that simplifies this work to a similar degree? I understand and appreciate that Spring-WS is flexible and whatnot, but sometimes you just want to whip up a quick webservice.
If you want the quick-and-easy tooled approach, then Spring-WS is not for you. It emphasises flexibility, small footprint and runtime simplicity, at the expense of having a bit more to do at first.
If this isn't what you want, then stick with the more heavyweight stacks like CXF or Axis2.
It's explained on this page: Why Contract First?. Basically, since there are problems to be solved when starting from a WSDL, they have chosen to drop the ball. If you want to work from a WSDL and keep being integrated with Spring, then choose CXF.
Which Java SOAP XML object serialization library would you recommend for Java object exchange with other platforms / languages (.NET, Delphi)?
Communication scenarios could look like this:
Java object writer -> SOAP XML text -> .NET or Delphi object reader
.NET or Delphi object writer -> SOAP XML text -> Java object reader
I know there is the XStream XML serialization library and JSON as alternative solutions, however since Delphi and .Net have built-in support for SOAP XML serialized objects, this would offer a 'standardized' way with support for advanced features like nested objects, arrays and so on.
Edit:
Meanwhile, I found JAXB - (https://jaxb.dev.java.net/), JAXMe, and JiBX - Binding XML to Java Code(http://jibx.sourceforge.net/). But they do not generate SOAP serialized XML by default.
A possible solution would be a web service library which is able to run without a HTTP server, and offers a simple file interface for the SOAP XML content (not a complete request, just a serialized object). Axis 2 and CXF look very interesting.
I prefer JAX-WS (with JAXB 2.1 databinding) over the other liberaries I've used (JAX-RPC, Axis 1 and 2, but not XFire). The JAXB 2 databinding uses generics, which makes for a pleasant mapping of properties with a maxoccurs > 1. JAX-WS itself is reasonably well documented and provides a reasonably good API. The method and parameter annotations can get a bit out of hand in some cases - XML hell in annotation form. It usually isn't so bad.
One of the nice aspects of the JAX-WS stack is project Metro, which Sun co-developed with Microsoft and interoperates well with the web service support .NET 3.0, going so far as to implement MTOM in a workable fashion.
I would recommend CXF. It is a very good services stack and includes JAXB data binding and JAX-WS support. You may want to look at an open source integration platform like Mule that includes CXF (also supports Axis and XStream) if you need more advanced transformation and routing of your messages. It is lightweight and can be embedded or run without an app server.
In addition to Axis2 which works ok, Sun's JAX-WS (version 2) and Apache CXF (nee XFire) are worth checking out, it Soap is your thing. CXF may be the most mature of the 3, so that's my favorite, but all 3 are pretty good.
The standard library for this would probably be Apache Axis1. I would advise using axis2 instead of axis 1.4- though it works pretty well.
Bearing in mind that the all of the SOAP extensions make the dream of interoperability just that... a dream.
I think you have answered your own question.
XStream (outputting as JSON) is a nice clean solution. If you alias types you get a clean output format. After that it doesn't matter which SOAP stack you use so long as it is nice and interoperable with Delphi/.NET.