NBP rich client in a multi-tier enterprise application?

Just started a project that involves a rich client implemented in Netbeans Platform (NBP), Spring framework is chosen to implement business logic and for data access. Since I've come from a web application development backgro开发者_如何学运维und, I have some questions and would also like some suggestions.

1. What are the options for a rich client to integrate with Spring?
2. Any best practices/books/docs regarding a rich client in a multi-tier Java EE environment?
3. Anything that needs special attention?

We recently went through a similar experience at the company I work for. Sadly, we couldn't find any sort of definitive guide for the process. What we found were partial guides here and there. I'm not certain how others have dealt with this issue, and I am eager to see if any other solutions are posted here. I can, however, tell you how we handled it and hope that you can learn from our experience.

From the onset, we knew that we wanted to be able to control what version of Spring (and, in our case, Hibernate) we would use. Naturally, the versions built into the NetBeans IDE are a bit dated and we wanted to have the cutting-edge available when developing our server code.

What we ended up doing was creating two separate projects: one for our server code (our Services, DAOs, and Domain entities) and one for our client application. We then jared up the server code, copied the jar and its dependencies to the client project, and listed those jars as dependencies in the client code. We created a module in our NetBeans project called SpringHibernate, which housed those jars, and which almost every other module depended on.

I would recommend creating an ant task that will strip out the version numbers of your jars before adding them to your NetBeans project. This allows you to seamlessly update your jars in the server code without the client code ever knowing the difference. (NetBeans can be kind of picky when you start removing and re-adding jars.)

The first major task then is to create a Util class that can load your applicationContext.xml and return beans from the context. That process is outlined here.

One of the major snags that we hit was the creation of Sessions (or EntityManagers in JPA terms). The NetBeans Platform is a highly threaded environment, and EntityManagers are designed to only work on a single thread. To get around this we went with the Open Session In View route*. We created a class that could load the same EntityManager into any thread that requested it. We then created client proxies of our services which would load the EntityManager into its thread before calling the actual Spring-managed service. The added bonus of creating client proxy services was that they were able to be found with Lookup.getDefault().lookup(Service.class) via the @ServiceProvider annotation.

You then should create a custom LifeCycleManager that can teardown and close your EntityManager and EntityManagerFactory on application shutdown.

I hope this helps!

*I know that Open Session in View has been labeled as an AntiPattern, but as long as you understand the problems associated with it you can mitigate those issues (by caching things objects that are unlikely to change over time, making smart database calls, etc.). Plus, I remember during our research we found a forum post by Gavin King stating that Open Session In View is the recommended route for client applications. Of course, I can't find the post now, but it's out there somewhere.