Tải bản đầy đủ - 0 (trang)
5 UDDI, WSDL, and Metadata

5 UDDI, WSDL, and Metadata

Tải bản đầy đủ - 0trang

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


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

5 UDDI, WSDL, and Metadata

Tải bản đầy đủ ngay(0 tr)