Chapter 2: Web Services Architecture

Since web services are such a shift in how we approach distributed development, understanding how to model such systems is an important step in understanding how to properly design, develop, and apply Web services. Because these services can be shared across the Internet, the numbers of ways in which they can be modeled make identifying all the possibilities a challenge. For every Web services model one could conceive, extending it one level further through another partnership could lead to yet another model.

The challenge in laying out our architecture is in being able to accommodate all of the scenarios in which they may be used. Our architecture should provide a consistent method for designing Web services independent of the number of participants, the participants' level of involvement, and the technologies and platforms chosen. Let's start by identifying some of the main application scenarios for utilizing Web services.

Web Services Partnership Scenarios

Think of an application utilizing Web services as a chain of links, with each link representing a function in the application (see Figure 2-1). Any links between different partners would represent processes shared via Web services. The connection between those links would then represent the communication between a service and its consumer. That means that a Web service can also be a consumer of another Web service. The first link in any such chain is the only one not eligible to be a Web service. It represents the user interface for the entire application. The partner owning the first link is the "originator" of the application and is responsible for the entire user experience and thus owns the application.

Figure 2-1: The partners in a Web services-based application

Just like a chain depends on each link, the entire application depends on each of its contributing links. This dependency is something that can be shielded from the end user to some extent, but inherently, whatever functionality the link is providing is absent if the link is inoperable. This is no different from any other application that is unable to access functionality from one of its logic or data components.

Figure 2-1 shows four participants in the partnership "chain." Let's say the chain represents the mobile application accessed in our hypothetical traffic scenario from Chapter 1. Partner A is the mobile application owner (perhaps the cellular service provider), partner B is the airline, partner C the hotel, and partner D a third-party vendor providing a calendaring service. In this particular partnership scenario, the application partner knows it is exposing some set of functionality, but does not necessarily know whether it is coming all from one vendor or from multiple vendors.

If each link represents a step (a term that here loosely indicates value), some partners contribute more to the overall application than others. Partners A, B, and D all contribute one link, but partner C contributes three links. Even though they provide more functionality, that doesn't necessarily mean that partner C has the dominant position in the business relationship, since partners A and B are necessary for partner C to be accessed by a user. Partner C may have chosen to focus only on the logic of the functionality and forgo the investment in designing a presentation for end users. However, that means in another application partner C might be directly utilized by the application owner (see Figure 2-2).

Figure 2-2: The shifting of partners in a Web services-based application

Here you can see that partner C is connected directly to partner A. Perhaps the mobile application wanted to provide just a hotel reservation system, and so the airline's functionality wasn't needed for this application. In another application scenario, partner A might have realized that partner B wasn't providing any value and was only acting as a reseller of partner C's service. Bypassing partner B might not only save costs for the application, but also provide better performance, since a hop is eliminated.

• A hop represents a system on the network as the data is transferred between the caller and the caller's destination. A smaller number of hops implies faster throughput given a consistent transfer rate between hops.

When partner C originates the application (see Figure 2-3), partner C must provide functionality over and above what it provided for the other applications. This is because partner C is now responsible for presenting the application to the end user. Previously, partner C was concerned only with providing the functionality for its piece of the process, not delivering the entire application. This scenario is like the hotel company providing the mobile application for the user stuck in traffic. The merits of doing this are obviously up for debate, but the idea is that the option exists.

Figure 2-3: Partner C as the application owner

One more high-level scenario that needs mentioning is the owner/broker model. In this kind of partnership, the originator connects to each partner in the process directly and essentially brokers the services into a single application (see Figure 2-4).

Figure 2-4: Partners in a brokered Web services application

In this scenario, the mobile application provider may be expanding its reservation application to utilize several major hotel chains and their reservation systems. There is less dependency between the partners, since there is no stacking of functionality. This arrangement is appropriate, since each partner is a competitor with the others and would have no incentive to support the others. However, the owner is still just as dependent on each partner for its functionality.

Note 

This may seem to be the ideal scenario for a Web service, but it may not be possible. You may have some partners that only provide partial service, but are partnering with others to provide a more robust service. In other instances, there may be core functionality that a partner needs, and the partner may be using a Web service partner for that service. A good example of this would be a financial authorization process. A broker may be using a shipping partner, and that shipping partner may use another service to authorize a credit card or account.

Of course, some hybridization of these models is also possible (see Figure 2-5). Some partners further down the application chain may act as brokers, and some partners may have entire application chains behind their service offering. It doesn't really matter to the partners, since the end result is the same regardless of the model.

Figure 2-5: Partners in a hybrid Web services application

This idea is very similar to other complex partnerships that exist between businesses today. For example, take a hardware vendor that manufactures computers. While the hardware vendor may assemble the system, the vendor doesn't make every item in it. The vendor has a partner that provides the video card, for instance. If you take this example one level further, the video card manufacturer probably does not make every item on its cards. It may have a partner that provides the memory for its components. You could probably take this example even one level further by identifying the suppliers the memory manufacturer uses to build the memory chips. If you extend this out to every component in a computer, you can see just how many partnerships are involved in the end product.

As you can see, Web service applications can get very complex, depending on how many partners integrate their services. Hopefully, though, you are starting to realize that you could expose Web services to a large pool of users, as well as mix and match services from other providers to build a variety of applications. To aid in this reusability, there are certain rules that have to be followed so that developers on any platform can easily integrate your Web service into their application. Once you have this established, you can then scale this out by integrating additional services just like you would any other type of native object. We will look at specific application scenarios later that will further illustrate this concept.

• Scale refers to the ability for an application or process to grow its capacity to meet demand. To scale an application out simply means to increase its load capacity.

Because a Web service is a little different from the applications we are accustomed to, our architecture analysis begins by looking at the communication architecture: that is, the architecture that defines the communication, or transport mechanism, between Web services and their consumers. It is important to understand how consumers communicate with Web services before looking closely at the internal workings, because this communication is what really differentiates Web services from other exposed processes. Once you understand how the externals work, you will have a much better appreciation for the issues that have to be addressed internally.

Then we will look directly at the individual layers of a Web service application, independent of the communication mechanism. This helps to provide a big picture view of the process of using Web services and a breakdown of the n-tier view.