• 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

Utilty of EJB client jar

 
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
whats the advantage of creating a ejb client jar project along with the corrosponding ejb project over creating an ejb project alone.How is the ejb client jar project used by other projects?
Is it neccessary to create ejb client project if a client residing in application1 on appserver1 needs to access an ejb running in application2 deployed on appserver2?
How will the ejb client jar be used for the above mentioned sceanrio?
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gavi,

In the simplest scenario RMI clients need only the home and remote interfaces in order to access the bean. Therefore is required that those two classes to be located in the client�s classpath. If the bean throws application exceptions, or it uses VO/DTO (either as input param or returned args) for transferring data from the server to the client then those classes need to be in the classpath as well. Other type of clients like CORBA/IIOP clients need also special stub classes in order to access the bean over the RMI-IIOP protocol. As you might guess these stubs need to be in the classpath either. However all other classes that the bean itself requires, like the bean�s class or other utility classes and libraries, packed along with the bean, are not required by the clients. Hence it makes sense to subtract client specific classes from the whole package and pack them separately as a client specific functionality. This way the clients will have only the minimal set of classes in order to be able to access the bean. After all why should a standalone client load the bean class if s/he doesn�t need it at all?
If the client is another server component like a jsp, servlet or other bean running in a different jvm, then from the bean�s perspective this is just another standalone client and therefore it needs to include all classes required by such a client.
Regards.
 
Gavi Raaghav
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply.
So if another component running on a seperate jvm needs to access ejb then the componenet needs to have the ejb client jar in its classpth? correct...
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


So if another component running on a seperate jvm needs to access ejb then the componenet needs to have the ejb client jar in its classpth? correct...


correct.
 
reply
    Bookmark Topic Watch Topic
  • New Topic