Implement an enterprise service bus revised
Download as PPTX, PDF3 likes1,011 views
This document provides advice for implementing an Enterprise Service Bus (ESB) by highlighting important considerations. It emphasizes that an ESB is a platform to deliver solutions and must be implemented as part of broader initiatives to be successful. It also stresses the importance of people, processes, technology, governance and change management for a functioning ESB.
Implement an enterprise service bus revised
- 1. Implement an Enterprise Service Bus Get your Services on the Bus. If you are a CIO, Enterprise Architect, Solution Architect, or IT Manager forced with the challenge of integrating application services, this research is for you! Enterprise Service Bus (ESB) technology is often seen as the solution to integration problems. Unfortunately, if ESB technology is not implemented properly and used for the wrong reasons, it becomes a liability. An ESB is a platform on which solutions are built and delivered. Solutions can constrain the effectiveness and efficiencies of the underlying ESB technology. ESB solutions that are implemented as part of larger initiatives are usualy more successful, but if enterprise capacity and scalability are not taken into consideration, it can fail outside of the original scope. In addition, if the solution was not architected with flexibility in mind, it will fail when IT and business requirements change. Beyond implementation, ESBs are complex solutions that require careful consideration of maintenance and management. Given that an ESB can be at the center of a service oriented architecture, if it isn’t available, neither are your application services. Organizations that adopt a service oriented architecture, without implementing an ESB, end up with SOS: service oriented spaghetti! Plan for your ESB implementation by ensuring the appropriate people, processes, technology, and data are in place or risk failure. ESB implementations are rarely done independent of other initiatives. Find a project that requires a lot of integration, and leverage it to demonstrate the value of an ESB. Identification and use of common integration patterns will accelerate design, development, testing, and deployment times. Record architecture decisions at design time, to avoid revisiting the same problems during implementation. Where possible, put ESB configuration and message persistent data stores on storage area networks (SANs) or servers separate from the ESB processor. Designing for capacity of the services that use the ESB is just as important as the ESB itself. A solution is only as good as its weakest point. Avoid using generic credentials for service access to/from the ESB. Compromise of the generic credentials opens up services and/or the ESB to malicious activity that cannot be traced back to the individual. Canonical models are one of the hardest things to do in an ESB implementation, but they also provide the most benefit to the enterprise. Without canonical models, you’re just creating more point-to-point interactions inside the ESB. ESBs are built for stateless mediation of services and events. Extending their functionality to include stateful management can complicate the solution and threaten overall success of the project. Governance and control of change management is critical in an integrated environment. One uncontrolled change can cause a domino effect of failures across the environment.