Why All SOAs Need ESBs

I've recently asked one of my developers to research some integration and middleware technologies for a project we're working on. After spending a couple days on this, he said to me "these things are all part of ESBs now". I.e. all the integration and middleware vendors have pretty much taken these capabilities and bundled them into their ESB platforms. "Oh you need a message bus? That's part of our ESB now." "Oh you need this adapter? That's included in our ESB." In most cases when you're implementing an SOA, you will need some piece of middleware or integration technology. With just about every vendor making these things part of their ESB suites, you're probably gonna end up getting an ESB even if you don't need a whole freakin' ESB. That's why all SOAs need ESBs (regardless of whether or not you really need them)!

Event Driven Architectures

Came across a pretty cool open source product several weeks ago. It's an event stream processing engine called Esper developed by a couple guys who look like they have a lot of experience building systems for the financial sector. Makes sense since I can see a lot applications for EDA's in the financial domain. Esper defines its own EQL (event query language) that allows you to define SQL-like expressions to process against the stream of events coming in. Thus you can use EQL to define rules to correlate the events that are passing through. The thing I like about this product is its ability to take in XML messages as events. You can use XPath to define the properties of those XML-based events and then reference those events and properties in your EQL expressions. This has a lot of applicability in Web Services and ESB-based systems where you have a lot of XML messages being passed around. This could probably be used to implement the supply chain ESB scenario that I wrote about in this article.

EDA, esper

When Should You Use an ESB?

With all the hype around ESBs, a lot of people think that you need an ESB to build an SOA. That isn't always the case. I'm getting tired of seeing boilerplate SOA architecture diagrams with an ESB in the center. As with any other product, you should only use it if you require the functionality provided by it. Though there's no firm definition of what exactly is an ESB, you often see a core set of functionality that's provided by all ESB products. I talk about them in this posting. They are:

• Protocol Adaptors
• Data Transformation
• Routing
• Orchestration
• Synchronous/Asynchronous Messaging
• Endpoint virtualization

So when might you need such functionality? For example, if you're working in an environment with legacy systems and not all of them can support SOAP/HTTP. Or perhaps if you're building some type of automated workflow system or BPM. Or some event-driven system that requires asynchronous messaging and routing. If you just required some data transformation or endpoint virtualization I probably would not go with an ESB--it would be a bit overkill. Anyways, the point is look at your requirements and your environmental constraints first to see if you need the functionality that's provided by an ESB before you throw an ESB into your architecture.

soa, esb

BAM and SOA

Saw some talk (from David Linthicum and David Black) recently in the blogosphere on doing business activity monitoring (BAM) and business intelligence (BI) within SOAs. This is an idea I've been keen on for a while now. Wrote an article about it for DM Review last August.

The opportunity lays in the fact that SOAs have a holistic view of the business processes that are executing within them, thus they can provide the context that ties together the data collected from BAM or BI to provide actionable information at a business level versus just giving you the raw data that your analysts have to try to manually tie together. Combine this with the fact that you have standard XML messages from which to harvest the data from and it becomes a very attractive opportunity that organizations with SOAs should definitely take advantage of.

In his entry, Black goes a bit further to talk about how ESBs can provide a good platform for this stuff, which is essentially what I was detailing in my article as well. According to his blog, Black, who recently joined Cape Clear, will be working to help them add BAM capabilities to their ESB. This will be a great feature that will distinguish them from their competitors. I'll definitely be keeping my eye out for this feature to see when it becomes available.

soa, bam, bi, esb

Using an ESB to Connect the Enterprise to Mobile Users

Years ago, I worked for a company that built products for mobile and wireless applications. We had a platform for developing systems that connected the enterprise applications with users in the field through their handhelds, PDA's, smartphones, etc. I was thinking about it the other day and it struck me how similar that platform was to what we call ESBs today. Thus, it struck me that besides being SOA infrastructure, ESBs are also good for extending the enterprise to the edge--the mobile users. Here are some reasons why:

• Enterprise apps are available as a set of loosely-coupled services that can be selectively exposed to the mobile devices. This is not a direct result of using an ESB, but if an organization is using an ESB, then they are most likely building (or already have) an SOA--so their enterprise apps will be available as a set of loosely-coupled services.

• The asynchronous messaging, guaranteed messaging, and store and forward capabilities of most ESBs are perfect for occasionally connected devices.

• The data transformation capabilities of ESBs can be used to transform data for optimized presentation on the devices. For example, converting from XML, HTML to WML.

• The protocol mediation capabilities allow for converting to/from different protocols supported by the devices, e.g. WAP-->HTTP-->SOAP. Note some type of gateway will still be needed to convert between the various wireless protocols such as GSM, CDMA, CDPD, Bluetooth, etc. to the TCP/IP based protocols that most of the enterprise apps are built on top of. But once all that's in place, it will abstract complexities of wireless communications protocols from the enterprise developers, and vice-versa--developers of the mobile apps don't have to deal with the enteprise issues.

Here's a rough sketch of what it may look like.

ESB, mobile computing

How Robust is Your ESB?

Organizations are increasingly looking at using an Enterprise Service Bus as the technical foundation for building SOAs these days. With the ESB playing such a critical role in your SOA infrastructure, it is important to understand the characteristics by which to measure the robustness of your ESB. There are various definitions of an ESB out in industry, so the best way to look at them is by the capabilities that people commonly think of when they refer to an ESB.

Although the functionality of an ESB can vary greatly from vendor to vendor, you will find that common to all of them is a core set of functionality that includes the following:

• Protocol Adaptors
• Transformation
• Routing
• Orchestration
• Synchronous/Asynchronous Messaging
• Endpoint virtualization

Based this reference set of capabilities and an understanding of how this type of functionality is typically implemented, one can get an idea of where there may be potential performance bottlenecks, fragile points, and other robustness issues that can plague an ESB. Knowing what these are can help you to make a more informed decision when choosing your ESB vendor and product.

Protocol Adapters
One of the core functionalities of ESBs is protocol adaptation--that is connecting services that run on one type of protocol to services that run on another type of protocol. For example, adapting from SOAP to JMS, FTP to SOAP, SOAP to IIOP, etc. ESBs that are built on top of a messaging-oriented middleware will typically use adapters that connect different protocols into the messaging bus. This is similar to how some products accomplish data transformation using a canonical data model but here the ESBs use a canonical protocol internally based on messaging. Adapters then just transform other protocols to/from this format, while internally components communicate using this normalized protocol. Other ESBs that are not built on top of a message-oriented middleware will typically use a series of interceptors, similar to a pipes and filters architecture in which messages flow through a sequence of interceptors. Usually this type of architecture will perform both protocol adaptation and data transformation as the messages flow through the interceptors.

Transformation
Data transformation is very resource intensive. All the parsing that is required makes it very CPU intensive. The resulting parse trees are loaded into memory for manipulation, making it also very memory intensive. For very large datasets, not everything can be loaded into memory, making the operations also very I/O intensive. Because of these characteristics, it is very important to look for an ESB with a high quality transformation engine. The transformation engine can be evaluated using different types of datasets and transformation. For example, evaluate how it handles large, complex source and target schemas. How does it handle complex transformations? How does it handle large datasets? Run tests using these scenarios and observe CPU, memory, and I/O usage for the transformation engine.

Routing
Services communicate with each other by placing messages onto the bus and the ESB determines how to route those messages to the correct destinations. There are a couple different ways in which this functionality may be implemement. Some implementations may use a generic set of dispatchers that listen on a set of generic incoming channels and dispatches the messages to their destinations. Another approach uses specific channels for the different services. With this approach the service consumer just places the message onto the specific channel of its intended service and a dispatcher specific to that service will dispatch the message to the destination.

Some implementations route messages by having different queues for different destinations. Observe the CPU and memory usage of the message bus processes to see if the message router is saturating the message bus. What is the performance of message router for different types of routes, multiple hops, etc.? Parsing of the message itinerary can also be performance intensive. Message routers often use multiple threads to listen to incoming messages and route them to their destinations.

Orchestration
Orchestration allows developers to hook together multiple services using complex logic to form a larger integrated process. Most ESBs provide orchestration capabilities based on some type of BPEL (or equivalent) orchestration engine. Orchestration is a complex capability and there are many issues you need to consider when evaluating an ESB’s orchestration capabilities. Does it pre-compile the orchestration instructions to improve performance or does it process the instructions on the fly? If the instructions are pre-compiled, then it will be more difficult to dynamically update the process to respond to new events. On the other hand, if the instructions are processed on the fly, then there may be a performance hit due to that. A process is typically long running and thus maintains state and context. This means that the orchestration engine is usually a stateful service. Being stateful makes it more difficult to distribute for failover and scalability. For example, if the ESB containing the orchestration engine in which the process is running fails, how will it migrate that process and its state to a backup instance? The statefulness also creates an affinity with a particular ESB instance which means the messages have to flow through that particular instance—making load distribution across multiple instances difficult, if not impossible.
Keep an eye on the memory usage of the orchestration engine since a lot of implementations build an entire object graph of the process. How many processes can it run concurrently?

Synchronous/Asynchronous Messaging
The messaging backbone is what allows the highly distributed nature of an ESB. One of the results of this is that the capabilities of the ESB can then be distributed across multiple nodes--one of the primary distinctions between an ESB and some of the more traditional EAI hubs. Some of the vendors whose products don't have a messaging backbone will argue that one is not necessary to achieve this highly distributed characteristic of ESBs. In any case, regardless of how the capability is implemented, most ESBs support highly distributed synchronous and asynchronous messaging. Thus, it is important to understand what characteristics should be of concern when evaluating this capability. Important things to consider--throughput of the messaging, size of the messages, latency of message transfer, reliability of message delivery. Observe how these metrics vary across different messaging patterns:

• Small, chatty messages
• Large, bursty messages
• How many inbound messages can it handle
• How many outbound messages can it handle

Endpoint Virtualization
Clients are abstracted away from the actual physical network location of a service. They invoke services by using logical addresses for the service endpoints provided by the ESB. This allows for such things as multiple instances of that service for load-balancing and failover. One of the concerns here is whether or not a particular ESB's implementation of endpoint virtualization is interoperable with the WS-Addressing standards.

SOA, ESB