Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

An App Integration Value-Add?

Web services promise to deliver additional value to application integration, but organizations should weigh the cost and invasiveness vs. information- or business process-level integration.

David S. Linthicum is the CTO of Mercator Software, Reston VA., and an internationally known application integration and e-business expert. His latest book is B2B Application Integration: e-Business Enable Your Enterprise (Addison Wesley Longman).

An App Integration Value-Add?

Here we go again. The latest notion to take the information system development world by storm is that of Web services. Major vendors (including Microsoft, Hewlett-Packard, and Sun) are outlining their Web services strategies, and the press is promoting the concept as the biggest paradigm shift since the Web itself. At the same time, rank-and-file IT professionals are trying to understand what Web services are, and their value within the enterprise. The promise of Web services is exciting: the ability to create new applications by aggregating the services of many other applications that exist locally or remotely on the Internet. Before organizations jump on the bandwagon, though, they should consider several issues:

First, the concept of Web services is still mostly marketecture. There are no large implementations of Web services-based applications, albeit new-generation applications are emerging. So the advantages and limitations of this technology are not yet fully understood.

Second, this is an old idea with new wrapping. The concept is similar to the decade's old promise of distributed objects: provide the infrastructure for applications to exchange information, as well as leverage methods encapsulated within those applications. Web services simply put a newer, sexier architecture and enabling technology into the mix, most importantly, adding the word "Web."

Finally, standards overload prevails. As in the days of distributed objects, vendors see a hot space emerging and are staking their Web services claims, publishing proprietary standards that they call "open." The inevitable shakeout will only delay the acceptance of Web services.

Despite the usual drawbacks of emerging technology, Web services -- at least the notion of Web services -- is an interesting technology for the world of inter- and intra-company application integration. Web services hold the promise of moving beyond the simple exchange of information -- the dominating mechanism for application integration today -- to the concept of accessing application services that are encapsulated within old and new applications. This means organizations can not only move information from application to application, but they also can create composite applications, leveraging any number of back-end application services found in any number of applications, local or remote.

Key to this concept is figuring out how Web services fit into the existing application integration technology and approaches. For example, when is the use of Web services appropriate, and how is cost-effectiveness determined? Keep in mind that implementing Web services is bound to be an invasive process, and thus more expensive than enabling systems for simple information exchange.

Evolving Approaches
Application integration is innate to almost all e-business system development. Applications can no longer exist as standalone entities, but instead must share information with other information systems, inside and outside corporations. Indeed, organizations have been moving closer to a well-integrated enterprise and (in some instances) a supply chain that provides most information systems with access to real-time information from other applications when needed. This information-oriented application integration is the most popular way of doing application integration today.

However, as real-time information exchange between systems improves, the trend is to view application integration at a higher level of abstraction, or through business processes. This approach allows those exchanging information between various applications to view the information flow in the context of a business model, or business processes that define business logic, sequence, sub-processes, and hierarchies of processes. This ability to control application integration through abstract business process automation abstractions that also account for lower-level mechanisms such as transformation and intelligent routing can be called business process-oriented application integration.

While information-oriented and business process-oriented integration provide a functional solution for many application integration problem domains, it is the integration of both application services and application methods that generally provide more value in the long run, albeit at a cost.

This is not a new approach. Organizations have been looking for mechanisms to bind applications together at the service level for years, including frameworks, transactions, and distributed objects, all in wide use today. However, the notion of Web services, such as Microsoft's .NET strategy, is gaining steam. The attempt is to identify a new mechanism that can better leverage the power of the Internet to provide access to remote application services through a well-defined interface and directory services. (See the sidebar on Universal Description, Discovery and Integration, UDDI.) This can be called application services-oriented application integration.

UDDI: Publish and Discover
The Universal Description, Discovery, and Integration (UDDI) specification aims to define a common mechanism to both publish and discover information about Web services. IBM, Microsoft, Ariba, and the 63 others driving UDDI hope to create a type of "Yellow Pages" for the Internet. The first generation of the specification is out now, with the second generation due out in 12 months.

UDDI is really just a set of databases where businesses can register their Web services as well as locate other Web services they may be interested in leveraging.

For instance, a company could register a unique program for predicting breakage found in a shipment of glass products, depending on the method of shipping, point of origin, and destination. That company may publish this information in the UDDI databases, thus allowing other organizations to find this Web service and understand how to access this service programmatically as well as the interfaces employed.

Web Services Exposed
The uses for the application services type of integration are endless, including creation of composite applications, or applications that aggregate the processes/services and information of many applications. For example, using this paradigm, application developers simply need to create the interface, then add the application services by binding the interface to as many Internet-connected application services as required.

Indeed, Web services promise to deliver additional value to application integration, including a standard method for publishing and subscribing to software services, local and remote. Applications locate the services using UDDI and determine the interface definition using Web Service Description Language (WSDL). (See Sidebar on page two.)

The concept of .NET, for instance, is to provide this total integration. (Note: There are competing standards from IBM, HP, Sun, and BEA). .NET defines Internet-connected applications as Web services. Think of Web services as methods exposed by a company or software program that are both discoverable and accessible by other programs or organizations that are in need of a particular service, such as purchasing a product, reserving a flight, or calculating tariffs. These are discreet business services that have value to many organizations.

Microsoft's .NET (and other Web services strategies for that matter) is an architectural vision, more so than an actual technology. However, pieces are beginning to emerge, such as UDDI, and a host of tools forthcoming from Microsoft that provide the opportunity for this approach to application integration. What is more, the Standard Object Access Protocol (SOAP) is providing .NET a standard way to expose objects through firewalls, business to business.

The downside, at least with serviced-based integration, is that this makes it necessary to change the source and target applications, or worse, in a number of instances, to create a new application (a composite application). This adds cost to the application integration project, and is the reason that many choose to stay at the information level going forward.

Still, the upside of this approach is that it is consistent with the "baby step" approach most enterprises find comfortable when implementing solutions to integration problems. Application service-based solutions (e.g., Web services) tend to be created in a series of small, lower-risk steps.

Go to page two
Copyright 2002. Reprinted by permission.


Ask David Linthicum a question

Talk back or comment on this article

The Best Web Links for Web Services

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.