So what's the status of remote invocations on EJBs in AS7?

[jaikiran]

Many of you have been asking about support for invocation of EJBs from a remote client, ever since 7.0.x was released. Here's an update to those of you who have been waiting patiently for remote invocations on EJB in AS7. For some time, I have been replying in many threads, that it'll be available soon (without providing the real details, although those of you following the AS7 dev list https://lists.jboss.org/mailman/listinfo/jboss-as7-dev would know the progress). So I thought, it was time to let you all know how it's progressing.

The plan for remote invocation on EJBs has been (and still is) that it'll be available in one of the 7.1 Beta releases. Ofcourse, 7.1 Beta release would also include other features and bug fixes. As promised we have been working on implementing the remote EJB invocation on a high priority. We have made some good ground on getting this functional. Infact, the current AS7 upstream does have support for remote EJB invocations. *BUT* (yes, before you start rushing to download the nightly binary, please read the rest of this post ), in AS7 we have introduced a new EJB client API which is a JBoss specific API which allows you to invoke on EJBs. This is different from the traditional JNDI lookup and invoke process and involves dealing with the client API. The goal and details of the API will all be documented and made available. The current AS7 upstream has support for invoking EJBs via this API. Those of you who follow the AS7 dev list already know about this.

This however, does *not* mean that you will have to start using this API instead of the traditional JNDI usage. Infact, now that the API is in place and functional, we are working on implementing a way where you would still use JNDI and internally we would delegate the calls via this EJB client API. This part is what is currently work-in-progress and should be available soon. The reason why we haven't yet asked users to test the current AS7 upstream, is because we would first want you to try the typical JNDI access, before we present to you the new EJB client API. Once the support for invocation on proxy returned by a JNDI lookup is ready, we'll be asking users to test out our nightly builds and provide feedback. Ideally, we would like this to be available atleast a week before a 7.1 Beta release happens, so that any bugs reported can be fixed before the release. We are planning to make this support available in AS7 upstream as soon as possible and although I can't really promise, we are targetting for this to be available maybe in the next week. Take that as a rough estimate though, since we can't really predict how things are going to work out.

As for the timeline and exact dates for the Beta release, it's not something that I know. Keep an eye on the JIRA roadmap and I believe it will be updated accordingly.

[szhigunov]

Does anybody know if remote JNDI lookup for JMS objects will be supported in 7.1 Beta? Is it coming together with "remote EJB" function?

Tried to ask HornetQ group and the answer is:

"thats really a question for the AS7 guys, its not really anything to do with HornetQ"

[dmlloyd]

Sergey Zhigunov wrote:

Does anybody know if remote JNDI lookup for JMS objects will be supported in 7.1 Beta? Is it coming together with "remote EJB" function?

Not exactly.  We don't have a specific plan for general remote JNDI of any sort.  Like Jaikiran said, the current plan for EJB is to allow JNDI lookups (they just won't necessarily hit the server) but also provide a native API for creating EJB proxies.

We don't have a similar plan in place for HornetQ as of yet.  So currently the only way to create connection factories from a remote client is programmatically.  That said, there are a few different ways we can proceed:

1. Leave that as is (i.e. using HornetQ via JNDI from the client is totally unsupported)
2. Add a client JNDI layer for HornetQ similar to what we've done EJBs where you "look up" the connection factory using a special URL scheme e.g. "hornetq:blah", where the JNDI name sections are parsed and used directly to construct the connection factory, or indirectly to look up a connection factory configuration in some configuration bound to the local client (like a properties file or something) - this solution would be implemented directly as an enhancement to HornetQ
3. Create a separate, purely client-side JNDI facility in which the JNDI directory is located locally in the client's memory, and populate it from a client-side configuration file which contains the configuration for things such as HornetQ connection factories and EJB proxies
4. Create a separate, purely client-side JNDI facility in which the JNDI directory is located locally in the client's memory, and populate it via downloading objects from a connection to a service e.g. a URL or similar
5. Create a separate remote JNDI service for Remoting in which the server can be configured to expose certain (serializable) bindings to clients (perhaps an alternate namespace such as "java:jboss-remote/foo/bar/..." which would be mapped to "foo/bar/..." on the client), and users can use that to look up anything bound therein (the JNDI context's lifespan would be bound to the connection's because each lookup request would translate into one network request)
6. Create a separate, client-side JNDI facility in which the JNDI directory is located locally in the client's memory, and use a Remoting service to automatically maintain synchronization between the client directory and the server (so that the client directory survives a connection fault)

There may be other paths forward as well.

[refon]

Reading your answer shows this is not a simple feature to address in a developper perspective!

On the other hand I guess Sergey and I are looking for simpler more "end user" oriented answer like:

This is the path to migrating your former JMS / EJB remote JNDI calls as supported by JBOSS AS 5 / 6 to JBOSS AS 7. 

I dare to speak on behalf of Sergey given a former thread on JMS/JNDI subject :

http://community.jboss.org/message/630225#630198

[szhigunov]

Thanks David for detailed answer. A lot of interesting design choices. I was under the impression that the final goal for AS7 was to get JEE 6 certified. Can you get certified with no JNDI access to JMS from the client (option 1)?

Migration to proprietary code (HornetQ API) makes client, obviously, not-portable and gets more complicated when Spring (my case) or other framework is involved.

As I read the answer, the final solution has not been worked out yet ant when it can be released is unclear at the moment. Correct?

[dmlloyd]

Patrick Refondini wrote:

Reading your answer shows this is not a simple feature to address in a developper perspective!

On the other hand I guess Sergey and I are looking for simpler more "end user" oriented answer like:

This is the path to migrating your former JMS / EJB remote JNDI calls as supported by JBOSS AS 5 / 6 to JBOSS AS 7. 

I dare to speak on behalf of Sergey given a former thread on JMS/JNDI subject :

http://community.jboss.org/message/630225#630198

Indeed it's never that simple.  Anyone who tells you otherwise is trying to sell you something!

[dmlloyd]

Sergey Zhigunov wrote:

Thanks David for detailed answer. A lot of interesting design choices. I was under the impression that the final goal for AS7 was to get JEE 6 certified. Can you get certified with no JNDI access to JMS from the client (option 1)?

There is nothing in the Java EE platform specification about remote JNDI access from standalone clients.  It only defines what is known as "EE Application Client" which is essentially a way to run an application JAR (with a Main-Class) inside a "client container", which basically gives you AS-like things such as JNDI, JMS, JDBC data sources, transactions, injection, etc. at the application level.  This we do support - in fact this mode is more usable now than in previous releases.

In fact having JNDI run over RMI is simply a convention that some vendors conform to.  We were interested in exploring alternatives since early in the AS 7 lifecycle, since RMI is something we want to move away from - it's a dead-end performance-wise and it's a pain to deal with in terms of security and provisioning (firewall rules in particular can be a challenge).

Sergey Zhigunov wrote:

Migration to proprietary code (HornetQ API) makes client, obviously, not-portable and gets more complicated when Spring (my case) or other framework is involved.

As I read the answer, the final solution has not been worked out yet ant when it can be released is unclear at the moment. Correct?

Correct.  I recognize that the current status quo is not ideal, but we just need to choose the right path forward at this point.

[jaikiran]

For those of you following this thread, we have added support for remote EJB invocations (which includes invocations on proxies returned via JNDI lookup on the client side) in AS7 upstream as of last weekend. I'm in the process of adding some documentation to help users start testing this. And while coming up with a sample application, we've have uncovered a bug which can leave the client JVM (program) waiting for non-daemon threads to exit. We are in the process of fixing that and we'll soon publish the document to start testing remote invocations.

[jaikiran]

Support for invocations on EJBs from a remote client is now available http://community.jboss.org/thread/175081?tstart=0

[suikast42]

I have actually a client that call EJB's over JNDI lookup and get sone status back over JMS and publish some stuff to JMS. Is that in  focus for 7.1 release to have proxies for jms like org.jboss.ejb.client.naming.jms ??

[henk53]

David Lloyd wrote:

There is nothing in the Java EE platform specification about remote JNDI access from standalone clients.

Indeed, and especially for JMS it doesn't really say much about sending messages to any remote server at all, which is when you think of it rather strange for a specification that deals about messaging.

The JMS 2.0 specification seems to be taken some steps in this direction, as the following paragraph from the JSR says:

There is a requirement in the user community for an application running in a Java EE application server to be able to use a JMS provider other than the one provided by the application server itself. There are two main reasons for this.

Messaging is commonly used as a technology to connect one system to another, possibly quite different, system. If these systems use different application servers then it is inevitable that for at least one of them the JMS provider being used will be "foreign" to its application server.

Unfortunately this is only about one Java EE server to the other, but it's a beginning.

In fact having JNDI run over RMI is simply a convention that some vendors conform to.

Is there actually any vendor which doesn't support this? It seems to be such a widespread convention that it's actually strange to realize it isn't specified.

We were interested in exploring alternatives since early in the AS 7 lifecycle, since RMI is something we want to move away from [...] I recognize that the current status quo is not ideal, but we just need to choose the right path forward at this point.

Is there already any idea if not via JNDI how a remote client (either standalone, another application server, or two JBoss AS same version instances) will communicate then?

[jaikiran]

henk de boer wrote:

We were interested in exploring alternatives since early in the AS 7 lifecycle, since RMI is something we want to move away from [...] I recognize that the current status quo is not ideal, but we just need to choose the right path forward at this point.

Is there already any idea if not via JNDI how a remote client (either standalone, another application server, or two JBoss AS same version instances) will communicate then?

Keep an eye on https://issues.jboss.org/browse/AS7-1338

[henk53]

jaikiran pai wrote:

Keep an eye on https://issues.jboss.org/browse/AS7-1338

Thanks for the pointer. Yes, I was watching that one already

One thing that I still don't understand; originally it seemed the entire reason to not support JNDI anymore was that JBoss wanted to break with the past and investigate alternative, potentially superior, methods for communication early on in the development of JBoss AS 7.x.

But now the beta of the candidate release (7.1.0.CR1b) has been released. Now I'm not 100% sure what a CR beta is, but normally a candidate release would indicate that all decisions have been made and there's just bug hunting left, right?

So shouldn't it by now be clear what the much discussed alternative to JNDI is?

[jaikiran]

henk de boer wrote:

But now the beta of the candidate release (7.1.0.CR1b) has been released. Now I'm not 100% sure what a CR beta is, but normally a candidate release would indicate that all decisions have been made and there's just bug hunting left, right?

It's not a beta of a candidate release. It's just named "b" because after CR1 was released we identified 2 potential major bugs. So we released a new CR1 (the previous one I think was implicitly named "a"). See this http://lists.jboss.org/pipermail/jboss-as7-dev/2011-December/004949.html

henk de boer wrote:

So shouldn't it by now be clear what the much discussed alternative to JNDI is?

That JIRA already has some clear requirements on what should be expected. But the implementation details aren't clear.

[henk53]

jaikiran pai wrote:

henk de boer wrote:

So shouldn't it by now be clear what the much discussed alternative to JNDI is?

That JIRA already has some clear requirements on what should be expected. But the implementation details aren't clear.

Since JBoss AS 7.1 final has now been released, I wonder whether the implementation details have become clear now? AS7-1338 is only about getting the normal JNDI way to work again. I'm just curious what this much discussed alternative has finally turned out to be.

Also, is the official stance of JBoss that JNDI is old and legacy and this alternative is the way forward?