This page discusses - Implement mechanisms which support loose coupling between clients and componentsThis page discusses - Implement mechanisms which support loose coupling between clients and components
EJB access beans can greatly simplify client access to enterprise beans and alleviate the performance problems associated with remote calls for multiple enterprise bean attributes.
Access beans are Java bean representations of enterprise beans. They are typically used in client programs that employ JavaServer Pages (JSP) files, servlets, or enterprise beans that interface with other enterprise beans. Access beans shield you from the complexities of managing enterprise bean lifecycles. This means that you can program to enterprise beans as easily as you can program to Java beans, which greatly simplifies your enterprise bean client programs and helps reduce your overall development time.
To understand how access beans solve the problem of performance degradation in client-to-enterprise bean interactions, it is helpful to review how a client program typically accesses an enterprise bean:
Client obtains a context to the name server (name service context).
Client looks up the home of the enterprise bean using the name service context.
Client creates an enterprise bean instance from the enterprise bean home, which returns an enterprise bean proxy object.
Client accesses the remote methods of the enterprise bean instance through an enterprise bean proxy object using a remote call.
Since each client call to an enterprise bean proxy object is a remote call, performance declines if an enterprise bean has numerous attributes and multiple remote calls are made to set or get the attributes. Access beans solve the performance problem by simply caching server-side data, such as entity data, on the client side. A local cache of enterprise bean attributes significantly improves access speed to an enterprise bean.
There are four types of access beans in WebSphere Studio:
Java bean wrappers
Java bean wrapper access beans allow either a session or entity bean to be used like a standard Java bean.
NOTE: Java bean wrappers are not supported for beans in an EJB 2.0 module that contain only a local client view.
A copy helper access bean has the same basic characteristics as a Java bean wrapper, but introduces some additional characteristics of its own.
It is, for example, optimized for use with a single entity enterprise bean instance. Unlike a Java bean wrapper, a copy helper incorporates a single copy helper object that contains a local copy of attributes from a remote entity bean.
NOTE: Not supported for enterprise beans with only a local client view.
An EJB factory is an access bean that simplifies the creating or finding of an enterprise bean instance.
An EJB factory encapsulates the function provided by two objects: an InitialContext and an enterprise bean's home interface. It allows you to set the provider URL and other settings needed to perform the enterprise bean home lookup operation. The superclass of the EJB factory hides the implementation details of performing the lookup in the name service and the PortableRemoteObject.narrow() operation needed to acquire the EJB home implementation. (Note that EJB factories are not serializable because they are helper classes used to obtain remote EJB instances.)
A data class is an access bean that is similar to a copy helper access bean, but it employs a different technology.
A data class provides the data storage and access methods for cacheable enterprise bean properties. You can define multiple data classes for an enterprise bean, each with a different set of cached properties. Data classes are supported with enterprise beans having both local and remote client views.
In copy helpers, a property cache is stored as a hashtable within the access bean. However, in data classes, the cache is a container of the fields, getters, and setters needed to provide data storage and access of the cached properties. Also, the cache object remembers when properties are modified so that only 'dirty' properties are persisted when you commit the cache.
Java bean wrapper and copy helper access beans in WebSphere Studio are similar to the Java bean wrapper and copy helper access beans used in VisualAge for Java. (Note, however, that in WebSphere Studio there is no support for the rowset access beans used in VisualAge for Java.)
NOTE: Data access beans and copy helper beans cannot be created for session beans. Only Java wrapper access beans can be created for session beans. This not a limitation, this is by design. All access bean types can be created for entity beans.
By comparison, EJB factories and data classes are new types of access beans that are specific to Application Developer. Since EJB factories are like Java bean wrappers and data classes are like copy helpers, they can replace the function provided by Java bean wrappers and copy helpers. However, unlike the relationship between copy helpers and Java bean wrappers, data classes are not a superset of EJB factories.
The new technology that underlies EJB factory and data class access beans simplifies the process of creating or editing access beans. You can use the Create an Access Bean wizard or the Edit an Access Bean wizard to easily create or edit data class access beans. If you have an existing application that employs access beans that were created in VisualAge for Java, you can use the wizards to create or edit Java bean wrapper or copy helper access beans. However, if you are developing a new application in WebSphere Studio, it is recommended that you create only data class access beans, which employ the new technology. EJB factories are automatically created by the Create an Access Bean wizard regardless of whether you choose to create a data class, Java bean wrapper, or copy helper. For this reason, EJB factories do not appear on the selection page of the Create an Access Bean wizard, where you specify the type of access bean that you want to create.
Visit http://java.boot.by for the updates.