Integration Framework Comparison

Messaging Integration Framework

Comparison

1      Introduction

1.1    Purpose of the Document

Evaluate the different messaging integration frameworks which are commonly used in communication with messaging providers.

1.3    Conventions

• Boxes with grey background are used for examples description, bold underlined words is meant to highlight the important parts of the example.

 Example box, underlined section, rest of the example.

1.4    Definitions, Acronyms and Abbreviations

Acronym / Abbreviation	Description
MDB	Message driven bean
Oracle AQ	Oracle advanced queue
JMS	Java Messaging Service
EJB	Enterprise Java Bean

2  POC Scope

2.1    Scenarios

 The messaging framework should fulfill the following function scenarios requirements,

• Sending JMS messages to a queue based on a configured connection factory and destination.

• Out of the box support for XML messages: As XML message type is not supported by default in JMS as a message type, support for sending/receiving XML message by using the framework is one of the required features.

• Receiving JMS messages by a configurable pool of receivers.

• Select received messages based on criteria.

• Support for transaction management.

• Support for both synchronous and asynchronous messaging.

• Support for synchronous messaging using temporary queue: this technique reserve the system resources because there is no need to maintain a permanent queue for the reply in the system.

• Support for synchronous messaging with optional response.

• Handle secure messages transportation by encrypting the message body.

3      Approach

3.1    Tools & Technology

In this POC we’re going to shortlist from the following techniques of handling messaging requirements to only three options to be evaluation,

3.1.1    Frameworks List

• EJB3 by Oracle OC4J 10.x implementation.

• Spring Integration project: handle integration part of Spring project.

• Standalone JMS APIs: is a basic way of handling messages, most of the other options are depending on this APIs underneath, so it will not be evaluated here.

• Oracle BPEL JMS adapters, not to be evaluated due to dependency on Oracle SOA suit.

• Oracle proprietary messaging APIs: this is not standard APIs, subject to unexpected changes with server upgrades, is not commonly used or well known, and works only with Oracle AQ, so it will be excluded from this POC.

• Oracle BPEL AQ adapter: Depends on Oracle proprietary APIs, will be excluded for the same reasons.

• Oracle ESB JMS adapters: there is no available ESB in the current technology stack; this option will be excluded as well.

• Apache Camel: an open source integration framework which can be plugged and used from within Spring framework.

3.1.2    Selected candidates

The final list to be evaluated is as follows,

• Apache Camel v 2.4.

• Spring integration project v1.0.4.

• EJB3 by Oracle OC4J 10.x implementation.
  

3.2    Overview

In this section I will provide a brief overview about the selected candidates.

3.2.1    Apache Camel v2.4

Apache Camel is a rule-based routing and mediation engine which provides a Java object based implementation of the Enterprise Integration Patterns using an API (or declarative Java Domain Specific Language) to configure routing and mediation rules. The domain specific language means that Apache Camel can support type-safe smart completion of routing rules in your IDE using regular Java code without huge amounts of XML configuration files; though XML configuration inside Spring is also supported.

At the core of the Camel framework is a routing engine, or more precisely a routing-engine builder. It allows you to define your own routing rules, decide from which sources to accept messages, and determine how to process and send those messages to other destinations. Camel uses an integration language that allows you to define complex routing rules, akin to business processes.  

For more information please visit http://camel.apache.org/

3.2.2    Spring integration project v1.0.4

Spring Integration is a new addition to the Spring portfolio. It provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns while building on the Spring Framework's existing support for enterprise integration. It enables simple messaging within Spring-based applications and integrates with external systems via simple adapters. Those adapters provide a higher-level of abstraction over Spring's support for remoting, messaging, and scheduling. Spring Integration's primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.

For more information please visit http://www.springsource.org/spring-integration

3.2.3  EJB 3

Enterprise JavaBeans (EJB) is a platform for building portable, reusable, and scalable business applications using the Java programming language. Since its initial releases, EJB has been touted as a component model or framework that lets you build enterprise Java applications without having to reinvent services such as transactions, security, automated persistence, and so on that you may need for building an application. EJB allows application developers to focus on building business logic without having to spend time on building infrastructure code.

There are three types of EJB components: session beans, message-driven beans, and entities. Session beans and message-driven beans are used to implement business logic in an EJB application, and entities are used for persistence.

For more information please visit http://www.oracle.com/technetwork/java/index-jsp-140203.html

3.3    Evaluation criteria

Each of the selected three frameworks is going to be evaluated based on selected criterions, by the end of the execution of the POC the frameworks will be compared between each other based on the differences represented by fully, partial, or failed to support the required features; the following are the required features,

1. The Framework satisfies the specified functional scenarios mentioned in section 2.1.

2. Ease of Development: evaluated based on the following points,

• Availability of plug-ins or code generators to help in speed up development if any.
• Handle of the transaction management by the framework.
• Support annotations and dependency injection.
• Support for the known EAI patterns.
• Implicit Type conversion between message types and the corresponding Java objects.
• Minimal number of lines of code required for the provider, receiver, and configuration.

3. Scalability: each framework will be evaluated against the following points,

• Framework allows configurable pool of receivers.
• Framework support for clustering and load balancing.

4. Maintainability: evaluation against the following points

• Is standard APIs.
• Platform independent.
• Support for the latest JEE versions.
• Active community in case of open source, standard APIs will pass in this point as active community.
• Available support from Oracle as a vendor for the platform, for example problems in EJB3 running on OC4J is supported by Oracle support team.
• Documentation is available and easy to follow.

5. Security: scores if the technology supports the following points, one for each,

• Secured message send and receive (authentication/authorization).
• Secured message transportation (Encryption/Decryption).

Performance will not get considered in the evaluation because it depends on the vendors and the set of requirements under testing, there are many factors affecting the performance, thus a performance evaluation would be unpractical to use in selecting one of the frameworks.

4      POC Outcome

4.1    Apache Camel v2.4

4.1.1Functional scenarios,

Sending JMS messages to a queue based on a configured connection factory and destination. Fully

Note

In Spring applicationContext.xml define the connection factory and destination as follows.

<jee:jndi-lookup id="myQueue" jndi-name="java:comp/resource/Test_AQ/Queues/myQueue"/>

     <jee:jndi-lookup id="myConnectionFactory" jndi-name="java:comp/resource/Test_AQ/QueueConnectionFactories/queueCF"/>

·         Out of the box support for XML messages. Fully

Note

Camel supports automatic conversion from XML objects to JMS text messages, Camel also supports data conversion from text to XML on the receiver side, and from object to XML on the provider side by using Camel DataFormat components, e.g. to Marshall a Java object using Camel’s JaxbDataFormat,

JAXBContext jci = JAXBContext.newInstance(MessageBody.class);

DataFormat jaxb = new JaxbDataFormat(jci);

ByteArrayOutputStream baos = new ByteArrayOutputStream();

jaxb.marshal(exchng, mb, baos);

To unmarshall the object again using Camel processors in the receiver side,

//Use Camel built in data formatter to convert the XML text message to our Java object. 

JAXBContext jc = JAXBContext.newInstance(MessageBody.class);

DataFormat jaxb = new JaxbDataFormat(jc);

//start routing the message from queue to a bean reference.

from("jms:queue:myQueue).unmarshal(jaxb).beanRef("camelReceiver", receiveMessage")

In the previous example the XML is unmarshalled to the corresponding Java object before sending that object as a parameter to the specified bean method.

·         Receiving JMS messages by a configurable pool of receivers. Fully

Note

Available via configuration, in Spring applicationContext.xml configure the concurrent consumers in the camel JMS component as follows,

<bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration">

    <property name="connectionFactory" ref="myConnectionFactory"/>

    <property name="concurrentConsumers" value="10"/> 

</bean>

·         Select received messages based on criteria. Fully

 Note

Selector property can be defined in the jms component URI while routing the message,

//start routing the message from queue to a bean reference.

from("jms:queue:myQueue?selector=txType='async'")

.unmarshal(jaxb).beanRef("camelReceiver", "receiveMessage")

Camel also has another feature to dispatch messages based on filtering criteria using message filter pattern, or by using built-in processors, but in this case and unlike selectors the messages will be consumed from the queue, for example to dispatch the message based on XPATH expression

//start routing the message from queue to a bean reference if declaration type element is import or export.

from("jms:queue:myQueue?selector=txType='async'")                

.choice().when().xpath("/messageBody/declarationType[text()='imp' or text()='exp']")

.unmarshal(jaxb).beanRef("camelReceiver", "receiveMessage")

By using XPATH filters you have access to anywhere in the message including header and body data, XPATH filters feature is in Camel only, and there is no corresponding feature in Spring Integration or in EJB3.

Support for transaction management. Fully

 Note

Makes use of Spring JMS transaction manager.

<!—define transaction manage -- >

<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">

    <property name="connectionFactory" ref="myConnectionFactory"/>

</bean>

<!—use the spring transaction manager in jms config -- >

<bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration">

    <property name="connectionFactory" ref="myConnectionFactory"/>

    <property name="transactionManager" ref="jmsTransactionManager"/>

    <property name="transacted" value="true"/>

</bean>

<!—use the conf in Camel jms component -- >

<bean id="jms" class="org.apache.camel.component.jms.JmsComponent">

  <property name="configuration" ref="jmsConfig"/>  

</bean>

For more information please visit http://camel.apache.org/transactional-client.html

Support for both synchronous and asynchronous messaging. Fully

 Note

Camel supports sending both Async and Synchronous JMS messages; this is wrapped in Camel in a high level interface using the Camel Exchange object,

exchange.setPattern(ExchangePattern.InOnly); //for Async

OR,

exchange.setPattern(ExchangePattern.InOut); // for sync

·         Support for synchronous messaging using temporary queue. Fully

Note

Camel handle the creation of temporary queue to send the reply, this technique reserves the system resources because there is no need to maintain a permanent queue for handling the replies in the system.

Support for synchronous messaging with optional response. Fully

Note

In the Camel exchange object the exchange pattern can be set to inOptionalOut, in this case the client will not get time out error in case the response is missing.

exchange.setPattern(ExchangePattern.InOptionalOut); // for sync with optional out

·         Handle secure messages transportation by encrypting the message body. Fully

 Note

 Camel offers encryption/decryption components to secure payloads or selectively apply encryption/decryption capabilities on portions/sections of a payload, Camel also supports communication with secured end points; example, to decrypt a message secured by apache security package,

from("jms:queue:myQueue?selector=txType='sync'")

.unmarshal().secureXML()

For more information (check http://camel.apache.org/security.html,)

4.1.2    Ease Development,

·         Plug-in helps in code generation if any, Fail

Note, no available plug-ins for Camel development.

·         Handle of transactions management by the framework, Fully

Note, depends on Spring framework transaction.

·         Support annotations and dependency injection as it saves development time. Fully

  Note

 Camel supports dependency injection and has support for automatic package discovery, for example,

<camel:camelContext id="camel" >  

    <camel:package>com.dc.poc.camel</camel:package>    

</camel:camelContext>

In this example Camel will search automatically for classes extend from camel components like routers.

·         Support for EAI patterns. Fully

 Note

Supports the full set of EAI patterns as built in processors, for example the message routing and message filter pattern is applied as follows,

//start routing the message from queue to a bean reference if declaration type element is import or export.

from("jms:queue:myQueue?selector=txType='async'")               

.choice().when().xpath("/messageBody/declarationType[text()='imp' or text()='exp']")

.unmarshal(jaxb).beanRef("camelReceiver", "receiveMessage")

For information about the EAI support http://camel.apache.org/enterprise-integration-patterns.html)

·         Implicit Type conversion between message types and the corresponding Java objects. Fully

Note

Camel supports implicit type conversions like converting XML Node object to a text message while sending the message, for full mapping list please visit http://camel.apache.org/jms.html

·         Minimal number of lines of code required for the provider, receiver, and the configuration. Fully

Note

Provider: 120, Apache Camel didn’t give much attention to the provider side as it gave in the receiver side, like enabling DSL language in provider for example, that would reduced the required lines of code.

Receiver: 74

Configuration: 43

4.1.3    Scalability:

·         Framework allows configurable pool of receivers. Fully

Note, Camel JMS component can be configured for the number of concurrent   consumers, (check the previous points of the functional scenarios for the sample configuration)

·      Framework support for clustering and load balancing. Fully

Note, Camel has support for clustered environment with existing load balancing component for load balancing different end points, (for more information check http://camel.apache.org/clustering-and-loadbalancing.html) (and check http://camel.apache.org/load-balancer.html)

4.1.4    Maintainability:

·        Standard APIs, FAIL.

·    Platform independent. Fully

·    Support for the latest JEE versions Fully

·   Active community in case of open source, standard APIs will pass in this point as active community. Fully

·   Available support from Oracle as a vendor for the platform FAIL

Note

Camel provides only charged support like any other open source framework.

·       Documentation is available and easy to follow. Partial

Note

Free documentation is neither well organized nor easy to follow, but commercial documentation is available and clear to follow.

4.1.5   Security:

·      Secured message send and receive. Fully

Note

 Camel support JAAS security model for JMS components.

·   Secured message transportation. Fully

Note

 Camel provide XMLSecurity component to encrypt and decrypt messages as shown previously in the functional scenarios.

4.2   Spring integration v1.04

4.2.1    Functional scenarios,

·         Sending JMS messages to a queue based on a configured connection factory and destination. Fully.

      Note

   In the Spring applicationContext.xml define the connection factory and destination as follows

<jee:jndi-lookup id="myQueue" jndi-name="java:comp/resource/Test_AQ/Queues/myQueue"/>

     <jee:jndi-lookup id="myConnectionFactory" jndi-name="java:comp/resource/Test_AQ/QueueConnectionFactories/queueCF"/>

·     Out of the box support for XML messages. Fully

                   Note

    Spring Integration supports data conversion from object to XML text and from XML text back to Java object using Spring Integration Transformer handlers, in Spring applicationContext.xml file define the transformers as following,

<chain input-channel="receiverChannel">   

      <si-xml:unmarshalling-transformer id="defaultUnmarshaller" unmarshaller="unmarshaller" />
 <service-activator ref="ReceiverSpringInt" method="receiveMessage" />    

 </chain>

In this example the XML text will be unmarshalled to the Java object by the transformer and then pass the object as a parameter to the method in the referenced bean.

For more info please visit, http://static.springsource.org/spring-integration/reference/htmlsingle/spring-integration-reference.html#transformer) .

·       Receiving JMS messages by a configurable pool of receivers. Fully

      Note

   Available via configuration in Spring applicationContext.xml, define the inbound gateway with number of concurrent consumers as follows,

<jms:inbound-gateway id="jmsInGateway" auto-startup="true" concurrent-consumers="10" acknowledge="transacted" connection-factory="myConnectionFactory"

      transaction-manager="jmsTransactionManager" request-destination="myQueue"  request-channel="receiverChannel" />

·         Select received messages based on criteria. FAIL

                  Note

   Selector property is not supported in the current version of Spring Integration 1.4 for the inbound gateway definition.

·  Support for transaction management. Fully

                   Note

    In Spring applicationContext.xml you can define the spring transaction manager bean as follows,

<beans:bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">

Then pass the transaction manager to the channel adapter as follows,

<jms:inbound-gateway id="jmsInGateway" acknowledge="transacted" connection-factory="myConnectionFactory"

      transaction-manager="jmsTransactionManager" request-destination="myQueue" request-channel="receiverChannel" />

·        Support for both synchronous and asynchronous messaging. Fully

Note

 If the targeted method in the receiver bean returns a value, the inbound gateway will try to send a reply on the specified reply channel.

<chain input-channel="syncChannel">

        <si-xml:unmarshalling-transformer id="defaultUnmarshaller" unmarshaller="unmarshaller"/>
      <service-activator ref="ReceiverSpringInt" method="receiveSyncMessage"/>    

</chain>

            In the previous snippet the method receiveSyncMessage returns a String value.

·         Support for synchronous messaging using temporary queue. Fully

Note

If no reply channel specified as in the previous configuration, Spring Integration automatically handles the creation of temporary queue to send the reply, this technique reserves the system resources because there is no need to maintain a permanent queue for reply in the system.

·         Support for synchronous messaging with optional response. FAIL

Note

Spring Integration doesn’t have a configuration for supporting optional response, thus you have to write extra configuration for a router to direct the message to the right channel with either Sync or A Sync service activator.

<router>

      <beans:bean id="myHeaderValueRouter" class="org.springframework.integration.router.HeaderValueRouter">

      <beans:constructor-arg value="txType" />

      <beans:property name="channelResolver">

      <beans:bean class="org.springframework.integration.channel.MapBasedChannelResolver">

         <beans:property name="channelMap">

            <beans:map>

              <beans:entry key="sync" value-ref="syncChannel" />

              <beans:entry key="async" value-ref="aSyncChannel" />

            </beans:map>

          </beans:property>

       </beans:bean>

     </beans:property>

   </beans:bean> 

</router>

·         Handle secure send and receive of the messages by encrypting the message body. FAIL

Note

              There is no component in Spring Integration to handle message content encryption.

4.2.2    Ease of Development,

·        Plug-in helps in code generation if any, Fully

 Note

Tools like springsource-tool-suite, and other plugins available for configuration generation using wizards.

·       Handle of transactions by the framework, Fully

Note

Spring framework provides a transaction manager implementation.

·         Support annotations and dependency injection as it saves development time. Fully

Note

 All types of end points can be defined by annotation.

·        Support for EAI patterns. Partial

Note

Spring Integration has built in support for partial set of EAI patterns, for example message filter pattern has no implementation to XPATH filter, or header based filter, also pattern like load balancer has no implementation in the framework (Camel has allot more built in implementation for the EIP).

·         Implicit Type conversion between message types and the corresponding Java objects. FAIL

Note

No such support in the Spring integration; explicit transformers should be configured for the type conversion.

·      Minimal number of lines of code required for the provider, receiver, and the configuration. Fully

Note

Spring has the least required line of codes but much longer configuration is required.

Provider: 64.

Receiver: 32.

Configuration: 93.

4.2.3   Scalability:

·        Framework allows configurable pool of receivers. Fully

Note

Spring Integration JMS inbound gateway component can be configured for the number of concurrent consumers, for example,

<jms:inbound-gateway id="jmsInGateway" concurrent-consumers="10"  connection-factory="myConnectionFactory" transaction-manager="jmsTransactionManager" request-destination="myQueue"  request-channel="receiverChannel" />

·       Framework support for clustering and load balancing. Partial

Note

Spring Integration can work on clustered environment, but unlike Apache Camel, Spring Integration does not provide component to implement the Load balancer integration pattern (for more info, Spring integration forum, http://forum.springsource.org/showthread.php?t=67865&highlight=cluster)

4.2.4    Maintainability:

·      Standard APIs, FAIL.

·      Platform independent. Fully

·      Support for the latest JEE versions. Fully

·     Active community in case of open source, standard APIs will pass in this point as active community. Fully

·         Available support from Oracle as a vendor for the platform FAIL

Note

Spring Integration provides only charged type support like any other open source framework.

·        Documentation is available and easy to follow. Fully

Note

Free documentation is well organized and is easy to follow.

4.2.5    Security:

·         Secured message send and receive. Fully

Note

 Spring integration has support for Spring Security component (aka. Acegi) for authentication and authorization.

·     Secured message transportation. FAIL

Note

 There is no current component for message encryption/decryption in the Spring Integration.

4.3    EJB3 by Oracle OC4J 10.x implementation

4.3.1    Functional scenarios

·        Sending JMS messages to a queue based on the configured connection and destination: Fully.

   Note

In any container managed object a resource annotation can be used to inject the connection factory and the required destination, example, in stateless session bean you can define,

@Resource(mappedName = "java:comp/resource/Test_AQ/QueueConnectionFactories/queueCF")

    private QueueConnectionFactory connectionFactory;

@Resource(mappedName = "java:comp/resource/Test_AQ/Queues/MYQUEUE")

    private Queue queue;

·     Out of the box support for XML messages. Partial

                  Note

JEE 5 supports marshalling and unmarshalling of XML messages by using JAXB 2.0 packages, but there is no existing component like in the previous frameworks for direct handling of that transformation; example using JAXB 2.0:

JAXBContext context1 = JAXBContext.newInstance(MessageBody.class);

Marshaller m = context1.createMarshaller();

m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

ByteArrayOutputStream baos = new ByteArrayOutputStream();

m.marshal(mb, baos);   

In that example the Java object will be marshaled to XML text using JAXB 2.0.

·         Receiving JMS messages by a configurable pool of receivers. Fully

    
Note

By using activation property max pool size inside the @MessageDriven definition,

@ActivationConfigProperty(propertyName="MaxPoolSize",propertyValue="50")

·         Select received messages based on criteria. Fully

                  Note

By using messageSelector inside the @MessageDriven activation property definition,

@ActivationConfigProperty (propertyName="messageSelector", propertyValue="(txType = 'async') OR (txType = 'sync')")

·         Support for transaction management. Fully

               Note

    Transaction can be handled by either the EJB container or by the bean managed approach,

@TransactionManagement(TransactionManagementType.BEAN)//to indicates //bean managed transaction, it’s required in case of Sync mode.

·         Support for both synchronous and A synchronous messaging. Fully

    Note

 By using the reply queue message header, the receiver can send reply back to the provider; for Oracle AQ a workaround is required to access the reply queue as in the example below,

logger.info("MESSAGE BEAN: sending reply");

Context cxt = new InitialContext();

Queue replyQueue = (Queue)cxt.lookup("java:comp/resource/Test_AQ/Queues/"+ ((Queue)inMessage.getJMSReplyTo()).getQueueName());

If you tried to use the reply queue directly as in normal scenario using the message.getJMSReplyTo(), a JMS exception will be thrown.

·         Support for synchronous messaging using temporary queue. Partial

 Note

JMS APIs support the creation of temporary queue which lives during the connection time only, after closing the connection these temporary queues are deleted; to use temporary queues with Oracle AQ a workaround is required to re-lookup the queue again using AQ JNDI URL format like in the previous example.

replyQueue = session.createTemporaryQueue();

·         Support for synchronous messaging with optional response. FAIL

 Note

               There is no direct support by using a property or a configuration for optional reply in EJB3.

·         Handle secure send and receive of the messages by encrypting the message body. FAIL

Note

              There is no direct support in EJB 3 by component or configuration to handle message content encryption, but it can be implemented using Java crypto package.

4.3.2    Ease of Development,

·         Plug-in helps in code generation if any, Fully

Note

EJB 3 creation has built in support in eclipse and Jdeveloper.

·       Handle of transactions by the framework, Fully

Note

EJB3 Container can handle the transaction management, also a bean managed transaction is supported.

·         Support annotations and dependency injection as it saves development time. Fully

Note

 Connection factory, destination, and message receivers can be defined by annotation.

·         Support for EAI patterns. FAIL

Note

There is no built in support in EJB3 for EIPs.

·         Implicit Type conversion between message types and the corresponding Java objects. FAIL

Note

              No such support in EJB3, explicit conversion should be written.

·         Minimal number of lines of code required for the provider, receiver, and the configuration. Partial

Note

EJB 3 required the longest lines of code but requires zero configurations.

Provider: 208.

Receiver: 176.

Configuration: 0.

4.3.3    Scalability:

·        Framework allows configurable pool of receivers. Fully

Note

           MaxPoolSize property can be used as shown in the function scenarios section.

·      Framework support for clustering and load balancing. Partial

Note

EJB 3 can be deployed and used in clustered environment, which means that you will deploy the same application on several nodes and in this case, we have competitor consumers. Depending on the load on the servers, messages can be consume by application 1 running on Server 1 instead of application 2 running on Server 2; but there is no dedicated load balancer component like what Apache Camel provides.

4.3.4    Maintainability:

·        Standard APIs: FAIL.

Note

Oracle AS implementation uses a non standard annotation to support EJB3.

.

·        Platform independent: FAIL.

Note

Oracle AS implementation for the EJB3 is not portable.

·       Support for the latest JEE versions: FAIL.

Note

Oracle AS implementation injects the EJB3 specification in J2EE 4 platform.

·      Active community in case of open source, standard APIs will pass in this point as active community: Fully.

·    Available support from Oracle as a vendor for the platform: Fully.

Note

Oracle supports their servers’ implementation of EJB 3.

•    Documentation is available and easy to follow: Fully.

Note

Free documentation is well organized and is easy to follow, allot of commercial documentations are available as well.

4.3.5  Security:

·        Secured message send and receive. Fully.

Note

Secured connection pools can be configured and used by EJB 3.

·    Secured message transportation. FAIL

Note

There is no current component for message encryption in EJB3.

4.4    Summary of the results

Here is a summary comparison for the three options,

Criteria	Apache Camel v2.4	Spring Integration v1.4	EJB3 by Oracle AS 10.x
Select received messages based on criteria.	Fully	Fail	Fully
Note		Selector property is not supported in the current version of Spring Int. 1.4
Support for synchronous messaging with optional response.	Fully	Fail	Fail
Note	Only Apache Camel provides this feature.
Handle secure send and receive of the messages by encrypting the message body	Fully	Fail	Fail
Note	Apache Camel provides two components to secure the messages content.
Support for XML messages.	Fully	Fully	Partial
Note			There is no built in component to handle XML messages in EJB3
Support for synchronous messaging using temporary queues.	Fully	Fully	Partial
Note	Automatic handle in case reply is provided from the receiver.	Automatically handled in case no reply channel is configured.	No automatic handle for temporary queue creation and use.
Support for EAI patterns.	Fully	Partial	Fail
Note	Allot of built in components for full EIP implementation.	Implementation exists but there is no as much components as in Camel.	NA.
Implicit Type conversion between message types and the corresponding Java objects.	Fully	Fail	Fail
Note	In Camel there is implicit mapping between the message body object types and the corresponding message types.
Plug-in helps in code generation if any.	Fail	Fully	Fully
Standard APIs.	Fail	Fail	Fail
Note			Failed because of oracle implementation is not following the standards.
Platform independent	Fully	Fully	Fail
Note			Oracle implementation is not portable to other application servers.
Support for the latest JEE versions	Fully	Fully	Fail
Note			It supports J2EE 4.
Available support from Oracle as a vendor for the platform.	Fail	Fail	Fully
Documentation is available and easy to follow.	Partial	Fully	Fully
Note	Free documentation is neither well organized nor easy to follow.
Minimal number of lines of code and configuration.	Partial	Fully	Fail
Note	Apache Camel didn’t enable DSL language in provider side, which would reduce the required lines of code. Provider: 120, Receiver: 74 Configuration: 43	Spring has the least lines of codes but much longer configuration is required. Provider: 64. Receiver: 32. Configuration: 93	EJB 3 required the longest lines of code but zero configuration. Provider: 208. Receiver: 176. Configuration: 0.
Framework support for clustering and load balancing.	Fully	Partial	Partial
	Camel provides Load balancing and failover components for the endpoints.	No control over load balancing the receivers	No control over load balancing the receivers.

4.5   Conclusion

In case there is a requirement for lengthy process with complex message processing, Apache Camel is the most recommended option because of the following reasons,

·         Provides allot of useful built in processors which implement the full EIP set.

·         The process flow is more coherent and readable in Apache Camel; Spring configuration is less readable and hard to match together as one process flow.

·         Provides more features than Spring like the out of the box message security with two encrypt/decrypt components, optional reply, and the selector property.

In case the requirement is a direct integration between two systems, or the message processing is of moderate complexity, Spring Integration is the recommended approach for the following reasons,

• Learning curve for the Spring Integration is less, especially because most of the development team is already aware about the base Spring framework, thus the required investment is lesser than the one required in case of Apache Camel.

• Spring Integration development is more homogenous with the current Customs’ applications and easier to include with the current code/configuration files.

• Spring Integration provides a good deal of ready made components supporting the EAI patters implementation which is more than enough for a medium complexity process.

EJB 3 by Oracle AS 10.x is not recommended approach as a messaging integration framework for the following reasons,

·         EJB3 provides only the basic features of integration.

·         The poor support of Oracle AS for EJB3; Oracle AS is built over J2EE 4 while EJB3 specification is included only in JEE 5 specification or higher versions, Oracle AS injected the support of EJB 3 in J2EE 4 environment, that was reflected on difficulty of application setup and deployment due to Jars conflict between the two platforms..

·        Oracle had to implement non standard annotations to support EJB3 which made it less portable.

·         It required some workarounds and special annotations to integrate EJB3 with Oracle AQ.

5      Appendix A

5.1    References

• Apache Camel home: http://camel.apache.org/index.html
• Spring Integration reference manual, http://static.springsource.org/spring-integration/reference/htmlsingle/spring-integration-reference.html
• Spring Integration Forum http://forum.springsource.org/forumdisplay.php?f=42
• Manning, Camel In Action Ch1
• Wiley, Mastering Enterprise Java Beans 3.0
• JEE 5 tutorial.