Jersey/JAX-RS Mule Connector
March 6th, 2008This week I put the finishing touches on the first version of a Jersey connector for Mule. It makes it really easy to drop in JAX-RS services into a Mule application.
For the non-Mule users out there - you’re probably asking, why would I need Mule and JAX-RS?
Imagine this scenario: you receive messages over HTTP. You wish to process these messages asynchronously with your backend servers. With Mule its pretty easy to set up an HTTP listener and connect it to a JMS queue. You can then have pull messages off the queue and process them asynchronously within a transaction. JAX-RS makes it very easy to map your Java class to resources with it’s simple annotations.
While you could piece this together all yourself, Mule is like integration glue - it makes connecting all these things easier. </marketing>
March 8th, 2008 at 10:59 am
Hi Dan, nice to know this Jersey connector is ready. I’d like to know something.
I’m currently implementing some asynchronous operations that populate a queue that will be processed with some batch instances. We’re thinking about using an Atom Feed for this queue, but haven’t decided yet how we’re gonna do the batch processing.
The component that populates the queue exposes RESTful interfaces that manipulate plain XML (not using Atom). Does Mule have support for batch processing such content? The XMLs and the queue are not very complex. If Mule offers a nice way of processing such a queue, then I’d certainly consider using it, perhaps refactoring our RESTful interfaces to use this Jersey connector.
March 9th, 2008 at 7:06 am
I’d rather see you contributing to a CXF JAX-RS implementation to make it as good or even better as Jersey
March 9th, 2008 at 11:49 am
I see the CXF JAX-RS implementation as kind of redundant. Why not just embed the Jersey JAX-RS implementation? Its quite emedddable…
March 10th, 2008 at 12:45 pm
Should we take it to the CXF-DEV list
?
That said, a couple of comments.
Lets take JAXB. Everyone has it embedded, right ? I believe there’s very little space fro innovation there. It’s a low-level activity (dealing with schema and (un)marshalling). JAX-RS is different, this is where services are provided and there’s more space for the innovation there and eventually for some healthy competition. As you’d likely agree, JAX-RS alone is not of much value, it’s the combination of tools and services provided by the containers which make the difference.
So I’m not quite ready to agree that CXF JAX-RS is redundant even though integrating with Jersey is an option. What would you say of at least two other non-Sun JAX-RS implementations ? Is CXF JAXWS redundant given that a good quality JAXWS reference impl is available from Sun ?
March 10th, 2008 at 1:45 pm
Re: JAX-WS - I’m beginning to think so, yes. Companies like BEA are now completely on the JAX-WS RI band wagon because it simply doesn’t make sense to invest in all these alternate solutions. JBoss is in the same boat. If Sun had approached the whole RI differently and in a more open source manner, there is a good chance I would have advocated a move to Metro instead of founding CXF.
That aside, where is this value and why can’t it be done by reusing the existing implementation out there? I asked this same question to Bill Burke of JBoss but never got a satisfactory reply.
While the tools and services do make a difference, Jersey doesn’t suck, they accept contributions/feedback quite readily. Same for the Metro team. The only thing the Metro team has done wrong IMO is broken API backward compatibility from 2.0 to 2.1.
March 10th, 2008 at 1:55 pm
I’m not trying to say that CXF currently doesn’t add value - it does do some cool things. Its just that in retrospect, given the quality of the RI now, it may have been better to all just work on one thing. Given Sun’s past though, the RI would not have been a safe bet to make and it did suck for quite a while.
March 10th, 2008 at 8:06 pm
Bruno: if I understand, you’re trying to find the best way to consume restful queues via Mule?
All Jersey does really is make it easy to build RESTful interfaces. You could use the HTTP polling component inside Mule though to poll for new things on the queue. This configuration is a little out of date (it’ll be updated by next week when our RC3 release is out), but you may want to look at this:
http://www.mulesource.org/display/ABDERA/Cookbook
The PollingHttpReceiver understands ETags out of the box as well.
March 10th, 2008 at 9:00 pm
Hi Dan, i just looked this HTTP Polling Component, and I think it might help me. In the next few days we’re going to discuss the queue implementation and processing, and then i’ll analyse the possible options, Mule among them.
Thanks again for the help.
March 10th, 2008 at 9:08 pm
By the way, just to leave my thoughts on embedding Jersey. I think this should be the default options for most tools supporting JSR-311. I haven’t used Jersey yet for production code, but from what I could see so far, they’re doing a very good job.
The parts of the JSR regarding the URI mappings (into classes and methods) and the support to multiple content-types is very helpful, and I wouldn’t like to reimplement this. I developed some URI mapping logic with custom annotations before i got to know Jersey, and I definitely prefer to have it as a container feature than to implement it myself.
Developing support for multiple content-type would be even greater trouble, and I will definitely skip doing this
This seems to me as much effort as developing Hibernate Database Dialects.
Why not contributing to Jersey in features they might not address very well?
Just my 2 cents