In this blog entry entitled Taking RMH's JAX-WS Challenge, Jason Greene responds to another challenge of JAX-WS by Richard Monson-Haefel, with a workable implementation and walk-through of an Ebay web service from the server-side. He'd already done the same thing for the client-side, which generated a retraction -- and a challenge rephrased to point to the server side of JAX-WS instead.

I agree with Greene that JAX-RPC is easy. JAX-RPC mostly shields Java developers from the widely dreaded angle brackets. JAX-RPC is a de-skilling sucess story. Whereas Greene's antagonist, Loughran is evangelizing an alternative to JAX-RPC that goes in the opposite direction, raising the skill barrier:

...the XML must be faced and understood eventually. ... Developers will be expected to use XPath specifications to
work with contents of the message... If Alpine succeeds, it will be a SOAP stack that requires an understanding of XML before it can be used.

The REST vs. WS-* battle has been raging on in the blogosphere as of late and you just pick up on this blog post? Don't get me wrong, this is a worthy one, but I have been struck by how absent TheServerSide has been from the growing backlash against WS-*.
Here are a few links:
http://www.tbray.org/ongoing/When/200x/2006/02/22/WS-Flurry
http://www.tbray.org/ongoing/When/200x/2006/03/24/WS-Evolving
http://www.markbaker.ca/2002/09/Blog/

There are many more, but these are a decent jumping off place.

Sounds like things are getting better from JAX-RPC with JAX-WS. That is good to see.

I still wonder, however, if we'd all be better off if we just stuck a fork in SOAP & WS-* and went back to the drawing board. IMHO WSDL, XSD, SOAP, WS-* were a nice experiment, but haven't delivered. Maybe this latest crop of APIs, tools, Service Centric ESBs, etc. will get us over the hump. I'm not holding my breath.

Maybe this latest crop of APIs, tools, Service Centric ESBs, etc. will get us over the hump.

What 'hump' are you referring to? Can you cite literature mentioning it?

Not sure if the blogs I listed and the links hanging off them qualify as "literature", but that is all I have for you.

Maybe this latest crop of APIs, tools, Service Centric ESBs, etc. will get us over the hump.

What 'hump' are you referring to? Can you cite literature mentioning it?

<glib>

Hey Captain Ahab,

I think it mentions these problems in Moby Dick.

</glib>


Why does this have to be mentioned in literature? I think developer blogs are okay.

I've actually been trying to avoid writing my own SOAP stack, primarily because it would force me to understand all those SOAP specs like WS-Addressing, MTOM, WS-Security, etc, etc, and that just scared me. Then there is the testing.

Instead I've been using pre-release versions of Axis2. This has a mode where you bypass JAXRPC, bypass XBeans and get at their Axiom object model of stuff, which I then turned into Xom data structures for use in my own code.

But now, for various reasons, I am back working on Alpine. Its not yet ready for use by me, let alone anyone else, and I am just starting to test the stack against itself, before I worry about interop testing.

Server side is relatively simple: a servlet accepts POSTs, feeds it through a handler chain and then returns it, or maps any thrown exception into a SOAPFault.

Client side is proving to be trickier. What is the best way to model an async conversation with a remote endpoint? I'm playing with the java5 concurrent stuff, so that you queue transmissions for delivery, can wait for a Future<V> result to arrive, and I also have progress callbacks (with cancel options), for handling long operations. All of this is built on jakarta httpclient, so I dont have to worry about how java.net varies so wildly from the HTTP spec in places.

I'm doing this as part of a project to deliver a long haul API for deploying things on a grid, for which an interop test endpoint is due to be live by friday april 14, so lets just say I have a busy week ahead of me.

-steve loughran

<spam>

  Jason reworked and rewrote the web services chapters for my soon to be published O'Reilly EJB 3.0 book. He also is one of the main developers of JBoss Web Services project.

</spam>

<spam>&nbsp;&nbsp;Jason reworked and rewrote the web services chapters for my soon to be published O'Reilly EJB 3.0 book. He also is one of the main developers of JBoss Web Services project.</spam>

Can you fill me in on the history of "your book"? I have the 3rd edition, which I think is a great book, and it's by Richard Monson-Haefel. I see that there is a 4th edition with you as a co-author, and 250 more pages (but I have not actually read the 4th edition). Is Richard out of the process now?

Now, I guess I'll wait for the EJB 3.0 book.

It will be interesting to compare them, because I think the 3rd edition was a really good book.

Do you still plan to cover and update CMP 2.x or just focus on CMP 3 in this new version? Dumping CMP 1.1 would be no great loss beyond a historical mention.

<spam>&amp;nbsp;&amp;nbsp;Jason reworked and rewrote the web services chapters for my soon to be published O'Reilly EJB 3.0 book. He also is one of the main developers of JBoss Web Services project.</spam>

Can you fill me in on the history of "your book"? I have the 3rd edition, which I think is a great book, and it's by Richard Monson-Haefel. I see that there is a 4th edition with you as a co-author, and 250 more pages (but I have not actually read the 4th edition). Is Richard out of the process now?Now, I guess I'll wait for the EJB 3.0 book.It will be interesting to compare them, because I think the 3rd edition was a really good book.Do you still plan to cover and update CMP 2.x or just focus on CMP 3 in this new version? Dumping CMP 1.1 would be no great loss beyond a historical mention.

It is an adaptation of RMH's EJB 4th edition and covers EJB3 and Java Persistence. CMP and BMP is not covered. There is also a JBoss workbook.

Said it before, sayin' it again.

SOAP simply is not helpful for the most obvious uses for web services.

XML schema is all that is needed. You create an XML document. You post it using HTTP. You read an XML document back!

Good programming tools that bind XML schema to Java are really all that is needed here. SOAP is the EJB of XML (too heavyweight for most tasks and not demonstrably elegant for many). If you are creating a web service, I recommend you create a straightforward XML schema, making good use of abstract xml data types. Keep your security part of your schema rather than relying on a complexifying "frameworks". Usernames, passwords, and HTTPS for encryption if needed.

Remember, SOAP in no way makes your web services blanket "compatible" or "interoperable" with other web services. In fact, in many ways it makes services less interoperable by introducing incompatibilities at the SOAP implementation level, that would otherwise not have been present.