SOA Using Java Web Services, chapter 3: 'Basic SOA Using REST', chapter 3: 'Basic SOA Using REST' |
 |
| 25 May 2007 | Prentice Hall Professional |
|
|
Download chapter 3: 'Basic SOA Using REST'
 This chapter is excerpted from the book titled, SOA Using Java Web
Services, authored by Mark Hansen, published by Prentice Hall
Professional, May, 2007, ISBN 0130449687, Copyright 2007 Pearson
Education, Inc. For more information please visit:
www.prenhallprofessional.com
Chapter Excerpt:
3.1.1 What Is REST?
REST-style services (i.e., RESTful services) adhere to a set of constraints
and architectural principles that include the following:
- RESTful services are stateless. As Fielding writes in Section 5.1.3 of
his thesis, "each request from client to server must contain all the
information necessary to understand the request, and cannot take
advantage of any stored context on the server."
- RESTful services have a uniform interface. This constraint is usually
taken to mean that the only allowed operations are the HTTP operations:
GET, POST, PUT, and DELETE.
- REST-based architectures are built from resources (pieces of information)
that are uniquely identified by URIs. For example, in a
RESTful purchasing system, each purchase order has a unique URI.
- REST components manipulate resources by exchanging representations
of the resources. For example, a purchase order resource can
be represented by an XML document. Within a RESTful purchasing
system, a purchase order might be updated by posting an XML document
containing the changed purchase order to its URI.
Fielding writes that "REST-based architectures communicate primarily
through the transfer of representations of resources" (Section 5.3.3). This is
fundamentally different from the Remote Procedure Call (RPC) approach
that encapsulates the notion of invoking a procedure on the remote server.
Hence, RPC messages typically contain information about the procedure to
be invoked or action to be taken. This information is referred to as a verb in
a Web service request. In the REST model, the only verbs allowed are
GET, POST, PUT, and DELETE. In the RPC approach, typically many
operations are invoked at the same URI. This is to be contrasted with the
REST approach of having a unique URI for each resource.
These are the basic principles behind REST. However, when people
talk about the benefits of RESTful systems today, they usually are not
strictly applying these principles. For example, among REST advocates,
keeping shopping cart data on the server and maintaining a session related
to the shopping process that is using the cart is acceptable.2 In fact, the
XML/HTTP Binding provided by JAX-WS for implementing RESTful
services provides for session management capabilities using cookies, URL
rewriting, and SSL session IDs.
More significant deviations from Fielding's definition of REST involve
getting around the "uniform interface" constraint by embedding verbs and
parameters inside URLs. The Amazom.com REST interface, for example,
includes verbs in query strings and doesn't have unique URIs for each
resource. Systems like this, although labeled as RESTful, are really starting
to look very much like RPC using XML over HTTP without SOAP.
For the purposes of this book, I am not going to wade into a debate on
what is or isn't RESTful. I simply define RESTful Web Services in contrast
to SOAP Web Services. Table 3–1 illustrates the principal differences.
a. Some would argue that XML Schema could be used as an interface definition for RESTful
services. Not only is that approach possible, but it is used in many practical cases. However,
it is not a complete interface solution because many, if not most, RESTful services
incorporate HTTP parameters (e.g., URL query strings) in addition to XML as part of their
invocation interface. Chapter 9 looks at the Yahoo! Shopping RESTful interface, which uses
HTTP parameters in this manner.
This is consistent with common usage in the REST versus SOAP debates.
REST uses simple XML over HTTP without a WSDL interface definition.
3.1.2 Topics Covered in This Chapter
In addition to introducing RESTful Web Services, this chapter introduces
and reviews some basic techniques for integrating Enterprise Information
Systems (EISs) using XML, XSLT, HTTP, and Java. For each example, I
demonstrate how to implement it with and without JWS. The versions of
the examples without JWS use basic Java HTTP and XML techniques. Both
approaches are provided to give you a sense of what is really happening,
under the covers, when a Web service is consumed or deployed using JWS.
This should give you a better understanding of the mechanisms underlying
JWS and when to use them. For simple Web services, often it is easier to
work with the basic Java tools than to pull out all the power of JWS. On the
other hand, you will see from these examples how things can quickly get
complicated and require the power of the JWS technologies.
Since one focus of this book is on SOA-style development for the enterprise,
many of the examples deal with EIS—the basic infrastructure of most
corporate computing environments. This chapter describes
- Structuring EIS Records as XML documents
- Getting EIS records from a REST service (with and without JWS)
- Posting EIS records to a REST service (with and without JWS)
- Basic SOA-style integration of REST services using XSLT for data
transformation
- Deploying a REST service to be used for getting EIS records—in
other words, an HTTP GET service (with and without JWS)
- Deploying a REST service to be used for posting EIS records—in
other words, an HTTP POST service (with and without JWS)
3.2 XML Documents and Schema for EIS Records
The first step toward implementing an SOA component that consumes
or provides EIS records involves formatting the EIS records that need to
be exchanged as XML documents. This process is formalized by creating
an XML Schema to represent the structure of an XML document for a
particular EIS record. This section introduces some simple examples
that are used throughout this chapter to illustrate the role of XML and
XML Schema in SOA-style applications development based on Web Services.
Understanding these examples requires a basic knowledge of XML
and XML Schema. If you are new to XML, you should get an introductory
text such as Beginning XML by David Hunter et al. [Hunter]. For
the necessary background on XML Schema, I suggest Definitive XML
Schema by Priscilla Walmsley [Walmsley]. Alternatively, if you know
basic XML, but need to brush up on XML Schema, you can probably
find all you need to know for this book by reading through the W3C's
"XML Schema Part 0: Primer" [XSD Part 0].
To illustrate how XML is used, I employ an example based on the fictitious
XYZ Corporation. The example illustrates real SOA challenges faced
by many companies. XYZ Corporation has an Order Management System
(OMS) that needs to be integrated with a Customer Service System (CSS).
The OMS should be thought of as an EIS, such as SAP, for taking customer
orders and tracking them through delivery. The CSS should be thought of
as an EIS, such as Oracle's Siebel Customer Relationship Management
Applications, that is used by customer service employees as a tool for handling
customer inquiries.
XYZ Corporation would like to build an SOA application bridging the
OMS and the CSS. Every time a new order is entered in the OMS (or an
existing order is updated), the new SOA application should transfer that
information to the CSS and add it to the relevant customer's history log.
The purpose of this SOA application is to ensure that customer service representatives
have fast access, through the CSS, to basic customer order
information. If customer service representatives need access to more
detailed order information from the OMS, the CSS will contain the keys
within the customer history log (updated via the SOA application) to query
the OMS and access that detailed information.
Figure 3–1 illustrates what an OMS order record looks like as it might
appear on a user interface.
 Chapter 3: 'Basic SOA Using REST'
Visit the Prentice Hall
Professional website for a detailed description and to learn how to purchase this title.
|
|
|
|
