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; and
- changing enabling technology
The fact of the matter is that many inter- and intra-enterprise 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.
Those 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:
- composite; and
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. Data moves from system to system in support of a particular business transaction, but there is also a requirement to access application services. For instance, 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.
Composite application solutions refer to architectures that require many application services to aggregate into a single instance of an application. 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, etc. Going forward this will be the most popular architecture for Web services since it's closest to the concept.
Autonomous-distributed solutions refer to those architectures where the Web services are so tightly coupled that they appear as a single application. 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.
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, method-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 methods. 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 instance, 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.
When considering Web services with application integration, there are some missing pieces. For instance, Web services don't provide the mechanism to leverage user interfaces. The Web Services User Interface (WSUI) initiative, announced in June 2001, is moving to solve this problem, but the technical obstacles are significant. Also, 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 PKI (Public Key Infrastructure).
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 examples of Web services at work in the near future.
Indeed, organizations need to determine how to move application integration from simple information movement to a method-sharing infrastructure that provides access to reusable application services that allow developers to quickly create robust applications without having to reinvent the wheel. Organizations might find that 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, Web services must be analyzed for the real value before pulling it into the enterprise or trading community. There are many issues to consider, 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.Go to Page One
Copyright 2002. Reprinted by permission.
FOR MORE INFORMATION:Ask David Linthicum a question Talk back or comment on this article Th e Best Web Links for Web Services