Well said, Steve. Although it is very much possible to build jca-adapter
like functionality using pure OSGi bundles, I would recommend building
JCA adapters if one is writing transactional connectors. Having said
that if you are writing stateless non-transactional connectors, then
OSGi bundle is definitely an option as you would not have to worry about
implementing any of the JCA artifacts. It gives you more flexibility
like service dynamism, upgrade, etc. - I don't have to explain as you
seem to be already familiar with it. It's too bad that GlassFish does
not yet support RARs as OSGi bundles - that would have given us the
benefit of both the platforms. I have already brought it up to the
attention of our jca module owners to make our underlying work manager
available as a service (just like what we have done to our
TransactionManager or HttpService) so one could leverage it from an OSGi
bundle without having to write a connector.
Thanks,
Sahoo
ps: Steve, would you mind telling us a bit more about how you use these
technologies? I don't recollect interacting with you.
On Friday 10 February 2012 08:06 AM, Steven Siebert wrote:
> Great question! I am eager to hear from the community on this as well.
>
> I considered the same questions when hybrid modules were starting to
> be introduced. I came to the conclusion that those restrictions
> placed by the specifications are there so the container(s)/app server
> can manage performance (so the container can be manage the available
> resources for all applications/modules running on the system),
> security, transactions (ie file system access via java.io
> <http://java.io> is not transactable), and provide a foundation for
> best practices (to support scalability, etc). There are good reasons
> for those restrictions, covered in the specification, and "going
> around" those with OSGi could/would undermine those things. IMO, it
> would be great if the next OSGi/EE specifications provided some clear
> APIs, such as the JCA Worker API (all in all, I like this
> idea)..sadly, I haven't had any time at all to read up on the latest
> JSR's and OSGi specs. IMO, JCA's are still the best way to go for
> legacy/external system integration if SOA technologies aren't
> appropriate.
>
> With some of the specs coming out, I held off on implementing any
> production hybrid apps. I'm usually a open-standards-following kind
> of programmer, but add to the mix that nobody else on my current team
> would be able to maintain it without pain - it really didn't make any
> sense. EJB + CDI + a sprinkling of ServiceLoader has really got me
> far along in building modular EE 7 applications for now.
>
> Regards,
>
> Steve
>
>
> On Thu, Feb 9, 2012 at 8:38 PM, <forums_at_java.net
> <mailto:forums_at_java.net>> wrote:
>
> Now that OSGi is an integral part of Glassfish (and other enterprise
> servers) and a good amount of work has gone into making it quite
> easy to
> build "hybrid EJBs" that leverage all the niceties of both a J2EE
> and OSGi
> container, are there general "do's and don'ts" when integrating
> 3rd party
> bundles into a J2EE container? For example, J2EE frowns upon a user
> spawning and managing their own threads inside the context of an
> EJB as the
> container provides its own pooling and control of such things.
> However, now
> that Glassfish sits inside an OSGi container, is it legitimate to
> build/integrate a pure OSGi bundle that handles some low level
> external
> communications ( sockets, multiple threads, whatever...) that can then
> directly communicate with some hybrid bundles inside the container
> via OSGi
> service registry.
>
> Essentially Im trying to get a feel for if its architecturally
> kosher to
> bypass something like building your own JCA adapter to communicate
> with an
> external legacy business process in favor of a pure OSGi bundle that
> communicates with that same external business process and
> leverages the OSGi
> container to feed the data into the hybrid EJBs. I know its
> physcially
> possible, just trying to get a feel from the community as to what they
> thought...
>
> Thanks!
>
>
> --
>
> [Message sent by forum member 'cdiebner']
>
> View Post: http://forums.java.net/node/883407
>
>
>