[hibernate-issues] [Hibernate-JIRA] Commented: (EJB-255) Remoting capabilities

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=co... ] Dimitry Voytenko commented on EJB-255: -------------------------------------- Emmanuel, The same documents above describe solutions for transactions. They're of course not 100% prone, but could suffice for a big number of use cases. There're other interesting ideas there as well, such as remote commit notifications, etc. For the firewalled HTTP environments regular JDBC is out of the question and "remote" JDBC has a lot of problems, such as: - Security issues. Working via public channels (such as HTTP) increases pressure on security. The secuirty will have to be controlled on the server side. Remote Hibernate would help to minimize necessary effort and configuration by keeping the setup only on the server side. And it's much easier to control security on the service methods than JDBC calls (if possible at all). - Transaction issues. These are very hard to resolve with remote JDBC calls via HTTP, but having summary of the object graph changes, this should be relatively straigthforward to setup. It would be similar to current's local Hibernate setup with the restriction that Session.flush() cannot be called (or will do nothing). - Notification issues. The most of the information necessary for such a task can be derived from the persistence mapping. Hibernate already has an extensive event mechanism, which could be generalized for such tasks. Remote JDBC won't help much propagating events to the clients, but Hibernate + JMS on the server side could. - Optimization. Join-optimization when selects for associations are added into the primary entity's queries and later "groupped" by Hibernate to build collections and remove duplicates. Such techniques work great in the local network, but b/c they're potentially fetch a lot of data, won't work so well via HTTP. So here, the optimization goals can conflict. In the local network - it's number of JDBC calls, in others - amount of data passed has much bigger penalty weight. Finally, I believe the effort shouldn't be duplicated for this functionality, b/c "client" will require significantly less code and configuration, b/c most of the functionality can be proxied from/to server. There's no need in the JDBC and JDBC support code all these and a lot of other functionality can be setup to only reside on the server side. This would give an added benefit of the space required by the client which would allow or improve deployment in the rich client environments. In other words, client can be made as thin as possible. Additionally, this could be very much in sync with the current SCA/SDO initiatives. SDO could be a very good transport for object graphs in both directions. I'm not saying that SDO should necessarily be used for the implementation, but the patterns are the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira