Raible Designs

[CSS 2006] To ESB or not to ESB?

Do you have to have an ESB to have a SOA? I'm sitting in Denise Hatzidakis's talk titled "To ESB or not to ESB" as requested by Mick Huisking. Dinese is the Chief Technologist at Perficient, Inc.. It's interesting, on her opening slide she has a @perficient.com e-mail address, as well as an @us.ibm.com address.

"SOA stands for Same Old Architecture"

This talk focuses on using an ESB and how to build it. There's a lot of ESB products out there. An ESB is not about a product - it's about what kind of connectivity you need between your systems.

An ESB is an "Architectural Pattern". In fact, it's possible to construct service buses from a variety of different underlying integration technologies.... The architecture pattern remains valid and is a guiding priciple to enable the integration and federation of mulitpler service bus instantiations

--Rob High, SOA Foundation Chief Architect

An ESB enables standards-based integration between loosely-coupled apps and services within and across:

• services oriented architectures - where distributed applications are composed of granular re-usable services with well-defined, published and standards-compliant interfaces
• message driven architectures - where applications send messgaes through the ESB to receiving apps
• event driven architectures - where applications generate and consume messages anonymously

"SOA - it was EJBs a couple of years ago"

When implementing a "Virtual Provider", who is responsible for building that?

• The Service Consumer?
• The Prospective Service Provider?
• The Service Broker?
• The Internal Enterprise-wide Governance Body on SOA?

The Service Consumer may have to foot the bill or agree to split it with the prospective provider. The provider may not be ready or willing (no funding or not a priority) to build a service interface for the consumer.

The biggest barrier to ESB implementation success is often political - it rarely has anything to do with technology.

There's 3 core layers in an ESB:

• Micro Composition/Decomposition & Customized Routing: Protocol mapping, pattern recognition (where you deal with the messages), message validation, service brokering
• Enterprise Service Bus - Core Layer
• Bus Connections: HTTP, JDBC, etc.

The key USB purpose is Routing Service Requests. The ESB proxies the means to manage the service infrastructure and the capability to operate in today's distributed, heterogeneous environment. Denise said she told IBM not to build an ESB, because it's not about the product, it's about the architecture. However, apparently one CEO wouldn't buy the IBM Stack because "ESB" wasn't on the purchase order.

ESB Capabilities: Communications, Service Interaction, Integration (databases, legacy, etc.), Quality of Service, etc.

An ESB leverages underlying communication fabrics of SOA infrastructure - providing on-ramps and off-ramps. Typical requirements are: HTTP (SAOP/HTTP, XML/HTTP), MQ (SOAP/JMS/MQ, XML/MQ, text/MQ), Adapters, WS-I, WS-Security, RAMP. Web services are a key enabler of SOA, but they certainly aren't a requirement.

Message Models

• Describe messages exchanged with requesters and providers
• Based on Meta-models
• An ESB supports one or more message meta-models
• An ESB supports multiple message content models
  • Can include industry standard model as well as enterprise specific models
  • Can include weakly-typed models

Canonicalize on the message format itself (using something like SOAP or JMS, just agree on which one). Let the business logic reside in the message itself. You will want an ESB that supports multiple content models.

Mediation Flows: process messages exchanged between requester and provider via ESB (large grained, moderately reusable, constructed from Mediation Patterns.

Mediation Patterns and Message Processing: Allow manipulation of messages during a message flow (provided by a mediation framework).

Mediation enables Service Virtualization of identity via routing, interaction vi conversion and interface via transformation.

Mediation enabled Aspect Oriented Connectivity - Security & Management, Logging Auditing, Dynamic Routing, etc.

Example Mediation Patterns: request/response, request/multi-response, event propagation, distribute, correlate, monitor, gateway, transform - log - route.

Connectivity, Message Model and Message Flows are the 3 main components in an ESB. What's not in the ESB? Everything else!

Do you have to have an ESB to do an SOA? No.

Do get a good ROI from your SOA, you need to have a loose coupling in your implementation. Tighter coupling tends to cost more over time, but looser coupling requires greater investment up front. There's more design work and more implementation work that happens in the beginning. You might not need a full-blown ESB (is this starting to sound like EJB containers), you can probably do an SOA architecture with your current tools and technologies. When I was at Xcel Energy last year, a bunch of good friends built an ESB on top of JBoss - using Quartz, JMS, EJB, Spring and Hibernate.

What does "loosely coupled" mean? It's not a well defined term. We now what "coupled" and "decoupled" means, but there's a lot of grey in between.

At this point, my battery began to die. Denise was a good speaker, but she had a lot of information on her slides - makes a real-time blogger's fingers hurt. ;-)

Tonight, I'll be attending the Q & A, followed by a Spring BOF. Should be fun.