to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 Glossary lookup:

 

> stories > platform choice


Composite approach lifts integration woes

by David Longworth
June 25th, 2003

Combining disjointed processes into composite applications can unlock some of the most intractable integration challenges in business today.

 
• print  • comment
Web services standards are freeing composite applications from their proprietary past, but assembling them still requires care and skill:
  • Composite applications bring together elements from various existing applications
  • Standardization and web services make them easier to connect and configure
  • But synchronizing information remains a challenge
  • Process co-ordination becomes increasingly complex
  • Tools and skills are under developed


Glossary terms: composite application, WSRP, web services, integration, business process, lookup tool

Composite applications reuse functionality from existing applications by breaking them down into components, separating out the business logic, and then joining selected elements back together again for presentation to the user as a single (hence 'composite') application. This can produce remarkable results when applied to business operations that sit at the apex of several different applications, for example customer service call centers, or returns item processing.

For a long time, however, the only way to achieve these results has been by way of "painful customization," says Rey Currie, VP of platform product management at tools vendor Quovadx. "People have been building new applications out of old applications for some time, but they've been doing it via back-end integration, hooking up to the data store and then making changes to the application. The business logic is not decoupled. The interface is probably proprietary and it's inflexible. When you've only got a couple of applications in the business that's possible. But as you get more users and they become less homogenous, that's less practical."

Now a better method is emerging, which uses standardization and web services to make composite applications easier to connect and configure, says Gartner analyst Massimo Pezzini, who was one of the first to use the term. "I would say that I see web services — specifically WSDL — as a composite application enabler," says Pezzini. "In other words you can implement composite apps even without web services. However web services fit well with composite apps as they allow you to encapsulate existing apps into components you can invoke using SOAP — or any other underlying protocol — from multiple front end apps. This is what we call Service Oriented Architecture (SOA)."

Higher-level skills
But although web services remove many of the obstacles to assembling composite applications, there's still no guarantee that, once assembled, they'll actually work as intended. That requires higher-level skills and tools that as yet remain largely undeveloped within an SOA context.

"The ease of use, sophistication and performance level of the tools has not been good enough," admits Prasantha Jayakody, market manager at WRQ, whose Verastream toolset allows customers to encapsulate mainframe and other legacy apps as web services, for subsequent use in composite applications. "But there's also not been a good understanding of what options there are today," he adds.

The only aspect that's clear to all is the standards foundation. That infrastructure consists of Java, XML and HTTP plus the web services standards WSDL, SOAP and, to a lesser extent UDDI and business process management under BPEL4WS. These are or will be supported by the main J2EE or .NET application servers. Other standards are still emerging, such as Web Services for Remote Portlets (WSRP), a standard for portals to communicate with web services, and the interoperability profiles under development at WS-I.

This is a great improvement on what went before, says Dr Ian Howells, VP marketing EMEA at SeeBeyond, an EAI vendor that is now staking its future on composite applications: "Composite application development appeared several years ago, but it was not transferable because the applications were built on systems that were phenomenally proprietary. If the vendor went away, then making changes was difficult. Now composite applications are built on a standards-based infrastructure."

Interoperability lapses
Even though the standards now exist, composition applications still need to be built on a separate integration layer that bridges the various systems on which each of the components run. "Encapsulation products are needed to bridge the J2EE environment and the 'legacy' software platforms," says Pezzini. "If the J2EE server runs on a different system than the mainframe, the encapsulation products also transport data from the two environments over the network."

This distributed approach is different from the old way of doing things, when everything was wired directly into the integration vendor's proprietary platform. And it exposes all the various levels of incompatibility that exist between separate application stacks.

Even within the standards-based infrastructure, different vendors' implementations of standards often create interoperability lapses, so that, for example, native point-to-point SOAP calls can't be relied on.

In addition, information models may be incompatible. While at first glance it may look trivial, the kind of synchronization that needs to happen in composite applications for even the most straightforward details to be pulled together is complex.

"The main problem with composite applications is sorting out the semantic differences between the data models and interfaces of the two parts of the application," explains Pezzini. "Web services provide, at best, an interoperability platform at the technical level, but they don't help that much in terms of reconciling the way two apps internally represent customers or products."

Unifying architecture
SeeBeyond's Howells gives the example of customer details being held in two separate applications that often need to be combined: SAP ERP and Siebel CRM. In SAP, the details might be name and address, while in Siebel they might be name, age and sex. The easiest way to bring the two together is to create a new screen with name, address, age and sex. But while the traditional method has been to set up that screen within SAP or Siebel, the composite application creates a new combined screen that sits outside the existing applications.

"The characteristics of composite applications are different — it's interaction centric as opposed to transaction centric," says Howells. "We're not writing a new SAP. It's a three-to-six month, very connected, medium risk development. And it's doing simple things, like order entry. It still plays well to SAP's strategy around NetWeaver and Siebel's UAN and can also synchronize with other systems."

Trusting in a single vendor's unifying architecture is one way of minimizing the incompatibilities. But, says Howells, "everybody is uneasy about buying the whole stack from one vendor." Unsurprisingly, vendors who specialize in composite applications recommend keeping the integration layer separate from the core applications.

Quovadx' Currie says: "ERP vendors feel they know your business best. Some applications vendors offer really good functions. But you need something in the middle which ties the disparate application and business logic together without having to go to applications vendors."

Process management
A final element that invariably only comes to light after development is the management burden for the newly assembled composite applications. This too needs to be handled separately from the existing applications. "Organizations that are committed to exposing functions as web services are going to end up with millions of services or super services," says Currie. "They need to have best practice guidelines built into a process engine, with tools to add new business processes and rules which business analysts, not technologists, can use."

Setting up a business process management engine that contains the rules for composite applications separately from the existing applications will also allow the gradual decommissioning of legacy systems, adds Currie. Such rationalization is often the overriding goal of such projects, yet has rarely been achieved in traditional EAI implementations.

With their requirements for their own separate integration, presentation, application management and business process management layers, composite applications share many of the same ingredients as service oriented architectures. Indeed, composite applications, SOA and web services appear to be inextricably linked. Most vendors and analysts see web services as coming to fruition through composite applications — Gartner predicts three quarters of web services deployed by Global 2000 enterprises will have been implemented as a means of integrating new development with pre-existing applications.

Layered on top of web services and SOA, it seems composite applications are set to become the public face of these emerging technologies. No longer restricted to a proprietary niche, the skills required to assemble and manage them effectively are going to be much in demand.


More on this topic


Related

How to assemble composite applications
Gartner middleware expert Massimo Pezzini has published a succinct briefing paper ...

Unplug and play
Composite application assembly and agile development ...


 
 


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.