[ 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

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=co... ] Dimitry Voytenko commented on EJB-255: -------------------------------------- Emmanuel, You're definetely right. Most of points that I make can be resolved in other ways (using remote JDBC drivers, encryption, etc). And I'm definetely not saying that this is the way to go. As the matter of fact we're currently using remote JDBC for tunnelling over HTTP or DTOs for simpler tasks. What I'm trying to do is to invite a debate on how benefitial this approach would be and how easy would it be to implement it using Hibernate. Well, the fact is that there're a number of approaches for building rich clients, including Eclipse, Java Swing, Spring RCP, .NET, etc. If Hibernate would turn out to be easily usable in this scenarios, it would make life of many developers much easier and would further consolidate Hibernate's position and applicability. Also, all of these concepts also apply for other multi-tiered architectures. That's exactly what I meant, the fact that Hibernate already has most of what's necessary for such task. I guess I meant here that overall security handling would be more consitent for both Remote EM and Services/DTO. While most of stuff is doable some other ways, piece by piece it might turn out that the Remote EM could be a very ellegant and good implementation. I still wanted to re-emphasize some points here: 1) Security. There's still something here. In the Hibernate's reference guide, it describes how security can be setup using Hibernate events mechanism, where it's possible to veto changes based on the user's context. It's much harder to trust that some environments would do it properly if they would have necessary context at all. In case of rich client application, for instance, you would have to rely that user's context is correct. This is, of course, is possible to do, but given the integration capability of modern rich client platforms (where modules from multiple vendors can be integrated together) it's much harder to do. 2) Authentication. Remote tiers (such as rich clients and others) don't always have sufficient authentication data. I.e. they're required to athenticate themselves with a server, but afterwords all the communication is performed using session tokens. This makes it much harder to implement "my stuff" scenarios. For instance user has any number of stock portfolios, which can be retrieved using SQL "select * from portfolio where owner = ?". Here, a) the specific user identification for the query might not be known to a client and b) there's a security concern that client can see somebody else's portfolios. Whereas either concern can be easily deal with on the server side. 3) Transactions is a big concern for a remote JDBC. In case of HTTP at the very least sessions should be forbidden to do session flush and locking policies are affected. The documents above describe the solution for transaction management that seems to me pretty simple, but powerfull. Additionally, some ORM framewors in case of rollback restore Java objects to the previous state in addition to rolling back the transactions in the database. If this weight is taken off developers, this could be a great feature on the rich client side. 4) Notification issues. Using Hibernate's event mechanisms and messaging middleware (JMS) it's very simple and efficient to create notifications to interested parties regardless how they are deployed (server side components, rich clients, etc). It'd be much less reliable to drive this process from the clients. Additionally it would put some unwanted restrictions on the deployment and, again, would require some actions to improve security. All these steps would be unncessary if changes and notifications would go through the server side. 5) Configuration. Security, transactions, notifications, mapping itself, etc. This is a lot of configuration. Maintaining and updating it would be pretty hard. It looks like Remote EM approach would allow to avoid most of this configuration for particular "client" scenarios. Even in case of mapping configuration most of the settings would be unnecessary. I also have to say, that this approach has lots of problems (such as class version management, etc), not to mention all the uncertainties as there're not that many systems that implement it. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=co... ] Marek Mosiewicz commented on EJB-255: ------------------------------------- Remote client and filtering could result in nice row level security solution. Currently Hibernate does not offer read/insert/update/delete annotations for entity but if it would it could be interesting in some scenarios. Of course there is question if not better to make this on database but there is e.g. no portable solution for row level security, so there is niche where Hibernate could go. Marek Mosiewicz http://www.jotel.com.pl -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=co... ] Marek Mosiewicz commented on EJB-255: ------------------------------------- "Currently Hibernate does not offer read/insert/update/delete annotations for entity but if it would it could be interesting in some scenarios. " What do you mean? Some annotation to control permissions to operations. In fact there is no good solution to db security in case you use connection pool, becouse you can not use db security(it would require different connection to each app user). It can be useful to application to say that table x can be updated by role y and viewd by role z. It could be also easy to add some WHERE rewriter and have row level security (user x can access only this data from warehouse table where it fulfill some codition).Now in case of web application it is in duty of application logic, but could be done by hibernate in many cases. But problem is more serious problem in case of remote access. Currently you usually control it in SessionBeans, but it could be nice to give client EntityManager which is secure aware. Remote client would get SessionBean with EntityManager interface and it could do only what it is allowed. If client want to save or load entity which he is not allowed it will throw Exception. I now have something similar in my SessionBean which try to analyze query and apply security logic to it. But it only accepts simple queries. Next step would be remote EntityManager (local class connecting with server via servlet or as SessionBean) which would be secure and would lazy load and would do intellingent flush. Now there is great duplication of work. I have to update grants to tables for client (which uses db security) and duplicate security logic in SessionBean which does not use db security due to connection pooling. A other solution would be connection pooling which can be J2EE security aware and would get separate connection per user (using which password?), but it is not what connection pool is (anyway it would work well in many scenarios) Third solution I use is mentioned early intelligent session bean which makes security checks. But then I can not use lazy loading and any intelligent flush (I have limited ability to navigate relations) Marek Mosiewicz http://www.jotel.com.pl -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=co... ] Emmanuel Bernard commented on EJB-255: -------------------------------------- We have 2 solutions to your problem. Hibernate integrates with JACC (thoough the integration is arguably not tested on a regular basis). And the filter feature allow row level restrictions (ie the additional where clause). This is not related to remote capabilities though -- 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