Where s the Fit?

Where's the Fit?

So, if Web services are coming, and application integration needs this mechanism to add even more value to the enterprise or trading community, how do Web services fit with "traditional" approaches to application integration? The answer has many parts, including:

• Requirement patterns.

• Solution patterns.

• Changing enabling technology.

The fact of the matter is that many inter- and intraenterprise problem domains don't need service-level access to applications; information exchange is good enough, if not desirable. Moreover, most organizations don't have application integration strategies. These organizations need to get their own houses under control first, determine their integration requirements, create a plan, and then select the correct approach to application integration and matching technology. Simply jumping to Web services without understanding the business requirements could be disastrous or, worse, could cause the organization to miss strategic opportunities.

Organizations that require Web services have a need to access both information and application services that exist in local and remote information systems. Typically, these problem domains have the following characteristics:

• There are redundant application services that exist at two or more systems.

• There is a need to create a new application that satisfies a business need, but is also able to leverage aggregated application services from remote systems.

• The information residing within the source or target system is of significantly less value when decoupled from the services.

When applying Web services technology to solve application integration problems, there are patterns or architectures to consider, as well. These are

• Event-driven

• Composite

• Autonomous-distributed

It's also correct to consider these solution patterns as an evolution of the Web services integration technology over time, as well as options.

Event-driven Web services solutions refer to those architectures that deal more with information movement than application service aggregation (see Figure 4.3). Data moves from system to system in support of a particular business transaction, but there is also a requirement to access application services. For example, moving order information from system to system and company to company to support the purchase of a car, or employing a common Web service to calculate logistics information, sharable by all source and target systems. This is a hybrid architecture that mixes both Web services and traditional application integration technology, such as integration servers.

Figure 4.3. Event-driven solution.

Composite-application solutions refer to architectures that require many application services to aggregate into a single instance of an application (see Figure 4.4). Organizations have been dealing with this paradigm for years as component-oriented programming, where many predefined application components combine to create a single application. However, within the notion of Web services, the application components reside on a remote computer, and the Web services are accessed as pieces of an application. For instance, the master application that monitors shipments invokes a series of Web services (running on remote computers) that provide application services for logistics processes, least-cost routing, billing, and so on. Going forward, this will be the most popular architecture for Web services, because it's closest to the concept.

Figure 4.4. Composite-application solution.

Autonomous-distributed solutions refer to those architectures where the Web services are so tightly coupled that they appear as a single application (see Figure 4.5). This is the final destination for Web services, binding many applications together, inter- and intracompany, into a single, unified whole. However, the proliferation of this architecture is years away.

Figure 4.5. Autonomous-distributed solution.

Finally, the enabling technology is morphing to accommodate Web services. In addition to development tools that support the creation of Web services-enabled applications, "traditional" application integration products are moving to Web services through the addition of several new features. These include the creation of new adapters that provide service-level (as well as information-level) access to remote systems, application service-binding mechanisms innate to the server, and interface aggregation to support the combination of many Web services into a single Web service.

Most adapters were built to support simple information exchange and don't support access to remote application services. These adapters will have to learn how to access application services, abstracting the interface within the integration server. Web services-enabled adapters will emerge sometime in the near future.

However, it does not make much sense to create application service-enabled adapters without an integration server that can process Web services as well as information. This is a bit more complex, but next-generation integration servers are emerging that have the ability to process Web services as well as information, aggregating services within the integration server as required; for example, combining several Web services into one, or passing Web services access between systems. What's more, Web services-enabled integration servers provide enabling mechanisms including WSDL and access to UDDI.

Web services represent an exciting prospect for both application development and application integration. However, like any new concept, it's going to take some time before organizations understand how and where to leverage Web services in the domain of application integration...or in any domain, for that matter. Clearly, first-generation systems are emerging and count on more Web services at work in the near future.

Missing Pieces

When considering Web services with application integration, there are some missing pieces. For example, Web services don't provide the mechanism to leverage user interfaces. The Web Services User Interface (WSUI) initiative, announced in June 2001, continues to move toward a solution to this problem, but the technical obstacles are significant. In addition, current Web services do not address security well, lacking support for authentication, encryption, and access control. Indeed, Web services do not have the ability to authenticate publishers or consumers of the Web services.

The XML-Based Security Services Technical Committee from the Organization for the Advancement of Structured Information Standards (OASIS) is looking to shore up security within Web services with the Security Assertion Markup Language (SAML). This security standard allows organizations to share authentication information among those they wish to share Web services with as partner organizations. Other emerging security standards include the XML Key Management Specification (XKMS), based on Public Key Infrastructure (PKI).

Indeed, organizations need to determine how to move application integration from simple information movement to an application service-sharing infrastructure that provides access to reusable application services services that allow developers to quickly create robust applications without having to reinvent the wheel. Organizations might find that an aggregation of remotely hosted application services will provide a more efficient and cost-effective paradigm for creating and integrating applications.

Like any other new technology, we must analyze Web services for the real value before pulling it into the enterprise or trading community. Many issues must be considered, including the invasiveness of this technology, the strategic needs of the business, and missing pieces of the standard that are at this point mere promises. We'll cover Web services in a lot more detail, later in the book.

UDDI

The Universal Description, Discovery and Integration specification aims to define a common mechanism to both publish and discover information about Web services. IBM, Microsoft, Ariba, and the 63 others that back UDDI hope to create a type of "Yellow Pages" for the Internet.

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 example, a company could register a unique program for predicting breakage found in a shipment of glass products, depending on the application service 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, understand how to access this service programmatically, and understand the interfaces employed.