EJB design: Using EJBs in a Swing Client
- Posted by: alexander thomas
- Posted on: September 22 2000 04:10 EDT
I am currently thinking about a reasonable way how to make a swing client communicate with an EJB aware application server.
The following requirements turned out to be necessary so far:
1) only a few stateless session EJB stubs are allowed on the client side
2) communication between client and server is based on the exchange of ordinary beans
3) as a consequence to the first point a transaction on the client does not relate to a single transaction on the sever in a simple way.
If somebody knows some good resources on this matter - please let me take part of your insight.
Also, if somebody would like to discuss this topic in further detail, please add some remarks to this message thread and I will follow it up.
- Using EJBs in a Swing Client by Dimitri Rakitine on September 22 2000 05:05 EDT
- Using EJBs in a Swing Client by alexander thomas on September 22 2000 06:46 EDT
- Using EJBs in a Swing Client by Jeffrey McArthur on October 18 2000 16:47 EDT
- Using EJBs in a Swing Client by amit sinha on December 02 2000 16:20 EST
I'm definitely missing something here. Why Swing client is any different from servlets, applets, Java applications, CORBA clients, etc?
I am talking about swing clients as a synonym for a client with a more sophisticated means of user interaction. Thus, you can use the terms java application, applet, etc as well.
In opposition to a typical browser based application, I am wondering in which way it is possible to put a reasonable amount of information on the client. Also, the flow of control could be (at least partially) handled by the client as well.
As a result the manipulations the user will do on those data will be more interactive as there is not so much net-traffic.
I think this is different to the way browser based applications are typically realized.
Again, why EJB layer should be aware of how sophisticated user interaction model of it's client is?
If network reality would make it possible, I would do the following:
-Make entity beans available at the client and regard them as models.
-Assemble some dialogs which serve as views/controllers on the models.
But, as responses from the application server will be reasonably delayed, invocations on simple setter methods on entity EJBs will not be an option.
Instead I will be forced to use session beans and lager objects as parameters.
All of this will increase complexity in the client.
Maybe the EJB layer looks the same in other cases as well (that would be reasonable).
Whatsoever, I am looking for some good resources/advises on how to organize the client with respect to the formerly said.
A generally accepted EJB pattern is for applications to access session beans that facade multiple entity beans. You can use a stateful session bean to encapsulate the *logical* dialogue process (i.e. independent of presentation), represented as a finite state machine. You can then front this with any physical UI that uses this state model (whether a java application, applet or servlet).
So I don't think you really want entity beans available at the client - nor for that matter session beans. The interface of the stateful session bean holding the logical dialogue should be designed to avoid multiple network round-trips for passing attributes. Instead it should pass objects that act as attribute containers.
I interface with my Entity Beans through Session Bean Proxies that I generate using Perculator (www.backsource.org). These proxies manage all cacheing and communication with the Entities. Each proxy defines a method called renderXML, which create tags like this:
From that description, I automatically generate a Swing client with the appropriate component (labels for keys, text fields for strings and numbers, combo boxes for dates, etc). Of course things are a little more complicated than this, but the general idea I like since it allows the client to choose how to render the information. The same renderXML method will work with any client (PC, palm pilot, pager, cell phone) since each client can choose an appropriate interface.
As another seed thought, I use an client specific XML file to fine tune the generated interfaces. You might check out BML at http://www-4.ibm.com/software/developer/library/bean-markup1/?dwzone=xml#resources for ideas how these client xml files can look. If you can't tell, there is a lot of reflection used in my solution. I can now write one XML file, feed it to percolator, generate beans, and then generate a generic Swing client without typing any code!
I am doing the same thing--calling session beans from the Swing Client. Do you have any idea of what all class files(stubs, skeletons, weblogic files etc)needs to put on the client machine. Please provide some help