EB SERVICES - PART 1
Integration using Real-time Web Services
PERTH, AUSTRALIA – October
31, 2001: Previous issues of TEN
(TEN#15 and TEN#16) discussed the emerging field of Corporate Portals. This
issue introduces some initial concepts and reasons for the rapid growth of Web
Services for the Corporate Intranet, for Extranets and for the Internet. Because
many readers of TEN are non-technical, I will relate Web Services to other
technologies that are more familiar. Later issues will examine web service
concepts further, and will look in more detail at some of the tools and products
that are being released to support this burgeoning field.
TEN - The Enterprise Newsletter
Back to Contents.
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
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
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. We will discuss Web Services and related XML technologies in
this and later issues of TEN.
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
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.
Back to Contents.
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.
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.
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
Back to Contents.
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
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.
We finish this issue with a
brief summary of Web Service Resources on the Internet, and vendors of Web
Service development tools. We will examine these resources and development
products further, in later issues of TEN.
Back to Contents.
Services Resources and Vendors
The field of Web Services is
one of the most rapidly evolving areas relating to XML. Some dedicated web sites
have been developed to provide information on Web Services, WSDL, UDDI and SOAP.
I have provided a brief introduction to some of the resources that are
available. The benefits achieved from Web Services mean that this field is in
turmoil. The following web sites change daily, so visit them often.
This web site is a central jumping-off point to everything related to Web
Services. It includes News, Software, Events and Papers. Visit
This is the web site for the UDDI Registry and Repository. It provides full
details of UDDI, with additional information on WSDL and SOAP. Visit
The World Wide Web Consortium web site publishes Working Drafts, Recommendations
and papers relating to all XML specifications. SOAP, UDDI and WSDL
specifications and primer papers will be published here as they move through the
W3C Specification process. For example, the “SOAP V1.2 Part 1: Messaging
Framework” specification is at
http://www.w3.org/TR/2001/WD-soap12-part1-20011002/, with “SOAP Version 1.2
Part 2: Adjuncts” at
This is a web site that provides papers, news, software and resources for Web
Services, SOAP, WSDL and UDDI. Visit
XML Cover Pages:
Robin Cover maintains a section of his XML Cover Pages web site dedicated to Web
Services. He includes an abstract on each topic, with links to the topic detail
and related information. Visit
Microsoft on UDDI:
Microsoft has a UDDI web site that provides links to Microsoft UDDI resources,
plus related resource links for UDDI, WSDL and SOAP. Visit
IBM on WSDL:
IBM offers many articles, resources, software and links from their
DeveloperWorks web site. Visit
For example, a two part series of articles, titled: ”Understanding WSDL
in a UDDI Registry – Parts 1 and 2” is available from
To ensure you are aware of
any new resources that become available in this area, I also recommend that you
do a regular search of the Internet using the key words: “web services” SOAP
There are many software
vendors developing products and tools to support Web Services. A brief list,
with links to relevant web sites, follows. A search of each vendor’s web site
using the same key words as above will also yield valuable information.
IBM – with its other founding developers of Web Services, Microsoft and Ariba –
jointly submitted initial Web Services specifications to the W3C for
consideration in Sep 2000. IBM is developing extensive support for Web Services
using WebSphere. Visit http://www.ibm.com/xml/.
Microsoft is using its “.NET” initiative (called ‘dot Net’) to transform the
company – moving its software product functionality to the Internet. Web
Services are integral to .NET, for real-time integration of services. For
example, “Hailstorm” – partly released with Windows XP – offers some initial Web
http://www.microsoft.com/business/articles/net/netvision.asp for an article
discussing Microsoft’s vision, or visit
http://www.microsoft.com/net/ directly. Many articles are available,
including online training and webcast seminars on all aspects of .NET. Microsoft
also offer a free DVD containing the VisualStudio.net Beta 2, with 2 GB of .NET
The Software AG EntireX Web Services Development Environment supports
integration using many RPC technologies, including Web Services, Java, CORBA and
COM. Search for “EntireX” from
http://www.softwareag.com/ or visit
http://www.softwareagusa.com/. The Software AG Tamino XML Database also
provides extensive XML development capabilities. Tamino is supplied within the
Software AG XML Starter Kit, available for download, or on CD. Visit
HP is extending its e-Speak initiative to
support Web Services and related languages. Visit
http://www.hp.com/ and search using the above key words. Many useful links
The Sun Open Net Environment (Sun.ONE) is being
developed by Sun to support Web Services, as an answer to Microsoft .NET. Visit
http://www.sun.com/ and search using the above
key words. Many relevant ONE links are available.
The CapeConnect Web Services Platform and CapeStudio
Rapid Development Platform provide support for development and delivery of Web
We will look at product
offerings, either released or in development, from many of the companies above
in later issues of The Enterprise Newsletter.
Back to Contents.