Web Services Part 1: Existing Problems
- Existing Problems in the Market
- Current Technological Challenges
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This is the beginning of a new series covering web services, including their origins, related standards, revenue models, integration challenges, architectures, migration plans, first-generation and second-generation application service providers (ASPs), interviews with leading industry executives, and product reviews. Many of these topics will be similarly discussed in my upcoming book (tentatively titled Applying Web Services Solutions), to be published as part of Prentice Hall's Harris Kern Enterprise Computing Institute.
This first article provides some historical perspective and references. This is not intended as an academic discussion on the history of computing as much as an illustration of how many of these existing technologies, combined with business needs, form the foundation for web services. In doing so, I hope to demystify the hype and demonstrate that web services are an evolutionary concept rather than a revolutionary paradigm. With apologies to a noted computer lecturer, "This technology [pick your favorite] is not a silver bullet. It is yet another silver bullet."
Existing Problems in the Market
In the early days of Internet commerce (say, five years ago) much of the emphasis—and hence, progress—was centered on commerce initiated by people. That is, a person would visit a site, perform some searches and then place an order.
NOTE
For the sake of simplicity, we are using the most common example, which is a person visiting a web site. As we'll see later, much of this interaction and automation take place on the Internet, which may or may not include a site per se.
While this model is acceptable for an individual consumer, it falls short in cases where the purchase cycle tends to be repeated frequently, such as when a corporation purchases a variety of items from multiple sources. These are some of the deficiencies of this model:
Requiring a person to manually perform a process can be time-consuming and error-prone. Automating such processes would certainly streamline a company's operations significantly.
The information returned from the transaction is a mix of presentation-related data (graphics, formatting instructions, etc.) and business data (product names, codes, prices, etc.), and not in a format that can be easily integrated into another system. Consequently, it often requires a person to distinguish what is actually relevant in most interactions. Consider how expensive it is for a purchasing agent to reenter information returned from a purchasing system into an accounting system. This seems rather antiquated, but many companies are still performing much of their processing manually because there are few, if any, standards for information that's being passed around. What is needed is a universal format—or at least a way to separate business data from presentation data.
In many cases, the functionality offered by one site cannot be merged with another site to provide a more complete solution to the consumer, due to technical limitations (lack of standards, integration challenges, incompatible technologies, and so on). As an example, consider a consumer who wants to book an entire vacation online (flight, car, lodging, and local activities). The traveler or travel agent has to cobble together a package by visiting multiple sites and then ensure that all the relevant criteria—identification, dates, locations, etc.—are matched. Anyone who has ever planned a vacation has experienced the amount of work involved; no wonder cruise ships are so popular! This clumsy user experience exists because it's currently too difficult for the site operators to break the sites into discrete sets of sub-processes that can be merged or integrated into an experience that's relevant to the consumer; in this case, a total vacation experience. The focus of each site is narrow—the ski school is offering skiing instruction, the airline is offering flights, etc.—whereas, as far as the user is concerned, all of these events have to be scheduled and booked to accomplish his overall goal; that is, booking the entire vacation. Unfortunately, the site that offers skiing instruction has no way of knowing that the consumer visiting the site is the same person who's staying at a local hotel on a particular date. Without that little detail, the skiing site would have to ask for that information again. Multiply this registration process n times, and the poor consumer feels like taking a vacation after just planning the vacation!
NOTE
In more technical terms, the sites cannot share the state of the user session. Current technologies allow for saving the state as long as the visitor is on the same site, but maintaining state between sites is much trickier.
Even with these problems, the Internet has enjoyed phenomenal growth, so what's the big deal? Well, if these and other issues can be addressed, the potential growth may dwarf what we've seen so far.