I’m giving a presentation at the SDForum Java SIG tomorrow evening, April 4, on aspect oriented programming with the Spring Framework.
I will be discussing a model for using the AOP features of Spring to expose Hibernate-managed POJOs to remote clients through web services complete with role-based security and declarative transactions. It follows one of the service API design approaches I discussed in this forum last year. The source for this presentation is available here.
This approach seems interesting in our context, which is a fat swing client with close proximity to a relatively thin server. Our alternatives seem to come down to the following:
* 2-tier architecture: Remote the database connection, and run the persistence and domain layers on each client. This is cheap and easy, but have unfortunate properties with respect to cross-client consistency and synchronization
* 3-tier architecture with coarse-grained services: The safe bet, but has a large overhead as the gui functionality will be very rich and needs to navigate in the domain model in various ways. Plus, I’ve never appreciated the way the object graph partitioning is hardwired into the business service definitions.
* And, in the middle: 3 tier architecture with afine-grained, domain-model focused interface. Basically should provide the transparently navigatable domain object of alternative 1, but with the possibility of augmenting with server-side functionality.
Am I correct if I say that your approach is a possible implementation of the last option, including possibility of adding optimizions of the object graph partitioning to reduce network traffic, if necessary?
Would you consider this approach currently too experimental to use in a mission-critical enterprise application?
Regards,
Trond Isaksen, Norway
Yes, I believe that your option 3 is closest to the approach I describe. The other entry I posted on July 31 and reference in this post discusses the pros and cons of this approach in more detail.
We have used this approach in a few applications and find that it refactors well into a well defined remote API layer (DTOs and all that) if the application needs it. You start out with exposing domain objects through your remote API and start adding client-specific objects to the API as you need them for efficiency or clarity in the API.
Honestly, I have not yet come to full resolution on whether this approach or starting with a well-defined remote API using REST or RPC is better. As Tony Mowers says in his comment in the other post I reference, it really does depend on your application. For example, if your server application is just a CRUD engine for a single client app, then exposing your domain model is a fairly straight forward solution.
-alon
BTW, I used your beanvisitor class from the presentation as inspiration. (Ok, I basically stole it:-).
During testing it broke down from time to time. It turns out that System.identityHashCode()’s are NOT unique in the JVM. This means the beanvisitor will sometimes believe it has been through an object when it really hasn’t. Replacing it with a Set of object references fixed the problem.
Remember, it’s not stealing if you follow the license terms included in the distribution.
Regarding the System.identityHashCode() issue, we did run in to this issue in the RemotingConverter implementation. If you look there you see we are using an IdentityHashMap where previously we were using System.identityHashCode() and a regular HashMap. Interesting that the bug we fixed with that change did not surface in the BeanVisitor. Good catch.
-alon