IBM eXtreme Scale vs ORMs

Ah, that's a solution I have also been thinking over for quite long time. Distributed object caching - that's the next generation platform for most applications. I am sure this is one of the most interesting areas to work in. Shall I seek for opportunities with IBM, maybe? :)


Why am I so excited? Simple. Nowadays a typical application server is built upon some ORM solution to talk to the backend database. This combination faces too many architectural issues that cannot be solved in a simple way. Just a few examples:

1) Building Data Transfer Objects (DTOs) is actually a huge pain as it requires either a separate identically-structured hierarchy or an extra layer transforming existing value objects into transportable form. Remember a nasty issue using lazily-loaded entities outside the session scope in Hibernate?
Sometimes (actually quite often) instead of the original objects the remote model rather wants a new entity constituted of attributes from multiple objects joined by some navigation paths in the entity tree. For example, in GUI user might prefer seeing some Customer particulars in the same row as Order details while in the object model Customer and Order are naturally different entities associated by a one-to-many realtionship.
2) Any modern ORM inevitably imposes slight overhead when materializing objects from database and storing changes back. It might be negligable for the application with moderate number of transactions, but strikes immediately for highly loaded servers. Too often there is no much chance to boost performance in such cases.
3) Some entities in the object model might not need persistence at all. For example, it is very common for a trading application to have Bid and Offer prices ticking thousands time in a second. It is usually impractical to store this data to the database (even if keeping bid/offer values in a disk is a requirement, it is usually better to have another application responsible for that). However, these two values must eventually be displayed to the user. That implies DTOs must transport those values although there is no need to persist them. Those values might also need to be combined with some persistent attribites like Financial Instrument details. Any chance to do that with ORM? Without ORM? Enjoying mixture of transient and persistent models? None of ORM actually offers any support for transient models just because the idea of ORM is to provide transparent persistence rather than managing a domain of business entities. In other words a ORM is persistence with caching, but what we really need is caching with optional persistence.

How a caching solution similar to IBM's one may help? Lets see how it copes with the issues just mentioned:
1) No need for DTOs since cache operates with objects stored in a transportable form so that to be able to fully or partially distribute it between the nodes in the data grid. All nodes share identically structured memory representation of each entity. Any GUI application is just another node in the grid and that significantly simplifies requirements to the middleware.
2) Cache-managed objects may be specially crafted to inflict minimal overhead when retrieving from or sending to the storage. In particular, entity class can be made smart enough to carry all information required by persistence thus elimiating multiple look-ups by the enitity class whenever the persister, the loader, the proxy factory, or any other related context is needed.
3) Persistence is optional for a caching grid. Some entities may be persistent, some - transient. In both cases entity remains manageable by the cache thus allowing for a generic API to work with objects (JPA EntityManager is a very good example of that). The grid also takes care of managing state changes in a transactional manner to any entity irrespective of whether it is persistent or transient.

It is just a simple and brief comparison of what advantages a distributed object model may offer versus the ORM-based approach. Actually using of the caching solution can make unnecessary even more crutches typically employed otherwise.