ESB architecture eases app integration

An ESB is a standards-based, service-oriented backbone capable of connecting hundreds of application endpoints. ESBs combine messaging, Web services, XML, data transformation and management to reliably connect and coordinate application interaction.

There’s a shift under way to tie applications together to create business processes such as online ordering systems. A new category of integration middleware is emerging to help make this a reality – the enterprise service bus. Gartner predicts this new infrastructure will run in the majority of companies by 2005.

An ESB is a standards-based, service-oriented backbone capable of connecting hundreds of application endpoints. ESBs combine messaging, Web services, XML, data transformation and management to reliably connect and coordinate application interaction.

The ESB deployment model is an integrated network of collaborating service nodes, deployed in service containers.

Service containers are dispatched to specific parts of the network, depending on the location of application endpoints and the required placement of integration services such as transformation or intelligent routing. Service containers are connected in a logical bus topology by communication servers.

Applications interact via XML messages, which enter and exit service containers through endpoints. The applications need no awareness of the underlying communication protocols or physical location; they see only simple in-boxes and out-boxes. Because of this mapping, services can be upgraded, moved or replaced without disrupting existing business systems or modifying applications.

XML use throughout an ESB provides a great deal of flexibility and makes the infrastructure more resilient to application and business changes. For example, using XML style sheets, an ESB can transform message content from one format to another. Applications don’t need to adhere to a specific format, and data no longer needs to be sent to a central location for transformation.

An ESB treats all applications as services regardless of how they are connected to the bus, letting companies incrementally move to a service-oriented architecture with minimal risk and reduced upfront investment. It’s easy to create service interfaces for applications built into the Java 2 Platform Enterprise Edition and Microsoft’s .Net environments using third-party tools.

What’s more, an ESB provides several options for handling existing applications. Common approaches include using file-drop or application-specific adapters. A file-drop adapter uses XML messages to interact with an ESB – appearing as a proper message-driven service on the bus – while using flat-file transfer to interact with the target application. Application adapters usually are written by third parties and provide the link between the message-driven service interface the ESB requires and the native code interfaces of the target application.

Each service is described in a common directory. Developers connect applications by looking up services in the directory and then orchestrating their interaction. The ESB uses intelligent routing to perform the orchestration. An XML itinerary contains the marching orders for the required sequence of services that the message must pass through to complete a process.

Message routing can change according to real-time events and message content. For example, the developer can employ a combination of XPATH expressions and JavaScript-based routing rules to direct message delivery.

It’s important to note that the technologies used within an ESB are standards-based. The impact of this is significant: Integration projects will require much less outsourcing.

IDC describes the ESB as disruptive technology that “will revolutionize IT and enable flexible and scalable distributed computing for generations to come.” The arrival of the ESB will indeed have a dramatic impact on our concept of the “network” and how companies go about integrating their systems.