5 Replies Latest reply: Jun 4, 2012 6:03 PM by Tomohisa igarashi RSS

JCA gateway 1st prototype

Tomohisa igarashi Expert

Hi all,

 

I have written a prototype for JCA gateway, only support message inflow at first.

 

Branches

https://github.com/igarashitm/parent/tree/SWITCHYARD-708

https://github.com/igarashitm/core/tree/SWITCHYARD-708

https://github.com/igarashitm/components/tree/SWITCHYARD-708

https://github.com/igarashitm/release/tree/SWITCHYARD-708

 

Configuration model

Almost same as SCA JCA binding. Ommitted some parameters right now though.

http://docs.oasis-open.org/opencsa/sca-bindings/sca-jcabinding-1.1-spec.pdf

And I have added two elements for SwitchYard

  • binding.jca/inboundInteraction/endpointClass: the name of concrete Endpoint class
  • binding.jca/inboundInteraction/transacted: boolean value that indicates the delivery should be transacted or not.

 

Key classes of JCA component

Related Repository: components

  • org.switchyard.component.jca.deploy.InboundHandler: This is the SwitchYard ServiceHandler and also implements JCA MessageEndpointFactory. This performs JCA Endpoint activation and set up the Endpoint proxy to pass to the ResourceAdapter.
  • org.switchyard.component.jca.EndpointProxy: JCA Endpoint proxy implementation. This class sets up the common facilities like transaction, concurrency control, and ClassLoader for actual Endpoint implementation.
  • org.switchyard.component.jca.endpoint.AbstractInflowEndpoint: Base class for the concrete JCA Endpoint implementation.
  • org.switchyard.component.jca.endpoint.JMSEndpoint: A concrete implementation of JCA Endpoint for JMS messaging. We need to set the binding.jca/inboundInteraction/endpointClass configuration parameter as the name of this class to use.

 

Injecting ResourceAdapterRepository from AS7 service

Related Repository: core, release

I have added the addResourceDependency() method on org.switchyard.deploy.Component and inject ResourceAdapterRepository into JCAComponent via SwitchYardComponentService.

 

I'd appreciate if you let me know anything you have noticed. I will add testcases and maybe a quickstart until then.

 

Thanks,

Tomo

  • 1. Re: JCA gateway 1st prototype
    Keith Babo Master

    Awesome, Tomo.  I will take a look at this tomorrow and get feedback to you.

  • 2. Re: JCA gateway 1st prototype
    Keith Babo Master

    Sorry it took so long.  There's a lot to digest here and I'm afraid I've only scratched the surface.  This looks like a great start though, so I'll share the feedback I have and we can go from there.

     

    - The changes to core and release to inject the RA repository are perfect for now, since they are small and do exactly what you need.  I will probably want to develop a more generic mechanism for this, where a component module can be injected with various bits as needed.  For AS7 runtime, this would specified in our subsystem definition in standalone.xml.  No need to worry about this now though.

     

    - Looks like you've borrowed a good deal of code from JBoss ESB on the actual JCA inbound implementation, which is good.  That implementation is rock solid, so there's no reason to change much - just move it forward and adapt it to our component/activator APIs.

     

    - The test cases and quickstart will help a lot in reviewing this at the next level.  It would be good to have a JMS JCA example (this can be the quickstart) and a more general example which likely could be used in unit tests in the component repository.  I believe that IronJacamar has pretty solid unit test and standalone support.  This is important to make sure we honor the various bits of the JCA inflow contract and will also help validate that other (i.e. non JMS) adapters will work.

     

    - Looks like there is some CCI stuff in there right now, which I assume you will use for the oubound (reference binding) support?

     

    - The config model is present, but I did not see a schema.  Do you think we can use the JCA binding spec directly or should we use our own schema definition?

     

    cheers,

    keith

  • 3. Re: JCA gateway 1st prototype
    Tomohisa igarashi Expert

    Thanks for the comment, Keith!

     

    - Looks like you've borrowed a good deal of code from JBoss ESB on the actual JCA inbound implementation, which is good.  That implementation is rock solid, so there's no reason to change much - just move it forward and adapt it to our component/activator APIs.

    Yep, EndpointProxy is a most important infrastructure that is originally come from JBossESB's

     

    - The test cases and quickstart will help a lot in reviewing this at the next level.  It would be good to have a JMS JCA example (this can be the quickstart) and a more general example which likely could be used in unit tests in the component repository.  I believe that IronJacamar has pretty solid unit test and standalone support.  This is important to make sure we honor the various bits of the JCA inflow contract and will also help validate that other (i.e. non JMS) adapters will work.

    Yeah, I'm thinking just now is to cook up the JCAMixIn using Embedded IronJacamar! It will support some basic unit tests.

     

    - Looks like there is some CCI stuff in there right now, which I assume you will use for the oubound (reference binding) support?

    ah, nope, it's just a sample Endpoint for Message inflow in the case of using CCI interface. JCA spec defines the CCI message listener as the default interface, however I guess the CCI Endpoint should be specialized to the specific ResourceAdapter(and EIS over the adapter), so just provide a sample. well, CCI MessageListener actually support InOut sequence while JMS MessageListener just support InOnly.

     

    - The config model is present, but I did not see a schema.  Do you think we can use the JCA binding spec directly or should we use our own schema definition?

    I think we can use SCA JCA binding schema directly, since the elements I've added is allowed by that schema. I will confirm it in the tests.

     

    Thanks,

    Tomo

  • 4. Re: JCA gateway 1st prototype
    Tomohisa igarashi Expert

    Added some testcases, JCAMixIn, a quickstart(jca-inflow-hornetq), and some bug fixes.

     

    Branches

     

    JCAMixIn

    A test tool for the SwitchYard application that has JCA gateway. JCAMixIn has 2 built-in ResourceAdapter, MockResourceAdapter and HornetQ ResourceAdapter. MockResourceAdapter is useful for the SwitchYard application to have unit test. We can mock-up the EIS behaviour without actual connection with using this ResourceAdapter. You might want to take a look at this example usage: https://github.com/igarashitm/components/blob/SWITCHYARD-708/jca/src/test/java/org/switchyard/component/jca/deploy/JCACCIServiceBindingTest.java

    HornetQ ResourceAdapter is just built from HornetQ repository, and we can test the interaction with HornetQ with using HornetQMixIn as well. Example usage: https://github.com/igarashitm/components/blob/SWITCHYARD-708/jca/src/test/java/org/switchyard/component/jca/deploy/JCAJMSServiceBindingTest.java

    I'd like to note that there is some dirty hack against IronJacamar at this moment. I needed to have some reflection calls to integrate the IronJacamar into our test kit. All of them are in this class: https://github.com/igarashitm/core/blob/SWITCHYARD-708/test/src/main/java/com/github/fungal/impl/SwitchYardIronJacamarHandler.java

    Now it has been moved to https://github.com/igarashitm/core/blob/SWITCHYARD-708/test/src/main/java/org/switchyard/test/mixins/jca/SwitchYardIronJacamarHandler.java

     

    JBossASNamingServiceInstaller instead of MockNamingContext

    JCAMixIn uses IronJacamar embedded for the ResourceAdapter container, and the IronJacamar needs naming service which supports javax.naming.Reference binding. MockNamingContext doesn't support this and looks not so easy to add that feature, so I have simply brought the JBossAS naming service component into our SwitchYardTestKit.

     

    Configuration Schema

    Currently the binding.jca schema is almost same as SCA JCA Binding, and has some unnecessary element/attribute in its Schema. For example, /binding.jca/inboundConnection/resourceAdapter/@type must be specified, but we don't need it because the ResourceAdapter MUST implement javax.resource.spi.ResourceAdapter and that's all, so we don't really need to know the ResourceAdapter's concrete class type. We may need to remove those unnecessary element/attribute to avoid user confusion.

  • 5. Re: JCA gateway 1st prototype
    Tomohisa igarashi Expert

    Ignore this comment. ConnectorServices.RA_REPOSITORY_SERVICE could be cooked up easily using String literal.

     

    JBoss AS7 has a API change in ConnectorServices between 7.1.0 and 7.1.1 - which is referenced from SwitchYardSubsystemAdd, and my branch needs 7.1.1 for both of standalone and OpenShift. I wish the AS7 version in OpenShift will get up to date before we merge this.

     

    Message was edited by: Tomohisa igarashi