Methodologies and Technologies for Rapid Enterprise Architecture Delivery


| Home | Courses | Projects | Papers | Contact Us |


Issue No 17:

 Enterprise Integration using Real-time Web Services

Printable PDF Version


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.  

Clive Finkelstein
TEN - The Enterprise Newsletter

Back to Contents.

Introduction to Web Services

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. We will discuss Web Services and related XML technologies in this and later issues of TEN.

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.

Back to Contents.

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 ( 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.

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.

Back to Contents.

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 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 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.

 Web 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. 

Web Services.ORG: This web site is a central jumping-off point to everything related to Web Services. It includes News, Software, Events and Papers. Visit

UDDI.ORG: 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

W3C.ORG: 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, with “SOAP Version 1.2 Part 2: Adjuncts” at

SOAPRPC.COM: 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 WSDL UDDI.

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 Corporation: 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

Microsoft Corporation: 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 Services. Visit for an article discussing Microsoft’s vision, or visit directly. Many articles are available, including online training and webcast seminars on all aspects of .NET. Microsoft also offer a free DVD containing the Beta 2, with 2 GB of .NET code samples.

Software AG: 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 or visit 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

Hewlett-Packard: HP is extending its e-Speak initiative to support Web Services and related languages. Visit and search using the above key words. Many useful links are provided.

SUN: The Sun Open Net Environment (Sun.ONE) is being developed by Sun to support Web Services, as an answer to Microsoft .NET. Visit and search using the above key words. Many relevant ONE links are available.

Clear Case: The CapeConnect Web Services Platform and CapeStudio Rapid Development Platform provide support for development and delivery of Web Services. Visit

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.



TEN Archive
Contact Us





Clive Finkelstein is the "Father" of Information Engineering (IE), developed by him from 1976. He is an International Consultant and Instructor, and was the Managing Director of Information Engineering Services Pty Ltd (IES) in Australia. 

Clive Finkelstein's books, online interviews, courses and details are available at

For More Information, Contact:

  Clive Finkelstein
59B Valentine Ave
Dianella, Perth WA 6059 Australia
Web Site:

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.

| Home | Courses | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 2004-2009 Information Engineering Services Pty Ltd. All Rights Reserved.