and joining it with the dealer inventory database so that users see only relevant information for their area. The standard SOA approach is to have a service extract the data from each database and then generate the appropriate XML.

“For performance reasons, that won’t work in a two-hour window,” Noy notes, given the many large feeds involved. So, Zag simply has the two databases directly perform a join each day. “If you are doing data-intensive things, do it where the data is,” he says. Zag’s composite apps then access the joined database — in which the data is already tagged and sorted to reflect business requirements — to respond to user queries. “We exposed a well-defined interface of stored procedures to do this task quickly,” Noy adds.

 

Blazing a new trail

Zag’s current model for integration relies on direct connections between services, rather than the message brokering offered by ESBs or conventional EAI software. But as the complexity of interactions among services increases, Noy expects a more centralized orchestration approach will be needed. As an ESB infrastructure is phased in, the existing services will plug in to the bus, allowing for central monitoring and management, as well as taking advantage of security and protocol translation services provided by the ESB.

Zag’s experience demonstrates that there is no single correct approach to SOA. The architecture can vary while still delivering on the key SOA principles of functional abstraction, component modularity, and business-process-aligned services. “As long as the interfaces are well-defined and the responsibilities are clearly delineated, how you arrange the pieces should be up to the project’s needs, not some preordained model,” Noy says.

— Galen Gruman