Re: Session Facade's EB placeholders: PKs or Handles?

[Juan Pablo Lorandi]

Title: Message

Handles usually persist the PK and the EJBHome JNDI binding and make the proper lookups(lookup home, then lookup bean using the PK). There is no evident gain of using handles, and many will also point to the original server instance(it really depends on the implementation of the server, but this is the most common case). Perhaps you could test you particular app server, but I doubt that

 

Regarding the possible manipulation of PKs, simply encapsulate them:

 

public interface FrontEndPK extends java.io.Serializable {

}

 

public interface FECustomerPK extends FrontEndPK {

    public String getFullName(); // maybe allow some access to some properties???

}

 

Making your PKs implement FrontEndPK instead of Serializable. Inmediate downside is that you would have to implement a PK class even for PKs that map to existing classes (like String or Long). Or just use Serializable as the return format for PKs. Either way, your Outer Facade would look like this:

 

public FrontEndPK findCustomer(String param);

public java.io.Serializable findCustomer(String param);

public void deposit(FrontEndPK customer, double amount);

public void deposit(FECustomerPK customer, double amount); // leverages strong type checking

 

Since from what you tell no interaction with PKs is needed, just the ability of the FrontEnd to obtain PKs from the Outer Facade and be able to store them, then this should be enough(in reality it might be different, if so, please explain further).

 

My 2c,

 

Juan Pablo Lorandi

Chief Software Architect

Code Foundry Ltd.

[EMAIL PROTECTED]

Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050  Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com

 

Disclaimer:

 

Opinions expressed are entirely personal and bear no relevance to opinions held by my employer.

Code Foundry Ltd.'s opinion is that I should get back to work.

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of May Charles N
Sent: Wednesday, October 16, 2002 2:46 PM
To: [EMAIL PROTECTED]
Subject: Session Facade's EB placeholders: PKs or Handles?

I'm looking for opinions on how to structure an outer Facade, friendly to Applets/JSPs, which ultimately manipulates Entity Beans. Here is the proposed architecture:

Outer Session Bean Facade -> Inner Session Bean Facade -> Entity Beans

This much is given: the Entity Beans are CMP and TX_REQUIRED, and are intended only to be manipulated by the Inner Session Facade. The methods on the Inner Session Facade have arguments and return values which all rest in EJB Space (that is, where Entity Beans are passed and returned, they are passed 'directly' as implementers of javax.ejb.EJBObject rather than passing a placeholder like a Handle or a Primary Key).

Where I want opinions is on structuring the Outer Session Facade's methods. Where I need to represent Entity Beans for method parameters or return values, I can't use javax.ejb.EJBObject implementers because I need them to be able to serialize. I see two options:

• pass javax.ejb.Handle instances.
• pass primary key instances.
  

I see the advantage of passing Handles to be that the front end can only hold one if it actually corresponds to an existing Entity, and that when the Handle gets passed to the back end as a parameter there may be some savings when the Handle has to be transformed into its javax.ejb.EJBObject counterpart. The disadvantage is that Handles are larger when serialized than primary keys are.

The advantage of passing Primary Keys instead is that they are type-safe and leaner on the wire (smaller when serialized). They are also easier for novice front-end developers to conceptualize. On the other hand, they invite the front-end to toy illegitimately with the inner values of the primary keys. For example, the front-end could instantiate a primary key which doesn't correspond to an actual Entity Bean, and relationships between Entity Beans could be manipulated in a non-object oriented way by direct getter/setter methods for foreign key values. Also, whenever a primary key is intercepted by the inner session facade, the appropriate findByPrimaryKey method must be called rather than just handle's getEJBObject(). I just don't see that the front end should ever really concern itself with the internal value of the primary key for any Entity Bean.

Based on my reasons above, I lean toward making the outer session facade pass and receive Handles as placeholders for Entity Beans, rather than primary keys. What do others think about this?

Charles May
Technology Delivery Department (TDD)
Mellon Financial Corporation
Pittsburgh, PA