Architecting Web Services

Architecting Web Services

Software architects are at the vanguard of the software development lifecycle. If Web Services truly represent a paradigm shift in how distributed computing is performed, rather than merely an incremental improvement, it is up to the architects first to under-stand this shift and then to communicate it to their teams as well as their management.

Software architecture is a broad, somewhat-vague discipline that includes elements of design, abstraction, and aesthetics, as well as a more fundamental view of what really works and what doesn’t. Architects touch upon the hardware, the network, the applica-tions, and the interfaces as well as the users, the partners, and the marketplace. In order to architect complex, multifaceted systems, including those made up of Web Services, architects must exercise many ways of thinking and many ways of viewing the problems before them.

One established model for how architects visualize the systems before them is the 4+1 View Model of Software Architecture, popularized by Philippe Kruchten of Rational Software. Whereas the four blind men each touch the elephant in a different place and therefore come to different understandings of it, the architect has clear vision, seeing the elephant from all four views. As a result, the architect has a comprehensive picture of the elephant.

This is the same with the 4+1 View Model. This model describes four distinct ways of looking at the architecture for a system, plus a fifth view that overlaps the others, as shown in Figure 14.4.

Each of the four main views takes the perspective of key stakeholders in the development process. The fifth view, the Use-Case View, overlaps the other views and plays a special role with regard to the architecture. This section approaches the Web Services model from each of the four views, demonstrating the different ways architects should envision Web Services. A discussion of the Use-Case View closes out the chapter.

The Implementation Architectural View: The Web Services Technology Stack

In general, the Implementation View (also called the Development or Component View) describes the organization of the software artifacts and also addresses issues of software management. The Implementation View of the SOA focuses on the Web Services technology stack, as shown in Figure 14.5.

Figure 14.5 shows a conceptual Web Services technology stack, where each layer on the left builds upon the capabilities of the layer beneath it. The vertical columns on the right represent capabilities that the architect must address at every level of the stack.

The base stack includes those technologies necessary to create and invoke Web Services. At the bottom is the network layer, which fundamentally allows Web Services to be available to service requesters. Although HTTP is the de facto standard network protocol, the architect may consider any of a number of other options, including SMTP (for e-mail), FTP, IIOP, or messaging technologies such as MQ. Some of these choices are request/response based, whereas others are message based; furthermore, some are syn-chronous, whereas others are asynchronous. The architect may find that in a large sys-tem, a combination of different network protocols is appropriate.

In the next two layers, SOAP is the XML-based messaging protocol that forms the basis for all interactions with Web Services. When running on top of HTTP, SOAP messages are simple POST operations with SOAP’s XML envelope as the payload. SOAP mes-sages support the publish, find, and bind operations that form the basis of the SOA, as shown previously in Figure 14.2. (SOAP is covered in depth in Chapter 15.)

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. (These elements are fully described in Chapter 16.)

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 descrip-tions that apply to a particular implementation. Endpoint descriptions can contain secu-rity, 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.

Only when the architect has dealt with the issues of service publication and discovery can he move on to the more complex issues regarding the interaction of multiple Web Services. The two protocols shown in Figure 14.5, WSFL and WSCL, are still in development, and it’s not clear how these layers will be handled in the future.

One important lesson to be gained from the Web Services stack is that security, QoS, transactions, and service management each apply to every layer in the stack. The architect must therefore consider the intersection of each vertical column with each horizontal layer. For example, network security will likely be handled by HTTPS (SSL over HTTP), but the security of individual messages may still need to be handled by encrypted payloads and digital signatures, which are incorporated into the SOAP header. Securing the base stack is relatively straightforward, because it is internal to the enter-prise; securing Web Services involved in publication and discovery across the Internet is another issue entirely.

QoS, as well, means different things at each layer. Network QoS involves network uptime, packet delivery, and valid HTTP messages. Reliable messaging, however, depends heavily on the capabilities of the endpoint manager, which uses WSEL or another endpoint description language. Transactions depend on endpoint descriptions, as well.

Transactions, in fact, must be handled on multiple levels of the service stack, because of the complexity of handling rollbacks in a multi-enterprise Web Services environment. To roll back a particular conversation, each operation within that conversation may need to be reversed. Alternatively, there may need to be a way to remember the earlier state of multiple systems in order to perform a rollback. In either case, there is no single span of control managing the transactional environment. Transactions may be some of the most intractable issues with Web Services today.

On top of all of these development and implementation concerns, the architect must also think about the management of Web Services. Management of Web Services will likely be handled by a management application, which may need to be built in-house. This management application must be able to do the following:

   Determine the availability and health of the Web Services infrastructure, in-cluding the network as well as the physical systems that support the execution of the Web Services.

   Determine the availability and health of the internal Web Services themselves. Web Services may need to be built with a management interface in order to support this level of management.

   Determine the availability and health of the service registries. Some of these reg-istries may be internal to the enterprise, allowing for direct access to their inner workings, but other registries are external and may only expose a minimal interface for external management.

   Determine the availability and health of external Web Services, once they are dis-covered, attempt to invoke them. Again, these services are external and may not provide a management interface.

   Control and configure all internal systems, including the infrastructure as well as the Web Services themselves.

These management requirements emphasize the need for a standard way of building management interfaces for Web Services (as well as the infrastructure that supports them). In addition, there is clearly a need for a reporting and recovery process for pub-licly available Web Services (either on the open Internet or available to specific business partners). Partners should be able to access an interface that provides status reports on a company’s services and infrastructure, without having to understand the details of how the company manages its internal infrastructure.

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 func-tionality 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 14.6 shows a possible (simplified) workflow for this interaction.

This workflow consists of two separate workflows: a public workflow as well as one pri-vate 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 preexist-ing 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 indi-vidual 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 architect must work with several different elements in a complex workflow like this one, including the following:

   The sequencing rules that describe how the Web Services interact over time.

   The information flows between each of the services (including the necessary data mapping).

   The service providers responsible for executing each step. Is the inventory-manage-ment service responsible for executing any of its internal steps, or are they taken care of by the component services?

   The associations between activities in the workflow.

   The operations offered by each service provider.

The three component services within the inventory-management service may also repre-sent applications that are not themselves Web Services. In such a case, the inventory-management service is responsible for communicating with each component via a preexisting framework, such as CORBA, DCOM, or J2EE.

Once the purchased item has been shipped (assuming there were no errors), the account-ing service is responsible for interacting with the ERP system. This system is an example of a component that is not itself a Web Service. Typically, the architect will call for a wrapper that will present a Web Service interface to the rest of the system. In this case, the accounting service may itself be that wrapper, in which case the links between it and the ERP system would be implemented with the APIs provided by the ERP system.

This simple example appears to be a synchronous system—that is, there is a single, closed loop starting and ending at the buyer that every request follows to completion. In reality, however, some of the processes will be synchronous whereas others will be asyn-chronous. The inventory-management service will likely communicate with the buyer through the public e-commerce service to determine whether or not the product is in stock, and then the pick, pack, and ship process will take place asynchronously. As a result, the architect must also consider how the buyer (as well as the seller) will be able to monitor and control the asynchronous inventory service.

If this is a B2B example, then the buyer’s purchasing service likely ties into the buyer’s enterprise systems as part of its supply chain management system. However, in a Business to Consumer (B2C) situation, the buyer’s purchasing service might be hosted on a B2C Web site. In this situation, the user context is a primary concern

of the architect.

User context is a critical part of all consumer (and generally, individual user) focused Web Services, including Microsoft’s .NET My Services initiative as well as Sun’s SunONE framework.

The user context contains information about the user as well as information about the user’s session, including the following:

  Demographic information, credit card information, and so on

  The user’s physical location

  The user’s locale (the user’s language, currency, number format, and so on)

  The user’s security level and permissions

  Personalization information that pertains to the Web site the user is visiting, including merchandise preferences, calendar information, buddy lists, and so on

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 environ-ment for dealing with hardware and network issues.

Because Web Services typically exchange messages over HTTP, a Web server is typi-cally the desired host for supporting a Web Service. Both the Microsoft and the J2EE platforms share a similar developer model, as shown in Figure 14.7.

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 (as shown previously in Figure 14.3), 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 in Figure 14.6. 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 14.8.

Figure 14.8 shows an e-commerce workflow much like the one in Figure 14.6, except that multiple buyers have looked up the seller in a registry and have chosen to invoke the seller’s e-commerce service. Likewise, the seller looks up third-party credit services in an external registry and looks up pick, pack, and ship services in an internal registry. (As before, these three services are used as examples rather than to indicate how inventory management would actually take place.) The inventory-management service then selects the internal components on-the-fly at runtime.

This example begs the following questions: What if the buyer sends an automatic query to a registry, identifies and qualifies an appropriate seller on-the-fly, and negotiates the purchase dynamically? What if the seller looks up a potentially different credit service every time, given a changing set of criteria such a service might need to meet? Even more significant, what if the seller’s inventory-management service dynamically selects its pick, pack, and ship services at runtime, depending on supply chain issues such as availability, price, and logistics?

Herein lies the power of Web Services. The architect must be able to plan and structure processes where individual Web Services might be selected, queried, and invoked dynamically at runtime. Therefore, the Process View is the most important, and yet the least understood, of the architectural views of the SOA.

JIT integration also complicates scalability and redundancy issues. Many of these issues can be handled by the underlying software platform that supports the Web Services. However, with JIT integration, it is not necessarily possible to predict at design time which Web Services will be invoked or what service implementations they will expose. How do you plan for scalability and redundancy when you don’t even know whether a particular component will be invoked at all?