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.
The same principle can hold true for web service design. With the growing popularity of Service Oriented Architecture (SOA), numerous software vendors are embracing SOA by making many of their functions available through a web service Internet Application Programming Interface (API). However, this API will rarely have operation parameters that conform to the generic type of canonical entities or generic type of functions that are specific to the Business or Data Architecture for the Enterprise. Following the same model from the message transformation abstraction in the message bus model of integration, only generic business services in the ESB should be exposed to prevent the same point-to-point integrations that can cause vendor lock-in as shown in Figure B. This process becomes more and more important as the number of consumers of services that are exposed through the ESB grows. As the services become known throughout the enterprise and usage becomes more widespread, dependencies on service providing systems can become stronger than ever envisioned.
Service Usage Tracking and Reporting
It is important to be able to understand who the consumers of services are and what their usage patterns are. There are many ways to implement service usage tracking, from simple logging to building reports and dashboards. As services are exposed to the general user population, it is wise to require some type of authentication to use any service in your enterprise. These authentication credentials can be brokered by the managers of the ESB or by the services themselves. These credentials serve two main purposes:
- Requiring credentials eliminates any unauthorized or unplanned usage of the services
- Requiring credentials can make it easier to track usage
Requiring credentials for any service usage reduces variables when determining the root cause of performance-related issues or even system-related issues relative to data coming from service calls. Having authentication requirements in place eliminates unauthorized consumers from coming in and creating an excessive number of service calls that were not anticipated during the design phase. When credentials are used to authenticate each call, it is easy to track all the operations being done by the consuming applications. If Service Level Agreements (SLAs) are established for service response times with different consuming applications, it is imperative that there is a clear method for understanding the actual versus the expected load from each consuming application for any given service. If this tracking is not in place, it is almost impossible to understand how to work with the owners of the client applications to fund the necessary scaling of the service hosting hardware resources.
Driving Consumption
Migration to an ESB may initially seem like a trivial task within itself. Nevertheless, when migrating to an ESB the organization doing so is usually making a statement that they want to engender a more widespread use of the services within the enterprise. An organization must take the necessary steps to make their services, and the groups supporting them, ready to deal with the ensuing wider consumption of services. Taking the few basic steps of ensuring that there is complete abstraction from system specific services and that there is an ability to track consumer usage will go a long way in providing Enterprise services consumers a very stable and supportable service layer that can be relied on.
