Architectural Question Regarding J2EE+Thick Client

Discussions

EJB design: Architectural Question Regarding J2EE+Thick Client

  1. It seems like 99% of all design blueprints and examples regarding J2EE assume a web-client. Unfortunately, I am trying to create a backend framework to be accessed by a large java client and am torn between two philosophical directions. Any suggestions or feedback would be greatly
    appreciated:

    Idea 1
    -------
    Client accesses a single session bean containing all remote methods (~150) via RMI/IIOP. The session bean could act as a facade with each of the ~150 methods in the session bean forwarding the request to finer grained subobjects/beans.

    Idea 2
    -------
    Client accesses a single session bean containing a single execute() method with an operationCode as one of the parameters. Presumably, a dispatcher would then use the operationCode to broker the request to an appropriate handler or command object. The method signature could might look like: public Object execute(String operationCode, Object[] params);

    Idea 3
    -------
    Write code to convert the 200+ objects used in the client to xml and back to objects, and access the container via some sort of SOAP/XML-RPC way.

    Right now I favor idea 1 simply because it makes retrofitting the client somewhat simpler, but I fear ease of extensibility down the road.
    Idea 2 is interesting, but it prevents different exceptions from being thrown on a method-by-method level as well as reducing type safety.
    Idea 3 does not seem appropriate for many reasons, one being it would take forever.

    Thanks,
    Thaddeus
  2. In idea 1 why just a single session bean.
    A bean with 150 methods will be difficult to maintain and
    could have performance issues also.
    Why not have beans module wise ?

    Thanks,
    Badrish
  3. I agree with Badrish(idea 1), it's just that you should split the logic into several Session Beans. One Session Bean should contain only those methods related to a usecase. For example in a Bookstore application, you can use a Session Bean(and related Entity Beans) for authentication, another Session Bean for getting data about books, another Session Bean for buying books on-line. I hope you got the point.
      It's not very wise to use just one Session Bean because this will get bigger and harder to maintain as you add more and more situations(usecases) to your application.