Commerce One Conductor takes on integration

What business really wants from IT is automation of the processes that make the business go. Ironically, the very enterprise-level support systems that CIOs installed in the ’90s to support HR, customer service, accounts receivable, and so on are the primary hurdle.

Business processes typically cut across system boundaries and require the interoperability and choreography of multiple systems. Yet, most enterprise-level support systems focus instead on one task without thinking about working with other systems. Web services promise to solve the problems of integrating these enterprise systems and most vendors already support basic Web services protocols -- but the real problem is that tricky integration process.

There are basically three choices to integrate systems with Web services: (1) write a custom application in Java or some other programming language that interfaces with enterprise systems and creates the integrated functionality; (2) buy message buses, integration brokers, business process modeling tools, and other middleware and configure them to provide the functionality; or (3) buy an all-in-one integration suite such as Conductor from Commerce One.

The advantage of an integrated solution, like Conductor, is that someone else does the difficult task of making everything work together. What’s more, as an application, the integration comes with useful features and tools that you can’t afford to build if you’re doing the integration yourself. This is certainly true of Conductor, an impressive package of tools that is greater than the sum of its parts.

More Than Just Interoperability

Conductor is fundamentally a Web services intermediary: Its interoperability engine forms a layer between various enterprise systems and services to ensure that everything can talk to everything else. It does the hard work of translating protocols, ensuring message delivery, and managing services such as security. But Conductor exceeds the standard interoperability engine, providing a sophisticated suite of tools for building and operating applications that automate business processes.

The heart of Conductor is the registry, an all-purpose directory of services, users, documents, and transformations that the rest of the system uses to compose custom business processes. The rest of Conductor is designed to make maximum use of the registry; consequently, business process applications built in Conductor automatically respond to any process change a user makes, reconfiguring connections as necessary and without maintenance.

Building a business process application requires some sort of programming language, too. BPEL (Business Process Execution Language) is emerging as the standard way to specify business processes, but Conductor makes use of its own internal language to create business processes instead. You never see Conductor’s internal language as such, because you create business processes and link them to services in the registry using graphical programming tools called the Graphical Process Builder (GPB).

GPB allows easy visualization of the process flow, decision points, and actions taken. Some might perceive the lack of support of BPEL as a weakness, but I think it simply reflects the instability of the BPEL standard as Conductor was being developed.