Create a winning web services strategy with a hub
March 6, 2012 Leave a comment
SOA Architecture and Enterprise Service Bus aren’t new concepts to IT but the drive to migrate to RESTful services over the past few years has made them more relevant than they once were. A good rule of thumb to follow to determine if you need an ESB is to analyze and visualize what your infrastructure looks like. Service bus architecture works best when your architecture looks like a wagon wheel or “hub” with spokes, multiple systems whether they be external and internal communicating with a central “brain” or repository of information.
Let’s look at some of the reasons an ESB implementation is a good idea.
- An ESB provides a facade or interface on top of external systems that your applications need to interact with providing you with ability to replace those external systems at will without changing the in front of the ESB. Simple interface-driven design at it’s best.
- An ESB provides a common home for your enterprise business logic, data transformations and hard core systems interactions.
- User interfaces into the system can also be more readily shifted from one technology to another making you more agile. Also, multiple interfaces can run off the same ESB services, e.g. iPhone, iPad, Ajax framework UIs, etc.
- An ESB gives you an external API for other business partnerships to integrate with you… Most often third-party integrations are an afterthought resulting in a reactionary measure to accommodate another system
- An ESB encourages code reuse in your enterprise…
- An ESB gives you a set of standards, SOAP, MTOM, REST, JSON, etc. Standards make integrations much simpler.
- Developers are no longer accessing your databases directly with code. Control over performance is pushed back to the ESB tier.
- An ESB is ideal in an environment where you need “translation”, multiple systems in .NET, JAVA, PHP, C++ and legacy
A lot of great reasons to use an ESB in your system architecture, but an ESB isn’t the catch all solution. It has a few drawbacks that need to be considered.
- ESB implementations aren’t for the faint of heart. It takes some expertise to plan and execute a successful hub.
- ESB-based systems have an increase in network chatter since all interactions are back to the ESB via the network.
- There are not many open source solutions for ESB implementation. MuleESB is the leading one for Java. Commercially, BizTalk, webMethods and TIBCO are available but extremely expensive, but also feature rich..
- In larger IT organizations, an ESB implementation is usually confined to a small group and other groups tend to ignore it’s existence and continue to write logic straight into their projects, creating a silo approach of small isolated projects with duplicated logic and code.
- ESB can create a bottle neck in larger organizations that have many projects running in parallel. The ESB team has to grow to meet the demand by other groups and service their requests.
- An ESB doesn’t make sense if you have a small number of system interactions. For example, a product company with a single product and database doesn’t need an ESB implementation. Again, it goes back to what your visualization looks like. In this example, the diagram one be a single spoke and we are looking for the wagon wheel…
ESB, HUB, SOA… whatever you want to call it, it is all about the same thing. Reducing complexity, reduce cost of ownership, increase agility and provide easy integrations to make your IT organization successful.
