Context
Application clients need to exchange data with enterprise beans.
Problem
Java 2 Platform, Enterprise Edition (J2EE) applications implement server-side
business components as session beans and entity beans. Some methods exposed by the
business components return data to the client. Often, the client invokes a business object's
get methods multiple times until it obtains all the attribute values.
Session beans represent the business services and are not shared between users. A
session bean provides coarse-grained service methods when implemented per the Session
Facade pattern.
Entity beans, on the other hand, are multiuser, transactional objects representing
persistent data. An entity bean exposes the values of attributes by providing an accessor
method (also referred to as a getter or get method) for each attribute it wishes to expose.
Every method call made to the business service object, be it an entity bean or a
session bean, is potentially remote. Thus, in an Enterprise JavaBeans (EJB) application such
remote invocations use the network layer regardless of the proximity of the client to the
bean, creating a network overhead. Enterprise bean method calls may permeate the network
layers of the system even if the client and the EJB container holding the entity bean are both
running in the same JVM, OS, or physical machine. Some vendors may implement
mechanisms to reduce this overhead by using a more direct access approach and bypassing
the network.
As the usage of these remote methods increases, application performance can
significantly degrade. Therefore, using multiple calls to get methods that return single
attribute values is inefficient for obtaining data values from an enterprise bean.
Forces
All access to an enterprise bean is performed via remote interfaces to the bean. Every
call to an enterprise bean is potentially a remote method call with network overhead.
Typically, applications have a greater frequency of read transactions than update
transactions. The client requires the data from the business tier for presentation, display, and
other read-only types of processing. The client updates the data in the business tier much
less frequently than it reads the data.
The client usually requires values for more than one attribute or dependent object
from an enterprise bean. Thus, the client may invoke multiple remote calls to obtain the
required data.
The number of calls made by the client to the enterprise bean impacts network
performance. Chattier applications-those with increased traffic between client and server
tiers-often degrade network performance.
Solution
Use a Transfer Object to encapsulate the business data. A single method call is used
to send and retrieve the Transfer Object. When the client requests the enterprise bean for the
business data, the enterprise bean can construct the Transfer Object, populate it with its
attribute values, and pass it by value to the client.
Clients usually require more than one value from an enterprise bean. To reduce the
number of remote calls and to avoid the associated overhead, it is best to use Transfer
Objects to transport the data from the enterprise bean to its client.
When an enterprise bean uses a Transfer Object, the client makes a single remote
method invocation to the enterprise bean to request the Transfer Object instead of numerous
remote method calls to get individual attribute values. The enterprise bean then constructs a
new Transfer Object instance, copies values into the object and returns it to the client. The
client receives the Transfer Object and can then invoke accessor (or getter) methods on the
Transfer Object to get the individual attribute values from the Transfer Object. Or, the
implementation of the Transfer Object may be such that it makes all attributes public.
Because the Transfer Object is passed by value to the client, all calls to the Transfer Object
instance are local calls instead of remote method invocations.
业务层模式:Transfer Object—传输对象模式
最新推荐文章于 2019-06-10 09:59:53 发布