I was recently visiting a client to discuss possibly augmenting the work we were doing for them from straight messaging to Managed Services, when a question came up about whether we could connect our services to their ESB. This is not the first time I’ve been asked about this, and while the answer is always “YES”, the form this takes varies with the client’s circumstances and goals. There are many variations, but I like to “bucketize” them where possible into three models:
- B2B Broker on the ESB: This is basically NOT connecting directly to the ESB, but connecting to an existing or new B2B or comms gateway that is connected to the ESB. This is a typical method where the B2B team and strategy are external to the ESB from a design and architecture perspective, and trading partner configuration is encapsulated within the B2B broker/gateway. This model is usually easy to configure, but can result in latency between the managed services and the ESB, and the potential for confusion if there is a lack of synchronization between the B2B software and whatever data is driving the ESB routing logic. The advantage to this approach (aside from the ease), is that the security and any data transformation can be handled prior to the ESB. This is the most common scenario today, usually leveraging some secure variant of FTP from the B2B Broker to managed services.
- Custom integration to the ESB: Rather than a commercial gateway that is integrated to an ESB, this is more of an exposed “endpoint” (usually, though not always web services — SOAP or REST). The service provides “mapping” logic, sometimes of data, but usually of envelope, to augment the inbound transaction so that it can be properly handled by the ESB. An advantage to this approach is that Web Services management and government can layer security on without burdening the ESB with providing this for external entities. This is particularly important when the transactions or documents coming in are not self-contained (meaning that they contain sufficient information to be routed and handled without augmentaion). This is typically the model in use when a customer asks us to integrate with them via web services.
- Direct to ESB integration: In this model, the transaction is entered — more or less directly — into the ESB. I tend to see this most with XML traffic, although an EDI enabled ESB could certainly accept X12 or EDIFACT. An example of this model would be JMS over HTTP (currently supported to a customer’s TIBCO system, for instance), where the network layer is used for securing the connection, but the routing and processing logic is directly on the ESB. This is the “purest” model, but requires the ESB implementation to have been designed with external transactions in mind. Paradoxically, where this works it is likely to be the model the customer insists upon. The advantage to this approach is flexibility, and the elimination of a number of way stations inbound. As attractive as this approach is, most organizations still shy away from directly connecting their ESBs to the outside world.
I expect that more and more organizations will start to consider approaches 2&3 going forward, but it will take time. Direct to ESB integration is a strong step to efficiently connecting external partners to an organizations Service Oriented Architecture (SOA), but that’s a topic for another blog entry.
