SOA style of architecture is being adopted gradually by the industry. Organizations have started to view their business capabilities as set of well managed Services that are modular and reusable in different business processes. Business is slowly realizing the value of SOA with respect to Reuse, Business-IT alignment, and Agility.
Product vendors have responded swiftly by introducing SOA enabling products that help expedite the adoption process. There are many ESB & Broker products introduced that are expected to introduce loose coupling by placing intermediary that handles integration concerns between business applications.
Some of the commercial products are:
1. IBM WebSphere Message Broker, Websphere ESB, WebSphere MQ.
2. TIBCO Businessworks,
3. Webmethods Broker, Integration Server,
4. Oracle Service Bus
5. Sonic ESB, etc
Apart from the commercial products there are open source products and lightweight frameworks that can do the role of ESB's for e.g Mule, Service mix, etc.
Often, I have seen many organizations using the ESB or Integration platforms as Application platforms. This means they use them to build business applications that produces and consumes inter-application messages. This is to me an anti-pattern where Integration platforms are loaded with business logic, complex persistence flows and business decisions. It is a kind of bad-smell in the design of the system and usage. I see following dis-advantages in using this model.
1. The purpose of ESB's is to be an integration middleware, de-coupling producer and consumer applications in many ways.
2. ESB's help induce seperation of concern between Integration-logic and Business-logic. All integration logic is isolated in Integration environment, so that if it changes the change is limited to Integration platform and not applications.
3. ESB's are appropriate for connectivity, translations, enrichment's and validations in the context message processing. When we start putting applications and business logic inside ESB, then it starts smelling and add more complexity to manage.
4. Most commercial vendors provide message flow framework to write mediators. Sequencing of activities within mediators creates a message processing flow. The flow is created to link the source application to the target application. Adding business logic, entity persistence, rules and decisions, controlling application logic in flows will defeat the purpose of seperation of concerns. Hence it increases rigidity and complexity of applications.
5. ESB's are not made to write applications, where applications need complex persistence mechanism, caching support, data-structure support and other application frameworks.
6. Business applications are best written in good object oriented languages, leveraging application frameworks, containers, management tools etc. For e.g. building order processing engines on Broker or ESB is not good idea as it is defeating ESB's purpose, and not leveraging application frameworks.
7. Applications are best written in OO platforms or frameworks like the Java, dotNet, Ruby on Rails etc.. and deployed on Application Servers like Websphere Application Server, JBoss, Tomcat, etc. The advantages of using OO is huge when written in good abstracted manner, resulting in well defined, modular, maintainable, reusable & component based applications.
I have often seen organizations that use Broker platforms to write applications that processes messages but also host business logic, business entity and persistence of business entities. I find this as anti-pattern. Probable reasons they take this decision are:
1. Immaturity of decision making,
2. Organizations do not spend efforts in evaluation of architectural and platform decisions.
3. Not enough understanding and appreciation of Object oriented platforms.
4. Ivory tower architects making decisions without practical experience on platforms.
5. Not enough experience on Agile, Object oriented principles and processes.
6. Not enough clarity on usage of architectural styles and their fitment.
I would recommend reading following articles to understand fundamentals of ESB style of architecture.
Mark Richards on ESB
Fundamentals of ESB
I do welcome comments on this topic, please write your thoughts..
Product vendors have responded swiftly by introducing SOA enabling products that help expedite the adoption process. There are many ESB & Broker products introduced that are expected to introduce loose coupling by placing intermediary that handles integration concerns between business applications.
Some of the commercial products are:
1. IBM WebSphere Message Broker, Websphere ESB, WebSphere MQ.
2. TIBCO Businessworks,
3. Webmethods Broker, Integration Server,
4. Oracle Service Bus
5. Sonic ESB, etc
Apart from the commercial products there are open source products and lightweight frameworks that can do the role of ESB's for e.g Mule, Service mix, etc.
Often, I have seen many organizations using the ESB or Integration platforms as Application platforms. This means they use them to build business applications that produces and consumes inter-application messages. This is to me an anti-pattern where Integration platforms are loaded with business logic, complex persistence flows and business decisions. It is a kind of bad-smell in the design of the system and usage. I see following dis-advantages in using this model.
1. The purpose of ESB's is to be an integration middleware, de-coupling producer and consumer applications in many ways.
2. ESB's help induce seperation of concern between Integration-logic and Business-logic. All integration logic is isolated in Integration environment, so that if it changes the change is limited to Integration platform and not applications.
3. ESB's are appropriate for connectivity, translations, enrichment's and validations in the context message processing. When we start putting applications and business logic inside ESB, then it starts smelling and add more complexity to manage.
4. Most commercial vendors provide message flow framework to write mediators. Sequencing of activities within mediators creates a message processing flow. The flow is created to link the source application to the target application. Adding business logic, entity persistence, rules and decisions, controlling application logic in flows will defeat the purpose of seperation of concerns. Hence it increases rigidity and complexity of applications.
5. ESB's are not made to write applications, where applications need complex persistence mechanism, caching support, data-structure support and other application frameworks.
6. Business applications are best written in good object oriented languages, leveraging application frameworks, containers, management tools etc. For e.g. building order processing engines on Broker or ESB is not good idea as it is defeating ESB's purpose, and not leveraging application frameworks.
7. Applications are best written in OO platforms or frameworks like the Java, dotNet, Ruby on Rails etc.. and deployed on Application Servers like Websphere Application Server, JBoss, Tomcat, etc. The advantages of using OO is huge when written in good abstracted manner, resulting in well defined, modular, maintainable, reusable & component based applications.
I have often seen organizations that use Broker platforms to write applications that processes messages but also host business logic, business entity and persistence of business entities. I find this as anti-pattern. Probable reasons they take this decision are:
1. Immaturity of decision making,
2. Organizations do not spend efforts in evaluation of architectural and platform decisions.
3. Not enough understanding and appreciation of Object oriented platforms.
4. Ivory tower architects making decisions without practical experience on platforms.
5. Not enough experience on Agile, Object oriented principles and processes.
6. Not enough clarity on usage of architectural styles and their fitment.
I would recommend reading following articles to understand fundamentals of ESB style of architecture.
Mark Richards on ESB
Fundamentals of ESB
I do welcome comments on this topic, please write your thoughts..
No comments:
Post a Comment