Architecting Web Services

What Are Web Services?

Simply put, Web Services are loosely coupled, contracted components that communicate via XML-based interfaces. Let‘s take a closer look at this definition:

•        Loosely coupled means that Web Services and the programs that invoke them can be changed independently of each other. Loose coupling also implies that Web Services are platform independent.

•        Contracted means that a Web Service‘s behavior, its input and output parameters, and how to bind to it are publicly available.

•        A component is encapsulated code, which means that the implementation of each component is hidden from outside the component. Each component‘s functionality is only known by the interface it exposes.

•         Because all Web Services‘ interfaces are built with XML, they all share the advan- tages of XML: They have a human readable, text-based format that is firewall friendly and self-describing. All Web Services are described using a standard XML notation called its service description.

Put another way, Web Services are self-contained applications that can be described, published, located, and invoked over the Internet (or any network, for that matter).

Business Motivations for Web Services;

The vision of global e-business largely remains unrealized. Executives dream about seamless interactions both with other companies as well as e-marketplaces, but the technology lags behind the vision. Today‘s information technology is still extraordinarily complex and expensive. Even with standards such as Electronic Data Interchange (EDI), Java 2 Enterprise Edition (J2EE), Common Object Request Broker Architecture (CORBA), and Windows Distributed interNet Application (Windows DNA), communicating between different corporate systems is still filled with hair-pulling detail work.

The business world needs more powerful techniques to scale business solutions without increasing complexity to unmanageable levels. In addition, there is a clear need for open, flexible, and dynamic solutions for enabling global e-business interactions among systems. The Web Services model promises to deliver these solutions by addressing complexity and costs, providing a common language for B2B e-commerce, and enabling the vision of a global e-marketplace.

B2B E-Commerce:

Business to Business (B2B) e-commerce has been around for more than a decade in the form of the Electronic Data Interchange (EDI). EDI is quite powerful and has gained widespread acceptance but is limited by its semantic ambiguity. For example, a ―quantity‖ field in a given form may stand for number of boxes for one company but the number of pallets for another. People have to resolve each ambiguity manually, making EDI useful primarily in a hub-and-spoke arrangement, where one large company can dictate the meaning of each field to its suppliers.

When the Internet opened up the prospect of many-to-many e-commerce, it soon became clear that there needed to be a way to agree upon a single business vocabulary for all participants in each trading group. XML provided the basis for building such vocabularies because of its inherent extensibility. However, XML‘s greatest strength also proved to be a weakness, because its extensibility led to hundreds of different business vocabularies, often with overlapping applicability.

The Web Services model addresses this Tower of Babel problem by providing for dynamic service descriptions. Individual Web Services can describe their interfaces at runtime, allowing for dynamic interpretation of the semantics of the XML that underlies the messages Web Services send and receive.

Technical Motivations for Web Services:

The technical motivations for Web Services are far more complex than the business motivations. Fundamentally, technologists are looking for the simplicity and flexibility promised, but never delivered, by RPC architectures and object-oriented technologies.

Limitations of CORBA and DCOM:

Programming has been performed on a computer-by-computer basis for much of the history of computing. Programs were discrete chunks of computer code that ran on individual computers. Even object-oriented programming originated in a single-computer environment. This isolated computer mind set has been around so long that it pervades all thinking about software.

Then along came networks, and technologists looked for ways to break up program functionality onto multiple computers. Early communication protocols, such as the Network

File System for Unix and Microsoft‘s Distributed Computing Environment, focused on the network layer. These protocols, in turn, led to the development of wire protocols for distributed computing—in particular, the Object Remote Procedure Call (ORPC) proto- col for Microsoft‘s DCOM and the Object Management Group‘s Internet Inter-ORB Protocol (IIOP) that underlies

CORBA.

RPC architectures such as DCOM and CORBA enabled programs to be broken into different pieces running on different computers. Object-oriented techniques were particularly suited to this distributed environment for a few reasons. First, objects maintained their own discrete identities. Second, the code that handles the communication between objects could be encapsulated into its own set of classes so that programmers working in a distributed environment needn‘t worry about how this communication worked.

However,  programmers  still  had  that  isolated  computer  mindset,  which  colored  both

DCOM‘s and CORBA‘s approach: Write your programs so that the remote computer appears to be a part of your own computer. RPC architectures all involved marshalling a piece of a program on one computer and shipping it to another system.

The Service-Oriented Architecture (SOA)

In order for Web Services to be able to work well together, they must participate in a set of shared organizing principles we call a service-oriented architecture (SOA). The term service oriented means that the architecture is described and organized to support Web Services‘ dynamic, automated description, publication, discovery, and use.

The SOA organizes Web Services into three basic roles: the service provider, the service requester, and the service registry. The relationships among these three roles are shown in Figure.

Architecting Web Services:

Oneestablishedmodelforhowarchitectsvisualizethesystemsbeforethemisthe4+1ViewModelo f Software Architecture, popularized by Philippe Kruchten of Rational Software. Where as the four blind men each touch the elephant in a different place and there forecometodifferentunderstandingsofit,thearchitecthasclear vision, seeing the elephantfromallfourviews.Asaresult,thearchitecthasacomprehensivepicture of the elephant.

Thisisthesamewiththe4+1ViewModel.Thismodeldescribesfourdistinctwaysof lookingatthearchitectureforasystem,plusafifthviewthatoverlapstheothers,as shownin Figure.

The Web Services Technology Stack:

The bases tack includes those technologies necessary to create and invoke Web Services.

At the bottom is thenet work layer, which fundamentally allows Web

Services to be availabletoservicerequesters.AlthoughHTTPisthedefactostandardnetworkprotocol, thearchitectmayconsideranyofanumberofotheroptions,includingSMTP(fore-mail),FTP,IIOP,ormessagingtechnologiessuchasMQ.Someofthesechoicesare

request/responsebased,whereasothersaremessagebased;furthermore,somearesynchromos,whereas othersareasynchronous.Thearchitectmayfindthatinalargesys-tem,acombinationofdifferentnetworkprotocolsisappropriate.

On top of the SOAP layer comes three layers that together form the service description. WSDL is the de facto standard for service descriptions, with the addition of the still- tentative WSEL for endpoint descriptions. The service interface definition contains the binding, portType, message, and type elements, which form the portion of the service description that is reusable from one implementation to another.

The service implementation definition, however, contains those elements that are specific to each implementation: the service and port elements. A third party (say, a standards body) might specify the service interface definition for a particular type of Web Service, leaving the service implementation definition up to each implementation team.

Next comes the endpoint description, which introduces semantics to the service descriptions that apply to a particular implementation. Endpoint descriptions can contain security, QoS, and management attributes that help to define the policies for each of these vertical columns.

Once the architect has dealt with all the issues in the base stack, the Web Services are essentially fully constructed. Next, the development team uses UDDI to publish the services to a registry or another repository of information about available Web Services. Once Web Services are published, UDDI can then be used to discover them in the registries.

The Logical Architectural View: Composition of Web Services:

The Logical (or Design) Architectural View starts with the end user‘s functional require ments and provides a top-down abstraction of the overall design of the system. In the

case of B2B functionality (say, in the case of processing a purchase order), the user interface may be handled separately from the Web Services; therefore, the ―end users‖ in this case are the businesses themselves. In other cases, Web Services may provide functionality to the user interface more directly.

In the B2B case, the functional requirements of a Web Services–based system will typi-cally involve complex conversations among Web Services that participate in multi-step business processes. In addition, the individual Web Services involved are likely to be composed of component Web Services. As a result, an architect working from the Logical View will likely be concerned with workflows of Web Services.

For example, let‘s take the case of a buyer‘s Web Service contacting a seller‘s Web Service to make a purchase. Figure shows a possible (simplified) workflow for this interaction.

This workflow consists of two separate workflows: a public workflow as well as one private to the seller. From the buyer‘s point of view, the seller is exposing a single public Web

Service that is composed of separate Web Services in succession.

The interfaces to the two public services are both written in WSDL. The buyer has obtained the seller‘s service description beforehand—either by looking it up in a registry or through a prearranged relationship between the buyer and the seller. The buyer uses the service description to build the SOAP messages it exchanges with the seller.

Once the seller receives a request from the buyer, a sequence of business processes within the private workflow takes place. First, a credit-validation service sends a request to a third-party, credit-checking Web Service, which it may have established a preexisting relationship with. This third-party service is an example of an enabling service. Depending on the response from the third-party service, the seller continues with the e-commerce workflow or possibly sends a ―credit rejected‖ response back to the buyer. (The architect must consider both the ―rejected‖ special case as well as how to handle the situation where the third-party credit service is unavailable.) In a more general case, it will likely not be necessary to query this service if the seller has an established relationship with the buyer.

Once the buyer‘s credit is approved, the internal credit-validation service sends a request to the inventory-management service. This service is recursively constructed from individual component services (three of which are shown for illustration purposes, but in reality such services would be more complex). The architect must determine the interface for the inventory-management service as well as detail the workflow that takes place within the service.

The Deployment Architectural View: From Application Servers to Peer-to-Peer:

The Deployment (or Physical) Architectural View maps the software to its underlying platforms, including the hardware, the network, and the supporting software platforms. Today,

Web Services are hosted on application server platforms such as IBM‘s WebSphere, BEA‘s WebLogic, and Microsoft‘s Windows 2000. There are many benefits to building Web Services on top of platforms like these: They handle database access, load balancing, scalability, and interface support as well as provide a familiar environment for dealing with hardware and network issues.

This model follows a traditional n-tier architecture, except that the Web server is also responsible for sending and receiving the XML messages that form the Web Services interface. The technology that supports Web Services is therefore already well under- stood; the fundamental difference between Web Services and Web pages is that pages are intended for humans to read, whereas Web Services expose an interface intended for machines.

Running Web Services off of Web servers is not the only way to support the services, however. It is also possible to build Web Services on a peer-to-peer (P2P) developer model. P2P, popularized by the Napster music service, is a distributed

architecture that does not rely on central servers but rather distributes responsibility to systems (called peers) in the network. Unfortunately, P2P technologies are every bit as new and bleeding edge as Web Services, so only time will tell which P2P models will become established. The self-organizing promise of Web Services does lend itself to P2P, but a lot of work remains before we will see how this fascinating area will develop.

The Process Architectural View: Life in the Runtime

The Process Architectural View addresses all runtime issues, including processes, concur-rency, and scalability. As the applications of Web Services move up the hierarchy of Web Service integration options to JIT integration the Process Architectural View will take on increasing importance. In fact, the Process Architectural View will be where the bulk of the SOA architect‘s work will take place.

For example, let‘s take another look at the simple e-commerce workflow. If you just look at the figure, you might think that there‘s nothing much new here; this diagram could represent an e-commerce system based on a simple n-tier architecture.

The reason that the diagram doesn‘t immediately demonstrate the power of the Web Services model is that in the diagram, the buyer has already identified the seller, the seller has already identified its third-party credit service, and the seller‘s private work- flow is already put in place. If all these statements are in fact true, then, yes, Web Services has little to offer over traditional n-tier architectures. On the other hand, let‘s take a JIT approach, as shown in Figure.