Archive for the ‘Integration Technlogies’ Category

Canonical Models


I have vested quiet some time  researching on Canonical Models lately. It has caught my attention since I see a lot enterprises drifting towards opting canonical models as a solution for integration needs. It definitively nails the problem down provided applied to the right situations and in the right way.


For a briefer on this subject, we know that a lot of organizations around the world work today by talking to several legacy applications, third party systems, B2B feeds and so on which only grows considering the business and technological enhancements needs. To add on that, all these systems understand their own language, format and data. This brings along various transformations between all the participants, varying models, changes and other booby traps in order to establish a successful communication!

Is there a way to simplify this all? Yes, canonical models is the solution out there for these demanding situations. What are these? How can they be applied? When should they be applied? What sort of analysis should be done? What are the technological and functional requirements? Are there any tools to help ease the entire process? Well, I know the list of questions can only grow.

I have done quiet some research on this and spoke to subject matter experts from various corners from business to technical backgrounds. The end result was quiet convincing and extremely appealing which for sure is no cake walk. I will be publishing a book on this soon. Watch out for the article and let me know what you all would like to see in it?


Evolution of Open-Source Enterprise Service Bus (ESB)

December 31, 2009 2 comments


Evolution of open-source Enterprise Service Bus (ESB):


Developers involved in complex system integration will know how intriguing system integration can get to. Integration of disparate enterprise applications is always challenging because of the need to get them work together. It also has become an increasingly essential element of IT, where we oftenly come across terms such as BI (Business Integration), B2B (Business to Business) etc. A decade earlier, technology choices were limited. Integration of enterprise applications had to chose either an application server or a heavyweight enterprise application integration (EAI) solution that required a huge upfront investment in infrastructure, money, and human resources. There was a need for a lightweight solution which is easy to deploy and manage. Many enterprises at that time, built thier own abstractions on top of thier messaging servers. By doing so, it was an extreme undertaking and a huge burden on the developers.

Since IBM first released MQSeries, enterprises have been sold on the benefits of decoupling systems using point-to-point message queues. When TIBCO brought Rendezvous to the market, it expanded the horizons of messaging by introducing the publish-subscribe model. The Java Message Service (JMS)—born through Sun’s Java Community Process (JCP)—set out to unify the point-to-point and publish-subscribe messaging models. It wasn’t long before enterprises required more than just messaging, they also needed a way to orchestrate messages between systems and perform transformations.

To address this need, major vendors such as IBM, Oracle, and Microsoft built EAI brokers that added message brokering and centralized transformation engines on top of their existing messaging servers. The problem with the EAI approach was that it adopted a hub-and-spoke architecture where all data had to flow through the EAI broker. Although this worked for many applications, enterprises were soon pushing the boundaries of these systems and it became clear that something more flexible, scalable, and distributed was required. Enterprises needed connectivity, transaction management, security, and message routing, and they needed to host services that operated on data moving around their systems.

Working on integration projects used to mean working with enterprise application integration (EAI) products, each of which implemented its own stack of tools with proprietary technology. To switch from one EAI product to another meant learning the proprietary technology and toolset from that new product. With more focus on open standards that emerged in the integration market, the market changed from EAI to service oriented architecture (SOA) and enterprise service bus (ESB) products. Examples of these open standards are Java Message Service (JMS), SOAP, XML, and WS*. With open standards available, more and more open source projects began to implement these specifications.  There was a need for an open source solution built on open standards.

The next step of this evolution led to what is now known as an ESB: Data and exchanges are conveyed from system to system in a single logical bus, decoupling all the systems from each other. This leads to a much more maintainable system and can save a lot of time in the long term. Integration technologies are becoming commodity software, and the rise of open source integration frameworks is hence becoming increasingly important. Open source is now unavoidable, from JMS brokers to SOAP stacks to ESBs. Companies generally use ESBs to convey sensitive data, and they sometimes need advice when they’re developing the applications hosted in the ESBs or when they’re putting these applications in production. The industry needed the ESB. 

Read more…