• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Reasons using enterprise application client?

 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 1357
39
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Bartender
Posts: 1357
39
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 .
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic