views:

138

answers:

3

I need to integrate some services that are external and that are offered as SOAP Services. I don't like to use SOAP inside our system for a few reasons. I think from a pragmatic point of view it should be fairly easy to adapt SOAP to REST. This is not a SOAP vs. REST question!

I'm just trying to collect java libraries, code, howtos etc. to accomplish this. Due the difference in its nature I don't expect a ready made solution. Just a couple of hints for tools and such to get going.

+1  A: 

Apache CXF has support for REST services by implementing the Java JAX-RS 1.0 standard.

JAX-RS is part of the JavaEE 6 standard and its interfaces live in the javax.ws.rs namespace.

DevX has an article on how to write services for JAX-RS, although they use the reference implementation (Jersey) to do it.

R. Bemrose
I don't want to implement a REST service. I want to translate a REST request to a SOAP request. And to be honest I try to make thinks _less_ complicated :) Therefor the CXF link did not seem to be very helpful in that case. The DevX link can only be read if you are registered and I'm not
Norbert Hartl
The way you have your question worded is sounds like you want to consume SOAP services and expose them through a RESTful interface.
laz
Yes, that is what I want to do. Maybe I didn't get the CXF page. The things I saw were bindings/adapters/.. to several standards. So to me it appears as a intermediation tool between all things called "SOA". That means it makes things complicated at first. And taking that I can state that I'm looking for quite the opposite.
Norbert Hartl
Oh, I was under the impression that you wanted to getting rid of a SOAP service and replacing it with a REST service, not that you were having one call the other. CXF supports both types of services; you could write a REST service that in turn calls a SOAP service, as CXF supports both.
R. Bemrose
Do you have any examples/links dealing with exactly that case? What I could grok from the CXF site is that is indeed possible to do this. But on the other hand it appeared being very complicated to achieve simple things. So a few handwoven adapters might be more easy/feasible to do.
Norbert Hartl
Thanks for the hint. As I don't have a server to play with I was kinda stuck. But then I saw that CXF is generating dummy impls for the server side. That is perfect!
Norbert Hartl
@Norbert Hartl: Sorry about not responding to your previous comment: I've never actually gotten to use CXF in any projects... we still use Apache Axis1 in any Java apps that use web services, and the producer side is in .NET.
R. Bemrose
+1  A: 

Your best bet may be to create your own layer that translates the REST calls made from your application into the equivalent SOAP calls expected by the external service, and translates the responses going in the other direction. You could implement this layer as a RESTful web service (basically a proxy), which would eliminate SOAP dependencies inside your system.

Rob H
I was thinking about that and it is still my last ressort. I hoped there might be other supporting stuff to ease the task. So I take your vote as a confirmation of my original thought ;) thanks!
Norbert Hartl
Unfortunately, I don't think you'll find a good universal REST-to-SOAP translator. The two programming models are quite different and in order to do a coherent translation, it takes a human to understand the semantics of the interface, assuming the interface is nontrivial.
Rob H
I tried to acknowledge this in my question already. I know the two models have enough differences that make a generic solution hard to achieve. On the other hand it is projecting a graph (references) into a tree (url path) and the rest is type safety. My use case is XML centric anyway so that every response from the SOAP server is better being handled by XPath or XSLT. I'm not interested in intermediate java objects
Norbert Hartl
I think it's worth mentioning that if you use a tool like Spring Web Services, programming a SOAP client is really not very difficult and shouldn't intrude much on your code base. You can supply the XML payload yourself if you wish and you can parse the response with XPath or XSLT without creating/generating Java domain objects.
Rob H
It is less about intrusion of my code base. Most of the system is really HTTP centric. So I want to push the SOAP stuff to the borders of the overall system to be able to leverage the use of other services like caches etc. There needs to be a conversion to HTTP anyway because that is what the clients consume. So I want to convert/adapt it as early as possible.
Norbert Hartl
btw. I looked at Spring Web Services and that looks interesting
Norbert Hartl
A: 

If your SOAP services are based on a document oriented approach already you might want to think about simply putting an HTTP gateway (aka reverse proxy) in front of them. Maybe a little transformation is all you need for a large percentage of your use cases?

(Document oriented SOAP is referring to an 'approach' where the SOAP message act as control wrappers around business level documents as opposed to serialized domain objects. With a document oriented style you might be pretty close to an HTTP based solution using GET and POST.

This http://www.coactus.com/blog/2005/07/towards-truly-document-oriented-web-services/ might help clarify my point.

Jan Algermissen