Business Intelligence Network - The Vision for BI and Beyond

Rapid Delivery Technologies for Enterprise Architecture: Web Services Concepts

Published: June 14, 2007

This article introduces the concepts and reasons for the rapid growth of web services. It covers the concepts in some technical detail, with typical examples and applications using web services and the evolution of web services.

Introduction to Web Services
As we discussed briefly in earlier articles, each program and each software component is still largely hand-coded from scratch. Yet much of the hand-coded logic in most programs is implied by the database structure that the program is designed to use. Code generators today can use standard code patterns to automatically generate 80% to 90% of the program code that was previously manually coded. Using these code generators, we are starting to see the automatic generation of programs in a variety of languages. However, object-oriented programming has not yet delivered on its promise of interchangeable and reusable code modules. It is true that object-oriented programmers can develop reusable code modules, but it takes considerable time and skill to achieve this result. This has limited our ability to reuse much code.

Because of the 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 programming interfaces (APIs). 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), distributed COM (DCOM) and other RPC approaches have enabled tightly coupled integration of code across dissimilar platforms in real time.

But the complexity of 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 article.

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, in my EAI concepts article, we discussed problems 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 table (for the sales and order entry departments), the client table (for the credit control department), and the debtor table (for the accounts receivable section of the finance department).

These tables must be changed using special address-change maintenance programs written for each separate department. The same details must be updated in every table where the customer’s address exists redundantly. This is redundant work. It also requires redundant staffing to enter these redundant data changes. These programs may each use change procedures that do not all operate the same way. This also means redundant training, if the 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 standard process throughout the enterprise. This leads 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 emerged to address the problems of software integration discussed previously. Early work carried out independently by various companies over the period from 1999 to 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. Web services are based on XML. Many companies are currently working on specifications for interoperable web services. (The Web Services Interoperability Group [WS-I] was founded by IBM, Microsoft, BEA and others in 2002. Its goal is to achieve seamless Web Services interoperability between all vendors in WS-I.] 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."

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 RPC technologies such as COM, DCOM 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 affect other components; their level of integration is fragile. 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 programming interfaces can also be defined using XML. An API can be specified in 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. Changes in one component do not affect other components as we saw with tightly coupled RPC approaches; instead, program integration is more flexible. 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 an enterprise (via its intranet) or available worldwide (via the Internet), no one would know of the existence of the available web services. Another XML language used to achieve this is 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.

 
Figure 1: Web services are implemented using SOAP, WSDL and UDDI.

Intranet and Internet Web Services for Integration
To understand their power, ease of use and flexibility, we will look at two examples that illustrate how web services can be used internally within an enterprise, and externally between enterprises. The first example uses web services within an enterprise, via the intranet. The second example then considers web services between enterprises, across the Internet.

Intranet Web Services Integration Example
We will use the earlier problem that we discussed in my EAI article arising from redundant data, requiring data entry to make required changes to each redundant data version. We saw that this resulted in redundant work and redundant staffing to do that work. It also often resulted in redundant training for the staff: to use different data entry procedures for each data maintenance process. These were all manual procedures that were used to make the required data 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.

In the EAI article’s Figures 18 and 19, we saw that EAI can assist here. Web services also offer a great deal of benefit. Each data entry maintenance program used to change a redundant table can be defined so that the data changes are expressed as web services, using SOAP. In this instance, integration with web services is achieved in real time.

For example, a web service using SOAP – called CreateNewCustomer – invokes the Create Customer logic and business rules in the customer data entry program used in the sales and order entry departments. ReadCustomer, UpdateCustomer and DeleteCustomer web services can also be defined, to invoke the corresponding Read, Change or Delete logic and business rules in the customer data entry program. Similarly, CreateNewClient, ReadClient, UpdateClient and DeleteClient 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, 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.

In the EAI article, we discussed in Figure 18 if a customer address change was made manually by the order entry department, an address change notification form was also printed. This form was sent to the credit control and accounts receivable sections; they could make the relevant manual data changes to the Client and Debtor tables that they also 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 tables with an integrated table for use by all. In addition, all of the previous application programs that used the redundant tables also have had to be replaced by new, integrated programs that used the integrated table. This approach, requiring table replacement and application program redevelopment, is expensive and complex.

Instead, these data changes can be expressed as web services for each redundant table. Each web service is specified using WSDL. This identifies the defined SOAP specifications and relevant SOAP input and output messages. When the WSDL specifications are published to the intranet web server, the address change notification form that was previously printed is replaced by SOAP and 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 tables as illustrated in Figure 2.

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 table needed to keep the redundant data up-to-date. The result is the immediate synchronization of all related data changes to all relevant tables. Using web services, redundant tables 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 tables and programs with integrated tables and programs.

The earlier redundant data problem has now been replaced by a replicated data environment – maintained up-to-date and synchronized in real time.

Figure 2: Address change notification using SOAP and web services avoids the need for manual reentry. (Adapted from Source: © 2001 Gartner Group. Reprinted with permission.)

Internet Web Services Integration Example
The second web services example shows their use outside the enterprise. In this case, 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 logistic (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 and 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 logistic 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, as shown in Figure 3. The bank defines its CreditCardApproval and CreditCardPayment web services as a combined CreditCardCheck web service using SOAP. It publishes these interfaces, plus SOAP input and output message formats, to its Internet Web Server using WSDL. It registers these credit card web services (defined by SOAP and WSDL) using UDDI to the UDDI Registry. Similarly, the supplier and the shipping company also register their respective web services using SOAP, WSDL and UDDI.

Figure 3: Invocation of remote web services for credit card approval, order fulfillment and shipping using SOAP. (Source: © 2001 Software AG. Reprinted with permission.)

To locate banks, suppliers and shipping companies that offer relevant web services, the store visits the UDDI Registry. 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.org Registry via UDDI and WSDL by the selected bank, supplier and shipping company. These standards act together as an integrating technology.

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 worldwide. This has clear advantages of greater simplicity and ease of use, which, in turn, 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 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 companies gain benefits from web services also. Web services can be easily published for worldwide access. Depending on the value of a web service to users worldwide, each web service can be charged on a per-use basis. Each “per-use” price may be a micro-payment of cents or micro-cents, for example. But such web services – which previously have been locked away in legacy application programs – can also generate additional revenue. We will discuss this example further later in the paper, when we consider transaction recovery and fee-paying in the Web Services Evolution section.

The next section of this paper discusses the basic concepts of SOAP, WSDL and UDDI in more detail, and their progress toward standard web services languages. Other XML markup languages that are also evolving to support web services are then introduced.

XML Standards for Web Services
The initial web services XML markup languages are now in place, with SOAP, UDDI and WSDL. These were defined in the first phase of web services, in the period from 1999 to 2001. They are listed in Table 1 and have now effectively become de facto standards. Each is described in more detail following the table.

Table 1: XML Markup Languages in the First Phase of Web Services
Standard Description

The following discussion provides an overview of how SOAP, WSDL and UDDI are both specified and used. This material can be skipped by readers who are not interested in these technical details. Most of the development tools discussed in next month’s paper will automatically generate many of these specifications.

However, if you do wish briefly to review this section, you will gain a better appreciation of how these XML protocols are used to define web services. This understanding may help you to identify new opportunities within your organization where web services can be utilized to great benefit.

For readability, only a broad description of SOAP, WSDL and UDDI are provided. Links are provided to relevant white papers with coding descriptions and downloadable code samples. These will enable you to move to greater detail, if that is of interest.

We will start by discussing SOAP for messaging between applications. We will next introduce WSDL to define application interfaces in more detail, along with relevant input and output messages. We will then see how services are published to a UDDI registry for later search and retrieval of relevant services for particular business purposes.

SOAP Definition
SOAP is an XML specification that defines the format of messages between application programs. It is both language- and platform-independent and was defined by Microsoft, DevelopMentor and UserLand to solve some of the problems associated with distributed applications. SOAP has since been submitted to the World Wide Web Consortium for consideration as a recommended standard. It has been widely adopted throughout the IT industry, with many languages and development environments now also providing automatic conversion of existing function calls to SOAP.

SOAP was defined for several purposes. These include XML messages and Remote RPC – as well as one-way and asynchronous messaging – for the invocation of code in any language and development environment on other machines. We will discuss the use of SOAP for XML messaging: exchanging data for RPC between application programs. Figure 4 illustrates the structure of a SOAP message envelope, which describes SOAP messages and their structure in more detail. The SOAP Message Structure specification is documented at http://www.w3c.org/ and also at http://www.w3.org/.

Figure 4: SOAP message envelope structure. (Source: © 2001 W3C. Reprinted with permission.)

The first element in a SOAP message is the envelope. This identifies the XML document as being a SOAP message and includes the SOAP header and SOAP body of the message. It defines the version information of the message and the rules to be followed by the relevant applications that process that SOAP message. Namespaces are defined that point to details of the relevant version and rule definitions. Within and immediately following the envelope, a SOAP message can contain a SOAP header element. This is optional; it can be used to extend the message syntax independent of any applications that process the message. This extension could include authorization or transaction information, for example.

The SOAP body element contains application-specific data. This may include remote procedure calls (RPC) to methods to be executed on receipt of the message. The syntax used to encode data in the body can be defined in encoding rules. The body element can hold any XML data that an application needs to receive or send as XML messages. In general, SOAP messages are not written directly by programmers. They are translated from program function calls in various languages to SOAP messages automatically by web services development tools or integrated development environments (IDEs), which will be discussed in my next article.

SOAP messages do not dictate either a transport or convention. SOAP supports many transport protocols – via HTTP, MSMQ, MQ Series, SMTP and TCP/IP. It has been implemented on different hardware and software platforms; in fact, more than 30 SOAP implementations are currently available. Most SOAP usage is for delivery of messages for remote procedure calls over HTTP via the Internet or intranet. This is indeed our focus for web services: using SOAP messages for RPC over HTTP. However, SOAP also supports document/literal messaging, as used for EAI (document / literal specifies that a complete electronic XML document is included in the SOAP envelope – this enables XML purchase orders to be included as part of the SOAP message, as discussed in the EAI article). This enables inclusion of the address change notification form in a SOAP message as we discussed for Figure 19 in that article.

WSDL Definition
The web services description language (WSDL) was defined to address the following questions in relation to web services: 

• What are the business services that are offered online by an organization?
• How can these business services be invoked online?
• What information does a business service require from a service requestor, when the service is invoked?
• How is this information to be provided, and in what format?
• How will the service send information back to the service requestor, and in what format?

Figure 5: Structure of WSDL interface and implementation files. (Source: © 2001 IBM Corporation. Reprinted with permission.)

Authoring in WSDL involves four steps to describe a service. Steps 1 – 3 first define the specifications of the web service interface, and required input and output messages. These result in the preparation of a WSDL interface file for the included web services. Step 4 describes the definition of the WSDL implementation file. These are illustrated in Figure 5.

When published to a UDDI registry by the owner of the web services (the “service provider”), the WSDL implementation file provides information needed by a user of the web service (the “service requestor”) to locate the WSDL interface file on the web server of the service provider.

By following the steps as described and illustrated in the WSDL specifications, you will see that the WSDL interface file and the WSDL implementation file provide the required information needed to describe the SOAP interface and the SOAP input and output messages for each web service.

After reading this section, you will recognize that once each web service is named, with each named input and output message, the coding of the WSDL interface file and WSDL implementation file could potentially be automatically generated. This is exactly what is discussed in my next article, when we cover the web service development tools and products offered by different software vendors.

UDDI Definition
UDDI specifies how to describe, publish and discover information about Web Services in a UDDI Registry (the definition and evolution of UDDI is now being managed within OASIS, which also is involved in the definition and evolution of ebXML). The structure and use of UDDI is analogous to a printed Yellow Pages directory. Three components are used:

• Yellow Pages with industrial categorizations based on service taxonomies for an industry. For example, a bank may register its credit card processing web services in the category of “Credit Card Services” and also “Banking Services.”
• White Pages which include the name, contact details and other identifiers of the enterprise (e.g., the name, address, phone, fax numbers and web site URLs of the bank). They describe the credit card processing web services that are offered, and reference the credit card WSDL specification files.
• Green Pages detail the technical information about services exposed by the enterprise. These also include URLs to the WSDL specifications. In turn, these reference the web service SOAP specifications on the bank’s web server.

The UDDI “Yellow Pages” are analogous to categories in the printed directory; the “White Pages” are analogous to detailed entries in the directory, referenced from the categories. Green Pages are also used, similar to details in a printed directory, and link to the WSDL files and from there to the SOAP specifications.

Details such as these are published to a UDDI registry describing the web services that are offered by the enterprise. Such an organization is called a “service provider,” while the organization managing the UDDI registry is called a “service broker.” Other organizations (called “service requestors”) use the UDDI registry to locate the details of services (Yellow and White Pages) that address a specific business use, and then locate the technical details (Green Pages) for specific services that are required.

Figure 6: Structure of a UDDI definition. (Source: © 2001 IBM Corporation. Reprinted with permission.)

The definition of web services in a UDDI registry is illustrated in Figure 6. The <BusinessEntity> element provides White Pages information about a service provider organization or business. It contains one or more elements that define each separate <BusinessService> that defines the Yellow Pages details. A <BusinessService> contains specifications of one or more <BindingTemplate>. Each <BindingTemplate> references a <tModel> element, defining the Green Pages technical model (tModel) specifications for a service.

Figure 7 shows how a WSDL Implementation File uses the <service> element to point to a UDDI <BusinessService> element and WSDL <port> elements to point to UDDI <BindingTemplate> elements. The WSDL interface file points to UDDI <tModel> (Green Pages) technical specifications.

Figure 7: Relationship between WSDL files and a UDDI definition. (Source: © 2001 IBM Corporation. Reprinted with permission.)

Figure 8 illustrates how UDDI, WSDL and SOAP are used, with the following description keyed to the figure. A service provider uses UDDI and WSDL to publish specifications for its web services – as “Yellow Pages” [1] – to a service broker. This may be a private registry, or a public UDDI registry such as at http://www.uddi.org/ [2]. A service requestor searches the UDDI registry later to discover available web services for a specific business purpose [3]. The service broker returns relevant UDDI and WSDL specifications for that business purpose as earlier published by each service provider [4].

The service requestor in Figure 8 selects the most relevant web services to address its needs [3], It uses the returned UDDI and WSDL specifications from the service broker UDDI registry to prepare its client service requests. These are then sent as SOAP input messages [5] to the SOAP server nominated by the service provider, using dynamic run-time-binding, with the web service processing results returned as SOAP output messages.

 Figure 8: Publishing and discovering web services using UDDI, WSDL and SOAP. (Source: © 2001 Software AG. Reprinted with permission.)

Web Services Evolution
Web services evolution has been defined in three phases. We refer to the period from 1999 to 2001 as Phase 1 and the period from 2002 to 2004 as Phase 2. The current period of 2005 and beyond is Phase 3 of web services evolution.

Phase 1 Evolution: 1999-2001
With development tools for SOAP, WSDL and UDDI now available from Microsoft, IBM, Sun, Software AG and many others – discussed in next month’s paper – the development of web services tools is now complete. Phase 1 has been the focus of this article to this point.

Phase 2 Evolution: 2002-2004
2002 saw business web services start to appear in large numbers, with business-to-consumer (B2C) access to mass consumer-oriented web services. An example of such B2C web services is “My Services” from Microsoft (code-named “Hailstorm”). These are part of Microsoft .NET, discussed in my next article.

Private UDDI registries support private exchanges. Public registries also emerged to support public exchanges, with government usage of web services accelerating sharply. Some of these public registries offered free access to web services, but most became available on a fee-paying basis. We will discuss some implications of fee-based web services in the following section.

A number of XML-based languages have been defined for Phase 2, as summarized in Table 2. Some of these are discussed following the table.

Table 2: XML Markup Languages in Phase 2 of Web Services

For web services to be able to deliver fast, seamless integration of business partners on an enterprise scale during Phase 2, a number of issues were addressed: quality of service (QoS), network reliability, transaction recovery, real-time messaging, security, and billing mechanisms. Some of these issues are discussed in the following paragraphs.

Web services networks between service providers and service requestors must handle end-point authentication between partners, and must provide security, data encryption and non-repudiation of transactions. Web services network vendors will also need to offer both synchronous and asynchronous messaging; the latter enables a client service requestor to carry out other tasks while waiting for a response from a service provider. Network-quality monitoring, error management and data-compression schemes help improve network scalability and reliability.

Web Service Network vendors that have emerged to address these issues include Grand Central, Flamenco Networks and Kenamea. Of these, Grand Central Communications uses a centralized hub topology for reliable, secure web services message delivery, while Flamenco uses a server proxy for a multipoint network approach. Both focus on transactional stability, with network monitoring on a server-to-server basis. On the other hand, Kenamea specializes in “last mile” network delivery to a broad range of device types, such as for supply chains. Flamenco Networks has been purchased by Digital Evolution and Kenamea has been purchased by Scivantage.

Transaction recovery is very important, particularly with web services transactions that involve concurrent database changes carried out by web services delivered by more than one service provider. In the Internet web services integration example that we discussed earlier for Figure 3, three service providers were involved: the bank, the supplier and the shipping (logistic) company. In this example, performance issues associated with Internet transmission latency and message traffic delays demand that asynchronous messaging be used to communicate with these three service providers. But errors can often occur:

1. The bank may decline to accept credit card payment for purchase because the customer’s credit limit has been exceeded or the card number is incorrect.
2. The supplier may find that some or all of the requested products are out-of-stock and so must be back-ordered, with credit card payment adjusted to pay only for products that can be delivered.

In these situations, if the first error occurs, the complete order placed with the supplier – as well as the pick-up to be made by the logistic company – must both be canceled. While the second error is less serious, because of the back-order, the credit card payment amount with the bank must be adjusted to the correct value for the actual products to be shipped.

The three web service transactions are in fact interdependent; each web service can only commit its database processing when it is certain that all related web services have completed successfully. But if complete failure occurs, such as for the first error described, all database changes by each web service must be completely rolled back. We see that web service transaction recovery in a multi-enterprise example such as this is certainly nontrivial. Full transaction recovery support must be provided by web services products that offer the functionality used in this example. We will discuss this in the later SOA article.

Web services authentication and security vendors have developed products to manage authorization credentials for disparate web services environments. Some vendors are Netegrity, Oblix and OpenNetwork. Netegrity was purchased by CA, Oblix by Oracle and OpenNetwork by BMC. One security-focused product is Microsoft Passport. (Microsoft Passport was proposed by Microsoft to move security for web services from the responsibility of each machine to a security layer spanning the Internet.)

Once an end user has been authenticated to Microsoft Passport, a user ID is allocated. This single ID identifies that person throughout the Internet. With this user ID, other service providers can find information about the user, based only on the specific details that the user has authorized for others to see and use. The overriding principle of Microsoft Passport is that the user is always in control. The user has sole authority to make as much, or as little, information available to others. There are more than 165 million users of Hotmail and MSDN who already use Microsoft Passport.

Microsoft announced the addition of Kerberos security support to Passport in 2001. This is a network-authentication protocol that adds strong, secret-key cryptography. With Kerberos support, Passport offers interoperability with other Kerberos-compliant protocols, all delivering strong authorization security. With interoperability as an objective, OASIS has defined the Security Assertion Markup Language (SAML). A link to the SAML specifications is provided in Table 2.

As we have discussed, Phase 2 of web services extended from 2002 to 2004. This period focused on the definition of additional web service standards that were also needed: SOAP-DSIG, WSIL, WSFL and WSCM. Table 2 describes these, and also includes other related standards and products: ebXML, BizTalk, HTTPR, SAML, WS-Security, XML-Signature XML-Encryption and WS-Federation. The links in Table 2 offer access to more resources. Phase 2 standards provided a dynamic infrastructure for businesses to interoperate using web services, leading to what IBM refers to as “Dynamic e-Business.”

Phase 3 Evolution: 2005 and Beyond
We are now in Phase 3. Organizations will change not only their business processes, but also their business models as they move to real-time collaboration and integration of processes both within and between enterprises. While Phase 1 and 2 both addressed the surfacing of Web Services previously locked away in current and legacy systems, Phase 3 will see the emergence of new software products and systems that are designed and developed from the outset to be delivered as web services. These will be used by organizations to find business partners dynamically, or to use remote resources to enable organizations to adapt rapidly to change. However, several challenges present themselves during this period.

Challenges in Phase 3 Evolution
As this article indicates, the adoption of web services from a technical perspective is not complex. We will see next month that the SOAP, WSDL and UDDI specifications are all automatically generated. However, web services alone cannot solve the data integration problem, as they do not address the information semantics issue.

The Importance of Message Semantics: Metadata
Web services provide standards for messaging, interfaces and discovery as we have discussed. But these standards are silent about definition of message payload metadata – the message content. We saw in the EAI article that XML – and thus web services – is totally dependent on the definition of metadata. In that article, we learned that industry markup vocabularies have been defined for most industries. These establish metadata for messages that are exchanged between trading partners. Industry markup vocabularies that we discussed include: RosettaNet (for IT and EC industries); IFX, OFX and FpML (for banking); HL7 (for healthcare); XBRL (for finance and audit); ebXML (for EDI) and many others.
 
Metadata is defined using data modeling methods, discussed in the EAI article. These methods can be used to define the content – and associated metadata – to be exchanged in messages between trading partners. Data models that are produced using these methods define the metadata that is inherent in electronic documents that are exchanged as messages. In the later modeling tools article, we will see that modeling tools that are used during data modeling to capture this metadata can also generate the relevant XML DTDs (document type definitions) or XSDs (XML schema definitions) that define the message content.

As we have seen in earlier articles, a lack of agreed metadata meaning is dangerous. The use of data modeling methods and modeling tools to generate metadata has been absent so far in the use of web services. This series of articles emphasizes the use for metadata for business integration – along with XML and web services for technology integration – as the solution to the challenge of a lack of message semantics definition. (The data modeling methods that define the semantics of the message content are even more critical for success with web services than the technical aspects discussed in this paper.)

Revenue Models for Web Services
Another challenge is associated with new business models that emerged to support web services during Phase 2, for wide business use in Phase 3. As IBM indicates, there are several questions that need to be addressed:

• What revenue models will be applicable for the service?
• How does the service provider address pricing?
• Does the service provider host their service or outsource the hosting? 
• How is billing handled?

New terminology is starting to emerge to describe this new environment. IBM has suggested the following terms. Similar terms are also emerging from Microsoft and others; these are shown in [square brackets].

Asset owner is the person or entity that owns a particular web service and the associated intellectual property pertaining to the software resource. Hosted service providers are a type of asset owner. Business entities in this category are usually companies that have a software asset that has been enabled for web services, who have selected a business-model-like subscription and now need a deployable environment to be hosted and managed. This role is best suited for small ISVs (independent software vendors), who prefer to delegate the actual hosting aspects of the service to an entity that is more adapt at managing the infrastructure and quality of service issues associated with such a role. Independent service providers are another type of asset owner. Business entities in this category are usually companies that wish to establish their own environment for web services and maybe even create a private UDDI node to publish those services to the web. This role is best suited for enterprise customers.

Service consumer is the requesting application or another service provider playing the role of an aggregator that will consume at least one fee-based software service [function/operation].

Service broker is a role that could be addressed by possibly two companies. The first could be any business entity interested in exploring the opportunities around directory services or Yellow Pages for reusable software components. The second would be a vendor who can provide the necessary UDDI and hosting assets needed to provide a public UDDI service (Green Pages).

Service provider is the person or entity that is actually implementing the hosting environment for the asset owner. The service provider may be the same as the asset owner, as in the case of an independent service provider. A service provider is the entity that is responsible for the deployment environment and provisioning aspects related to making a fee-based Web service available for sale. [Microsoft tends to use the term: service operator.]

Software asset mall (SAM) is a business entity that provides deployment and hosting facilities for two or more asset owners (hosted service providers). In such a case, the operator of the mall will collect revenue based on a combination of possible (but not exhaustive) service fees: hosting charges, transaction surcharges and access registration. A utility server is also necessary to meet the deployment and provisioning needs of a SAM.

An extensive list of enabling services associated with this terminology is suggested by IBM. These address: security, key management, transformation, logging, clock, calendar, authorization control, user management, tax calculator, credit check, payment services, account management, billing, fulfillment, order management, currency conversion, service credentialing, and metering service to name a few.

The XMETHODS web site provides a public list of web services. This lists several hundred web services that are available and based on SOAP, with direct links to each asset owner. Each service name link and description provides the full invocation details needed by each SOAP message.

A UDDI browser provides an easy UDDI online search capability, without programming. A service operator can be selected between XMETHODS, Microsoft and IBM UDDI test registries. This supports searching for: UDDI business names, service names, service types (tModel), SOAP services (tModel), discovery URL, DUNS Code, ISO 3166 codes and others. This UDDI browser will enable you to gain an appreciation of some of the many web services that are becoming available. Both Microsoft and IBM also provide a number of UDDI development tools, including UDDI editors, UDDI publishing tools, WSDL editors and WSDL generators.

Summary of Web Services
In this article we discussed the concepts of web services and associated XML technologies for real-time program and code module integration that is both language-independent and platform-independent. Web Services are specified in XML using SOAP, WSDL and UDDI.

Phase 1 evolution of Web Services was from 1999 – 2001. Phase 2 was from 2002 – 2004, with Phase 3 evolution from 2005 and beyond. Business web services started to appear in 2002 with business-to-consumer access to mass consumer-oriented web services. From 2003, UDDI registry adoption has grown rapidly. Organizations are now moving to real-time collaboration and integration of processes both within and between enterprises.

For web services to deliver fast, seamless integration of business partners on an enterprise scale, many issues must be addressed. These were discussed in the paper and include: quality of service, network reliability, transaction recovery, real-time messaging, security, and billing mechanisms.

There are many software vendors developing products and tools to support web services. Some of the major vendors follow. These are discussed in my next article.

Microsoft is using .NET to transform the company based on XML and web services. All .NET languages are built on a common language specification to unify programming models for cross-language integration.

IBM’s web services products are based on WebSphere and Java, with full support and generation of SOAP, WSDL and UDDI using Java 2 Enterprise Edition (J2EE). WebSphere Application Server is integrated with WebSphere Studio Workbench for the development of web services.

Software AG offers Enterprise Legacy Integrator for the generation of SOAP and WSDL from existing enterprise applications enabling their reuse. This also supports the generation of Java/EJB, .Net, Corba and RPC, with integration adapters for legacy applications, databases, CRM and ERP environments. CentraSite provides a web services asset management platform for active discovery, publication and usage of assets such as UDDI, WSDL, XSD and XSL.

Sun Open Net Environment (Sun.ONE) supports web services using Sun Forte for Java.

Oracle Application Server supports Java and web services development with Oracle JDeveloper and Application Development Framework (ADF).

Other web services software vendors include ERP vendors Oracle, SAP and PeopleSoft (now part of Oracle), with web services products also from BEA, Borland, IBM, Cacheon, Cape Clear, iPlanet, Killdara, SilverStream, VelociGen and others.

The later SOA article will continue our discussion of enterprise architecture technologies. It builds on the introduction to business process integration products for EAI that we considered in the EAI article. The SOA article uses concepts from web services to introduce business process management languages such as BPEL and WSCI. It also covers several emerging business process management products.

If you found this article helpful and would like to receive the latest insights each week from the experts featured on the Business Intelligence Network, please subscribe to the Bill Inmon Newsletter.