> I'm thinking about the classic example of an e-commerce site with
> a web-facing storefront and a separate customer service interface.
> Is it feasible to write the customer service interface as a Swing app
> that calls the EJBs? We're also concerned that we won't be able to do
> SQL "quick fixes" directly against the database because of JPA holding
> records, so the question of being able to write one-off programs without
> restarting the app has come up. Part of an appclient has to be deployed
> to the server along with the enterprise app, doesn't it?
Writing the Swing app is no problem. It can talk to Remote EJBs in two ways.
One, is the "official" JEE way using the appclient. This is, indeed, deployed to the app server, and typically run through a Webstart link (there are other ways of getting the application than webstart, but that's a simple way).
Using this model, you can leverage the new injection capabilities of EJB3, much like you do with modern servlets (e.g. @EJB YourRemoteEJB ejb;).
The other model is a generic, standalone client. This model is perfectly workable, and has no real dependencies on the app server. However, this model is not portable across JEE containers. But, to be fair, porting this is not particularly difficult with some clever refactoring. Just the actual connecting up to the host EJB server is the non-portable part, and that part can be readily isolated in your application. Once you have the actual EJB reference, all of that code is the same. The other detail is that you need to deploy container specific JARs with your application, which would change if you changed container. But it's really not that big of a deal. Once you do it the first time, you've worked out most of the issues. Consult the Glassfish EJB FAQ for details on this.
There's actually a 3rd way, and that's using just web services rather than remote EJB. This is a different development model (remote EJBs can return object graphs, while web services can only return object trees) and has its own challenges, but it's quite viable if you want to consider that option. It seems to me that the wind is turning toward web services over Remote EJBs.
You WILL potentially have issues with "quick SQL fixes", depending on their nature and how they are done. JPA caches much of it data, and a classic issue would be going in to the DB and, say, changing a flag on a customer record. Odds are if that customer has already been cached by the JPA, your application will not see the change.
One mechanism to avoid this is rather than doing "quick SQL fixes", instead, do "quick EQL fixes". And by that I mean create a simple, secure (natch), client to your EJB tier that can take arbitrary EQL statements and execute them. EQL is much like SQL for many tasks (so you can, say, easily do bulk EQL update statements, and the like). EQL is a JPA artifact, so it "knows" about the JPA cache and will "do the right thing".
This is far easier than fighting the JPA second level caches.
Another interesting thing you can do is add a scripting interface to the EJB tier which takes a JavaScript script and executes it. JavaScript it now bundled with Java 6, or can easily be added using the Rhino project. You can easily call your Entities from JavaScript (as well as your Session Beans), which would again leverage JPA. This, too, is not hard to implement, and gives you a lot of flexibility for writing "one offs" that you can readily run on the app tier.
Either of these gives a quick ability to do on the fly stuff via the app tier, without having to do a lot of work. Now, out of the box it won't necessarily be as nice as a good SQL program, but ideally you're not doing "exploratory" stuff on your production DB anyway, but you "know exactly what you need to do" and just need a mechanism to do it, so these ad hoc interfaces aren't as horrible as they may sound. And if you're wrap them tightly in transactions, they're pretty safe from typos, 10 thumb event's and other minor traumas.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=262472