You are hereMigrating to an Enterprise Service Bus - It's worth the effort to do it right
Migrating to an Enterprise Service Bus - It's worth the effort to do it right
John Jones--Migrating to an Enterprise Service Bus (ESB) is a bigger decision than many companies realize. It creates the opportunity for central management and access points for all the services available in the enterprise. When determining the need and the method for enabling an ESB for services, there are several important considerations. The ESB can act as a simple access point in terms of acting as a proxy to hosted web services; it can orchestrate calls to many web services through languages like BPEL, and it can also house the web service code itself. Regardless of the implementation method of the services, there are some overarching principles to consider before implementing your central access point.
Service Abstraction and Preventing Vendor Lock-In
First, as your organization implements more services through the ESB and promotes their centralized availability, more applications will make use of these services. Prior to enabling widespread usage, it is critical that services are properly abstracted such that consuming applications are not locked into the underlying system-specific implementation of the service. This concept is actually nothing new to Enterprise Architecture. As Enterprise Application Integration first started to take hold through message bus technology, messages were published to channels on a bus and subscribers could take the data in the message and take action based on the data. Early on, the publishers and subscribers were somewhat coupled in that the data publisher may have had the data in the format that the subscriber was expecting, or there was a custom data transformation implemented at the bus level from System A to System B. This process made the integration between the systems dependent on the system itself.
A best practice emerged from this challenge in that Enterprise Architects and Information Architects developed canonical data models to aid in the data transformations. A canonical model patterns the data entity as it should be represented to match how the business expects to receive that data entity. This data entity serves as an abstraction layer in the transformation of data from System A to System B. Now, using the canonical method, a message published from System A is transformed into a message conforming to the canonical model for that data entity, and then System B transforms the message from the canonical model to meet its own needs as shown in Figure A. This way System A or System B can be replaced with System C, and the integration between System C and the canonical model message format is the only piece of the integration to change.
Using the canonical data model allows for any number of systems to communicate with each other, prevents the likelihood of a data conversion explosion and takes away the potential of locking the applications into an underlying, system-specific service.