[ Pobierz całość w formacie PDF ]

public interface Employee extends EJBLocalObject, AttributeAccess
{
//Since attributes are stored in a hashmap in the entity bean,
//we need a central place to store the  keys used to reference
//attributes, so that the clients and the entity bean won t need
//need to be hard-coded with knowledge of the attribute key strings
public final static String ID =  EMPLOYEEID ;
public final static String NAME =  NAME ;
public final static String EMAIL =  EMAIL ;
public final static String AGE =  AGE ;
public final static String SSN =  SSN ;
public final static String SEX =  SEX ;
...
}
This approach works great for the DTO factory approach, where a ses-
sion bean is querying the entity bean directly for its attributes, with the
intention of returning a hard-coded data transfer object to the client,
instead of a HashMap. Here, only the session bean and the entity bean
need to agree on the names of the attribute keys, making the local/
remote interface a good place to localize names of the attributes. This
approach breaks down when using the Data Transfer Hashmap pattern,
since the client also needs to know the names of the key-values, but the
client does not have access to the entity bean s remote/local interface.
Shared class with static final member variables. Here we can create a
class that is shared by both the client classes and the server classes,
which is used to encapsulate the actual strings used to populate and
read strings from a HashMap behind a hard-coded final static variable,
accessible by both client and server. For example, a client would query
a hashmap for an attribute as follows:
accountMap.get(Names.ACCOUNTBALANCE)
Where the shared class called Names would look like:
public class Names {
public final static String ACCOUNTBALANCE =  BALANCE ;
...
}
38 Chapter One
One disadvantage to this method is that should the key mappings need
to be updated or added to, the new class would need to be redistributed
to the client and the server (and their JVM would thus need to be
restarted).
Place the Attribute contract in a JNDI tree. In this approach, a single-
ton of sorts is maintained by placing a class containing the keys in a
JNDI tree, accessible by client and server. Client and server code would
not need to be recompiled or rebooted, when keys were changed/
updated, since a central object in a JNDI tree would always contain the
freshest copy of keys. The trade-off with this solution is the overhead
incurred in grabbing the contract from the JNDI tree whenever key-
values are required.
The Generic Attribute Access pattern has many advantages:
One interface across all entity beans. Entity bean clients can manipulate
entity beans consistently via the attribute access interface, simplifying
client code. Entity beans are also simplified, because the attribute access
can be encapsulated in a superclass.
Scales well to large entity beans. Whether an entity bean has 20 or
2000 attributes, attribute access logic is simplified to just a few lines.
Low cost of maintenance over time. New views of server-side data can
be created that do not require any server-side programming. Clients can
dynamically decide which attributes to display.
Allows for dynamic addition of attributes at run time. When using
BMP, this pattern can easily be extended to allow for the ability to add
and remove attributes from an entity bean dynamically. This can be
achieved by adding an addAttribute and removeAttribute method to the
interface, which simply performs operations on the attribute HashMap.
Like all patterns, using Generic Attribute Access has its trade-offs:
Additional overhead per method call. For each attribute call, clients
must use an attribute key to identify attributes. Finally, attributes need
to be cast to their appropriate type after being extracted from the
HashMap object.
Need to maintain a contract for attribute keys. Since attributes are
requested by string, clients need to remember the key-strings used to
identify attributes. Defining a key-attribute contract (discussed earlier
in this pattern), can alleviate these dependencies.
Loss of strong typing/compile-time checking. When we use DTOs,
values passed by gets or sets are always of the correct type; any errors
would be passed at compile time. When we use Generic Attribute
EJB Layer Architectural Patterns 39
Access, attribute access must be managed by the client at run time by
casting objects to their correct type and associating the correct attribute
type with the correct key.
Overall, the Generic Attribute Access pattern provides a generic method of
managing the state of entity beans, eliminating the bulky repetitive code asso-
ciated with domain-specific entity bean data access.
Related Patterns
Property Container (Carey, et al., 2000)
Data Transfer HashMap
40 Chapter One
Business Interface
The EJB specification mandates that the enterprise bean class provide an
implementation of all methods declared in the remote or local interface, but
the bean cannot directly implement these interfaces.
How can inconsistencies between remote/local interface methods
and the enterprise bean implementation be discovered at compile
time?
* * * [ Pobierz całość w formacie PDF ]