The real world's sluggish networks slow the performance of several cooperating business objects running on different machines. In general, if an entity bean is not in the same location as the process performing the task and the network is a bottleneck, either the process must come to the data, or the data must come to the process. An example of the former option is a session bean that performs a certain task on behalf of a remote client. The classic client-server model is an implementation of the latter alternative, but I use another approach that I call astral cloning. In this article, I will explain how to use an entity bean implementation as a client-side cached version of the bean.
Many developers use some kind of caching to make a distributed system perform.
This article presumes that you are familiar with EJB programming. Also, I explain astral cloning and its consequences as it relates to container-managed entity beans only. Astral cloning To explain how to implement astral clones, I will first illustrate how an entity bean typically works. Standard invocation through a stub Figure 1 shows how a client calls several methods on a generated stub that implements the bean interface. Using RMI, the stub delegates these calls to the container, which is generated to run the bean implementation's instances.