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 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> 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<http://forums.java.net/node/883407>
>
>
>