Application Architecture for the Enterprise

« Day-to-Day: JEE5 Web Services | Main | Day-to-Day: JEE5 Analsysis Review »

JAX-WS is Bad, Bad!

I spent the day today researching Java Platform, Enterprise Edition 5 (JEE5) web services including the new Java API for XML Web Services 2.0 (JAX-WS), which is supposed to replace JAX-RPC. A while back I wrote that JAX-RPC is Bad, Bad, Bad! I gave a couple reasons of my own and also pointed to a paper from HP that clearly articulated JAX-RPC faults. JAX-WS 2.0 isn't much better, but to be fair I've given it only two Bads rather than three.

I spent 18 months writing a book on J2EE Web Services and when I was done I concluded that JAX-RPC was a grossly over engineered train wreck. The book I wrote was something short of 1,000 pages (Addison-Wesley reduced the font and changed the page layout to keep it below that threshold for marketing reasons). When I finished the book in 2004 I had made use of every fiber of that 1,000-page count and I still couldn't get into detail about everything. For example, the book was almost entirely a reference with only some tutorial aspects and very little in the way of architectural design. To me, if it takes 1,000 pages to write a reference book about a Java API, its likely that (a) the API is way to complex or (b) the writer sucks. I would prefer to blame the API. If I was to update the J2EE Web Services book for JEE5, it would probaby be longer than the first edition (no worries there; I have no intention of coughing up that hair-ball).

Sadly, I was little more impressed by JAX-WS 2.0, which is not as messy of a train wreck as JAX-RPC, but is still a train wreck. Yes, JAX-WS 2.0 does support annotations and they do cut down on the amount of XML configuration files you have to write, but even if you cut the XML required by JAX-RPC by 60% its still too much in my opinion. For the simplest web services (you know the ones that you'll never implement) JAX-RPC works fine, but once you get into more realistic scenarios the whole thing becomes an XML nightmare. JAX-WS 2.0 successfully reduces the configuration needed by introducing annotations with reasonable defaults, but it’s still a horribly complex technology. Again, really simple web services will probably be pretty easy to implement, but when it comes to supporting real-world scenarios it's going to get messy. Not only is the runtime behavior, including handler chains, still complicated but the number of annotations required could make source code (end-point interfaces or implementation classes) look like 20 kids tagged it with spray cans. It will be hard to see the code through all the annotations.

Doubt what I'm saying? Try to implement the eBay and web services with JAX-WS 2.0 – if it's really easy than show me and I'll eat my words. There you go JAX-WS 2.0 team: A challenge! You guys ought to be ashamed of yourselves. You could have taken this opportunity to re-engineer J2EE web services into something really simple, but you decided to put lipstick on the Pig instead.

NOTE: I recently posted my experiences trying to get JAX-WS to work against, Google, and eBay. The experience bears out my initial assessment that JAX-WS is a poor solution. See "Redeemed: JAX-WS still sucks!"


TrackBack URL for this entry:

Listed below are links to weblogs that reference JAX-WS is Bad, Bad!:

» JAX-WS is Bad, Bad! from Stefan Tilkov's Random Stuff
RMH on JAX-WS: Doubt what Im saying? Try to implement the eBay and web services with JAX-WS 2.0 if its really easy than show me and Ill eat my words. There you go JAX-WS 2.0 team: A challenge! You guys ought to b... [Read More]

» JAX-WS ist böse? from IT Blog
Gerade bin ich von einem Kurztripp zurück, da muss ich doch in RMH's Blog lesen, dass er für seine Analysten-Beschäftigung die WebService Fähigkeiten der JEE5 Platform untersucht hat: JAX-WS ist fast so schlimm wie JAX-RPC. Letzteres hatte er, nachdem die [Read More]

» Does Java EE 5 getting REST mean WOA will break out? from Enterprise Web 2.0
The REST vs. SOAP debate can seem like an esoteric discussion about Web services, but it's not. REST puts the Web back into Web services by taking what's been so successful with the fundamental protocol of the Web, namely HTTP, and making it into a se... [Read More]


If you feel JAX-WS is even only a small improvement over JAX-RPC, then I guess it's really good given how the underlying new WS standards have evolved to something insane (WSDL in particular).

I feel a little better now about putting down your Java Web Services book after a few hundred pages. I enjoyed the writing, but the whole very thick book was just a daunting read. Glad to know it gave you very serious reservations about the whole API.

The book has been useful to those folks who have no choice about what Web services technology they will be using (J2EE) or to our friends in India who use it for certification in J2EE Web Services. However, if you are trying to choose the best web services platform and do not have to use J2EE, than I would recommend looking elsewhere. I would love to give a recommendation, but I don't know if there is one worth recommending. In my opinion, the simpler the better. Personally, I like the idea of using E4X (Java/ECMAScript for XML) to process web services. There is no xml-to-object mismatch that way and is a pretty straightforward. This is kind of a radical (although not original) idea as most believe mapping XML web services to a remote object model is better, but I don't think that's the answer.

Personally I think for complicated messages it makes no big sense to map them on Objects. I prefer to use the low level APIs to get the Documents, and then process them with normal XML processing tools.

Exactly this kind of operation is hard to do with Toolkits like JAX-WS (JAAS is here only used) or AXIS.

I totally agree with RMH that mapping onto Objects is by itself so complicated, and seldom worth it. The whole Meta-Data driven approach much better works if you have a Schema to work with, and route real documents through your system.

But of course my viewpoint is more from the middle ware side and less from the Application Developer perspective.


C'mon dudes, it looks like you missed two chapters from the spec. JAX-WS may have its flaws, but unlike JAX-RPC it does offer pretty straightforward ways to operate at the XML level in both the client and the server. Take a look at section 4.3, "" and section 5.1, "". On the other hand, there is nothing radical in working at the XML level. Any application that performs generic message processing works at that level. WS-BPEL engines are good examples.


The sections you reference (4.3 Dispatcher and 5.1 Provider) do indeed show an approach that is more direct than the rest of the JAX-WS API. But, those sections use up 5 pages of a 143 page specification! And that is just the JAX-WS part of the specification, it doesn't include aspects of implementing JAX-WS that are left to other specifications such as the Web Services Annotation specification, JEE5, EJB 3.0, Servlets 2.5, ad noisome. I think it would be a little presumptions to excuse the entire hair-ball called "JAX-WS" because it managed to get closer to something usable in five out something like 200 - 300 pages of documentation. It's kind of like saying that a Rube Goldberg machine is a good solution because one of the thousands of operations (e.g. ringing a bell or throwing a little ball through a hoop) does something useful. You are ignoring the fact that the whole thing is a huge can of worms.


1. Sign up your ebay account
2. Download the RI, import the wsdl.
3. There is a bug in the early access where headers arent bound, correct it by adding this annotation:
@WebParam(name = "RequesterCredentials", targetNamespace = "urn:ebay:apis:eBLBaseComponents", partName = "RequesterCredentials", header = true)

4. Write this code
import ebay.apis.eblbasecomponents.*;
public class Foo
public static void main(String[] args) throws Exception
EBayAPIInterfaceService service = new EBayAPIInterfaceService();
EBayAPIInterface eBay = service.getEBayAPI();

CustomSecurityHeaderType header = new CustomSecurityHeaderType();
header.setEBayAuthToken(" Insert Auth Token ");
UserIdPasswordType creds = new UserIdPasswordType();
creds.setAppId(" APP ID ");
creds.setDevId(" DEV ID ");
creds.setAuthCert(" CERTIFICATE ID ");

GetItemRequestType request = new GetItemRequestType();
request.setVersion("453"); // Payload version
request.setErrorLanguage("en"); // Language for error messages
GetItemResponseType response = eBay.getItem(request, header);
ItemType item = response.getItem();
System.out.println("Title :" + item.getTitle());

5. Run it:

Hi Jason,

Thanks for the example. It does look simple in this case. I'll tell you what I'm going to do. In fairness I'm going to download the RI and attempt to duplicate this example. If its as easy as you make it look than I'll eat my words, but this is what I suspect: It's going to take me forever to figure out how to deploy the web service in the first place not to mention configuration and execution. I would be enormously happy if I was wrong as I would like nothing better than for JAX-WS to be as simple as we need it to be, but I have my doubts. I hope you are right and I'm wrong. I'll get back to you Jason. Please send me your real mailing address - you left a fake identity.

Hi Richard,

Sorry about the "nospam" email address, I have been getting alot of spam lately and I am paranoid it's web crawlers. I assumed that you wanted your challenge to be a client since you mentioned ebay and amaazon. For JAX-WS clients, you don't need to deploy anything, all you need is the generated annotated classes, and propper implemenation and api jars in the classpath. You could of course implement the server side by defining a class that impelments the endpoint interface, and reuse the same classes generated by wsimport, although ebay has alot of methods to implement (their wsdl file is 2.5 megs) :)

If you decide to reproduce this, the biggest challenge is getting all of the eBay stuff set up. You have to request a developer account, self certify the account, and associate it with an ebay user. Also, I forgot to note that eBay uses a nonstandard encoded url that duplicates some data in the ws request, so you will have to modify soap:address in their wsdl.


OK. Jason, thanks for giving me some more detail. I'll set it up as a client and see how it goes .... I should have something to say (or eat!) by the end of the week.

About the J2EE WS book. It is rather good. The reason that it is soooo big is
that it describes almost everything about webservices.. not only the j2ee part.

Well, that's true. But really only the first 270 pages are general in nature covering XML, XSD, WSDL, SOAP, and UDDI. The rest of the book is (except for some appendix material) is specifically about J2EE Web Services most of which covers JAX-RPC, SAAJ, and JAXR.

I'm curious about the revisiting of jax-ws based on Jason's comments. Richard, do you have an update?

Ok, so here is the deal on Justin's code: I have not taken the time to download the RI, set up an e-bay account, and try it out. I probably won't have time anytime soon, so I'm going to accept Jason word that it works. As promised I'm printing off the blog entry and plan to eat it tonight. I'll take a picture as proof but for the most part you'll have to take my word for it. Having done that, I want to get back to my original point. It is very complicated to set real-world web services with JAX-WS. There is a difference between a web service client and a web service ... ah .... service. What I'm talking about is hosting services implemented with JAX-WS using EJBs or service endpoints (pojos running in servlets). That points stands. Unfortunately for me however, I framed my challenge badly. Instead of making it easy to "access" a web service I should have said "implement" a web services defined by e-bay and In other words, using the WSDL that defines the e-bay and web services can you implement all of them in an Java EE using JAX-WS; if you had to host the services yourself how easy would it be to set up? That's what I meant, but that's not what I said so I humbly admit my error and look forward to a desert of Dynex multi-purpose paper after dinner. Hopefully it will not cause me too many problems with the plumbing.

Well I decided to try this. Besides all the headaches in getting all the Ebay pieces setup properly (their tool to create user account in the sandbox doesn't work and you have to search their forums to find this out and how to do it manually) the code example doesn't compile. It was easy to import the WSDL using wsimport but now the the eBay.getItem signature is now different:

GetItemResponseType response = eBay.getItem(request); // Old: .getItem(request, header);

Also there is some mention about changing the Ebay WSDL. What exactly does that mean? There doesn't seem to be any non-standard encoding that I can see in that element.

I'm still waiting for this to become easy at least on the client side. I'm just a plain old developer looking to use others web services. Why does it have to be hard?

Hi Dave,

Thanks for trying it out. I wish I had seen this post before I had breakfast this morning!



As I said, The difficulties are all on the eBay side, so complain to them. Oh, and you left out step 3 a BUG in the RI not a spec flaw.

3. There is a bug in the early access where headers arent bound, correct it by adding this annotation (modifying the endpoint interface):
@WebParam(name = "RequesterCredentials", targetNamespace = "urn:ebay:apis:eBLBaseComponents", partName = "RequesterCredentials", header = true)

Regarding the non-standard encoding, its in their documentation, but since you are having problems this is what i meant:


This got chopped (xml tags in comment):


Much of this criticism focuses on the ease of use, or the lack thereof, of the JAX-WS stack but I have a more fundamental problem with any web services toolkit found in Java or even .NET - the much touted advantage of generating a Web service endpoint out of existing code (annotated or otherwise). This flies in the face of a contracts-first design approach, leads to interop issues and keeps reinforcing the view that web services are just RPC with XML. There is no loss-less translation between XML and Java and using a tool to generate the interface from a programming language artifact will only result in proliferation of API-focused, potentially uninteroperable Web services. The focus should be on the schema and the message, not the programming langugate data types and parameters and a generated afterthought of a Web service.

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.