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
-
Architectural Question Regarding J2EE+Thick Client (2 messages)
- Posted by: Thaddeus Jampol
- Posted on: December 17 2003 21:36 EST
Threaded Messages (2)
- Architectural Question Regarding J2EE+Thick Client by Badrish Agarwal on December 18 2003 00:19 EST
- Architectural Question Regarding J2EE+Thick Client by sergiu truta on December 18 2003 04:32 EST
-
Architectural Question Regarding J2EE+Thick Client[ Go to top ]
- Posted by: Badrish Agarwal
- Posted on: December 18 2003 00:19 EST
- in response to Thaddeus Jampol
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 -
Architectural Question Regarding J2EE+Thick Client[ Go to top ]
- Posted by: sergiu truta
- Posted on: December 18 2003 04:32 EST
- in response to Badrish Agarwal
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.