Does a SOA “soft appliance” = an ESB

In my last post I covered some of the key features of a Service Oriented Architecture (SOA) “soft appliance” and how we have manifested those capabilities into a new platform called Intel SOA Expressway.

During many early presentations with customers and our first discussions with most analysts, a commonly asked question was “Is this just another ESB?”This is a good question.  Yet, there has been a standing debate as to what exactly is the definition of a ESB.  For the sake of moving this discussion along I will say that I view an "ESB" as a set of capabilities which are often represented in a software suite.  There are some features in the "ESB set" which are in common between SOA Expressway and an ESB product, but there are also some key differences.I will share my thoughts on the key similarities and differences in this post.

First, are the key similarities…both represent software-based infrastructure for enabling a scalable SOA.  Both provide capabilities for service orchestration, mediation, and content based routing which are often used to bring up service interfaces on existing infrastructure like applications and databases.

Next are the key differences.Many ESB products evolved from EAI technology stacks.Their heritage is data integration and messaging.Most of the features and resulting architecture derive from that heritage and focus has been put into extending the adapter libraries and messaging middleware to support things such as SOAP, XML, WS* standards, BPM, service repositories, and other features in the "ESB set".

The Intel SOA Expressway “soft appliance” design and feature emphasis is to improve the performance, scalability, security and manageability of SOA and other distributed systems architectures.Although it is a SOA infrastructure software stack with orchestration, mediation, routing and integration capabilities, the design and feature emphasis is in different areas than many other implementations. This has resulted in a different internal product architecture and focus on somewhat different usage models. For example, in the area of architecture many ESB products rely on a specific implementation of messaging middleware to perform many of their functions where SOA Expressway can provide its feature set such as message acceleration, data integration, security, routing and manageability features on any JMS capable message bus (open source or vendor provided).In the area of usage models, SOA Expressway operates as a very effective, high-speed perimeter security service providing high speed mediation functions like attachment encrypt / decrypt, sign / verify, LDAP integration, and policy enforcement.

Therefore, the soft appliance is a companion piece of technology to an ESB suite, adding performance acceleration, increasing scalability, and security mediation in a manner similar to the XML security and acceleration appliances, but in a software form factor providing for greater flexibility and reduced cost of deployment.Given this, SOA Expressway is sometimes referred to as a “hyper-esb” or “federated intermediary” to associate a label to its usage.

Why add another piece to your enterprise architecture? Why not just implement a classic XML security and acceleration appliance to the network?

Good questions.In the next few posts I will answer those questions and start sharing specific usage models, associated architectures and the kinds of benefits our customers are realizing as a result.

Thanks for getting this far.I look forward to hearing from you about your ESB deployment, especially in terms of what benefits it has provided and what incremental costs have arrived as well.


For more complete information about compiler optimizations, see our Optimization Notice.