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

[Dimitry Voytenko (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-255?page=comments#action_25598 ] 

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. 

>> I tend to like XUL over NetBeans/Eclipse as a rich platform approach
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.

>> I don't see the benefit to create a delta object change mechanism (this is already what Hibernate do when it talks to the DB :-) ) 
>> joins transfers more data than a PC diff ... using a Persistence Context + lazy loading + subselect + batch-size minimise those issues
That's exactly what I meant, the fact that Hibernate already has most of what's necessary for such task.

>> True business methods, with limited operations are interesting for security but then you no longer need a remote EM. 
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.


> Remoting capabilities
> ---------------------
>
>          Key: EJB-255
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-255
>      Project: Hibernate Entity Manager
>         Type: New Feature

>     Reporter: Dimitry Voytenko

>
>
> I came across Kodo's implementation of remote persistent managers for both JPA and JDO:
> http://www.solarmetric.com/Software/Documentation/3.2.0RC2/docs/ref_guide_remote.html
> http://www.solarmetric.com/Software/Documentation/3.2.0RC2/docs/ref_guide_remotepm.html
> The solution looks pretty ellegant. The main idea behind it is that server and client communicate b/w each other using object graphs (no proxies and no object serialization required) and thus working with JDO/JPA objects on client looks exactly the same as on the server, removing necessity of DTO objects in the majority of cases.
> Have you ever thought about including similar functionality for Hibernate? I do believe it could be a great peformance booster for many types of applications.

-- 
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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira