When Simple Won't DoWhen Simple Won't Do

Although distributed object standards such as CORBA and COM used to be the most popular way to approach service-oriented integration, today, most organizations are opting for Web services (which have design patterns consistent with traditional distributed objects, by the way). Application servers, such as BEA Systems' WebLogic and IBM's WebSphere also fit here, as do traditional development tools. Basically, any tool that can join applications together so that they're able to handle abstract behavior between applications fit into this category.

Process-oriented integration, in its functional form, provides you with the ability to join internal application processes together to create a master or meta process that exists to bind the applications together (see Figure 1). For example, you may have a single system that contains the processes associated with creating a product, another with processes associated with selling a product, and still another that ships a product. Process integration would bind these processes together, automating how the systems work concurrently and, in essence, creating a master process that spans many systems.

The difference between this tactic and information-oriented integration is that you approach process integration by creating a common business process to bind the applications together, whereas the information-oriented approach connects the applications through a series of information flows. Indeed, process-oriented integration and information-oriented and service-oriented approaches often coexist. The process integration technology provides another layer of abstraction (or another way to represent the information flows or service invocations), orchestrating how the systems interact or share both information and services.

Process integration technology exists in two forms: process integration technology from traditional EAI players such as Mercator and WebMethods and standalone process integration technology from vendors such as Metastorm and Versata. The technology from the EAI vendors is typically bound to the technology they sell, whereas the standalone technology needs additional development to see deeply into the source and target systems.

Figure 1 Master process for binding apps.

Like service-oriented technology, pro-cess-integration technology should only find its way into a project when it's needed. Typically, process-integration technology is indicated when the problem domain is complex (more than a dozen systems) and leverages abstract processes (instead of only information flows), or if the problem domain includes a composite application that lets the end users better create and manage their integration solution. The more systems you integrate and the more non-automated processes that exist between your applications, the more you'll need process integration.

In a simple world, all organizations would go either information-oriented or service-oriented, with some leveraging process integration and some not. However, things aren't that easy at all. Most enterprises or trading communities will find that they need to mix and match technology to meet their application integration needs. You could find yourself with several brand names, technology types, and standards. If that happens, don't be concerned as long as you've done your homework and understand your own requirements and the purpose of each technology. Most large enterprises will fall into this category and will have what seems like a hodgepodge of integration technologies — but it's probably the proper mix of application of technology. In contrast, many organizations force solutions (such as Web services) where they aren't needed and thus make the project overly expensive and complex, clearly risking failure.

As the world of application integration evolves, we are learning that application integration is hard work that requires a careful understanding of your own requirements as well as the knowledge of which technologies to bring to bear and how those technologies work together to form the right solution for your enterprise. So, the next time you hear your vendor say that they are "one-stop shopping" for all your application integration needs or the .Net zealots down the hall proclaim that all things must be Web services, know that you must first begin with your requirements, and then look for the technology or technologies that work for you. The technology must meet your requirements. Forcing your requirements to meet a technology just doesn't make good sense.

David S. Linthicum [[email protected]] is the author of three books on application integration, including Enterprise Application Integration (Addison-Wesley, 1999) and Next Generation Application Integration: From Simple Information to Web Services (Addison-Wesley, 2003). He is the former CTO of Mercator Software, as well as the former CTO of SAGA Software, both application integration technology vendors.

Resources

Ascential Software's Mercator solutions: www.ascential.com/news/mercator/index2.html

BEA Systems: www.bea.com

IBM: www.ibm.com

Metastorm: www.metastorm.com

SeeBeyond Technology: www.seebeyond.com

Sonic Software: www.sonicsoftware.com

Versata: www.versata.com

WebMethods: www.webmethods.com