9 Replies Latest reply on Apr 17, 2015 11:38 AM by laxmanporeddy

    Tooling for JCA Gateway


      Dear tooling magical elves,


      I think I can't fix the detail of outbound (which is for reference binding) in time, so I'd make a wish for inbound one (for service binding) at first.






      <binding.jca xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912/binding-jca">
             <resourceAdapter name="hornetq-ra.rar" type="javax.resource.spi.ResourceAdapter">
                 <property name="foo" value="bar"/>
             <activationSpec type="javax.resource.spi.ActivationSpec">
                 <property name="destinationType" value="javax.jms.Queue"/>
                 <property name="destination" value="queue/GreetingServiceQueue"/>
             <inboundOperation name="onMessage" selectedOperation="onMessage"/>
             <endpoint type="org.switchyard.component.jca.endpoint.JMSEndpoint">
                <property name="jmsEndpointSpecificProp" value="brabra"/>


      We currently have some constant values which is expected to be filled by tooling automatically. I don't have any use-case those paramter should be configurable right now, but it may appear someday.

      • binding.jca/inboundConnection/resourceAdapter/@type
      • binding.jca/inboundConnection/activationSpec/@type
      • binding.jca/inboundInteraction/inboundOperation/@selectedOperation - just same value as @name attribute


      And the options should be configured are here:

      • binding.jca/inboundConnection/resourceAdapter/@name - File name of resource adapter archive. User needs to fill it manually.
      • binding.jca/inboundConnection/resourceAdapter/property - Any number of name/value type String property may be supplied. It doesn't used right now though - we actually need is activationSpec/property
      • binding.jca/inboundConnection/activationSpec/property - Any number of name/value type String property may be supplied.
      • binding.jca/inboundInteraction/listener - FQN of the Endpoint interface. endpointClass should implement this interface.
      • binding.jca/inboundInteraction/inboundOperation - Operation name to be invoked on the listener and endpointClass. So if the listener has just one public method, then that's the one for this inboundOperation.
      • binding.jca/inboundInteraction/endpointClass
      • binding.jca/inboundInteraction/endpoint/@type - FQN of the Endpoint implementation class. We have 2 built-in Endpoint, JMSEndpoint and CCIEndpoint. These 2 have corresponding listener and inboundOperation, so if we can choose from list of 2 and then the listener, inboundOperation and endpointClass are filled automatically, that would be great otherwise, application developer should implement custom endpoint class for their specific EIS according to its resource adapter. The endpoint class must extends org.switchyard.component.jca.endpoint.AbstractInflowEndpoint class.
      • binding.jca/inboundInteraction/endpoint/property - Any number of name/value type String property may be supplied.
      • binding.jca/inboundInteraction/transacted - boolean value to indicate whether transaction is needed by endpoint or not. True by default.


      endpoint mapping is here:

      • JMSEndpoint
        • listener: javax.jms.MessageListener
        • inboundOperation: onMessage
        • endpointClass: org.switchyard.component.jca.endpoint.JMSEndpoint
      • CCIEndpoint
        • listener: javax.resource.cci.MessageListener
        • inboundOperation: onMessage
        • endpointClass: org.switchyard.component.jca.endpoint.CCIEndpoint



      Please let me know if there is any unclear point or something.





      Message was edited by: Tomohisa igarashi - needed to change endpointClass element into endpoint element to support property

        • 1. Re: Tooling for JCA Gateway

          forgot to say...


          Return type of the inboundOperation method indicates whether the Exchange should be IN_ONLY/IN_OUT - so if it's void then IN_ONLY, otherwise IN_OUT.

          • 2. Re: Tooling for JCA Gateway

            Hey Tomo,


            Does the file pointed to by binding.jca/inboundConnection/resourceAdapter/@name have to be copied into the switchyard project explicitly? I'm guessing it has to be on the project classpath at a minimum.

            • 3. Re: Tooling for JCA Gateway

              Hmm, SwitchYard itself doesn't need RAR file, but need it to be acquired from RAR repository in JBoss AS7. This @name attribute is used to look it up from AS7. So we may have it in src/test/resources to be deployed for the testcase, but it doesn't have to.


              When we use any EIS specific listener interface other than javax.jms.MessageListener and javax.resource.cci.MessageListener, developer should specify their custom Endpoint class, and listener interface as well. In this case, actual RAR file would be helpful to validate the listener interaface filled by developer is actually in RAR file, but it isn't needed. Otherwise, we already have these 2 interface in JavaEE spec and don't need to search it from RAR file

              • 4. Re: Tooling for JCA Gateway

                Though It may be too late for 0.5 release, posting outbound stuff for next.






                a bit noisy but many of them are optional.

                <binding.jca xmlns="urn:switchyard-component-jca:config:1.0">


                        <resourceAdapter name="hornetq-ra.rar">

                            <property name="prop1" value="value1"/>


                        <connection jndiName="java:/JmsXA">

                            <property name="prop2" value="value2"/>





                            <property name="prop3" value="value3"/>


                            <property name="prop4" value="value4"/>



                        <processor type="org.switchyard.component.jca.processor.JMSProcessor">

                            <property name="destination" value="TestQueue"/>





                quickstart for JCA JMS outbound binding



                Required elements/attribute for all processors

                • binding.jca/outboundConnection/resourceAdapter/@name - The name of RAR archive which should be deployed on application server
                • binding.jca/outboundConnection/connection/@jndiName - The JNDI name of ConnectionFactory
                • binding.jca/outboundInteraction/processor/@type - FQN of implementation class which processes outbound delivery. This class should be a subclass of org.switchyard.component.jca.processor.AbstractOutboundProcessor. There are JMSProcessor and CCIProcessor at this moment. (JDBCProcessor may be the next if a nice way to handle ResultSet comes to my mind... anyway)


                These are generic name/value type property which can be ommitted. for example, JMSProcessor only needs binding.jca/outboundInteraction/processor/property/@name="destination"

                • binding.jca/outboundConnection/resourceAdapter/property
                • binding.jca/outboundConnection/connection/property
                • binding.jca/outboundInteraction/connectionSpec/property
                • binding.jca/outboundInteraction/interactionSpec/property
                • binding.jca/outboundInteraction/processor/property






                Message was edited by: Tomohisa igarashi - moved "destination" property from interactionSpec to processor. JMSProcessor no longer need both of connectionSpec and interactionSpec.

                • 5. Re: Tooling for JCA Gateway

                  Here's what I've been working on for the UI for inbound and outbound:




                  Any feedback?

                  • 6. Re: Tooling for JCA Gateway

                    beautiful! I love that I feel like this is it at this moment.

                    • 7. Re: Tooling for JCA Gateway

                      Thanks Tomo! I'll try and finish it up today so it's ready to go whenever Keith is ready to pull all the JCA stuff in.

                      • 8. Re: Tooling for JCA Gateway

                        Ok, I've pushed to the SWITCHYARD-864b branch in tools so this code is ready whenever we are ready to pull all the JCA updates in. Support for both JCA inbound and JCA outbound bindings are included.

                        • 9. Re: Tooling for JCA Gateway

                          Tom, I am looking for example for IBM MQ and switchyad ( switch yard application that takes message from MQ queue and put response into another MQ queue)  . Can you please provide any steps and any useful links ?