Introduction to Web Services

Published in TDAN.com January 2002

Introduction

To understand the state of the Information Technology industry today, it is useful for us to consider similar problems and their solutions in other industries. We will use these solutions as
lessons for the IT industry. For example, consider how cars would be built and used, if the automobile industry had evolved not as it is today, but instead it had evolved similar to today’s
IT industry. Picture the following scenario …

I am driving along the highway. It is a beautiful day. My new car, the latest Model X from Major-General Autos, is purring along beautifully. I made the correct decision: it is a magnificent piece
of hardware; its performance is incredible. It really does get one million miles per cup of fuel as advertised. And I am sure ­ if it was not for the speed regulator mandated by the government
to keep the car’s speed below the sound barrier ­ that my new car would easily reach Mach 4. But speed limits are speed limits, and we all must abide by the law.

Then the car’s controls start to turn blue! I remember from the Car Operating Procedures course that the “blue controls of death” meant that the vehicle was developing a fault.
Thank goodness I decided to take that six month COP course. I really learned how to operate the car well; the operating procedures were all completely different from my previous car – the Model Y.
Some of my late friends had decided to skip that course and learn by trial and error. The COP course would have taught them how to avoid that crash.

I looked anxiously for a Major-General Autos Service Center. Only they would have the ability to replace the faulty component with a new part for my Model X. But that would really spoil my trip. I
know they are really fast, but a three month wait while they make a new “soft-part” by hand really does mean my holiday is ruined. The new object-oriented method of soft-parts
manufacture has not been accepted yet by the Major-General Autos soft-parts engineers. Most of them gained their soft-parts coding skills over 40 ­ 50 years. They all know that the new
object-oriented method for interchangeable soft-parts could not possibly work; it will never replace their special hand-crafting coding skills.

Of course, the above scenario is ridiculous. The automobile industry has not benefited from the speed and power efficiencies that technology has brought to the IT industry. But on the other hand
the auto industry has other advantages that IT still has to achieve.

For example, cars have a standard operating procedure. So learning to drive one car enables us to drive any car; all car controls and driving procedures are standardized. But this is not yet true
for computers. Most operating systems are now similar in operation, due largely to the dominance of Microsoft Windows. But the operating procedure for each different program still has to be learned
in detail. This is changing slowly, such as with common operating procedures now used by most programs in the Microsoft Office suite of products. But this common set of menus and procedures has not
achieved standard acceptance across all software developers or manufacturers. Many programs still require considerable training to be able to use them effectively.

But what about hardware and software parts interchangeability and reuse?

The proprietary hardware interfaces of a few years ago are now disappearing. Most manufacturers of hardware peripherals now use common technology interfaces such as PCI, USB, Firewire and
Bluetooth. Most peripherals today can be easily connected using these interfaces for the latest Intel-based machines or for Apple Macintoshes. These technologies are moving us closer to the
automobile industry concept of interchangeable hardware parts from inventory. But the delays arising from hand-crafted “soft-parts” in the scenario above are very real. We do not yet
have the capability for easy interchangeability and reuse of software. This is by far the greatest problem today in the cost and use of computers.

Each program and each software component is still largely hand-coded from scratch. Yet much of the hand-coded logic used in most programs is implied by the database structure that it is designed to
use. Code generators today can use standard code patterns to automatically generate 80% – 90% of the program code that was previously 100% manually coded. We are starting to see automatic
generation of programs in a variety of languages. But object-oriented programming has not yet delivered on its promise of inter-changeable and reusable code modules. Of course it is true that
object-oriented programmers can develop reusable code modules. But it takes considerable time and skill to achieve this result.

Because of different hardware and operating system platforms, we still have considerable problems in integrating code modules within and between enterprises. These different platforms and
programming languages use various Application Program Interfaces (APIs). Consequently programs or code modules written in one language with a particular API cannot be easily integrated with other
programs or code modules on different platforms. To address this problem, Remote Procedure Call (RPC) technologies that use CORBA (Common Object Request Broker Architecture), COM (Common Object
Model) and other approaches have enabled tightly-coupled integration of code across dissimilar platforms in real-time.

But the complexity of these RPC approaches for different APIs has meant that code module integration and reuse is still time-consuming and difficult. Web Services and associated XML technologies
have recently been developed to address real-time program and code module integration.

Furthermore, most enterprises have a common problem: different business processes and procedures are used to do the same thing, where a common standard procedure could be used instead. For example,
a common problem is experienced in updating a changed customer address in each of the different versions of Customer data in an enterprise. The customer address may need to be changed in the
Customer database (in the Sales Department), the Client database (in the Credit Control Department), and the Debtor database (in the Accounts Receivable section of the Finance Department).

These databases must be changed using special address-change maintenance programs written for each separate database. The same details must be updated in every database where the customer’s
address exists redundantly. This is redundant work. It requires redundant staffing to make these redundant changes. These programs may each use change procedures that do not all operate the same
way. This also means redundant training, if programs used for address-update all have different data entry operating procedures.

This address data should be able to be updated using a common customer-address-update process, used as a single standard process throughout the enterprise. This will lead to the design of common,
reusable business processes using Web Services, and common Web Service processes and workflows.

So now let us now consider the concepts, components and potential of Web Services in the IT industry.

Concepts and Components of Web Services

Web Services have recently emerged to address the problems of software integration discussed above. Early work carried out independently by various companies over the period 1999-2000 culminated in
the submission by IBM, Microsoft and Ariba of initial Web Services Specifications for consideration by the World Wide Web Consortium (W3C) in September, 2000. More than 130 companies are now
collectively working on a set of specifications for interoperable Web Services.

Web Services are based on XML. The IBM alphaWorks web site (http://www.alphaworks.ibm.com/) describes Web Services as follows:

“Web services are self-describing, self-contained, modular applications that can be mixed and matched with other Web services to create innovative products, processes, and value chains. Web
services are Internet applications that fulfill a specific task or a set of tasks that work with many other web services in an interoperable manner to carry out their part of a complex work flow or
a business transaction. In essence, they enable just-in-time application integration and these web applications can be dynamically changed by the creation of new web services. Various applications
that are available on the Internet can be accessed and invoked at run time without prior knowledge and programming requirements to enable business processes and decision-making at Web speeds.
IBM’s Web Services Toolkit provides a runtime environment as well as demo/examples to design and execute web-service applications to find one another and collaborate in business transactions
without programming requirements or human intervention.”

Previously, to combine or integrate different application programs, each Application Program Interface (API) used by code modules in those programs was defined for the specific language and
operating system used. It generally meant that all programs had to use the same language and operating system ­ analogous to the replacement of Model X “soft-parts” only using
hand-crafted parts from Major-General Autos engineers as described in the car analogy above.

This programmatic integration of code modules and applications using language-specific and operating-system-specific APIs has made program integration very difficult in the past. Code modules
integrated using Remote Procedure Call (RPC) technologies such as COM or CORBA interfaces have been used as we discussed earlier, but they are tightly-coupled. Because of this tight coupling, a
change that is made in one component can also affect other components. While they are effective, these technologies have been very complex and time-consuming. They have therefore been expensive to
use and maintain.

In contrast, Application Program Interfaces can also be defined using XML. An API can be specified using an XML language called SOAP (Simple Object Access Protocol), which offers the advantage that
it can be used with any programming language and operating system that understands XML. As SOAP is much simpler, integrated code modules can be loosely-coupled. This means that changes in one
component do not affect other components as we saw with tightly-coupled RPC approaches. Because of this, SOAP is less expensive to use and maintain.

The definition of APIs using SOAP is one required component of Web Services. The services that can be carried out by the code module or program must also be described. This is specified using
another language based on XML, called WSDL (Web Services Description Language). WSDL identifies the SOAP specification that is to be used for the code module API. It identifies the input and output
SOAP message formats that are also required for input to and output from the module or program. Each WSDL specification is then used to describe the particular Web Services to be accessed via the
Internet, or from a corporate Intranet, by publishing it to a relevant Internet or Intranet Web Server.

But SOAP and WSDL alone are not sufficient. Unless web services are published in an electronic “yellow pages” directory that is accessible within the enterprise (via an Intranet) or
available world-wide (via the Internet), no one would know of the existence of the available Web Services. A further XML language is used for this: called UDDI (Universal Description, Discovery and
Integration). This is used for publication in a UDDI directory, which enables the Web Services to be found by others. SOAP, WSDL and UDDI are related to each other as shown in Figure 1 (see
http://www.ies.aust.com/~ieinfo/ten17.htm#Fig1).

To understand the power, ease-of-use and flexibility of Web Services, we will look at two examples that illustrate how Web Services can be used within an enterprise, and also between enterprises.

Examples of Intranet and Internet Web Services

The first example uses Web Services within an enterprise. The earlier problems that we discussed arising from redundant data, with redundant data entry to make required changes to each redundant
data base, resulted in redundant work, redundant staffing and often redundant training to use different data entry procedures for each data base. These were all manual procedures that were used to
make the required changes. They were slow, error-prone and expensive. And until all required changes were made, other problems were encountered because the different versions of the data were not
synchronized.

Web Services offer considerable benefit here. Each data entry maintenance program used to change a redundant data base can be defined so that the data changes are expressed as Web Services, using
SOAP. For example, a Web Service can be defined to Create New Customer using SOAP, invoking the Create Customer logic and business rules within the Customer data entry program used by the Sales
Department. Similarly Read Customer, Update Customer and Delete Customer Web Services can also be defined, to invoke the corresponding read, change or delete logic and business rules in the
Customer data entry program. In the same way, Create Client, Read Client, Update Client and Delete Client Web Services can be defined with SOAP to invoke the corresponding logic and rules in the
Client data entry program for the Credit Control Department. And so also, similar SOAP Web Services can be defined to invoke the Debtor data entry program logic and rules in the Accounts Receivable
section of the Finance Department.

Previously, if a Customer data base change was made manually by the Sales Department, a Change Data Base Notice Form also had to be printed. This was then sent to the Credit Control and Accounts
Receivable sections so they could also make the relevant manual data changes to the Client and Debtor data bases that they maintain. We discussed that these manual changes were slow, error-prone
and expensive. In the past, the only way to avoid this manual updating was to completely replace the separate redundant data bases by an integrated data base. In addition, all of the previous
application programs that used the redundant data bases would have had to be replaced by new, integrated programs that instead used the integrated data base. This data base and application program
redevelopment and replacement were extremely expensive and complex.

Now, these data changes are expressed as Web Services for each of the redundant data bases. Each Web Service is specified using WSDL, which identifies the defined SOAP specifications, and relevant
SOAP input and output messages. When the WSDL specifications are published to the Intranet Web Server, the Change Data Base Notice Form that was previously printed is replaced by WSDL-defined Web
Services. Each WSDL specification identifies the relevant SOAP messages needed to invoke data change logic and business rules in the Customer, Client or Debtor data bases.

The slow, error-prone manual procedures for data entry are now replaced by real-time, dynamic Web Service transactions. These are sent via the Intranet as SOAP messages that invoke the relevant Web
Service in each data base needed to keep the redundant data up-to-date. The result is the immediate completion of all related data base changes to all relevant data bases. Using Web Services,
redundant data bases can remain, and can continue to be updated by their separate data entry programs. This updating is now done faster and automatically using SOAP messages and Web Services in
real-time, rather than having the costly redevelopment and replacement of the data bases and programs with integrated data bases and programs.

The second Web Services example shows their use outside the enterprise. In this example we will look at the ordering of products or services from an Online Store via the Internet.

The Store accepts orders online, for payment by credit card. The credit card must first be approved by the relevant Bank. If the card is valid and credit is available, payment is credited to the
Store’s Bank account. The Store then orders the requested products or services from its Supplier, and arranges with a Shipping Company for the goods to be picked up from the Supplier and
delivered directly to the Customer. This is called “drop-shipping”.

In the past, this scenario was carried out by the Store using mail, phone or fax to communicate with the Bank, the Supplier and the Shipping Company. This took time and often introduced errors or
delays. To improve customer service, the Store replaced this mail, phone and fax communication with online coordination with the Bank, the Supplier and the Shipping Company. But this presented
severe problems in the past using Remote Procedure Call technologies. For example, the Bank may use CORBA for online credit card authorization and payment The Shipping Company may use COM, and the
Supplier may use yet another RPC approach. These different RPC interfaces add dramatically to complexity and to the time required by the Store to implement this online coordination.

Now let us consider this scenario using Web Services. The Bank defines its Credit Card Approval and Credit Card Payment processes using SOAP. It publishes the SOAP interfaces, plus the input and
output SOAP message formats, to its Internet Web Server using WSDL. Then it registers these credit card Web Services (defined by SOAP and WSDL) using UDDI (Universal Description, Discovery and
Integration) to the UDDI Registry at http://www.uddi.org/. Similarly the Supplier and the Shipping Company register their respective Web Services using SOAP, WSDL
and UDDI.

To locate Banks, Suppliers and Shipping Companies that offer relevant Web Services, the Store visits the UDDI Registry at http://www.uddi.org/. It issues UDDI
“Find” requests to locate Web Services that satisfy its requirements. Using the SOAP, WSDL and UDDI specifications published by relevant companies, the Store prepares the SOAP
interface, and input and output messages. It sends these SOAP messages to the URL Internet address of the relevant Web Servers, as published in the UDDI Registry via UDDI and WSDL by the selected
Bank, Supplier and Shipping Company.

This Web Services approach has many benefits. A standard way is used to integrate with Web Services offered by any organization, regardless of where they are located world-wide. This has clear
advantages of greater simplicity and ease-of-use, which lead to benefits of faster implementation and lower cost.

The Store can select any Bank, Supplier and Shipping Company that meets its needs for Web Services. For example, if a Customer is located overseas, a Supplier and Shipping Company located near the
Customer can easily be used. This offers the benefit of lower cost ­ so producing greater profit, or the lower cost can be passed on to the Customer as lower prices.

Each of the Web Services companies gain benefits also. Web Services can be easily published for world-wide access. Depending on the value of a Web Service to users world-wide, each Web Service can
be charged on a per-use basis. Each “per-use” price may be a micro-payment less than a cent, for example. But such Web Services ­ which previously have been inaccessible; locked
away in legacy application programs ­ can also generate additional revenue.