Swing + JGoodies, EJB3 / Hibernate - Design question...
Hi,
Forgive me if I screw up the terminology here.. I'm pretty new to J2EE and Swing development. I'm developing a Swing based application to replace a paper process. It's basically a long form that gets submitted to a server where it is reviewed and in some cases sent back to the user for corrections. I'm having trouble figuring out a good implementation for the data tier.
The prototype that I've developed makes extensive use of the JGoodies framework (Forms, Binding, Validation). The domain model is basically a bunch of POJO's. For each object there is a separate validator object which has a a validate() method that returns a ValidationResult object. On the Swing side, there is a Model object for each POJO/Validator which listens for changes to the result of validate(). The GUI class attaches to the model and updates the GUI to reflect results of the validation. Basically the result is that if you don't fill out a required field, the field's background color changes and you get a list of reasons why you aren't allowed to submit the form at the bottom of the page. What you type in the field is synchronized with the data object on key release or focus changes (not sure yet).
Pretty much all of this functionality rests upon the domain model calling 'firePropertyChange' in the setXYZ() functions. This solution seems to work when the client uses Hibernate to persist the objects directly to the DB Server, but I'm wondering if/how it could work if we decided to use EJB3 Entity Beans for storing the data instead of Hibernate (primarily because we don't want to leave our DB server's port open on the firewall).
From what I've gathered, under EJB3 the POJO's that I'm currently using on the client side (which call 'firePropertyChange') would end up on the server. I am assuming that the 'firePropertyChange' functionality would be broken. When the client binds to the Entity Bean, the server would cause the creation of a new object with simple getters and setters based on the interface on the server side. I assume that this code would be generated for me automatically and I wouldn't be able to get the 'firePropertyChange' functionality back. In other words, the binding between the GUI and the POJO would be lost, along with the automatic validation.
Is this still possible? Was it ever? Was it possible with EJB2 using the Home objects? Should I just stick with Hibernate and let the clients access the DB server directly? Does anyone have any idea what I'm talking about? The only possibility I could think of was to create another layer of java objects and bind the matching properties between the EJB3 entity bean and the model beans that I already have, but this results in an additional class per form element.
Thanks,
Scott
[2829 byte] By [
sholodaka] at [2007-10-2 7:58:24]
> Hi,
>
> Forgive me if I screw up the terminology here.. I'm
> pretty new to J2EE and Swing development. I'm
> developing a Swing based application to replace a
> paper process. It's basically a long form that gets
> submitted to a server where it is reviewed and in
> some cases sent back to the user for corrections. I'm
> having trouble figuring out a good implementation for
> the data tier.
I'm not familiar with JGoodies. Just browsing their Web site I think they're targeting desktop app, not client/server over a network. firePropertyChange assumes that sender and receiver are both running in the same address space, not on two different hosts on the internet.
> The prototype that I've developed makes extensive use
> of the JGoodies framework (Forms, Binding,
> Validation). The domain model is basically a bunch of
> POJO's. For each object there is a separate validator
> object which has a a validate() method that returns a
> ValidationResult object. On the Swing side, there is
> a Model object for each POJO/Validator which listens
> for changes to the result of validate(). The GUI
> class attaches to the model and updates the GUI to
> reflect results of the validation. Basically the
> result is that if you don't fill out a required
> field, the field's background color changes and you
> get a list of reasons why you aren't allowed to
> submit the form at the bottom of the page. What you
> type in the field is synchronized with the data
> object on key release or focus changes (not sure
> yet).
Standard data validation stuff. So far, so good.
> Pretty much all of this functionality rests upon the
> domain model calling 'firePropertyChange' in the
> setXYZ() functions. This solution seems to work when
> the client uses Hibernate to persist the objects
> directly to the DB Server, but I'm wondering if/how
> it could work if we decided to use EJB3 Entity Beans
> for storing the data instead of Hibernate (primarily
> because we don't want to leave our DB server's port
> open on the firewall).
I'd say you most certainly do not want to leave that port open on the firewall. The successful functioning of your "firePropertyChange" has nothing at all to do with the choice between Hibernate and EJB3. Neither of them knows or cares.
> From what I've gathered, under EJB3 the POJO's that
> I'm currently using on the client side (which call
> 'firePropertyChange') would end up on the server. I
> am assuming that the 'firePropertyChange'
> functionality would be broken.
It means that your firePropertyChange would have to have JNDI lookups to find the EJB proxy.
> When the client binds
> to the Entity Bean, the server would cause the
> creation of a new object with simple getters and
> setters based on the interface on the server side. I
> assume that this code would be generated for me
> automatically and I wouldn't be able to get the
> 'firePropertyChange' functionality back. In other
> words, the binding between the GUI and the POJO would
> be lost, along with the automatic validation.
No, but I'm not sure that you want to do things this way.
> Is this still possible? Was it ever? Was it possible
> with EJB2 using the Home objects? Should I just stick
> with Hibernate and let the clients access the DB
> server directly? Does anyone have any idea what I'm
> talking about?
Do you know what you're talking about? 8)
> The only possibility I could think of
> was to create another layer of java objects and bind
> the matching properties between the EJB3 entity bean
> and the model beans that I already have, but this
> results in an additional class per form element.
>
> Thanks,
> Scott
You definitely want the app server and the database to be on the same side as the firewall. The EJB app tier will stand between the UI and the database. That way you can do validation and, perhaps more importantly, authentication and authorization.
You don't say whether this is an intranet (clients and servers inside the firewall) or Internet application (clients outside the firewall). If it's the latter, you'll have a very hard time indeed continuing with Swing. If you go with a web-based UI (JSPs and servlets), you eliminate the problem of getting through the firewall, but you take on the added complexity of a web tier, an app tier, and a persistence tier.
Why EJBs? You're using Hibernate and POJOs - good choice. Why not ditch EJBs altogether and go with Spring instead? You can use Spring MVC for your web tier and Bob's your uncle.
%
