I completely agree, I wish there was a specification-compliant way to get
around using a remote interface for this very situation. One way I have
found is to create the common services as OSGi bundles and provide these as
injectable services. This is great for GF or other app servers that expose
the OSGi franework it rides on in a similar manner (JBoss 6, JOnAS), but
remember that there is not a specification (EE or OSGi) compliant way of
doing this (yet!)...so deployment specifics will very.
Sahoo has made some great tutorial/blogs in this area that you might find
interesting:
http://weblogs.java.net/blog/ss141213/archive/2009/06/developing_hybr.html
http://weblogs.java.net/blog/2009/06/16/our-second-hybrid-application-ejb-osgi-service
That said, I really think EJB technologies has room to grow in the way of
supporting component design/modularity with better grace, without the need
of building a hybrid (OSGi/EJB) application....
Hope this helps.
Regards,
S
2011/4/15 Xavier Callejas <xavier_at_sistemasaereos.com.sv>
> On Vie 15 Abr 2011 14:13:01 Steven Siebert escribió:
> > I'm curious as to why the JNDI approach works - and wonder if this is
> > actually a bug. There are several cases I would not like to expose my
> > internal business interface out to the world, but if it was simply
> > available through JNDI from another EAR running on the same domain. I
> > think you might have found a bug =)
> >
>
> > Which version of GF are you running (3.0.1, 3.1)? I'm interested in
> > testing this, as it has security implications for me.
>
> 3.0.1
>
> I will prepare a test case where I can call a local session ben from
> another
> EAR just as I am doing right now, and will post it.
>
> The remote interface has practical performance disavanteges over local
> interface if you are running your EARs in same JVM (of course considering
> the
> securities implications). But for now I've finished experimenting with
> local
> interface and I am returning to remote interface, I must finish this work
> :p
>
> Thank you.
>
>