Enterprise Service Bus

''by Hossam Karim'' !The road for SOA According to Dave Chappell:\\ ''“An ESB is a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity”''\\ \\ While the definition is absolutely accurate; a great matter of confusion arises around the true implementation of an Enterprise Service Bus in the real world. Definitely, an application server or an integration adapter is not an ESB, but currently, this is the way vendors are promoting their already architected product offerings. Accidental architecture is always the result of lacking a core concrete, well designed technology, while trying to integrate an incompatible set of disparate applications using vendor specific technologies. This kind of infrastructure is not completely ready for SOA, but if you are hitting the road for SOA, an ESB is what you should be ridding.\\ \\ !What to expect from an ESB? Endless possibilities; scalability, performance, reliability and standards support should be on top of your expectations list. An ESB is all about delivering and connecting services, if the service you are expecting is not on the bus, at least the bus should allow you to seamlessly plug it in.\\ \\ Technically speaking, an architect’s expectations from an ESB can vary accordingly, but a common set of features should always be agreed upon:\\ !Standards support An ESB should be speaking the same language your world decided to learn and communicate with; this should not be limited to messaging standards, web services or transport protocols. Generally, an ESB should be built on standards or at least has the support for deploying and running standards-based components and services. New evolving specifications like SCA and JBI can be a critical offering when portability is a key for the client. !XML as the standard ESB data format The universal format that has widely proven its extensibility can hardly be ignored by an ESB. An ESB should be able to burn the oxygen that it’s provided services breath and digest the food your applications eat; but XML is always the blood that flows inside the ESB vessels. !Security Security is always a concern for any software user, so it should be when it comes to an ESB. The only difference is that in addition to providing a secure system, an ESB should be able to integrate your existing security systems and applications. Like any of the ESB offerings, security should also be an offered service. !Modeling, development, deployment, testing and simulation tools If your current integration software claims to be an ESB, and is not providing a complete modeling to deployment tool, you should consider something else. No matter how focused and small your project is, it will come the point when your system needs expansion or even maintenance. A typical ESB tool is the one that can understand your current UML models, provide you with the tools to expose the pieces that you trying to build as a service, and then packages and deploys your code and artifacts to its online instance. An excellent ESB tool will allow you to simulate and test what has just been modeled either online or offline and report possible critical issues or even warnings. This kind of tool might save huge time and resource consumption. !Dynamic service, endpoint and protocol binding activation and deactivation So you simulated, tested and successfully deployed your service. A few months later you decided to get this service offline for some security flaw, sorry, not supported; you have to shutdown the entire ESB instance. After deployment, you are asked to expose this service on a different protocol, sorry, you have to create another service or remove the current, modify it and then redeploy. A true service-oriented ESB will allow you to dynamically perform this kind of tasks without limitations, if there are dependencies or any other issues, you should be warned and the ESB should take care of deactivating the proper influenced objects and services. One idea about loosely coupled services, is allowing us to perform such tasks. !Service Orchestration Service can’t just perform by themselves; they just need a maestro. When orchestrating services, a typical ESB will go beyond defining the process of invoking services and processing simple logic, it will allow you to specify multiple routing targets, support asynchronous invocation and integrate your messaging security model as well. You should be able to delegate parts of you logic execution to an external module following a specific contract no matter what kind of language this module is written in, or what kind of logic it actually performs. The orchestration process itself, should be a deployment artifact where activation and deactivation applies. !Monitoring, Control and Management A centralized point of monitoring, control and management that can be accessed locally or remotely using a standard secure protocol, is something you don’t want your ESB if it does not have it. If the ESB is not providing this as a front end console, or at least as a service, it should definitely provide the API for managing all these aspects. !Partitioning, Clustering and High Availability An ESB, in one way or another, will act as a server. One should be asking, how reliable my server is. If your organization is geographically distributed, with common and non-common services needed to be available; an ESB will be a perfect solution for this situation. The true problem here is reliability. Can I partition my ESB with or without isolating selective set of services? Can I have clustered node instances of the ESB? An “Enterprise” Service Bus should properly answer these questions. !References * __ESB and SOA books__: ** Enterprise Service Bus: http://www.amazon.com/gp/product/0596006756 ** Enterprise Integration Patterns: http://www.amazon.com/gp/product/0321200683 * __Companies providing an ESB__: **SonicSoftware: http://www.sonicsoftware.com/products/sonic_esb/index.ssp **Tibco: http://www.tibco.com/software/esb/default.jsp **IONA: http://www.iona.com/products/artix/ **Cape Clear: http://www.capeclear.com/products/cc6.shtml **Oracle: http://www.oracle.com/technologies/soa/soa-suite.html **BEA: http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/service_bus/ **IBM: http://www-306.ibm.com/software/info/middleware/applications/index.jsp **Fiorano: http://www.fiorano.com/products/fesb/fioranoesb.htm *__Open Source ESBs__: **ServiceMix: http://servicemix.org/ **Open-ESB: https://open-esb.dev.java.net/ **Mule: http://mule.codehaus.org/ **Celtix: http://celtix.objectweb.org/