eAIJ: So, the interactions are the fundamental building blocks for your integration systems?

Green: Right. As products get more sophisticated, they also get more complicated. Here’s an example: Yo u set up your security system so a particular application can produce and consume certain types of business activities, but is precluded from consuming other types of business information that may not be appropriate. As you move the system from one site to another or start to deploy it globally, you must remember to set that security parameter in every place or the system won’t run. Well, we’ve taken that concern away. Yo u get it all set up in the R&D lab, press the button, and all that information is captured in the interaction.

eAIJ: What about business logic? Where should that reside in an integration system?

Green: Some advocates claim that all the business logic should reside in a central location. Rules engines are an example of this approach. All the business logic is captured through a set of rules executed by a single engine. We have a problem with strong reliance on rules engines because they typically require proprietary language and a highly centralized model. We’ve seen many cases of “altitude mismatch” where people want to operate at the business-process level but the application interfaces are low level.

eAIJ: Can you give an example of the mismatch?

Green: Yes. Say you send a purchase order to an application, but the application doesn’t have an interface that knows about purchase orders. The high-level construct then needs to be broken down so that multiple calls can be made to the application to accomplish the business function. Do you want to do that centrally? Usually not. Yo u typically want to send the purchase order to where the application is and have the adapter receive the purchase order and execute multiple calls. That way, the logic that’s unique to the application can be co-located with the application rather than added into some central area. We believe there’s some high-level business logic that needs to execute centrally and some application-specific processing that needs to run close to the application. That flexibility in architecture is powerful.

eAIJ: What do you see as an ideal integration architecture?

Green: The superior architecture is one that is fully distributed with a fully centralized management. Yo u should view the broker as a switch, as the router. For example, four applications in Los Angeles subscribe to information published by an application in New York. Yo u don’t want to send four copies of the information across the country. Yo u want the New York application to publish the information, hand it to its local broker, the local broker transparently route one copy to Los Angeles, and the Los Angeles broker to multiplex it out to the four applications. Yo u reduce network traffic and you have transparent routing. The New York application has no idea of the number or location of subscribing applications. The broker in the middle of the system handles much of the routing, queuing, and network communications aspects. This lets the applications handle the business processes and operate at a higher level.

eAIJ: XML has shot to prominence in the industry over the past year. How do you see the role of XML?

Green: It’s possible that a model could emerge where all applications talk XML, reducing the amount of data transformation. That’s where XML can really provide significant benefits. However, there’s no finite standard set of XML formats, so we’re likely to see a proliferation of different kinds of XML DTDs — to the point where increasingly, people will convert from one type of XML to another type of XML!