Tuesday, August 25, 2009

Integration without ESB

Because of unstructured / unplanned development over the years, we have problems because of point-to-point integration between software applications, tight coupling at those integration points, lots of code and fewer configurations.

Based on the no. of applications integrating, no. of integration points will increase. If we have point-to-point integration in all these integration points , the we will have problem in the similar magnitude.

Initially to overcome the problems of Point-To-Point integration, we had Hub & Spoke. It means Integration based on Messages. That is , a Message Broker like MSMQ is used. Different applications connect with each other through Message broker by sending messages. The problem that was encountered here was the single point of failure and also the high volume message handling capability of the Queue become a concern.

Then came the services based integration where SOA played a major role. This type of integration becomes significant especially when there is a need to integrate applications across heterogeneous platforms. Because, there interoperability is the key requirement. ESB played a key role in these types of architectures.

ESB is primarily used for :

1. Schema Transformation / Data Transformation : To Transform Data or Schema of the messages that it sends / receives


2. Intelligent Routing: To intelligently route messages to various service end points depending upon the content of those messages.

3. Service Aggregation: To act as a Fa├žade and make a series of web service calls as a single service. This is based on the pattern “Service Aggregation”. It may also include some conditional logic that defines which of the lower-level web services are called and in which order they are invoked.

4. Load Balancing: To load balance the service requests across different service end points. It may have the provision that at the time of registering a business service, we can specify the list of service end points, which can be changed later by adding or removing end points. Here it provides a layer of abstraction between service client & service provider.

5. Enforcing Security: centralized, standardized security management through security policy framework.

6. Service Management / Monitoring / Logging: Proactive / Reactive monitoring of the services performance.

With the platform vendors are maturing towards offering products that are compatible with the industry standards [especially WS-* like WS-ReliableMessaging ], ESB is gradually loosing it's position in the integration arena !

Saturday, August 15, 2009

Enterprise Agility = Enterprise Asset!

Enterprise Agility – The capability of an Enterprise to respond to the changing market demands in a short span of time, cost effectively. Cost effectiveness is becoming significant in the days where IT is subjected for demands to optimize its operating cost. For an enterprise to accomadate changes cost effectively, it should have built its systems based on pluggable architectures and other elements that ensure agility.

Consider two enterprises A and B. Say for EnterpriseA, for every change it’s should make, it will cost $1000. For EnterpriseB, it is zero dollars. Say for example, every year 10 changes are to be made. For EnterpriseA, it will need $10,000. For EnterpriseB, it will be zero. This $10,000 saving for the EnterpriseB can be considered as an asset!

One dollar saving = One dollar earning!!

Tuesday, August 11, 2009

Domain Model based approach for "Agile" Systems


  • Basically, the imperative to go for either SOA or BPM or BRM based solutions are to keep the systems agile, responsive to the changes in the business.

  • There are multiple factors that could impact either Business Rules or Business logics like market conditions, reulatory requirements etc. To insulate the systems from the consequences of those changes, they are built to have loose coupling

  • Loose coupling is achieved through different techniques. Service enabling a system assure loose coupling for which systems are built based on SOA. Declarative business rules through BRMs or dynamic business processess through BPM systems are other available techniques.

  • Extracting out the business rules from the application logic through BRM is another technique.

  • An addition to SOA/BPM/BRM based approaches, one of the available approach that will bring “Agility” as a default capability to a system is “Domain Model” based development.

  • In the cases where behaviours of the business is subject to lot of changes, having a domain model will decrease total cost of those changes. Having all the behaviours of business (that is likely to change) encapsulated in a single part of the software (domain model) decreases the amount of time we need to perform the change because it all will be performed at one place. This will avoid duplication of business logic / business rule.