1

I have a JCA adapter for connecting to EIS. Is it a good idea to replace the adapter with an OSGI module?

The features I need are

  1. Access the OSGI module from ejb3
  2. Access the OSGI module from CDI beans
  3. Access the OSGI module from a servlet
  4. Support declarative transaction mangement
  5. Propogate security context from ejb to osgi module

    • I dont use conection pooling.
    • I dont use Common Client interface

What are the cons of moving from JCA to OSGI module ?

Ondra Žižka
  • 43,948
  • 41
  • 217
  • 277
kiran.kumar M
  • 811
  • 8
  • 25

1 Answers1

1

The cons of moving are:

  • JCA is a Java EE standard - you can use a properly written connector in any Java EE container. Osgi is also a standard but not (yet) for Enterprise Applications and their frameworks.
  • All your listed "features" (I would call them "requirements") are tightly coupled to Java EE: EJB3, CDI, Servlet, TXN management and security are all done or provided by the various Java EE subsystems. You will have to dive deeply into the Java EE specs to provide the appropriate glue code.

This boils down to: A lot of error-prone work for no good reason. So my question would be: What are the pros for moving (in your case of course)?

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
A.H.
  • 63,967
  • 15
  • 92
  • 126
  • JEE has very good support to RDBMS based data stores.Integrating no-sql or an object database is an involved process. ie, write a JCA adapter, add an ra.xml , configure a datasource. With OSGI i expect the integration process will be lot simpler. Just drop the osgi bundle in the class path and start using the tx-mgt, declarative security and other nice features of JEE. API could be as simple as @inject NOSQLPersistanceManager – kiran.kumar M Apr 10 '12 at 07:13
  • 1
    The hard part - writing the JCA code is comparable to OSGI when you need the advanced JCA contracts like XA-transactions. The ra.xml does not matter in terms of effort. And the _configuration_ of the DS will be required for OSGI also - or would you hardcode the connection parameters into you OSGI-Bundle? Con for OSGI: With JEE/JCA you get a lot of infrastructure for free - with OSGI you will have to reinvent some wheels only to get on par with that - especially in your case because you want still to have access to EJB3,... – A.H. Apr 10 '12 at 19:22