Background

We are in a very exciting time of technical innovation and development. While the Internet is responsible for much of this innovative state, we have just started to tap into the potential of this paradigm of extensive connectivity. Every day there seems to be a new buzzword, and only people who spend every spare moment studying and reading have any hope of distinguishing the overhyped from the underappreciated.

One of the latest hot topics has been XML, for eXtensible Markup Language. XML is a standard for defining data in a very simple and flexible format. XML's simplicity and flexibility give it value and merit, but focusing on the technology alone does not help any business solve its problems or aid in its objectives. XML is an enabler of solutions, but is not itself a solution. Being an enabler means it is a part of the solution, perhaps unique in what it provides, perhaps not. XML is an enabler because, rightly or wrongly, almost everyone agrees that it is good. A few powerful voices have spoken out, and the rest of the software industry has literally been forced to follow, whether or not they have validated the proclamation. The outcome has been massive support for XML and everyone agreeing that it is a good thing where interconnectivity is concerned!

XML is also an enabler because it provides an essential piece of functionality for many applications. It describes data, which is the root of any worthwhile application, and any method for working with that data has merit. XML has additional value in this area because it makes certain aspects of working with data easy. Easy is usually a good thing also!

Into what kind of solutions does XML fit? Several possible answers exist, including Web services. First let us take a look at how we got to where we are. What have been our limitations, and why are we just now talking about Web services?

• The term Web refers to the Internet as a conceptual entity that utilizes the standards defined for its usage. This reference is more logical than physical since Web applications can be utilized on internal networks as well as the Internet itself.

While Web applications were initially very quick and simple to develop, they were also almost all presentation with no real substance. As our use of the Internet has matured, technology has advanced the depth and richness of what we can do on the Web. Most efforts have been focused on expanding the capabilities of what we can do on an application level. Applications are designed for end users, who have specific needs and requirements. We have pushed the boundaries of Web application capabilities to the point where we almost expect them to be accessed programmatically. The Web applications and tools we have today were built on technologies and protocols intended for human consumption, not system consumption. These are fundamentally different concepts.

• An application is a program designed for an end user. Therefore, a Web application is an application designed for use over Web-based protocols.

Content is by far the most flexible component of a Web application. Most Web developers take advantage of this flexible content and utilize it for more than it was intended. This includes trying to turn Web applications into programmatic services. Often when developers believe they are trying to share content, they are actually trying to share processes. Traditional Web developers must change this approach if they are to effectively utilize Web services.

Meanwhile, application developers approach this same challenge on a more traditional level. They have come up with component architectures to promote the reuse of business logic, but the same architectures don't apply in a massively distributed and disparate environment like the Web. Some compelling selling points of Web-based applications are their speed and ease of development, at least in a single, heterogeneous infrastructure. This does not necessarily carry over once you try to interoperate between disparate systems. For the business trip scenario at the beginning of this chapter, building the interface to access the airport and hotel information is relatively simple, assuming all of that information is in one location. Most likely, though, the hotel owns only its own information, the airline its own, and so on. It is the integration of this information, and more specifically, the process exposing it, that is problematic on the Web or anywhere else today.

Clearly, the partnerships necessary today to bring real value to businesses and applications collaborating over the Internet require much greater interoperability. Since the Internet first emerged to the public as a new medium, most advances have focused on making back-end systems and clients more robust. While this allows for much more productive and feature-rich applications, at this point the innovations of yesterday cannot meet today's needs regardless of effort or determination. The next generation of applications being conceived today (like our trip scenario) is simply not practical, if not impossible, without changing the way we think about Web applications.