Consider messaging integration framework in your architecture

Lately I have been dealing with a new architectural design for my company.

The main target was having all components in the same JVM.

Those components suppose to communicate with each other and the “outside” world, according to many different interfaces.

After planning and drawing all the participating components and connections, I decide to have a completely loose coupling integration.

No more procedure calls/Ejb calls/DI calls/ or any restricting call what so ever.

Each time I used those “dependent” calls I found myself struggling with it in the future.

So I chose to adapt myself a messaging framework.

After reading and researching on the net, I found two attractive messaging frameworks: Apache Camel, Spring-Integration. But since a big part of my project is on Spring, I decided to try “Spring-Integration”.

Think about having an engine, which is completely decoupled from your business logic. That engine gives you the ability to have your business component integrated without being “aware” to each other completely!!

Moreover it will be easier to test or change the entire enterprise framework if needed. Business logic components should concentrate on their business logic completely.

You get out of the box integration patterns tools like: aggregators, splitters, network adaptors, filters which make your integration task very easy and useful.

Let’s not forget the boilerplate code you earn – makes your code very clear and efficient.

So I started to play with Spring-Integration and I found my architecture’s components being very independent and clear in many aspects.

Hope you find it useful as I did,

Idan.

 

Related Articles:

(1328)