Java Reference
In-Depth Information
That said, I'm aware that this topic devotes hundreds of pages to the WS-* stuff and only a
single chapter to REST. The world is full of SOAP and WS-*, and for many of us it's im-
portant to know how to work with them. It does speak, however, to the comparative complex-
ity. And before we dump too much on Big Web Services (as Leonard Richardson and Sam
Ruby term them), the WS-* stack does work together to create more functionality than you get
with the basic ideas found in REST. That is, Big Web Services are bigger than REST because
they're talking about a lot more than REST is. That's not a value judgment; it's just pointing
out a fact. REST isn't trying to solve a lot of problems that the specs are tackling. For ex-
ample, WS-AtomicTransaction and WS-MetaDataExchange offer standard ways for disparate
components to participate in distributed transactions or for independent clients to negotiate
policies at runtime. And security in the form of SAML (which specifies SOAP as its bind-
ing) makes complex federated security policies across business partnerships realizable and
straightforward to implement with minimum manual and error-prone negotiation.
Moreover, many REST proponents argue that Remote Procedure Calls (RPC) are what op-
ponents object to most in SOAP-based services. But you can achieve a level of document ex-
change with SOAP. Using the document/literal bare style, which specifies no operation but
only presents an XML document as the child of the SOAP body, offers some of the features of
a RESTful architectural style. The operation invoked on the WSDL is matched by the schema
type presented. Notice, too, that the early Flickr REST API was in some ways RPC masquer-
ading as REST. Just because you don't have SOAP doesn't mean you're doing REST.
To settle this question, you must ask yourself what problem you're trying to solve with your
SOA. Assess your current architecture and the WS-* specs to determine the right target ar-
chitecture for your organization. Do not forget that while many resources, including many
recipes in this topic, show a code-first approach to building web services, you are free (and
in this topic very much encouraged) to build your services contract-first, and present the
ideal interface to the world. Just because tools such as binding customization let you bleed
implementation-specific business out into what's supposed to be a platform-independent in-
terface doesn't mean you should use them all over the place.
The WS-* specs are really about enterprise integration. REST is an architectural style. Ultim-
ately, I reject the REST versus SOAP battle as a false dichotomy. These two technologies can
be complementary to one another and can work in tandem. After all, the very point of SOA is
to not force you into a single stack, but to support heterogeneous environments. A good SOA
and integration practitioner or software architect has both REST and SOAP available to him,
and can apply them as necessary.
Many enterprise information systems, including PeopleSoft, SAP, and JDA, expose their sys-
tems with WSDL. At the point where you need to integrate with two decades of existing pro-
grams comprising two million lines of custom code, it becomes irrelevant very quickly if we
