Step back in time and think about the order of the Internet evolution . In the early Internet days, text-based content was king. Over time, Hypertext Transfer Protocol (HTTP) and Hypertext Markup Language (HTML) evolved to be rich enough to represent acceptable multimedia content. Further, the protocols and markup languages were easy enough that anyone could build and deploy a Web page. By this time, network bandwidth was still catching up to the content offered on the Internet.
Eventually, a critical mass hit the Internet:
Companies such as Amazon.com started to generate revenue.
Husbands ordered flowers for their wives on the Internet as a part of the culture rather than as a novelty.
Virtually all news organizations started to have a Web presence.
Out of all of the business that started to occur on the Internet, one Web page signaled the start of true online business: the FedEx package-tracking page. Although it seemed like a novelty at the time, today it is easy to forget exactly how revolutionary this HTML form was in terms of its impact to business.
The basis for the page was simple; using a tracking number given to you by FedEx, you can track your package as it moves across the country. Suddenly, FedEx was not just a company that moved a package from a supplier to a customer; it was a part of a value chain. This value chain starts with product manufacturing and ends with the consumption of the product by the consumer. The package tracker exposes the customer and the manufacturer to the shipping process and its progress in the value chain. Now, everyone in the value chain knows when a package was shipped and received and can get up-to-date estimates for delivery.
The FedEx package tracking application shows the progress of one business process, shipping, in a chain of many different processes that have to occur in the larger business process known as order to fulfillment . The order-to-fulfillment business process starts when a customer places an order with a company and ends when the customer receives the order. Although the separate package tracking application is nice, your customer must deal with two applications for keeping track of a single business process: the package tracking application and your own order processing application.
The ideal situation for a customer is that they can view the entire order-to-fulfillment process from a single location ”your Web site. Immediately after placing an order, customers can see the order being located, packaged, and shipped and receive an estimate for the arrival time to their doorstep. It is important to bring the shipping company and its information seamlessly into your own business process. To do this, you need to have your applications tightly coupled with the shipping company's applications. After the product is shipped, you actually want to reflect the shipping company's status rather than your own.
Either the shipping company or the manufacturing company is in a computing platform predicament. How does the shipping company expose their application in a way that all of their customers can easily access it? Should they use the Java platform? With this tactic, a company gains portability as well as a mindshare of more than 50 percent of the computing industry today. Unfortunately, some of the biggest companies do not yet use the Java platform. Further, disruptive technologies are always on the horizon, such as C#, that could make the decision to expose an application with the Java platform unwise.
The choice of the platform to expose your API in should be language neutral and remotely accessible to natural constructs available in any language. Language neutrality will make it equally simple ”and equally difficult ”for any language to access your API. Remote accessibility makes the service addressable from any language although it resides somewhere on the network. Web Services provide solutions to both of these issues. The World Wide Web Consortium (W3C) defines a Web Service to be the following:
a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.
If there are two things you should know after the 1990s, they are that everything connects to the Internet, and everything supports Extensible Markup Language (XML). With Web Services, you have solved the dilemma on how to allow access to the package-tracking application from a variety of platforms; you do it with XML-based Web Services that rely on the Internet.
FedEx choosing a neutral language and communication mechanism such as Web Services illustrates another important use of Web Services: tying together disparate architectures. Thinking about a shipping company, you cannot predict what computing platforms from which a company will request to access your API.
Consider the situation many companies are in today with multiple software suites serving the employee requirements. Often, these companies purchased their software from different software vendors . Eventually, a company realizes that its customer data resides in both systems, with each system having different data. To reconcile the data and keep it coordinated over time, a company can write batch programs and different proprietary synchronization programs.
To write these synchronization programs, a programmer must be knowledgeable about both systems at some level. Most often, programmers write simple programs that query the database from one system, convert the data to the format of the other system, and insert the data into the second database table. Unfortunately, a change to either application renders the data transfer program useless. Further, system administrators must take the program offline to run the synchronization program; this avoids problems with pushing data into locked tables or getting a partial update from the source system.
Web Services, again, come to the rescue. By surfacing an API in a language- neutral and platform-neutral format, programmers can access data from one system and quickly move it to the other through the Web Service. There are several strengths to this approach:
Programmers can write the data-transfer programs in any language or platform with which they are comfortable.
The source and target systems can control the requests and updates of data in such a way that they do not interfere with a running system.
Consider the scenario of a third architecture inserted into a company's integration needs. In this case, a programmer's job without Web Services would become even more difficult as they learn and leverage the various software data formats. With Web Services, they simply learn another API and extend their existing program.
Because your own company's applications are often a microcosm of the Internet's diversity in applications and platforms, Web Services can help with both internal integration projects and external integration projects.