This is an odd little idiom that I'm not ready to call a pattern.  I saw it first (with moderate disbelief) at a Customer site, and then later found myself recommending it at a couple more customers later.

It works like this.  A "standard" Entity Bean is an Object-Oriented view of a Database of some sort. Generally, you create Entity Beans to access some existing database tables, or some other sort of existing datasource.  However, this customer had done an odd thing.  Their application's "real" data was stored in a back-end mainframe system, in a form that was not at all conducive to object-oriented modeling.  So, what they did was when a user first started using their application, they kicked off a background thread that read the raw data out of this mainframe system, then created a set of Entity Beans to hold the data in a more meaningful form.  The Servlets and JSP's then used that data stored in the Entity Beans.

They did end up mapping the data in the Entity Beans to a mid-tier relational database, but that wasn't really necessary -- they could have used EJB Option A caching to simply store the Entity Beans in memory.  That is because the Entity Beans were really only acting as an object cache in this instance.  However, using a relational database and Option C caching did make it possible to allow multipe EJB Servers to share the load in a workload-managed environment.

Comments?  

-----

''A question: please forgive me, but what is "backwards" about this way of using entity beans?  Were they using EntityBeansAsDataGateways? Did they truly have a new way HowToUseEntityBeans?''

I think what is backwards is the design experience.  Usually it's either top-down in going from EJB model to data, or bottom up from data to EJB model.  This was an extreme case of meet-in-the-middle where they said that the EJB's don't represent back-end data ''at all'' but instead represent their own transformation of the data, but only temporarily...

(posted 1 hour later) Ahhh... now I see your confusion Randy.  The thing that I thought odd about this is that these people were using an EJB server for EXACTLY the same thing we used to recommend GemStone being used for all the time -- a  mid-tier object cache between the Data and the client.   You see the problem is that EJB's weren't designed to do that, and thus it surprised me when I saw someone building an object cache with them...  Kyle