-
1. Re: Remote EJB portable JNDI names
Prasad Deshpande wrote:
Hi Guys,
I'm glad that much awaited remoting is now in nightly builds of AS 7.1. Thanks a lot guys for that, I read throw Jaikiran's article https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI
A question straight came into mind, JEE6 defines portable names for ejb's deployed, if I have to access EJB's (be it stateless or stateful) using those names like java:global/<appName>/<moduleName>..... etc from a thin/stand-alone client, how do I do it? Why this jboss specific naming ejb:/ is defined? this implies, I can NOT use the same client code (that uses JNDI lookup) for accessing different application servers. Either I'll have to write a layer that is application server specific or will have to re-write entire stand-alone client.
I know that EE6 specs doesn't say anything about accessing JNDI names on stand-alone client, but wouldn't it be easier to use the very same JNDI names in stand-alone clients too for development simplicity? I read somewhere that java: namespace can not be accessed outside JVM for security reason is there any connection to that fact?
Thanks,
Prasad
That's a very good question. Asside from the security concern you raise, the main issue is that not everything in java:global is exportable, only the remote types are. Also the EE specs dictate the format of java:global, and since our ejb: is different (we need a way to disambiguate a bean deployed on multiple servers that a client may have multiple connections to [ a long standing issue ]). Additionally if you are running under an EE appclient environment, then the layout of java:global is different than whats on the server, since the EE client is allowed to have "local" resources. Lastly the ejb: namespace has a benefit that it does not require round trips to locate a bean, since the name is a fully global (across VMs) unique path. So there is a nice performance benefit to it.
I take your point that the portability problem is a pretty big annoyance. This is really a side-effect of the spec not defining portable client access. The only portable portion that is defined is access using the IIOP protocol, but the COSNames are still vendor specific. Using an EE app client would allow you to limit the name deltas to xml descriptors, the only issue is that bootstrapping the app client is not standardized so can be different among vendors as well. However, most utilize a mechanism where you have a grouping of librariers and a set of VM parameters you use to bootrstap your main class. Alternatively you could implement your own mechanism using simple properties files. Those could be generated using a maven/ant task that takes in various attributes like deployment name etc to generate it