The JCA gateway allows you to send and receive messages to/from EIS via JCA ResourceAdapter.
Binding Services with JCA message inflow
Composite-level services can be bound to a EIS with JCA message inflow using the <binding.jca> binding definition. The following configuration options are required for binding.jca:
Endpoint Properties
The build-in endpoints JMSEndpoint and CCIEndpoint has following configurable properties.
-
JMSEndpoint : Note that all the properties for this endpoint is to perform IN_OUT MEP. JCA JMS message inflow is generally IN_ONLY, but if you set these properties, JMSEndpoint sends reply or fault message back in return for inflow message.
-
connectionFactoryJNDIName : JNDI name of JMS ConnectionFactory
-
jndiPropertiesFileName : Name of the JNDI properties file
-
destinationType : Destination type of replyTo/faultTo. Possible values are Queue, Topic and JNDI deprecated. We recommend to use Queue or Topic and specify physical name
-
replyTo : Name of the replyTo destination
-
faultTo : Name of the faultTo destination
-
messageType : Type of the message. Possible values are Text, Object, Bytes, Map, Stream and Plain. Object message is used by default.
-
userName : User name
-
password : password
-
destinationJndiPropertiesFileName
-
CCIEndpoint
required property
Dynamic property configuration
Some of JMSEndpoint properties are configurable via context property. You can override those properties with specifying corresponding context property.
JMSEndpoint property name
|
Context property name
|
destinationType
|
org.switchyard.component.jca.endpoint.destinationType
|
replyTo
|
org.switchyard.component.jca.endpoint.replyTo
|
faultTo
|
org.switchyard.component.jca.endpoint.faultTo
|
messageType
|
org.switchyard.component.jca.endpoint.messageType
|
Here's an example of what a JCA service binding looks like. This example binds a service to the HornetQ JMS:
<sca:composite name="JCAInflowExample" targetNamespace="urn:userguide:jca-example-service:0.1.0">
<sca:service name="JCAService" promote="SomeService">
<jca:binding.jca>
<selector:operationSelector operationName="onMessage"/>
<jca:inboundConnection>
<jca:resourceAdapter name="hornetq-ra.rar"/>
<jca:activationSpec>
<jca:property name="destinationType" value="javax.jms.Queue"/>
<jca:property name="destination" value="ServiceQueue"/>
</jca:activationSpec>
</jca:inboundConnection>
<jca:inboundInteraction>
<jca:listener>javax.jms.MessageListener</jca:listener>
<jca:endpoint type="org.switchyard.component.jca.endpoint.JMSEndpoint"/>
<jca:transacted>true</jca:transacted>
<jca:batchCommit batchSize="10" batchTimeout="5000"/>
</jca:inboundInteraction>
</jca:binding.jca>
</service>
<!-- sca:component definition omitted -->
</sca:composite>
Binding References with JCA outbound
Composite-level references can be bound to a EIS with JCA outbound using the <binding.jca> binding definition. The following configuration options are required for binding.jca:
-
outboundConnection
-
resourceAdapter
-
connection
-
outboundInteraction
-
connectionSpec : Configuration for javax.resource.cci.ConnectionSpec. Note that JMSProcessor doesn't use this option.
-
interactionSpec : Configuration for _javax.resource.cci.InteractionSpec. _Note that JMSProcessor doesn't use this option.
-
processor
-
@type : FQN of the class which processes outbound delivery. There are 2 build-in processor, org.switchyard.component.jca.processor.JMSProcessor and org.switchyard.component.jca.processor.CCIProcessor. JMSProcessor just sends a message to the JMS provider, so it only supports IN_ONLY MEP. CCIProcessor sends a input record and return a output record which is returned by the EIS. If neither JMSProcessor nor CCIProcessor is applicable for the EIS you're supposed to bind to, then you need to implement its own processor class according to the ResourceAdapter implementation. Note that this class should be a subclass of org.switchyard.component.jca.processor.AbstractOutboundProcessor.
-
property : Properties to be injected into processor instance. See "Processor Properties" for more detail.
If the ConnectionFactory and JMS destination need to be looked up from remote JNDI provider, you can add JNDI properties file into your SwitchYard application and specify its file name with jndiPropertiesFileName property. If the ConnectionFactory and JMS Destination should be looked up from different JNDI provider, you can specify both of jndiPropertiesFileName and destinationJndiPropertiesFileName to point distinct JNDI properties file. JNDI destination lookup is deprecated. We recommend to specify Queue or Topic for destinationType and specify physical name for destination name
You can specify the message type to be sent with messageType property. Available values are Stream for StreamMessage, Map for MapMessage, Text for TextMessage, Object for ObjectMessage, Bytes for BytesMessage and Plain for Message with no payload (headers and properties only). ObjectMessage is used by default.
Processor Properties
The build-in processors JMSProcessor and CCIProcessor has following configurable properties.
-
JMSProcessor
-
connectionFactoryJNDIName : JNDI name of JMS ConnectionFactory
-
jndiPropertiesFileName : Name of the JNDI properties file
-
destinationType : Destination type. Possible values are Queue, Topic and JNDI deprecated. We recommend to use Queue or Topic and specify physical name
-
destination : Name of the destination
-
messageType : Type of the message. Possible values are Text, Object, Bytes, Map, Stream and Plain. Object message is used by default.
-
username : User name
-
password : password
-
destinationJndiPropertiesFileName deprecated
-
acknowledgeMode deprecated
-
transacted deprecated
-
CCIProcessor
-
connectionFactoryJNDIName : JNDI name of CCI ConnectionFactory
-
recordClassName : Name of the record record type to be used to interact with EIS. If you use CCIProcessor with the record type other than MappedRecord IndexedRecord or StreamableRecord, you need to implement corresponding RecordHandler. Please refer to org.switchyard.component.jca.processor.cci.IndexedRecordHandler, org.switchyard.component.jca.processor.cci.MappedRecordHandler and org.switchyard.component.jca.processor.cci.StreamableRecordHandler.
required property
Dynamic property configuration
Some of JMSProcessor properties are configurable via context property. You can override those properties with specifying corresponding context property.
JMSProcessor property name
|
Context property name
|
destinationType
|
org.switchyard.component.jca.processor.destinationType
|
destination
|
org.switchyard.component.jca.processor.destination
|
messageType
|
org.switchyard.component.jca.processor.messageType
|
Here's an example of what a JCA reference binding looks like. This example binds a reference to the HornetQ JMS:
<sca:composite name="JCAReferenceExample" targetNamespace="urn:userguide:jca-example-reference:0.1.0">
<sca:reference name="JCAReference" promote="SomeComponent/SomeReference" multiplicity="1..1">
<jca:binding.jca>
<jca:outboundConnection>
<jca:resourceAdapter name="hornetq-ra.rar"/>
<jca:connection jndiName="java:/JmsXA"/>
</jca:outboundConnection>
<jca:outboundInteraction>
<jca:processor type="org.switchyard.component.jca.processor.JMSProcessor">
<jca:property name="destinationType" value="Queue"/>
<jca:property name="destination" value="ReferenceQueue"/>
<jca:property name="messageType" value="Text"/>
</jca:processor>
</jca:outboundInteraction>
</jca:binding.jca>
</sca:reference>
</sca:composite>