J2EE Application Clients (Spec ch 9)

[geoff.hill]

I can't find anything anywhere on JBOSS about Application Clients (ch 9 of the J2EE spec). Has any work been done in this area? Are there any plans? Are there good reasons not to bother with them?

Am I the only one interested in this? Or am i just not finding where it is?

[jonlee]

I guess the application client in a client-container is an interesting idea. But I am still grappling with its usefulness as an implementation.

In many respects, you are moving a bare-bones copy of an EJB container to a client system. You must provide at a minimum, a JNDI for a cleint application container. But other services are optional.

You get away from the maintenance ideal and simplicity with what effectively becomes a fat client - and a microkernel as they call it in JBoss. Instead of just a Java application, you have a Java application plus a special client application container (operating system/framework).

It also seems an inordinately complex deplyoment life-cycle or at least it was when we did the training at SilverStream. I think SilverStream are the only ones to have even attempted to implement this. See this for a view of the development lifecycle:

http://www.novell.com/documentation/lg/workbench4/docs/help/books/devAppClients.html

To be honest, I haven't seen a captive client application in a natural state (production environment) and the fact that SilverStream/Novell offer this feature yet aren't in the top 3 app servers means that business-wise, it probably isn't a must-have feature.

For web-services and RMI/IIOP-based integration, most likely you are going to see app-server to app-server communication and app-servers are a super-set of the client application environment. But other than that, it is hard to envision a real client application container.

I'd personally really hate to have to maintain a container environment for individual users. ;)

Unless there is a huge cry for it, I wouldn't expect it to appear as part of the JBoss distribution. But as open-source, there is enough infrastructure components that you could build your own from the JBoss bits. You could even donate it to the JBoss cause. :)

[geoff.hill]

OK, I see what your saying, but I'll put my 2c worth and let you poke holes in it :-).

If you use java webstart to deliver the containerized app (so you generate a JNLP when you deploy your ear) then you have no maintenance or install to worry about, and you get a bunch of things for free.

(1) JNDI primed for the right server and with all your EJB homes in java:comp/env just like in another EJB. (Potentially these could be primed with proxies that use http or (yuk) soap for firewall-punching).

At the very least this gives you a mapping from an internal name which does not depend on the hard JNDI name the server responds to, and also means you don't need properties etc to tell you client where the server is.

(2) The right JBOSS client libs, which just migrate up when you upgrade JBOSS.

(3 - this is probably my favourite) The right client jars for your EJBs, no more marshalling exceptions or any of that when you deploy a new remote interface and it doesn't make it to your clients desktops.

(4) JAAS login to jboss-client. Your apps guys don's have to learn how to login JAAS, the container can log you in and you're away.

OK, comments invited.

[jonlee]

I really forgot to add - and the JBoss guys can smack me in the head later; have a look at the AOP developments. This is the direction of JBoss 4.0 and provides some of the services for which you are looking and a J2EE-like framework for normal Java applications.