Skip to end of metadata
Go to start of metadata

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:

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details.
  • inboundConnection
    • resourceAdapter
      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.
    • activationSpec
      • property : Properties to be injected into ActivationSpec instance. Required properties are specific to the ResourceAdapter implementation.
  • inboundInteraction
    • listener : FQN of the listener interface. When you use JMSEndpoint, javax.jms.MessageListener should be specified. When you use CCIEndpoint, javax.resource.cci.MessageListener should be specified. Otherwise, you may need to specify EIS specific listener interface according to its ResourceAdapter. Note that the endpoint class should implement this listener interface.
    • endpoint
      • @type : FQN of the Endpoint implementation class. There are 2 built-in Endpoint, org.switchyard.component.jca.endpoint.JMSEndpoint and org.switchyard.component.jca.endpoint.CCIEndpoint. Note that these 2 have corresponding listener. If neither JMSEndpoint nor CCIEndpoint is applicable for the EIS you're supposed to bind to, then you need to implement its own Endpoint class according to the ResourceAdapter implementation. The Endpoint class should be a subclass of org.switchyard.component.jca.endpoint.AbstractInflowEndpoint.
      • property : Properties to be injected into Endpoint class. See "Endpoint Properties" for more detail.
    • transacted : The boolean value to indicate whether transaction is needed by endpoint or not. True by default.
    • batchCommit : Multiple incoming messages are processed in one transaction if you define this element. The transaction is committed when the number of processed messages reach to batchSize, or batchTimeout milliseconds pass since the transaction is started. Transaction reaper thread is watching inflight transaction, and once batch timeout occurs the transaction reaper thread commits it.
      • @batchSize : The number of messages to be processed in one transaction
      • @batchTimeout : The batch timeout in milliseconds


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
    • connectionFactoryJNDIName : JNDI name of CCI ConnectionFactory

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:


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
      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.
    • connection
      • @jndiName : JNDI name which the ConnectionFactory is bound into.
  • outboundInteraction
    • connectionSpec : Configuration for javax.resource.cci.ConnectionSpec. Note that JMSProcessor doesn't use this option.
      • @type : FQN of the ConnectionSpec implementation class.
      • property : Properties to be injected into ConnectionSpec instance. 
    • interactionSpec : Configuration for _javax.resource.cci.InteractionSpec. _Note that JMSProcessor doesn't use this option.
      • @type : FQN of the InteractionSpec implementation class.
      • property : Properties to be injected into InteractionSpec instance.
    • 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.IndexedRecordHandlerorg.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:

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.