Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
EJB3 and rich-clients - a match not made in heaven?
At 3:37 AM on Oct 23, 2007, Manjuka Soysa
wrote:
Fresh Jobs for Developers Post a job opportunity
The main reason for the exercise was to remove the boilerplate Hibernate code, so that the business logic is clean and simple, and easy to maintain. Also, this will allow better re-use of code with other components being able to access the business logic.
With EJB3 this was pretty easy to achieve. In addition to boilerplate code, I removed all the code related to disconnecting and re-connecting objects from sessions (mostly calls to merge and reload).
Now I am faced with the problem of how the Swing client should invoke the session beans. There are two simple options supported by JEE - EJB remote client and web service. However neither of these satisfy all the use cases.
To make the GUI code as simple as possible, you would want a POJO model bound to the Swing components. For example, you would want to retrive an Order POJO from the server, do operations on the Order (add items, remove items, etc) without any server interactions or tracking changes. At the end you would just send the modified Order to the Server, and the container will take care of synchronizing changes.
There is no easy solution with EJB client or WebServices. You either need to :
1. Track changes (on the client side or using a stateful bean on the server side) and do a manual synchronization with the server domain model.
2. Pollute the server code with object disconnection and re-connection code. This will also require polluting the actual domain model with annotations to control graph object serialization.
I was reading about SDO (Service Data Objects), and a DAS (Data Access Service) for EJB3 might provide the synchronization. However I can not find such a DAS, or solutions based on one.
I would like to hear of any other approaches you have taken.
8 replies so far (
Post your own)
Re: EJB3 and rich-clients - a match not made in heaven?
> To make the GUI code as simple as possible, you would want a POJO model bound to the Swing components.> For example, you would want to retrive an Order POJO from the server, do operations on the Order
> (add items, remove items, etc) without any server interactions or tracking changes.
Why would you want this? Why not just create a method "addItem" on your session bean? That would be much easier. Or is it a requirement for the order not to be persisted while is is being built?
I think code can be much simpler, when you know what you are doing than when you do a "magic" synchronize client-with-server-model method. Also you get clean transaction boundaries. What happens if the order is changed in another session in between? How can you synchonize your changes in that case?
Re: EJB3 and rich-clients - a match not made in heaven?
I've been trying to play the same game. Unfortunately it's very painful. I'll let you know once/if I ever figure it outRe: EJB3 and rich-clients - a match not made in heaven?
Well, since we do everything on the "other side" of the transaction boundary with our web code, it's really not much different.We ran in to two readily identifiable issues.
1) Synchronizing collections
2) Working with simple "lookup" beans.
JPA doesn't really do much for you when dealing with maintaining relationships. For example, if you fetch an object containing a 1:M collection, detach it, remove an item from that collection, and then merge it back, JPA won't actually delete the missing item from the DB.
The other issue we had was with simple lookup objects. Things like "OrderType" and other, simple "Id, description" kind of fiddly bits that we hang off of our data to help ensure data integrity.
When dealing with just pure SQL, you pretty much ignore the bulk of these items and are mostly concerned with just the key. But it's a pain to have to order.setOrderType(em.find(OrderType.class, OrderType.NEWORDER)).
Turns out that if you try something equivalent to: order.setOrderType(new OrderType(OrderType.NEWORDER)) and try and merge that object, IF the system doesn't have a caches instance of your OrderType object, it will use the one we sent with the original order. The problem is, that the order OrderType is an empty shell, with none of the data from the DB. So, when anything else tries to load that ObjectType, you get a bunch of empty fields. The DB is fine, but the cache is corrupted. So, that made using simple skeleton objects a bit of an issue.
But we readily worked around both of these issues.
First, we have a generic Data layer, essentially mirroring the JPA (single fine, single update, single delete). Then we used this layer to add functionality to stock JPA.
For example, we have a simple merge utility that takes two instances of the object (the old and the new) and automatically synchronizes the collections (specifically, it automatically delete rows for us).
We also have a what we call "flesh out" so we can use simple filler "key" objects. The flesh out routine will, again, walk the object, find any Lookup annotated objects, and fetch the original from the JPA for the empty key shell we have in our domain object.
This works for the bulk (80-90%) of our objects, but we can overload the persistence layer for special cases.
We also subclass an abstract object so we can have methods like "getPrimaryKey", etc. on all of our entities.
It works a treat for us.
In theory the JPA will provide at least better collection handling in the future (I know that Hibernate can do some of this automatically already).
But overall we're so far happy with the JPA. Our single persistence layer is VERY nice, as it's trivial to add new entities to our system now unless they need some special handling. Now, we just create an new entity (with the NB wizard no less), clean up the code a bit, and voila, it's done.
Re: EJB3 and rich-clients - a match not made in heaven?
Perhaps you can afford looking at JMatter, a framework based on the NakeObjects pattern that provides what you are looking for and more (it still uses Hibernate under the covers but you won't need to work with it that much). Here is a link to Eitan's most recent article explaining the benefits of the framework (http://www.onjava.com/pub/a/onjava/2007/08/16/whats-the-matter-with-jmatter.html)Re: EJB3 and rich-clients - a match not made in heaven?
> JPA doesn't really do much for you when dealing with maintaining relationships. For example, if you fetch> an object containing a 1:M collection, detach it, remove an item from that collection, and then merge
> it back, JPA won't actually delete the missing item from the DB.
... but on the other hand: If you have a method:
removeItem(Item item) { entityManager.remove(item); }in a sessionBean and the client reloads the order afterwards, this is trivial (This is what I meant when I said a "synchronize client-with-server-model method" gets more complicated than just telling the server what you are trying to achieve).Your utility class to synchronize collections is very nice, but what if you want to add a constraint: Items may only be removed, if the order is in OrderState.OPEN?
> The other issue we had was with simple lookup objects. Things like "OrderType" and other, simple
> "Id, description" kind of fiddly bits that we hang off of our data to help ensure data integrity.
In that case I'd just ignore the description, map the orderType to an enum, write a nice swing ListCellRenderer, that renders this enum (probably by loading all OrderTypes from the db and displaying the description) and create a TestCase that checks that enum and lookup table stay synchronized.
The db will ensure the data integrity. Of course you have to define the possible OrderTypes once in the db and once in the enum. This is duplicated work and not nice, but should not matter all that much if the OrderTypes don't change.
If you introduce a new order type, you will probably need a new software release anyway since some processes will change, so there is no point in being able to add new orderTypes without changing the code.But this is definitely a tradeoff between configurability and easy to read code. If the orderTypes change frequently it is probably better to just map them to a String/Integer.
> But we readily worked around both of these issues.
[... description deleted ...]
Sounds like to much code for my taste...
All just imho, of course
Re: EJB3 and rich-clients - a match not made in heaven?
> ... but on the other hand: If you have a method:>
> removeItem(Item item) { > entityManager.remove(item); > >> in a sessionBean and the client reloads the order > afterwards,Hi Niklas, in answer to you previous post, and the solution suggested above, I think myself and the others are working on a situation where you want to do multiple adds or removes of the item, over a long period of time (a few minutes), and then click Cancel or Ok. If you click Cancel you want all changes rolled back. With your solution, you can't rollback - unless you are suggesting doing the whole operation within one transaction!
Re: EJB3 and rich-clients - a match not made in heaven?
> Well, since we do everything on the "other side" of> the transaction boundary with our web code, it's
> really not much different.
> For example, if you fetch
> an object containing a 1:M collection, detach it,
> remove an item from that collection, and then merge
> it back, JPA won't actually delete the missing item
> from the DB.
I thought CascadeType.ALL should handle this? Pretty sure on Hibernate with a 1:M collection it does delete from the DB if you remove from the collection.
> But we readily worked around both of these issues.
>
> First, we have a generic Data layer, essentially
> mirroring the JPA (single fine, single update, single
> delete). Then we used this layer to add functionality
> to stock JPA.
I see what you are doing.. I think that's really what an SDO-DAS for EJB3 should do. I guess it's a missing link in JEE. Thanks for your thoughts!
Re: EJB3 and rich-clients - a match not made in heaven?
Very interesting. I'd love to be able to read a nice article on the subject over at java.netRichard