Reasons using enterprise application client?

[K. Tsang]

Hello fellow ranchers

Say I have a EAR file. Inside, it has a EJB jar, web war and app client jar file. The (enterprise) app client here is a desktop GUI calling the EJBs accordingly.

Now if this EAR is deployed to some app server like JBoss or Glassfish, to access the app client, users will basically use java web start/ JNLP to run the client.

Given this is the case, I'm wondering if the effect is the same as separating the app client (not part of the EAR), have that EJB jar in its library path, and deploy the GUI app as a jar. Hence users not use web start.

The only disadvantage I can think for separating the app client is if the EJBs get changed, the client's version will be outdated. But other than that, are there any justification for using an enterprise app client?

Thanks

[Claude Moore]

Hi Tsang,

that's a nice question. As far as I know, applicationclient jar is useful to provide your java client application with all appserver-specific client jars to "connect" to services (EJBs, JMS and so on) exposed by target appserver, as well as remote interfaces - for example - of ejbs you develop and deploy. I think that building an update version of application client part of a Java EE application is a process that somehow keep track of updates applied to the whole application server runtime (via service packs, for example).

So said: if you export EJB client jar, appserver runtime jars and so on and let them available to your client's classpath, the whole thing works. In my experience - mainly based upon WebSphere usage - the main problem is that such client runtime is quite big: you have to deploy ejbclient runtime, orb runtime (for RMI) and a lot of other jars. This may be a bit annoying, mainly because if you upgrade runtime server, you have to upgrade the distributed client components as well on all your clients.

As a note: where I work, we develop a rich client which execute remote service call to WAS appserver. I preferred NOT to use RMI, instead we wrap client- server communication with Request / Response objects which maps input and output parameters, and do exchange them via http. Doing so we need not to keep client and server runtimes update together; client runtime is simply a standard JRE installation.

Regards,

Claude

[K. Tsang]

Claude Moore wrote:As a note: where I work, we develop a rich client which execute remote service call to WAS appserver. I preferred NOT to use RMI, instead we wrap client- server communication with Request / Response objects which maps input and output parameters, and do exchange them via http. Doing so we need not to keep client and server runtimes update together; client runtime is simply a standard JRE installation.

Thanks for your input Claude. So you are somewhat having web service client or equivalent to communicate with the server.

This approach indeed is another possibility making the client app jar much smaller.

[Claude Moore]

K. Tsang wrote:
Thanks for your input Claude. So you are somewhat having web service client or equivalent to communicate with the server.

This approach indeed is another possibility making the client app jar much smaller.

That is exactly the approach we followed. By the way, another consideration i'd like to put in this discussion is that Java SE lacks of a standard API -as far as I know- to work with its enterprise counterpart. And is a real pity.
You have always to relay upon a third party library. No built-in support for ejb communication. No built in REST support .