Welcome!

Microservices Expo Authors: Liz McMillan, Flint Brenton, Jason Bloomberg, Elizabeth White, Yeshim Deniz

Related Topics: Microservices Expo

Microservices Expo: Article

ESB Integration Patterns

An insider's look into SOA's implementation backbone

The past several years have seen some significant technology trends, such as service-oriented architecture (SOA), enterprise application integration (EAI), business-to-business (B2B), and Web services. These technologies have attempted to address the challenges of improving the results and increasing the value of integrated business processes, and have garnered the widespread attention of IT leaders, vendors, and industry analysts. The enterprise service bus (ESB) draws the best traits from these and other technology trends to form a new architecture for integration. The ESB concept is a new approach to integration that can provide the underpinnings for a loosely coupled integration network that can scale beyond the limits of a hub-and-spoke EAI broker.

An ESB is a highly distributed, event-driven, enterprise SOA that is geared toward integration. It is a standards-based integration platform that combines messaging, Web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity. An extended enterprise represents an organization and its business partners, which are separated by both business boundaries and physical boundaries. In an extended enterprise, even the applications that are under the control of a single corporation may be separated by geographic dispersion, corporate firewalls, and interdepartmental security policies.

An ESB is designed to be pervasive, meaning that it is capable of spanning the extended enterprise. But an ESB is also pervasive in the sense that it is capable of being used as a general-purpose integration environment that is suitable for any project, no matter how large or how small.

The SOA of the ESB
An ESB is the implementation backbone for a loosely coupled, event-driven SOA that enables a highly distributed universe of named routing destinations across a multi-protocol message bus.

An SOA provides an integration architect with a broad abstract view of applications and integration components to be dealt with as high-level services. Service components in an ESB expose coarse-grained, message-driven interfaces for the purpose of sharing data between applications, both synchronously and asynchronously. In an ESB, applications and event-driven services are connected through the bus as abstract endpoints. These abstract endpoints are tied together in a loosely coupled SOA, which allows them to operate independently from one another. An integration architect uses an ESB to tie together assemblies of abstract endpoints that form composite business processes, or process flows (see Figure 1).

What the endpoints actually represent can be very diverse. For example, an endpoint may represent a discrete operation, like a specialized service for calculating sales tax. The underlying implementation of the endpoint could represent a local binding to an application adaptor, or a callout to an external Web service. The applications and services can be physically located anywhere that is accessible by the bus.

Itinerary-Based Routing
In an ESB, data is passed between endpoints using messages. The coordination of the message passing is done using an ESB concept known as itinerary-based routing. A message itinerary is metadata that gets carried with a message that provides a list of forwarding addresses. The itinerary is a set of instructions telling the ESB invocation framework which endpoints the message needs to be delivered to as it travels from endpoint to endpoint across the bus. Itineraries contribute to the distributed nature of the ESB architecture by eliminating the dependency on a centralized routing engine, which could potentially be a single point of failure. They are intended for relatively finite microflows of messages. Simple branching and merging of routing paths can be achieved through integration patterns that take advantage of specialized splitter and aggregator services. More sophisticated process orchestrations are also possible using specialized orchestration engines that can be layered onto the bus as additional services.

Configuration, Not Coding
The mantra of the ESB is "configuration rather than coding." In an ESB, abstract endpoints, which are accessible through application adapters, message queues, Web services invocations, and a variety of other protocols, are configured through a tool interface rather than coded into applications. It's not that there's anything wrong with writing code, but there's plenty of code to be written elsewhere that doesn't have to do with hard-wiring interdependencies between applications and services.

With its distributed deployment infrastructure, an ESB can efficiently provide central configuration, deployment, and management of services that are distributed across the extended enterprise. Artifacts that affect the behavior of an integration service, such as an XSLT stylesheet that can be used by a data transformation service, are also configurable in an ESB.

The ESB Service Container
The highly distributed nature, and the ESB mantra of "configuration rather than coding" is largely due to traits of the ESB service container. A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components.

A service container is simple and lightweight, but it can have many discrete functions. As shown in Figure 2, service containers take on different roles as they are deployed across an ESB.

In its simplest form, a service container is an operating system process that can be managed by the ESB's invocation and management framework. A service container provides a number of facilities for the service implementation such as event dispatch, thread management, security (encryption, authentication, and access control), and QoS via reliable message delivery. Unlike its distant cousins, the J2EE application server container and the EAI broker, the ESB service container allows the selective deployment of integration functionality exactly when and where you need it, and nothing more than what you need.

A service container can host a single service, or can combine multiple services in a single container environment (see Figure 3).

An ESB service is also scalable in a fashion that is independent of all other ESB services. A service container may manage multiple instances of a service within a container. Several containers may also be distributed across multiple machines for the purposes of scaling up to handle increased message volume (see Figure 4).

The ESB Service Interface
The ESB container provides the message flow in and out of a service. It also handles a number of facilities, such as service life cycle and itinerary management. As shown in Figure 5, the container manages an entry endpoint and an exit endpoint, which are used by the container to dispatch a message to and from the service.

Messages are received by the service from a configurable entry endpoint. Upon completion of its task, the service implementation simply places its output message in the exit endpoint to be carried to its next destination. The next destination may be a reply to the original sender of the message, or more often may be sent along to the next leg of its journey using a forwarding address. The output message may be the same message that it received. The service may modify the message before sending it to the exit endpoint. Or, in the service may create a completely new message to serve as a "response" to the incoming message and send the new message in the exit endpoint.

What is placed in the exit endpoint depends on the context of the situation and the message being processed. In the case of a content-based routing (CBR) service, the message content will be unchanged, with new forwarding addresses set in the message header.

In more sophisticated cases, one input message can transform into many outputs, each with its own routing information. For example, a splitter service can receive a purchase order document, split it into multiple output messages, and send out the purchase order and its individual line items as separate messages to an inventory or order fulfillment service. The service implementation in this case does not have to be written using traditional coding practices; it can be implemented as a specialized transformation service that applies an XSLT stylesheet to the purchase order document to produce the multiple outputs.

Process Tracking and Error Handling
In addition to a normal exit endpoint to handle the outgoing flow of a message, additional destinations are available to the service for auditing the message and for reporting errors. The tracking endpoint can be utilized to monitor the progression of a message as it travels through a business process. Tracking can be handled at both the individual service level and the business-process level. From the service implementation's point of view, it simply places data into the tracking endpoint or fault endpoint, and the surrounding ESB invocation and management framework takes care of the tracking and error reporting. This approach provides a separation between the implementation of the service and the details the surrounding fault handling. The implementer of a service need only be concerned that it has a place to put such information, whether it is information concerning the successful processing of good data, or the reporting of errors and bad data.

Integration Patterns
One of the many benefits of using itinerary-based routing to coordinate the interactions between discrete integration services is the ease with which integration patterns can be created and reused to solve common integration challenges. A message itinerary can be a powerful and flexible tool for intercepting the path of a message and performing operations on it, thus adding value to the integration environment. Through configuration and management tools, additional processing steps can be inserted into a business process definition as event-driven services into an XML processing pipeline. The following describes two of the common integration patterns in use today: the "VETO" pattern, and a variation known as the "VETRO" pattern.

The VETO Pattern
VETO is a common integration pattern that stands for Validate, Enrich, Transform, Operate (see Figure 6). The VETO pattern and its variations can ensure that consistent, validated data will be routed throughout the ESB.

Validate
The "Validate" step is usually the first part of any ESB process and can be accomplished in a number of ways. It's important that if possible, this step happen independently; this removes the burden of validation from all of the downstream service implementations and promotes reuse. Building validation directly into the first service of a process makes it difficult to insert an additional service in front of it without requiring that the new service also provide its own validation.

An example of validation is to simply verify that an incoming message contains a well-formed XML document and conforms to a particular schema or WSDL document that describes the message. This requires that the service always have available the up-to-date XML schema for a particular message type. The schema and WSDL can be kept in the directory service and managed remotely by the management infrastructure of the ESB. A service may also have scripting associated with it, which can be made available to the service as a configuration parameter

If the target data is not in XML format, or if there is no schema or WSDL available, then a custom service can be used to validate the incoming message.

Enrich
The "Enrich" step involves adding additional data to a message to make it more meaningful and useful to a target service or application. The Enrich service could be implemented to invoke another service to look up additional data, or it could access a database to get what it needs.

Transform
The "Transform" step converts the message to a target format. This often involves converting the data structure to an internal canonical format, or converting from the canonical format to the target format of the "Operate" step. The target system may have its own built-in validation rules requiring that the transformation step modify the incoming data in order to prevent the target system from rejecting the message. In this sense, the transformation step is also providing pre-validation protection in a separate service that can be separately managed. While this may mean redundant logic in the short term, it provides more flexibility in the long term, because it allows the "Operate" step to focus on business logic.

Operate
The "Operate" step is the invocation of the target service or an interaction with the target application. If the target operation is an enterprise application that requires its own data format, then the previous transformation step converts the message to the target format required by the application.

Variations: The VETRO Pattern
The VETO pattern has many variations. One such variation is the VETRO pattern, which includes a "Route" step such as a content-based router service (Figure 7).

In some cases the validate, enrich, and transform steps can be accomplished in one service implementation. For example, a CBR service may use a script-based validation directly in the service itself, rather than using a separate service. This may provide some convenience, particularly if the context of validation can't easily be applied to other uses. However, keeping them as separate services further promotes loose coupling and service reuse, and allows the validation to be separately defined and managed. Through the flexibility of configuration and deployment, that choice can be revisited over time without affecting all of the application endpoints that use the pattern. The stages of the VETO pattern can be implemented as separate services that can be configured, reused, and independently swapped out for alternate implementations.

The VETO concept is profoundly simple, yet is at the heart of what an integration architect does regularly with an ESB. An ESB provides an event-driven SOA for applications in an integration fabric. Regardless of the process routing and orchestration method being used - whether itineraries or the more sophisticated process modeling using an orchestration service - it is the use of integration patterns such as VETO and its variations that provide the overall value and flexibility to the integration fabric.

Summary
I hope that this brief introduction to the ESB and its use of integration patterns has provided you with insight into the internal workings of the ESB, and given you a sense of how an integration architect can use event-driven components as services to construct reusable integration patterns in an enterprise SOA. The VETO pattern is one of many being used in ESB-based integrations.

I encourage you to learn more about the ESB as a technology concept, for it is already rapidly changing the way integration is being done across a variety of industries. So get reading, and get on the bus!

More Stories By Dave Chappell

David Chappell is vice president and chief technologist for SOA at Oracle Corporation, and is driving the vision for Oracle’s SOA on App Grid initiative.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@MicroservicesExpo Stories
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
Don’t go chasing waterfall … development, that is. According to a recent post by Madison Moore on Medium featuring insights from several software delivery industry leaders, waterfall is – while still popular – not the best way to win in the marketplace. With methodologies like Agile, DevOps and Continuous Delivery becoming ever more prominent over the past 15 years or so, waterfall is old news. Or, is it? Moore cites a recent study by Gartner: “According to Gartner’s IT Key Metrics Data report, ...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
In his session at Cloud Expo, Alan Winters, U.S. Head of Business Development at MobiDev, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to maximize project result...
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
You often hear the two titles of "DevOps" and "Immutable Infrastructure" used independently. In his session at DevOps Summit, John Willis, Technical Evangelist for Docker, covered the union between the two topics and why this is important. He provided an overview of Immutable Infrastructure then showed how an Immutable Continuous Delivery pipeline can be applied as a best practice for "DevOps." He ended the session with some interesting case study examples.
Both SaaS vendors and SaaS buyers are going “all-in” to hyperscale IaaS platforms such as AWS, which is disrupting the SaaS value proposition. Why should the enterprise SaaS consumer pay for the SaaS service if their data is resident in adjacent AWS S3 buckets? If both SaaS sellers and buyers are using the same cloud tools, automation and pay-per-transaction model offered by IaaS platforms, then why not host the “shrink-wrapped” software in the customers’ cloud? Further, serverless computing, cl...
"We view the cloud not as a specific technology but as a way of doing business and that way of doing business is transforming the way software, infrastructure and services are being delivered to business," explained Matthew Rosen, CEO and Director at Fusion, in this SYS-CON.tv interview at 18th Cloud Expo (http://www.CloudComputingExpo.com), held June 7-9 at the Javits Center in New York City, NY.
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that e...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
"DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
We all know that end users experience the Internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices – not doing so will be a path to eventual b...
"This all sounds great. But it's just not realistic." This is what a group of five senior IT executives told me during a workshop I held not long ago. We were working through an exercise on the organizational characteristics necessary to successfully execute a digital transformation, and the group was doing their ‘readout.' The executives loved everything we discussed and agreed that if such an environment existed, it would make transformation much easier. They just didn't believe it was reali...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes a lot of work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost ...
Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking questions to analyze and troubleshoot your infrastructure, to provisioning storage with snapshots, recovery and replication, your wildest sci-fi dream has come true. In his session at @DevOpsSummit at 20th Cloud Expo, Dan Florea, Director of Product Management at Tintri, provided a ChatOps demo where you can talk to your storage and manage it from anywhere, through Slack and similar services with...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Archi...