Building and Using EJB Controls

EJBs are a part of everyday life for the Web application developer. WebLogic Workshop offers a full feature set for consuming and creating EJBs. From an EJB user 's perspective, using an EJB requires no more than adding an EJB control to a project. EJB controls are simply wrappers around existing EJBs that allow them to be referenced easily in a Workshop application. Figure 8.5 shows the Insert Control - EJB Control dialog box.

Figure 8.5. The Insert Control - EJB Control dialog box.

To add a control to a Page Flow or another control, follow these steps:

1. From the Data Palette, click Add, EJB Control.

2. Set the control's instance name .

3. Enter a name for the control's Java Control Extension (JCX) wrapper.

4. Select a local control, packaged in an EJB Control project within the application, or a Server EJB, previously bound into the Java Naming and Directory Interface (JNDI) tree of a running instance of WebLogic Server.

5. Click Create to add a new control that your application can use.

WebLogic Workshop uses the EJBGen utility to take the drudgery out of creating EJBs. EJBGen takes a set of definition files and a single implementation file per EJB, and generates the required infrastructure to support the EJB at runtime. Figure 8.6 shows adding a new method to an existing control. You simply supply the name of the method, and it's generated for you. You can then edit the new method and change its signature if needed by double-clicking its name. The implementation file then contains all the used developed EJB code.

Figure 8.6. Adding methods to EJBs.

To create a new EJB, simply select a folder within an EJB project, right-click on the folder, and choose the EJB type you need. Full support is available for session beans, message-driven beans, entity beans, and entity beans from database management system (DBMS) tables. Workshop then creates an .ejb file to contain the control's implementation.

Selecting a method displays the EJB Property Editor with the familiar set of EJB properties. Transaction attributes, roles, and so forth are all supported at the method level. The details of EJBs are beyond the scope of this chapter; however, for more information, read EJB 2.1 Kick Start (Peter Thaggard, Sams Publishing, ISBN 0-672-32178-5).

By selecting the EJB as a whole, the developer can manipulate the default attributes that apply to the EJB. Those familiar with EJBs will be happy to see that all the WebLogic Server default tuning attributes are available, such as enable-call-by-reference , max-beans-in-cache , and max-beans-in-free-pool . In the past, all these attributes had to be edited manually in the weblogic-ejb.xml file.

Figure 8.7 shows the opening page of the wizard for creating an entity bean from a DBMS table. The entity bean wizard enables you to create an entity EJB that accesses a database table quickly and easily. To create a new entity EJB, select the datasource, table, fields, and other attributes of interest for the entity EJB you're creating. When you have completed the wizard steps, an entity EJB is created that fully supports managing the selected data from the selected database table. To save you time when creating entity EJBs, EJBGen generates methods to get and set fields and to find and add database rows.

Figure 8.7. Adding database-supported entity beans.

JNDI NAMING

WebLogic Workshop provides a set of properties for controlling an EJB's JNDI name. The Naming/Remote EJB properties control the JNDI name and the bean's Home and Remote class names . Likewise, the Naming/Local EJB properties control the local properties. If no values are supplied, Workshop provides functional, albeit cryptic, defaults based on the originally chosen EJB. When the application is deployed into a production environment, if you need to change the JNDI name, you can use the EJB properties to do so.

SHOP TALK : NAMING CONVENTIONS

WebLogic Workshop makes it easy to develop applications and controls ”perhaps too easy, in fact. Over the course of a single six- to eight-week development effort, I discovered that my team and I had written literally hundreds of controls, Page Flows, and Web pages, not to mention dozens of applications, Schemas, content for portals, and other Web application artifacts. What became painfully obvious was that, although each of us was internally consistent in our own naming schemes, we didn't name anything in exactly the same way. At a certain point, all our artifacts needed to be brought together. Although the application doesn't care whether you name a variable myVariable , MYVARIABLE or mYvARIable , it became clear that some simple naming conventions would help.

There are dozens of published naming conventions that focus on method and variable names, but we simply chose one and stuck with it. However, WebLogic Workshop introduces a number of new areas, namely projects, that have yet to be addressed. Our development team decided to examine and specify Web application projects, control projects, EJB projects, portal projects, and Schema projects, as most of our work fell into these areas. We also discovered that all our work fell into two distinct groupings: by business area or by function. Therefore, we came up with a set of business prefixes and functional prefixes. In addition, each prefix had its own set of prefixes. By combining a well-known set of prefixes with some simple project rules, we were able to minimize and in some cases eliminate much of the naming convention confusion. We simply managed a single prefix document and a slightly evolving set of naming guidelines. I've reproduced some of these guidelines in the following tables in the hopes that others can benefit from them.

Control Projects

Much of our work involved developing control projects that would be dropped into Web applications as required.

NAMING-CONVENTION AREA	CONVENTION	NOTES AND EXAMPLES
Project name	<Functional area prefix> Controls	All projects are prefixed with a word specifying the functional area they implement and end in the word Controls ”for example, AccountingControls .
Folders	<by sub prefix>	Folders and subfolders have the subfunctional area added to the name, such as AccountingControls/finance/billing . Because folders represent packages, this naming scheme avoids name clashes when multiple control sets are used together.
Control implementations	<subsystem within application> Resources intended to be used directly, such as controls, utilities, value objects, and so forth	Implementations are then separated by their functional areas ”for example, controls, exceptions, value objects (vinfo), specialized utilities ( utils ), and so forth. Some examples are .../finance/controls/*.jcs (or *.jcx) and .../finance/exceptions/*Exception.java . Note that the ellipses ( ... ) are used to indicate subfolders of a project or an application. For simplicity, database and rowset controls are prefixed with the name of the table they access, such as Tablename DB.jcx . All exceptions should be named via the exception they implement and end in Exception.java , as in ...finance/exceptions/ UnknownAccountException.java . Value objects are named by the data they return and end in Info .java , as in finance/controls/AccountInfo.java . Value objects should be packaged with the control that uses or returns them. Special utilities are packaged within utils ”for example, .../utils/MorgageRateCalculator.java . Note that exceptions, value objects, and utility classes are always stored at the FunctionalArea Controls \Subarea\SubSystem level to avoid naming clashes.
Supporting resources	subsystem /support Any supporting resources not intended to be used directly	Specialized support resources intended to be used only within a given package are nested within that package, as in ...finance/controls/support/ SupportResource .

EJB Projects

EJB projects were named similarly to control projects.

NAMING-CONVENTION AREA	CONVENTION	NOTES AND EXAMPLES
Project name	<FunctionalArea >EJB	Prefixed with the overall functional area and ending in EJB ”for example, CasinoTrackingEJB .
Folders	<subfunctionalarea>	Control folders and subfolders represent further breakdown of the functional area, as in gametableservices .
EJBs	<Function>{SEM} EJB Specific EJBs should be named by their function, followed by S for session, E for entity, or M for message-driven, and always end with EJB .	The structure should be consistent with control projects but use EJB rather than Control in the name ”for example, ... / ejb/checkrouletteSEJB.ejb , .../exceptions/*Exception.java , and .../utils/*.java .
JNDI name	JNDI names should be defined using traditional reverse-naming conventions.	com.casino.gametableservices.checkrouletteSEJB

Web Application Projects

Web application projects are used to contain the external interfaces, such as HTML, that clients and customers see.

NAMING-CONVENTION AREA	CONVENTION	EXAMPLE
Project name	<Functional area> web	All projects are prefixed with the functional area and end in web . Note that you need to be careful when naming Web applications because they ultimately result in a URL; for simplicity's sake, they are set in lowercase, as in casinoweb .
Folders	<Subsystem>	Subsystems are represented by the functional area they define, such as casinoweb\gaming\ .
Page Flows	<function> Controller.jpf	Follow the WebLogic Workshop convention but add the function as a prefix ”for example, listallgamesController.jpf .
Page Flow actions	<TaskactionTaskFunction>	Actions are best named as noun-verb pairs, starting with the noun and then adding the action being performed, as in userAdd . You can also reverse the order, as in addUser .
JSPs	<task> .jsp	JSPs are named based on the action they perform and are set in lowercase, as in makeuserbet.jsp .

In General

In general, the following conventions were helpful in quickly finding a specific bit of functionality.

NAMING-CONVENTION AREA	CONVENTION	NOTES AND EXAMPLES
Web services	function WS.ws	All Web services were named ending in WS ”for example, findAccountWS.jws .
Business process definitions	function PD.{jwf jpd}	Business process definitions always end in PD , as in cancelBetPD.jpd .