Tải bản đầy đủ - 0trang
5 UDDI, WSDL, and Metadata
5.5 UDDI, WSDL, and Metadata
Fig. 5.5 SOAP message sample
UDDI has proven to be the least used so far of the original three Web services
standards. In many ways, UDDI is either the least interesting or potentially most
interesting of these standards, depending on how important you think being able to
dynamically discover and link to services is to your application. Organizations are
developing large complex Web services systems today without the use of global
UDDI directories, using other methods of finding services such as personal contact
or published lists of services on Web sites. This could all change in the future,
especially when industry associations start releasing common service definitions
and need to publish directories of qualified service providers.
WSDL is used to describe Web services, including their interfaces, methods, and
parameters. The WSDL description of a service called StockQuoteService that
provides a single operation named GetLastTradePrice is depicted in Fig. 5.31.
5 Service-Oriented Architectures and Technologies
Stock quote service
Fig. 5.6 WSDL for the GetLastTradePrice service
This operation takes one parameter symbol of type string that names the stock of
interest and returns a float that holds the most recently traded price.
WSDL is well supported by development environments such as Visual Studio,
Eclipse, and WebSphere. These tools can generate WSDL automatically from program method and interface definitions, and they take in WSDL service definitions
5.6 Security, Transactions, and Reliability
and make it easy for developers to write code that calls these services. One adverse
side effect of this tool support is that it tends to encourage developers to think of
services as remote methods, rather than moving to the preferable and richer
message-based model provided by Web services.
Security, Transactions, and Reliability
One of the problems faced by most middleware protocols is that they do not work
well on the open Internet because of the connectivity barriers imposed by firewalls.
Most organizations do not want outsiders to have access to the protocols and
technologies they use internally for application integration and so block the necessary TCP/IP ports at their perimeter firewalls.
The common technology response to this problem, and the one adopted by
Web services, has been to co-opt the Web protocol, HTTP, as a transport layer
because of its ability to pass through most firewalls. This use of HTTP is convenient but also creates potential security problems as HTTP traffic is no longer just
innocuously fetching Web pages. Instead it may be making direct calls on internal
WS-Security and its associated standards address these problems by providing
strong cryptographic mechanisms to identify callers (authentication), protect content from eavesdroppers (encryption), and ensure information integrity (digital
signatures). These standards are designed to be extensible, letting them be adapted
easily to new security technologies and algorithms, and also supporting integration
with legacy security technologies.
WS-Security supports intermediary-based application architectures by allowing
multiple security header elements, each labeled with the role of their intended
recipient along the processing chain, and by supporting partial encryption and
partial signatures. As an illustration, in the example shown in Fig. 5.3, the sensitive
credit card details can be hidden by encrypting them, while leaving the rest of the
message unencrypted so that it can be read by the routing application.
The final set of Web services standards support transactions and reliable messaging. There are two types of Web service transactions supported by standards.
WS-AtomicTransactions supports conventional distributed ACID transactions and
assumes levels of trust and fast response times that make this standard suitable only
for internal application integration tasks and unusable for Internet-scale application
integration purposes. WS-BusinessActivity is a framework and a set of protocol
elements for coordinating the termination of loosely coupled integrated applications. It provides some support for atomicity by invoking compensators when a
distributed application finishes in failure.
The support for reliable messaging in Web services simply ensures that all
messages sent between two applications actually arrive at their destination in the
order they were sent. WS-ReliableMessaging does not guarantee delivery in the
5 Service-Oriented Architectures and Technologies
case of failure, unlike queued messaging middleware using persistent queues.
However, it is still a useful standard as it provides at most once, in-order message
delivery over any transport layer, even unreliable ones such as UDP or SMTP.
RESTful Web Services
The “Web” in “SOAP-based Web services” is really a misnomer as SOAP has
nothing to do with the Web, other than its (optional) use of the Web protocol,
HTTP, as a “firewall-friendly” transport layer. Perhaps as a reaction to this misuse
of the word “Web” (and SOAP’s total lack of adherence to the philosophies
underlying the “Web”), some adherents to the Web-way-of-doing-things have
developed and vigorously evangelized an alternative way of doing Web services:
REST (Representational State Transfer).
RESTful Web services rely on HTTP as a sufficiently rich protocol to completely
meet the needs of Web services applications. In the REST model, the HTTP GET,
POST, PUT, and DELETE verbs are used to transfer data (often in the form of XML
documents) between client and services. These documents are “representations” of
“resources” that are identified by normal Web URIs (Uniform Resource Identifiers).
This use of standard HTTP and Web technologies means that RESTful Web services
can leverage the full Web infrastructure, such as caching and indexing.
The following example shows how a simple customer database Web service
could be implemented using a RESTful approach. In this example, the customer
database is a “resource” and the individual customer records are also “resources” in
their own right. Each of these resources has a unique URI that can be used as the
subject of an HTTP verb.
The URI http://example.com/customers identifies the customer database resource.
GET requests sent to this URI return the set of all customers as a single XML
document containing a list of URIs that point to the individual customer resources.
The URI for each customer in the database is formed by appending the customer’s unique ID to the customer set URI. For example, http://example.com/
customers/1 identifies the resource corresponding to the customer with ID 1.
A GET request sent to one of these unique customer URIs retrieves an XML
document that contains a representation of the current state of the corresponding
Existing customer resources can be updated by PUTting an XML document
containing a representation of the desired new state of the customer to the
appropriate customer URI.
New customers can be added to the database by POSTing XML documents
containing the representation of the new resource to the collection URI. The
URIs for the new customer resources are returned using the HTTP location
header in the server’s responses.
Customer entries can be deleted by sending a DELETE request to the customer