Client and EJB in different JVM's


EJB programming & troubleshooting: Client and EJB in different JVM's

  1. Client and EJB in different JVM's (2 messages)

    I am working on a project trying to utilize the location transparency feature of J2EE-EJB's. I would be developing and deploying EJBs on a container in a dedicated instance of an Appserver. The clients that would invoke business methods would be running on a different JVM, different machines. I tested that out, i am able to do it with the JNDI lookup with properties including url password etc. Good going. Now, the question is,

    1. in order for the client to compile, I need to provide an ejbclient jar file, what all should that include? ATG Dynamo provides a runDarina tool that creates a jar file that contains, EJB stub, home, remote and WCC classes. I am curious, do I need all of those for the client to compile?

    Another question, may be trivial to many of you gurus:

    2. Planning on using a value object for communication between different client and business(ejb) tier. There are going to be say 5 clients accessing this business ejb(reminder, clients and ejbs are on different jvms) and if i need to modify a value object in order to account for the changes for one of the clients, by say, adding one more variable and getter, setter for it, do i need to recompile all of my clients to account for that change. I understand that the jar file that resides on the client tier would have the old jar that contains the older version of value object and the business tier would have newer version of value object. Can this work? I am trying to guage, if any change happens to a business tier, should all the client tiers have to be recompiled, server bounced etc?

    Sorry if this was a lengthy question, thanks in advance for your help

  2. question 1:
    Thumb rule,
    You need to include all those import classes that you used in the Bean class.
    You need not expose Bean and remote to the client. I prefer to do it manually from AAT and aviod third party tools which are not much accurate.
    question 2:
    Change of the framework to eliminate too many client jars for each client.Simultaneous development leads to re compilation very frequently.
    Making of common (if not for all) ejb service might resolve to an extent. Iam also following this post for a better suggesttion.
    And its a good question.
  3. ValueObjects, Question 2[ Go to top ]

    A good thing to do when working with ValueObject in this scenario, would be to use Interfaces to each ValueObject. A ValueObject implements a corresponding interface. In the client jar files, you only put the interfaces to the ValueObjects. To get this working, you need to do dynamic classloading. So when the implementation of the ValueObject changes, the client jar file doesn't need to be changed. BUT, If you alter or add a new Method signature in the ValueObject, you also need to change the client interfaces.