Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
Integration is an odd animal. It's typically a lot more network centric than standard business applications because it deals with routing messages between different applications and locations. But integration is also different from typical IP-type networking because it is much more dependent on application specifics, such as message data formats or business logic. This fact has frustrated users for quite some time -- it seems like integration solutions are more difficult to build than stand-alone applications and at the same time are more difficult to operate than typical networking equipment, such as routers and switches.
One of the ideas that has been floating around the integration community is Why can't integration be more like networking? If we can route IP-based traffic using hardware routers, gateways and switches, can't we extend that model to application data. In fact, there are a number of striking similarities between the two technologies. For example, a number of our patterns use examples from the domain of TCP/IP. So if we could make networking smart enough to deal with application level data (sometimes called application-aware routing), we could hope to achieve the same reliability and low cost of operation that we accomplish with IP-based networking equipment today.
The Market
There are a few vendors on the market today that are exploring this approach. We can roughly split this market into two segments:
The first category includes devices that specialize in XML transformations using XSLT and XPATH. These devices can be configured to accept XML data in form of SOAP messages or as plain XML over HTTP, transform the data and route it to a new destination. That destination can be fixed or it can be determined on the fly based on the content of the message (effectively implementing a Content-Based Router). Alternatively, these devices can be used as XSL co-processors from inside applications. Two vendors playing in this arena are DataPower and Sarvega (please note that I do not endorse any specific vendor, I am simply listing the ones I have come across).
The second segment includes devices that provide additional integration functions, such as application adapters, transformation, routing, and orchestration, making them essentially Message Brokers in a box. Orchestration can be configured via custom UI tools or BPEL4WS files. Two vendors specializing in this segment are Infotone and Cast Iron Systems. The line between the two categories can blur a little bit as the XML processors start to include more powerful routing functions as well.
Wintergreen Research estimates that this market will be $2 billion in size in 2008. The fact that the forecast reaches out this far into the future might give us a hint that this market is still early in the life cycle. It also means that it's hard to prove the researchers wrong...who knows what we'll be doing in 2008? :-)
The Benefits
These appliances appear to promise three key benefits when compared to tradition EAI solutions:
In general, dedicated appliances can offer better performance than general-purpose PCs or servers because they can employ custom hardware and software combinations and because they do not have to carry with them the overhead of graphical user interfaces, user management, Web browsers and other non-core services. However, a potential drawback of using custom processing hardware is the increased cost and the reduced flexibility due to longer development cycles. Therefore, it makes sense for the vendors to use as much off-the-shelf hardware as possible. As a result, in some cases the appliances look suspiciously like a rack-mounted PC loaded with special software. Big performance gains can still be achieved by writing specific software modules in assembler or in another language that is closer to the actual hardware because portability is not a concern. As a result XML appliances can outperform many popular XML parsers and XSLT processors by a factor of 10 to 1. This is one of the key selling points for the Hardware XML Processor vendors.
Fewer moving parts also means fewer things that can go wrong. If you are running a small real-time OS and a purpose-built XSLT engine you do not have to worry about Blaster worms and applying the latest service pack. Some appliances also use backplanes with redundant power supplies to make the hardware itself more reliable, even though you can find the same things in most PC servers as well. Overall, the message is "plug in and forget".
The manageability aspect targets the high cost of ownership of existing EAI solutions. Compared to networking solutions, traditional EAI middleware solutions are very complex and unstable so that most projects have a very hard time to hand the solution over to the operations and sysadmin staff once it is in production. This tends to drive the total cost of ownership (TCO) through the roof because full-time developers are required to keep the solution running.
No Free Lunch
So where's the catch? The obvious trick is to find the correct balance between simplicity and flexibility. If the integration appliance is based on a PC architecture and contains all the functions that a typical EAI suite contains we might not have gained over a traditional EAI suite. Instead, we might have introduced new dependencies and a new form of vendor lock-in. The key is to find the correct levels of abstraction for the solution and isolate variability points. Done right, this will leave us with recurring functions efficiently implemented in hardware that require relatively little configuration and customization. For example, for a Content-Based Router the only variability point might be a simple XPATH expression that determines where the message should be routed. Unfortunately, in real life things are rarely that easy and quickly the "configuration" turns into a full blown software development effort with all the required testing and debugging cycles. This is no different from many previous EAI vendors who told us that "real" development is no longer needed and all EAI solutions are just a matter of simple drag-drop configuration -- yeah right! The integration appliances are in danger of falling into the same trap or at least they have to deal with customers who just got burned by projects that turned from the promised 3 weeks of "configuration" into 12 months of heavy-duty development. I also think the appliances have to offer an additional premium in realized benefits to justify introducing another development platform to support.
Luckily, some of the Web services standards reduce vendor lock-in through the promotion of common languages such as XSLT and BPEL4WS for transformation and orchestration. This would allow us to use our regular development suite, test out "code" on a regular development box and then deploy it to a dedicated device for maximum stability and performance. At this moment, there are still a number of hurdles like evolving standards and a variety of vendor-proprietary extensions. But at least we are moving the right direction.
What Role do Patterns Play?
Why am I interested in this stuff? Developing a successful integration appliance requires vendors to identify commonly used constructs and distill them into reusable components that can be implemented inside the appliance. This effort shares some similarities with the search for patterns -- good solutions for recurring problems. There is, however, a small but important difference between the two. Patterns are by nature "fuzzy", they are not spec'd out components that are configured via an XML file. Patterns are solution concepts that can be translated or "realized" into an actual code solution. In my opinion, EAI is ripe with patterns but I think the jury is still out on whether EAI can be decomposed into reusable constructs. It will be interesting to see what the appliance vendors find. I will keep watching...
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.