In modern IT business applications don't live in isolation (most part of them at least). Different applications implemented with different technologies and using several different protocols, different data formats and different interfaces need to be connected in a single integrated solution. Today every IT company has to deal with this matter. A group of patterns (EIP) exists (http://www.eaipatterns.com/toc.html) to help implementing Enterprise Application Integration (EAI) following standards. In order to reach full EAI through this patterns, 3 ways are possible:
Using an ESB could add complexity to you solution: the ESBs available in the market (commercial and Open Source) provide a lot of other features that you don't really need if your goal is EAI only and often the learning curve of these products is really high.
So the best way in most part of the cases is to use an integration framework. These frameworks are lightweight, provide an implementation of all the EIPs, help to build an integration solution in a standard way without reinveting the wheel and have a very low learning curve. At present time there are three available great Open Source alternatives: Apache Camel, Spring Integration and Mule ESB. I found Apache Camel (https://camel.apache.org/) very easy to use. In particular I like the possibility to use the DSL it provides in Java and Groovy (the two languages I am mainly focused on in these last years, but they are not the only two supported by the Camel DSL) contexts. Furthermore it provides components for almost every technology available (HTTP, JMS, JMX, SMTP, JDBC, FTP, SIP, XMPP and many others) and it is easy any way to implement a custom component for a missing one. You can use Camel standalone, in a Servlet container, in a J2EE application server or in an OSGI context. But you can also start a Camel Context through a single Java class or a simple Groovy script (http://googlielmo.blogspot.ie/2014/05/execute-small-esb-with-groovy.html). Apache Camel provides also a lot of other interesting features like support for automate testing, support for transactions and concurrency, advanced transactional and not transactional error handling. Ultimately a choice that has met all my needs in terms of integration so far.
- Implement your own custom solution.
- Use a lightweight integration framework.
- Use an existing Enterprise Service Bus (ESB).
Using an ESB could add complexity to you solution: the ESBs available in the market (commercial and Open Source) provide a lot of other features that you don't really need if your goal is EAI only and often the learning curve of these products is really high.
So the best way in most part of the cases is to use an integration framework. These frameworks are lightweight, provide an implementation of all the EIPs, help to build an integration solution in a standard way without reinveting the wheel and have a very low learning curve. At present time there are three available great Open Source alternatives: Apache Camel, Spring Integration and Mule ESB. I found Apache Camel (https://camel.apache.org/) very easy to use. In particular I like the possibility to use the DSL it provides in Java and Groovy (the two languages I am mainly focused on in these last years, but they are not the only two supported by the Camel DSL) contexts. Furthermore it provides components for almost every technology available (HTTP, JMS, JMX, SMTP, JDBC, FTP, SIP, XMPP and many others) and it is easy any way to implement a custom component for a missing one. You can use Camel standalone, in a Servlet container, in a J2EE application server or in an OSGI context. But you can also start a Camel Context through a single Java class or a simple Groovy script (http://googlielmo.blogspot.ie/2014/05/execute-small-esb-with-groovy.html). Apache Camel provides also a lot of other interesting features like support for automate testing, support for transactions and concurrency, advanced transactional and not transactional error handling. Ultimately a choice that has met all my needs in terms of integration so far.
Comments
Post a Comment