[ Pobierz całość w formacie PDF ]
String summary)
throws NoSuchCategoryException,DelegateException
{
102 Chapter Four
try
{
return sb.addForum( categoryPK, forumTitle, summary);
}
catch(CreateException e)
{
throw new DelegateException();
//log errors, etc
} catch(RemoteException e)
{
throw new DelegateException();
//log errors, etc
}
}
... //more similarly implemented business methods
}//ForumServicesDelegate
For message-driven beans, the business delegates are created to group sim-
ilar use cases (that map to different message-driven beans, as shown in Figure
4.2), together in one class. Implementation is similar to that in the session bean
example, except that all methods return void.
The client view of a business delegate is simple. When a method needs to be
executed, it simply creates a new delegate and calls a method on it. Behind the
scenes, the business delegate initializes itself (using an EJBHomeFactory) in
the constructor, and then delegates the method call. Since EJB homes are
cached in the EJBHomeFactory, creating and using a business delegate is rela-
tively lightweight.
The only time when the semantics of using a business delegate change is
when using them to front stateful session beans. In this case, a client does not
create new business delegates upon every request, rather, it needs to create it
once and then cache it locally, reusing the same delegate (which internally
maintains a reference to the same stateful session bean). In a servlet applica-
tion, delegates are cached in the ServletSession. In order to support storing the
stateful Business Delegate in the HTTPSession, some changes need to be made
to the way the business delegates are written:
Business Delegate must be serializable. Since the delegate is stored in
the ServletSession, it should be declared as Serializable, in order to sup-
port servlet engines that passivate HTTPSessions, or support session
replication in a cluster.
Must use an EJB handle to support serialization. Since the delegate
can be serialized, it cannot simply contain a reference to the EJBObject,
as in the code sample shown earlier. EJBObjects are not guaranteed to
be serializable, thus the delegate must be written to use a handle object
so that the reference to the stateful session bean will remain intact, even
through serialization.
Client-Side EJB Interaction Patterns 103
One important side effect of using a business delegate to front a stateful ses-
sion bean is that the class and its methods can be synchronized, which protects
a client from making concurrent calls to the same stateful session bean (which
is disallowed by the EJB specification, since EJBObjects are not threadsafe).
This problem can occur in Web sites that use frames (where each frame needs
to make a request that ends up going through the same stateful session bean),
but is corrected transparently to the developer by using a business delegate.
Another atypical use of the Business Delegate pattern is as a method for
integration between non-Java applications and EJB. Since business delegates
are just simple Java objects, they can easily be wrapped with non-Java code
using JNI or some Java-com bridge. Because all the J2EE Javax interfaces are
hidden from the client, you don t have to provide non-Java versions of them.
This approach to integration removes the dependencies between non-Java
applications and the application server vendor s ORB. Because of the age-old
ORB interoperability problems, having non-Java applications communicate
with EJB via business delegates guarantees that clustering and security will
function correctly.
When should the Business Delegate pattern be used? For projects in which
the same developers are writing both the client- and the server-side code, the
benefits of decoupling the client code from the server APIs may not be large
enough to warrant the extra legwork in writing and maintaining this layer.
However, for large projects, where the Web team is separate from the EJB team,
business delegate can result in better decoupling between client and server-
side developers which can more than make up for the implementation work.
Related Patterns
Business Delegate (Alur, et al., 2001)
CHAPTER
5
Primary Key
Generation Strategies
Generating primary keys (PK) in a portable, scalable, and reliable fashion is a
great challenge in EJB. Many application servers provide a proprietary way to
create primary keys for entity beans. For example, Weblogic allows you to
automatically generate a primary key by transparently using your database s
built-in sequence/counter. While in many cases this is a simple and viable
solution, the problem with this approach is that when migrating code from
one application server to another, the PK generation mechanisms between the
different CMP implementations may not be compatible. The only way to
achieve true portability for entity bean primary key generation is to call some
external, user-created structure.
This section will go over three different primary key generation best prac-
tices, used in creating primary keys for entity beans:
Sequence Blocks. Provides a pattern for creating incrementing, integer pri-
mary keys with very few database accesses. The pattern uses a stateless
[ Pobierz całość w formacie PDF ]