Skip to main content

SOAP and REST - both equally important to Sun

Posted by arungupta on October 17, 2008 at 3:33 PM PDT



"Sun moving away from SOAP to embrace REST" is the misleading title
of an article recently published in href="http://www.sdtimes.com/SUN_MOVING_AWAY_FROM_SOAP_TO_EMBRACE_REST/About_JAVA_and_REST_and_SUN/32959">SD
Times. The article provides a good introduction to JAX-RS and
Jersey. But I really wonder what motivated the author of this
article to use this title. This blog, hopefully, provides a better
context.



Jersey is
the Reference Implementation of Java API for RESTful Web Services
(JAX-RS, JSR
311
)
and was released earlier this week. The headline indicates that Sun is
leaving SOAP and will support REST. The debate between
REST and SOAP is not new and there are religious camps on both sides
(even within Sun).
And that's completely understandable because each technology has its
own merits and demerits. But just because a new JSR aimed to make
RESTful Web services easy in
the Java platform is released, it does not mean Sun Microsystems is
leaving existing technology in trenches.



The addition of Jersey to Sun's software portfolio makes the Web
services stack from GlassFish community a more compelling and
comprehensive offering. This is in contrast  to "moving away"
from SOAP as indicated by the title. As a matter of fact, Jersey will
be included as part of Metro
soon,
the Web Services stack of GlassFish. And then you can use JAX-WS (or
Metro) if you like to use SOAP or JAX-RS (or Jersey) if you prefer
RESTful Web
services. It's all about a offering choice to the community instead of
showing a direction.



Here are some data points for JAX-WS:

  • The JAX-WS 2.0 specification was released on href="http://jcp.org/aboutJava/communityprocess/final/jsr224/index.html">May
    11, 2006. There have been couple of maintenance releases
    since then and another one brewing.
  • Parts of Metro, the implementation of JAX-WS, are currently
    baked into GlassFish, embeddable in JBoss WS Stack, and also part of
    Oracle Weblogic and IBM Websphere.
  • The implementation stack is mature and used in several key
    customer deployments. 
  • JAX-WS is already included in Java SE 6 and hence available
    to a much wider audience.
  • As opposed to "moving away", JAX-WS 2.2 (currently being
    worked upon) will be included in Java EE 6 platform, as will Jersey be.

So I believe both SOAP and REST are here to stay, at least in the near
future. And Sun Microsystems is committed to support them!



You still think Sun is moving away from SOAP ?



It seems a personal preference is interpreted as Sun's disinvestment in
SOAP. It's good to have increased readership but not at the cost
of misleading headlines :)



Technorati: jax-ws
rest href="http://technorati.com/tag/webservices">webservices
metro href="http://technorati.com/tag/sdtimes">sdtimes href="http://technorati.com/tag/glassfish">glassfish

Related Topics >>

Comments

"As I understand it, REST isn't a contract first design" REST doesn't enforce a contract first design, but most sane RESTafarians will define their XSD. On the other hand, SOAP doesn't *enforce* contract first, either. Most toolkits seem to encourage generating the WSDL from code. I think you're about as likely to see a contract-first approach in either case. Meanwhile, the semantics of SOAP services are less likely to be standardized. Nothing tells the stack that getCustomer and findOrder both are reading operations. On the other hand GET /order/xxxx and GET /customer/xxx is the same sort of thing, and can potentially be treated as the same by the stack.

why wonder? The title is hype. Hype sells. Would you have started reading the thing if it'd had a title like "Sun getting interested in REST"?

This entire debate is pointless, they are not even competing technologies. I think the reason why people think they are competing is because too many people thought SOAP was the way to go back before the REST concept was huge. One major reason SOAP will never go away is standards based - contract specified - services. Those services that can't be implemented a billion different ways. As I understand it, REST isn't a contract first design, which means you can't build standard interfaces on it that multiple competitors implement.

Or REST is to SOAP what running on a beach is to running in quicksand. I like how the number of jar file dependencies in an application grows 4x when you add SOAP support to it.

REST is to SOAP what cooking stone soup is to gourmet dining.