A Practical Guide to Enterprise Architecture

Web services have been chosen for in-depth discussion because they are a well known and extremely important example of an SOA implementation. Many enterprises have already started to implement Web services, and most others have plans to implement them in the future.

Web services are an example of an SOA. One very important thing that Web services have over most other SOA implementations is that they adhere to open standards. The open standards that form the basis of Web services theoretically allow any Web service to interact with any other Web service. Proprietary protocols, data translation, and vendor lock-in become a thing of the past. The menu of solutions for your IT problems grows enormously.

The open standards behind Web services have gained allegiance from all the big players IBM, Microsoft, Sun, BEA, and Oracle to name a few. These normally warring entities are in bed together on open standards because they realize it is vital for the future of their respective businesses that they be able to talk to anyone via Web services.

Following are the open standards utilized by Web services:

  • The transport protocols HTTP, FTP, and SMTP

  • The messaging protocol SOAP (Simple Object Access Protocol)

  • The interface description language WSDL

  • Registry protocols such as UDDI and repositories such as ebXML

Let's examine how Web services implements an SOA. One of the SOA principles is that services should be independent of the means of transport. Currently, all Web services communicate using a single transport: HTTP. FTP and SMTP are listed as alternate Web services transport modalities, but they are not particularly popular because they preclude carrying on a conversation between applications. However, HTTP will continue to be the most popular transport for Web services messages for some time to come. HTTP is popular for Web services because HTTP messages can pass readily through firewalls. When you are contemplating connecting to a service physically located in a different enterprise, or even in a different location within the same enterprise, firewall transparency is attractive. Difficulties in traversing firewalls are one of the reasons that Java applets and CORBA are not popular in Internet scenarios. Web services notwithstanding, it remains our recommendation that, when building internal SOA environments, time and attention be devoted to making the service transport independent.

To say that FTP and SMTP are incapable of supporting request-response Web services operations is inaccurate. See www.w3.org/TR/2002/WD-soap12-part0-20020626/#SMTP for an example of an SMTP SOAP message. Theoretically, you could have an application that could open the email, ingest the SOAP message, generate a reply SOAP message, and email it back to the sending application. However, email is designed for human ingestion, and that, plus the fact that issues such as delivery and reply operations are totally defined by the SMTP protocol, will keep Web services interactions with email on the level of sending a message to a human. FTP, and in particular FTPs, has some real potential as a Web services transport protocol to automate interactions with batch-processing systems.

Web services utilize the SOAP messaging protocol to transmit data. This protocol is central to Web services. The SOAP protocol, among other uses, defines how to represent a message in a standard manner. In addition, it defines data types to be used when using remote procedure calls (RPC) via Web services. XML is the language used to compose SOAP messages. A SOAP message consists of three parts:

  • Envelope, which basically identifies this XML as a SOAP message

  • Header, which contains information for activities such as transaction management, routing and security, processing directives, and so on for a system

  • Body, which contains the actual data

The SOAP protocol also demonstrates the difficulties of producing a completely unambiguous data communications vehicle. The original SOAP protocol left many key areas undefined or poorly defined. As a result, interoperability between Web services proved difficult to obtain. SOAP v1.2 has addressed some of those issues, but interoperability is still an elusive goal. Interoperability is discussed in detail later in this chapter.

Handling of the SOA contract requirements by Web services is very well developed and deserves detailed study by any organization implementing an SOA. As stated previously, the SOA contract must clearly state the service that is provided and what is required of the Web service consumer. This contract is in the form of WSDL. WSDL has been developed for the purpose of discovering Web services that suit the consumer's criteria. Using WSDL, the provider of the service describes that service. That description consists of the following:

  • The functionality that the service provides

  • A description of the messages that are acceptable to the service and their format

  • The protocol that the consumer must use to utilize the service

In conjunction with the WSDL contract specified by the service, Web services provide a mechanism to dynamically build the proxy that allows connection to the service using WSDL.

Web services offer two methods of establishing connections between modules: One is dynamic, the other static. It is possible to provide to the consumer of the Web service an object, a "stub," to which it can bind at compile time. Changes in binding information or the contract may require a recompile. Any static method of connecting Web Service consumer and supplier is limited and inflexible and puts the service outside an SOA . Of much more interest is the fact that Web services have evolved dynamic methods of service discovery via interaction with a registry.

The future world of Web services is certain to contain many different registries, each with its own API. Small consumer-oriented Web services will probably be concentrated in one or a few registries. However, the location of business services will most likely be much more diffuse. Many enterprises may choose to implement their own registry. Having a registry of their own provides corporations the level of control and security that most of them need to feel comfortable with Web services. Having a plethora of Web services registries is not a problem. Having a plethora of APIs to interact with a plethora of registries is a problem. Standardization on a small set of Web service registry APIs is important for the widespread adoption of Web services. Having to change the registry access code when changing a Web service from one provider to the other greatly reduces the agility that Web services offer.

Web services actually are beginning to deliver on the promise of a simple, universal, effective method to allow application-to-application communication between disparate entities. This versatility is achieved by the universal nature of the HTTP transport mechanism and the universal nature of the XML message format. We believe that an effective Web services strategy should be a part of every business's enterprise architecture.

Web Services Issues

Web services have some serious flaws, some temporary and some fundamental.

One concern is Web services are typically slower when compared to many proprietary approaches. XML is verbose and hence tends to produce messages that are larger than more optimized approaches. XML parsing tends to be a slow process. Asynchronous communication is sufficient in some circumstances, but sometimes the speed of RPC operations is necessary. Specifications for passing binary data in SOAP messages, reliable Web services, nailing down the SOAP specification to enhance interoperability, and more are still in flux.

For a detailed discussion of architectural considerations for Web services, see Java Web Services Architecture (McGovern, Tyagi, Stevens, and Mathew 2003).

Related

Категории