A Rant about GlassFish and Jersey

So you want to play around with Web Services, both SOAP and REST? Maybe you've had your fill of WSO2's Mashup Server, drooled over its strengths (XML processing and service exposure) and understood its limitations (legacy resource connectivity including persistence - no, Data Services didn't cut it for me). Now you want to look at a more conventional, Java-based (as opposed to JavaScript-based) server.

I had attended a Sun Tech Day many months ago when they demonstrated the GlassFish JEE app server and its REST implementation called Jersey. I had also heard a lot about Sun's advanced SOAP/WS-* stack, Project Tango. One of my consultant colleagues (a REST advocate, no less) showed me a Tango demo he had put together and was himself impressed with the policy-driven interoperability that it made possible.

So it was with fond visions of being able to build a Domain Model using Java objects and then expose the domain as services using both SOAP/WS-* and REST paradigms from the same box that I downloaded GlassFish.

The GlassFish Quickstart Guide gave me my first indications of trouble.

Why would you have instructions labelled Step 1 and Step 2 if there's something you need to do before either of them? (Shouldn't that at least be labelled Step 0?)

Steps

1. Add the install-dir/bin/ directory to the PATH environment variable.
2. Start the server by entering this command: asadmin start-domain domain1.

After searching in vain for the "bin" directory under the directory where I had installed (well, unzipped) GlassFish, I found this line above the two steps listed:

Once you install using "ant -f setup.xml", you start the server by starting the domain.

Casually, just in passing. Why they didn't just say

Step 0: Install GlassFish using "ant -f setup.xml"

beats me.

So I finally installed GlassFish and started up a "domain" from the command line. (All right, I'll go with your idiosyncrasies, although why I should know about "domains" and why you couldn't just give me a Linux "startup.sh" script and a Windows "startup.bat" script beats me once again.)

Oh, then I found that Jersey doesn't come bundled with GlassFish. I'd have to get that separately.

No problem, GlassFish has a tool called "Update Center", which lets you download modules like Jersey automatically.

Uh-oh. Update Center doesn't work through proxies. (You idiot, configure the proxy settings in the tool.) I did that. The "doesn't work" comment refers to after I configured my proxy settings in Update Center. And I didn't get a meaningful error message either, so I had no clue how to fix the problem, if indeed the problem was my fault. (These guys are starting to bug me.)

OK, good news, bad news. It appears from someone else's experience that Update Center only shows you older versions of Jersey, not the very latest one, so you can't use it anyway. You'll need to download and install Jersey manually.

All right, so I downloaded Jersey and ran the recommended script

$ ant -f jersey-on-glassfish.xml
-Dgf.home=$HOME/bin/glassfish install

Got the predicted error message, edited "jersey-on-glassfish.xml" and commented out the offending line. (Seriously Sun, even teeny-tiny Open Source projects provide working code. Why can't you?)

Finally got the ant script to work.

Hold on! Turns out there's something more. A lot more. To quote Drop By,

Be aware! This procedures will only install the examples and won’t add auto-magically the jersey jars to Glassfish’s runtime classpath. So
you have to take care by yourself to include the jars to the build target, see the provided examples:

Okay-doke. I ran

ant -f build-impl.xml library-inclusion-in-archive

I got an error with a TaskDef of all things. Some class (I forget what it was now) wasn't found, although it should have been. That's when I finally gave up.

There's simply no excuse for the abysmal state of readiness of GlassFish and Jersey. I know Jersey isn't yet at version 1.0, but GlassFish is at version 2.1, for goodness sake! In contrast, WSO2's Mashup Server worked, and worked pretty well, way back in the days of version 0.2. It was trivial to install and get running, the examples worked, and all my test examples worked as well. There were some problems that I faced, but those were when I had gone well past the basic stuff and started pushing the envelope.

I don't know if I have the time and patience to try GlassFish and/or Jersey again. It's just too hard.

My (unsubstantiated) Snapshot View of SOAP/WS-* and REST

At the moment, I haven't got the links to back me up, but I thought it's important to capture the thought before it escapes me.

I think SOAP/WS-* is an ambitious 100% vision for SOA that is 60% implemented.
And I think REST is a pragmatic 80% vision for SOA that is more than 90% implemented.

That model then explains to me the mutual contempt of both camps. The SOAP/WS-* group criticises REST for an overly simplistic model that does not cover a number of use cases - notably Quality of Service specification (security, reliability, transactions), policy-driven service interactions, process definition, exploitation of "industrial strength" message queue infrastructure, etc. That's because the SOAP/WS-* brief is all-encompassing. They've bitten off a lot.

The REST group criticises SOAP/WS-* for exactly that. They believe that SOAP/WS-* has bitten off more than it can chew. REST has taken a modest bite of the SOA problem, and has produced tangible results. What has SOAP/WS-* delivered except complexity?

A year ago, the winner of this argument would have been REST. But the SOAP/WS-* camp has been steadily chewing away at what they've bitten off. And delivering, bit by bit. Two words - Tango and WSO2. SOAP/WS-* complex? Vapourware? Not anymore.

Now it's the REST camp's turn to be defensive about their incompleteness of vision. We're beginning to hear mumblings about WADL, HTTPR and message-level security. I detect an air of defensiveness in talk about transactions and process definition. My long years of experience dealing with commercial vendors tells me that when someone questions the need for a capability, it usually means their product doesn't have it (yet). (Once they have the feature, it of course becomes indispensible and any rival product without it isn't serious competition.) Many of the RESTafarian arguments against the "unnecessary" features of SOAP/WS-* give me a feeling of déjà vu.

And oh, while REST is ahead of SOAP/WS-* on implementation, it's still not at 100%. Do let me know, for example, when PUT and DELETE are finally implemented by browsers. Ouch.

I'm not gloating that a bit of the REST smugness has been punctured (OK, just a little bit). I'm happy that the two worlds are improving their levels of maturity. In 2008, I'll be looking for REST to expand their vision, and for SOAP/WS-* to deliver on their vision.