The Hibernate Network Proxy, A Dumb Idea.

A friend of mine had a good idea for a Java project named "hibernate proxy". I renamed it "hibernate network proxy" because hibernate proxies are already a well known concept among hibernate users (it allows lazy loading through a Java Proxy class).

The hibernate network proxy, is a way to use hibernate remotely, that is to proxy hibernate calls through TCP (or even HTTP) to another machine, that will execute the session.saveOrUpdate or the session.load, etc. calls and return the corresponding objects, serialize them and deserialize them for use on the client.

As most projects in my company involves several distributed services, this idea could have been potentially very interesting, allowing hibernate use in several services that would interact with a common service in charge of the db. It made me think about other standard patterns:

• This is not very different from the classical EJB session facade architecture, except we don't expose application functionalities, only hibernate stuff. In fact we don't want to expose application functionalities since they are not shared between services.
• This is very similar to Entity EJBs used without facade, remotely, the first kind of design we heard about when EJBs came out. This would actually be a good fit for doing this kind of stuff, amazingly. I never thought remote entity EJBs were of any real use. Unfortunately for our projects, we already have a messaging infrastructure, and I am not sure how feasible it is to change of EJB transport protocol. Seeing the complexity of something like IIOP, it looks like a dead end.
• This is a kind of Hibernate Second Level Cache, a cache with remote capabilities. The cache would proxy the request to the db service, and the db service would answer to that. This is a possible implementation that seems very flexible.
• Use a regular TCP connection to the DB, and hibernate in a standard way. Ok, it does not use our internal message bus, but it is so simple and standard. 

The last solution raises the most important question:

Why does it need to be proxied? 

To go through some particular port? -> use a port forwarder.
To go through HTTP? -> use HTTPTunnel.
You want Java only? -> use JHttpTunnel,there is even JSch for ssh