Using an EJB as a source for a Model

Question

Hi,
Before starting with this post content it might be helpful to give you the desired output of what I am trying to do. Basically I need to have an HTML table that is populated from an EJB.
The current proposed solution is as follows: the Model that is associated with a TiledView will be used as client for the EJB. The Model will make use of the methods in the EJB to get different java.util.Collection objects for different Helper classes based on the find criteria.
For example, if the EJB represent a book and there is a home method to retrieve a list of books based of the book category. In this case the Model will act as a client of the EJB, retrieve the list of books and use the different methods in the Model, such as insert and retrieve, to get the list of books and to add a book up on request.
I know that my post might not be clear. But as I said, all that is needed is to have a TiledView that displays books information, which are retrieved from an EJB, and allow a user to select a book to display its information.
My suggested solution could be completely wrong, not visible and reflect a bad design. Please if any one went through such a situation give me a hint.
Regards,
Basil Mahdi

Answer 1

Basil,
This is some material I snipped from an internal Sun forum I posted to regarding a simple EJB Jato integration example.
I hate to give just any EJB JATO example because frankly there are so many different use cases with EJBs that no one example will match up against your needs. You can use an EJB
- in a Custom Model Operation you can encapsulate an EJB Method invocation
- in a Custom Command you can encapsulate any arbitrary code include calling an EJB
- as the backingstore for a CustomModel
- use a BeanAdapterModel to adapt to the value/transfer beans which are uses as parameters or return values of EJB methods
- use an ObjectAdapterModel to adapt an EJB directly by assigning the EJB reference in setObject() in the constructor of the OAM
As you can see, an EJB is just another business object API...its just that you acquire the reference with a few lines of ugly JDNI and Home interface APIs.
Nevertheless, here is some guidance. I would like to reinforce that there is no direct solution for adapting an EJB from BAM; EJBs are not JavaBeans. What is a solution is to have the parameters or return values of your EJBs use value/transfer object patterns in the form of JavaBeans. The BAM may be used to adapt to these parameters or return value of the EJB.
In short, when using BAM in a tileview to work with an EJB, there is little difference than using BAM at any other time, you the developer, must manage/code the placement of the EJB parameters directly into the BAM or in a scoped attribute to be used by the BAM.
In another example, you may have a SLSB which models an employee called EmployeeSupport. You may have a transfer object (JavaBean) of type EmployeeRecord. You may have operations on the EJB including:
public EmployeeRecord findEmployee(String employeeID);
public EmployeeRecord[] findEmployees(String location);
public void updateEmployee(EmployeeRecord);
One could create a BAM in the studio called EmployeeModel
You would set the JavaBean class to EmployeeRecord
You would run the Design Action to bootstrap the properties of EmployeeRecord as fields on the model
Now you have a model which is ready to adapt to EmployeeRecord bean.
Feel free to add material to the EmployeeModel to make a richer API; for instance you could encapsulate some EJB'ish code in their to act as a service locator for a EmployeeSupprt SLSB.
protected static EmployeeSupport support;
static {
javax.naming.Context context = new javax.naming.InitialContext();
Object objref = context.lookup("ejb/EmployeeSupport");
EmployeeSupportHome home = (EmployeeSupportHome)
javax.rmi.PortableRemoteObject.narrow(objref,EmployeeSupportHome .class);
support = home.create();
public static EmployeeSupport getEmployeeSupport() {
return support;
If you really wanted to hide the EJB'ishness of the EmployeeSupport you could even wrap the behavior and handle exceptions, etc.
public static EmployeeRecord findEmployee(String employeeID) {
return getEmployeeSupport().findEmployee(employeeID);
public static EmployeeRecord[] findEmployees(String location) {
return getEmployeeSupport().findEmployees(location);
public static void updateEmployee(EmployeeRecord record) {
return getEmployeeSupport().updateEmployee(record);
You could even help the view developer latch EJB transfer objects into the model for adaption; saving them from the effort
public void adaptEmployee(String employeeID) {
setBean(findEmployee(employeeID));
public void adaptLocation(String location) {
setBean(findEmployees(location));
public void save() {
updateEmployee((EmployeeRecord)getBean());
Create a search ViewBean, place a text field on it for an EmployeeID and button labeled Find. Leave the EmployeeID model binding default (to use a DefaultModel memory model). Open the handle request event method on the viewbean for the Find button.
public void handleFindRequest....{
EmployeeModel model = .....;
model.adaptEmployee(getEmployeeIDChild().getValue());
// display Edit page which has fields for editing the employee record
Create an edit ViewBean, with editable fields bound to the EmployeeModel; add an button labeled update
public void handleUdpateRequest....{
EmployeeModel model = .....;
model.save();
// do whatever is next ....
Notice that the we are jumping across request boundaries in this example. Using just default model reference configurations, the EmployeeModel will be created brand new during the Update request and there will be no bean currently adapted. Most likely, you would want to have the model (and hence its adapted bean) stored in HttpSession across at least these related requests. In this case the model reference used by the search ViewBean would have "store in session" true. and the model reference in the edit ViewBean would have "look in session" true.
What we recommend is that someone who understands the business tier design take the responsibility to create a set of "business delegates" as JATO models. An advanced technique would be to encapsulate these models in a component library JAR which multiple web applications can reuse. As you can imagine, there are so many ways to do the same thing. You could just as easily make a CustomModel or SimpleCustomModel to adapt to your EJB. You can also, if your EJB uses primitives or JavaBeans (or graphs of JavaBeans) for all parameters, use the ObjectAdapterModel to directly connect to an EJB.