I understand that with version 7.1 JBoss radically changed the way remote EJB are resolved and handled. Before, you'd fetch the complete invocation stack from exactly that remote host where you did the JNDI lookup (although the actual call might then be redirected to your local machine, if the bean is provided there, too). Starting with JBoss 7.1 you only have to configure the list of hosts that you want to contact. JBoss remoting asks all of them for the list of beans they offer and puts them in a local list that's dynamically updated when any of those beans are undeployed or new ones deployed. If you now do a (local) lookup, this list is iterated over to find a matching implementation.

That's a great feature! It's according to the spirit of section 3.4.1 of the EJB spec, where the two ways to obtain an instance of a business interface are specified (namely annotating as @EJB and calling SessionContext.lookup), adding: "In both cases, the syntax used in obtaining the reference to the Cart business interface is independent of whether the business interface is local or remote. In the case of remote access, the actual location of a referenced enterprise bean and EJB container are, in general, transparent to the client using the remote business interface of the bean."

That's really nice! You don't have to configure the connection between the server and the beans that it has deployed any more. It's enough to deploy it on a server your JBoss knows about (in your jboss-ejb-client.properties). You could even move an application from one server to another known server, without having to reconfigure the clients.

It could go one step further, though: Generally the qualified name of a business interface is unique enough. You don't want to care about the name of the jar or the ear/war that it's bundled in, just as you don't want to care about the server that it's deployed on.

Only when you have multiple versions of the same business interface deployed in parallel, you'd need to select the correct one. But that's simple: The interface is bundled in an api-jar (this is not the ejb-jar!) that the service and the clients share; and this jar can have a version in its manifest (or in the name, if it must be). The server publishes this version string together with the qualified name, the client container stores it, and when a client does a lookup, the container can do the match[1].

For more esoteric use cases, that matching algorithm might have to consider other qualifiers. Two scenarios come directly to my mind:

1) A service is deployed multiple times with different security levels or service level agreements. The client wants to contact the service instance with the matching (or better) qualifier.

2) A PaaS provider offers an additional SaaS, say for customer management. Simply by booking that service, a new instance is deployed, and the client can access it without further ado. The wiring is done based on the tenant-id that the containers of both the client and the service already manage.

3) A more complex one: We have three machines, A, B, and C; a client on A calls a service X, that's actually running on C, but B has the same service X deployed to "decorate" the real one on C. A should then call B, not C; while B should call C, not recursively B. I'm still thinking about how to best qualify such a use case.

A lot of smarts could be implemented here. The qualifiers could be obtained by configuring some deployment descriptors; by annotating the injection point and the bean; by annotating the business interface; by storing the configuration into a database; by dynamically fetching some properties of the host (e.g., load information for smart clustering); and probably many more. I think this asks for an extensible mechanism and a community of developers sharing their selectors.

After all, the whole thing is simply dependency injection for remote calls! We only need the qualifiers that CDI offers here as well. For the simple case, just annotating the client as @EJB or even @Inject would be enough; no more JNDI lookups and all that! Great! Like!!!

What do other JBoss users think? What do the developers think? What does the EJB-Spec EG think?!?

Have fun!

Rüdiger

[1] It may even be smart enough to understand that incremented micro-versions (the 3 in version 1.2.3) mean backward compatibility (i.e., it can be called by all 1.2.0 - 1.2.3 clients, which is not true for clients with version 1.2.4 ff. or 1.3.x).

Update 2011-01-27: Add SaaS use case.