Evolution of the Web Service Solution

Depending on whom you ask, you could get any number of answers to the question "What is the definition of a Web service?" This question may someday be as effective as "What platform is best for the enterprise?" in starting a war of words between software developers and system providers. We should all recognize that the success of Web services corresponds directly with the extent of the ability in the industry to agree on what Web services are and how they are implemented. If we all have differences at defining them, it will inevitably be fairly difficult to build and consume them across various implementations.

Although Web services will evolve over time, at some point we will reach the first "final" solution that will build critical mass.

• Critical mass is a term used to reference an arbitrary point in time when the use of a solution or product starts to pay off by producing a return on investments and/or is self-propagating.

It may still take a year or more for us the reach this solution, and it is best to take incremental steps of progress, learning and gathering support along the way. The development life cycle for Web services will take four such steps.

This process is shown as a pyramid (see Figure 1-10) for a very important reason. As we take each step and build on it, it will become harder and more painful to go back and make changes. That is why each step should be taken carefully even though we are all excited about getting to the top!

Figure 1-10: Web service development life cycle

Even as every Web service solution steps through this process, the industry is going through this same process on a macro scale. The question is how long the industries will be in step and how far they will get. Every step that the development community can take together through this process will lead to a more meaningful solution of Web services. At some point vendors will start to differentiate their offerings to compete for our attention, but the higher up this pyramid the industry is, the better off the providers, consumers, and users of Web services will be.

Determining the Objective

The first step is to agree on the purpose of Web services and focus industry efforts toward the same objective. Unfortunately, various marketing efforts and press statements have cluttered even this seemingly simple step. If someone wants to achieve something other than this objective, fine, but do everyone a favor and call it something other than Web services! Furthermore, this objective should be broad enough to accommodate changes in the designs and technologies between the first and nth implementations. With these goals in mind, this is what serves as a mission statement, or objective, for Web services that most unbiased experts should agree with:

The purpose of a Web service is to programmatically expose a process over a network through an open, standardized communication mechanism and format.

Parts of this objective should seem obvious when you consider that a service is a programmatically exposed function and we are intending to use these services over the Web. Unfortunately, this statement is so broad that it could apply to a number of things that exist that were not intended or ever thought to be Web services. Many solutions providing programmatic access to objects or components across systems could fit this definition. This purpose attempts to divorce the solution itself from the emerging technologies that have enabled this approach for the sake of longevity and flexibility until the industry agrees on a standard implementation.

Examining this statement in greater detail reveals some core ideas that are important to touch on. First, exposing an application programmatically is very different from exposing a user interface. A UI is not intended for other systems. For instance, a traditional client-server application exposes a screen that allows a user to access the functionality contained in its logic. A Web service has to be accessed by another application, which then provides access to the functionality to an end user. We look at this idea in more detail in the next chapter.

Next, the fact that a Web service is accessed over a network is critical because we are talking about integration. Integration is needed between systems, and the network is our path between those systems. Finally, an open, standardized communication mechanism and format are what will allow wide-scale integration. If everyone implements the same core formats and protocols, organizations should be able to cooperate and integrate regardless of their past and future vendor and technology choices.

Defining the Solution

It is important to realize that Web services are a solution, not a technology. The technology, although critical, is merely the facilitator and not the objective. Recall that our stated objective actually references no technology because it is not part of the requirements. Just like XML is an enabler, all the technologies that we can use to provide Web services are simply enablers facilitating the solution.

The next step in the establishment of Web services as an accepted standard is choosing the technology. The industry agrees on the basic building blocks on which to build Web services. The obvious choices here are TCP/IP and XML. Keep in mind that this step has more flexibility than our previous mission statement. At some point, Web services may utilize Ipv6 (the next version of IP, or Internet Protocol), which would mean a change to one of the building blocks, or at least the addition of a building block. These choices obviously grandfather in other technologies that they are built on (ASCII, physical networks, and so on). At this point, the following definition of a Web service solution is most appropriate:

A Web service is any process that can be integrated into external systems through valid XML documents over Internet protocols.

While still seemingly simplistic, this definition best describes the concept and minimum requirements necessary to solve the problem at hand: how to share processes between distinct systems over the Internet. Still key to this technical solution is its independence from any specific platforms or development tools to maintain the ability to integrate with any external system, regardless of its internal dependencies. This aspect is vital to gaining support across vendors for a consistent Web service solution. If this is maintained, Web services should become as accepted and ubiquitous as Web sites are today. The vast growth and proliferation of Web sites early in the Internet's development can be directly attributed to the open standards of HTML and HTTP, and the success of Web services will depend on the existence of nonproprietary implementations.

The core technologies defined here are the ones that the industry has accepted up to now. The inclusion of IP is necessary because it is the network layer for communication via the Internet. XML is the current industry standard for defining data, so XML is used to define the payload of a Web service. These standards may change over time, but today the use of both components is crucial to the value of Web services. Even with the technology advances coming, the definition at this step probably has the most meaning and should allow everyone to have a common understanding of Web services.

• A payload is the data transferred between processes during execution.

Optimizing the Implementation

This step is where we are today. We have defined the core technologies that will be used to provide and consume Web services, but we are still working on the specifics around their usage. These specifics include how the XML is utilized, which Internet Protocol is used, and how Web services are discovered. The best practices for Web services also must be defined, but that is difficult without many production implementations to reference. With new standards, such as SOAP (Simple Object Access Protocol) and XML offshoots, becoming defined and established, vendors are trying to build momentum around their implementations through actual usage in real scenarios. We will look at many of these standards in Chapter 9.

Identifying the Services

The final step is defining service offerings around Web services. How do we handle issues like security, authorization, and payment? How do we define the quality of service for Web services, and what is acceptable? Dialog and thoughts around these areas are ongoing, but until we complete the third step, no one can be certain what Web services are actually going to be like. Until then, all we can do is speculate. This topic is discussed further in Chapter 9.