Summary
By the time Sun released version 1.0 of the Enterprise JavaBeans (EJB) specifications in March of 1998, several vendors not only had endorsed this new server-side component architecture, but also had begun developing products based on the evolving specifications. Today there are several products that fully implement the required features of EJB 1.0, and some that also support optional EJB features. This article provides an overview of EJB and looks at how some of these products support EJB. If you have wondered what EJB is or have bits and pieces of information about it but are missing the big picture, you need to read this article.Bonus: Includes a Middleware and EJB Glossary. (9,000 words)
By Anil Hemrajani
Last month JavaWorld published the first article in this two-part series, covering the state of Java middleware. The first article provided an overview of the many features offered and promised by Java middleware; this article focuses specifically on one of those features: Enterprise JavaBeans (EJB).
By now you've probably heard about EJB, read articles about it, and possibly even written a few enterprise beans yourself. However, if you're like many people out there, you might not understand the big picture -- despite the fact that working with EJB is supposed to be extremely simple. Here's a list of questions many developers new to EJB struggle with:
This article addresses these and other common concerns about EJB. It includes examples of how some vendors provide EJB support. Moreover, this article addresses the following key issues:
In short, this article describes the current state of EJB and the Java middleware (tools) that support it. Rather than focus on in-depth coding examples, I devote attention to the more challenging aspects of working with EJB: the design issues and tools selection. To learn more about nitty-gritty programming with EJB, see the JavaWorld articles in the Resources section below. Furthermore, EJB programming (developing enterprise beans), in my opinion, is the easy part (as Sun intended it to be); design issues and tools selection are the more challenging aspects of working with EJB.
Note that throughout this article I use the terms Java middleware, application servers, and EJB servers somewhat interchangeably. Marketeers, authors of the EJB (or CORBA/DCOM) specification, and niche developers may see many distinctions among these terms, but for the purpose of this article they all mean the same thing.
Note also that this article is jam-packed with information on EJB. While it may seem overwhelming, don't be discouraged: EJB developers typically don't have to deal with all the issues discussed here. In fact, the EJB specifications define several roles and responsibilities that can be handled by either one person or several people, depending on the size of your project. Nevertheless, an understanding of the big picture is essential. And remember, developing enterprise beans is actually extremely simple.
Why do we need EJB?
Ever since the Web began to make the Internet popular and useful for almost everyone (not
just the government and students), new Net technologies (Internet, intranet and extranet)
have emerged from all directions and organizations. It is now close to impossible to keep
up with these technologies at the speed they're being introduced.
So, why should we add EJB to this list of technologies? Well, there are various reasons, but before we look at the reasons for EJB, let's look at several reasons why we need middleware or, more specifically, application servers.
Glue between clients and servers
On the front end, there are many different types of clients (desktops/browsers, PDAs, Web
phones, NCs/thin clients, different platforms). On the back end, there are many types of
platforms (Unix, Windows, Mac) and data repositories (RDBMS, ODBMS, Mainframe). Java
middleware connects the two (see Figure 1). In other words, business logic can be
implemented as reusable components in the middle tier, thereby providing access for a
variety of clients to all types of data on the back end.
|
Scalability and standards-based technologies
The original HTML and/or CGI solution isn't scalable and APIs such as Netscape's NSAPI and
Microsoft's ISAPI are proprietary. Most app servers provide standards-based technologies
that scale well. Additionally, these products typically provide features such as resource
pooling, fault-tolerance, security, management, and other built-in bells and whistles.
One-stop shop
Many app servers are a one-stop shop, that is, they support all the necessary protocols to
provide a complete application development solution. Take for example, BEA's WebLogic
application server, which provides support for HTTP, RMI, EJB, Servlets, JNDI, JDBC, and
other protocols, or Oracle's Application Server, which supports HTTP, CORBA/IIOP, and
more. This frees you from having to run multiple servers (e.g., a Web server, a CORBA ORB,
and an RMI server).
Now that we've looked why application servers are needed for Net development, let's look at why there's a need for EJB.
Productivity
EJB increases productivity for developers because they need not worry about low-level
system programming (such as connection pooling, security, transaction management, state
management, persistence, number of clients, and multithreading); they simply concentrate
on writing the business logic and develop the enterprise bean almost as if it will be used
by a single client.
Open server-side component architecture
In the past two or more decades, most server-based products have used the vendor's
proprietary APIs, so not many off-the-shelf, plug-and-play components have been available,
except from the vendors themselves. EJB changes this by providing portability across
platforms and vendors. Because EJB sets a clear path for application vendors, all must
provide the same minimal functionality in their server products, opening the flood gates
for component builders to build off-the-shelf server-side components, not just client-side
GUI components. For example, an off-the-shelf enterprise bean could handle functions such
as credit card validation.
Object-oriented programming on the server
Thanks to Java's object-oriented roots and the EJB component model, organizations can more
easily create and use reusable components, and thus spend less time writing code. One
factor helping this reusability is that the logic and data are packaged together in
objects. Additionally, EJB containers can translate relational data into objects
automatically. This eliminates the distinction between accessing data from a database
versus from any other object.
Java in the middle tier
EJB brings all Java features (such as security, directory services, and serialization) to
the middle tier. In general, EJB drives forward Sun's layer-and-leverage philosophy, which
calls for portability and leveraging existing enterprise investments.
Support for other languages and CORBA
EJB provides support for other languages and CORBA because the middleware vendor, not the
enterprise bean developer, handles the communication protocol issues. For example, the
default wire protocol for EJB is RMI; however, the EJB 1.0 specifications also provide
mapping to CORBA. Furthermore, a vendor can use any distributed protocol to support many
types of clients (COM/DCOM for example).
Who will support EJB?
EJB by itself isn't a product. Rather, it's a specification. One of the key objectives of
EJB is portability across platforms and vendor products. Several vendors already support
EJB or have announced plans to support it in future versions of existing products;
additionally, Sun intends to provide a reference implementation of EJB by the second
quarter of this year. Table 1 shows a partial list of vendors that have endorsed EJB:
| Vendor | Product |
| BEA Systems | WebLogic Application Server |
| Bluestone | Sapphire/Web |
| Gemstone | Gemstone/J |
| IBM | Websphere |
| Information Builders | Parlay Application Server |
| Inprise | Inprise Application Server |
| Lotus | Notes/Domino |
| Netscape | Netscape Application Server (Kiva) |
| Novera | jBusiness |
| Oracle | Oracle Application Server |
| Persistence | PowerTier for EJB |
| Progress | Aptivity, Webspeed |
| Secant | Extreme Enterprise Server for EJB |
| Silverstream | Silverstream Application Server |
| Sun | NetDynamics |
| Sybase | Enterprise Application Server |
| Valto Systems | Ejipt |
| Wall Data | Cyberprise Server |
Table 1. EJB endorsers
What exactly is EJB?
EJB is part of Sun's Java Platform for the Enterprise (JPE) initiative. JavaBeans
introduced a standard way of developing and using Java components on the client side.
Similarly, EJB serves as the Java component architecture for the server side.
EJB enables software developers to build server-side, reusable business objects (enterprise beans). However, EJB takes the notion of reusable objects one step further by providing for attribute-based programming to dynamically define lifecycle, transaction, security, and persistence behavior in EJB applications. For example, using attribute-based techniques, the same enterprise bean (in its binary form -- that is, class and/or Java archive [JAR] files) can exhibit different transactional behavior in different applications. Additionally, the method of persisting an enterprise bean can be altered during deployment without ever having to recode the enterprise bean. For example, an entity bean could use a relational database for its persistence or CICS; the enterprise bean developer never needs to know.
To provide a more concrete picture of what EJB is, let's look at the following topics borrowed from the EJB 1.0 specifications:
Goals
The EJB 1.0 specifications define certain goals for Java middleware vendors who will
implement this standard. The following are a few of these goals:
Features
To fulfill the above goals, EJB provides several features that make this distributed
component architecture so appealing. Table 2 provides a snapshot of these features (more
details on each feature are provided further in the article).
Feature |
Supported through |
| Component model |
|
| Object Persistence |
|
| Transaction management |
|
| Exception handling |
|
| Security |
|
| Naming and directory service |
|
| Wire protocol |
|
| Support for CORBA |
|
| Attribute-based programming |
|
| Deployment |
|
Table 2. EJB feature list
Three enterprise bean types -- which to use?
EJB provides three enterprise bean types: stateless session beans, stateful session beans,
and entity beans.
Stateless session beans are intended to be simple and lightweight, that is, easy to develop with low runtime resource requirements on the server for scalability components. Any state, if required, is maintained by the client, thereby making the server highly scalable. Since no state is maintained in this enterprise bean type, stateless session beans aren't tied to any specific client, hence any available instance of a stateless session bean can be used to service a client.
Stateful session beans provide easy and transparent state management on the server side. Because state is maintained in this enterprise bean type, the app server manages client-bean pairs. In other words, each instance of a given enterprise bean is created on behalf of a client and is intended to be a private resource to that client (although it could be shared across clients using the enterprise bean instance's handle). In essence, a stateful session bean is a logical extension of the client, except some of the client's load is distributed between itself and the enterprise bean on the server. Any conversational state-related data in the object's variables doesn't survive a server shutdown or crash, although a vendor could provide an enhanced implementation to make shutdowns and crashes transparent to the client by maintaining the enterprise bean's state. Stateful session beans can access persistent resources (such as databases and files) on behalf of the client, but unlike entity beans, they don't actually represent the data. For example, a session bean could access data via JDBC or an entity bean.
Entity beans are persistent objects and represent an object view of data
stored in permanent storage. To better understand what an entity bean is, think of it as a
row in a relational database. Along those lines, an entity bean can be created, found, and
removed -- using the create(), findxxx, and remove()
methods -- just as a database row can be INSERTed, SELECTed, and DELETEd in an SQL
database. An entity bean lives in an EJB container in much the same way a record
lives in a database. Herein lies the beauty of entity beans; a vendor can provide EJB
containers for various data sources (such as Oracle or CICS) and the enterprise bean
developer never needs to know. Unlike stateful session beans, entity beans can be accessed
by multiple clients concurrently -- the concurrency is managed by the EJB container. Since
entity beans provide an object view of the data, the actual data they map to in the
permanent store may either be created via the entity bean's create() method
or exist beforehand in the permanent store (for example, using an SQL database's INSERT
command). On the flip side, entity beans can be removed, either using the entity bean's remove()
method or by deleting the bean directly from the permanent store. The find()
methods can be used to return either a single object or collection of objects.
Deciding which type of enterprise bean to use is more an issue of design than of development. Here are two general rules of thumb:
Despite their differences, session and entity beans do share the following characteristics:
javax.ejb.Handle) can be obtained to a enterprise bean's instance
using the getHandle() method create() and remove()
methods using their home interface. The create() methods are used to
initialize the object's fields. For a big-picture look at what we've learned about EJB so far, Figure 2 portrays a snapshot of a hypothetical EJB server environment.
In particular, please note the following:
|
Persistence
One of EJB's key features is built-in persistence, which is provided by entity beans. The
persistence can be either bean-managed or container-managed.
For bean-managed persistence, the developer overrides the ejbLoad() and ejbStore()
methods and provides the custom code (for example, by using JDBC) to transfer the data
from the object's fields to the permanent store and vice versa. While bean-managed
persistence provides a lot of flexibility, it ties the entity bean to one method of
persistence, such as JDBC, and requires the developer to write and maintain the
persistence code. In some cases, however, the developer may have to employ a bean-managed
solution (e.g., if an EJB container provider's mapping tools allow mapping of an entity
bean to only a single table but the entity bean needs data from multiple tables).
Fortunately, many application-server vendors are beginning to bundle object-relational
(OR) mapping tools that can handle complex joins and other entity relationships and still
provide you with the benefits of container-managed persistence, and third-party OR tools
can fill the void if your favorite application server lacks an OR tool. Alternatively, you
can use a relational-database view to represent multiple tables and their relationships as
one table, but you should be aware that many databases do not support data updating in
multiple tables via views.
In a container-managed situation, a container provider (vendor) supplies mapping tools to map the entity bean's fields to the fields in the data store (such as a relational database table's columns). For example, Figure 3 shows Persistence Software Inc.'s PowerTier ObjectBuilder, an object-relational mapping tool. ObjectBuilder automates the mapping of complex beans, including inheritance, aggregation, and association, to relational tables, thus enabling greater developer productivity and more reliable code. (Persistence Software also offers Rational Rose integration for OR mapping and enterprise bean generation.)
|
While the mapping process can be tedious, the advantages of using container-managed persistence outweigh the minor disadvantages. For example, the container provider automatically generates the code to move the data between the entity bean's fields and the data store; for relational database applications, this is an automatic object-relational mapping feature. Additionally, the entity bean can be persisted into a different data source simply by using a different EJB container and remapping the fields. Furthermore, a container provider might optimize the data access by caching data in the containers, so the data store doesn't have to be accessed for every single request. Examples of EJB containers include WebLogic's JDBC- and file-based containers and Information Builder's EJB containers for CICS, 3270, MQ Series, and other legacy database systems.
Transaction management
EJB supports flat transactions, modeled after the CORBA Object Transaction Service (OTS)
version 1.1. For transactions, no distinction is made between a session bean and an entity
bean except for one subtle difference that allows only stateful-session beans to suspend a
user-managed transaction (when using the TX_BEAN_MANAGED transaction
attribute, discussed below). Additionally, the developer isn't exposed to the complexity
of transactions that could potentially be distributed across multiple data sources on
multiple platforms -- this responsibility is shifted to the Java middleware (or app
server) provider.
Transaction demarcation in an EJB environment can be handled in one of two ways. First,
the developer can programmatically control the scope of transaction using the javax.jts.UserTransaction
interface (an app server vendor must provide an implementation for this) at the client or
server. Secondly, the app server provider manages the transaction boundaries using the
deployment settings for the transaction attribute, which can apply to either the entire
enterprise bean or its specific methods. (This method is also known as declarative or
attribute-based programming.)
Table 3 provides a list of valid values for the EJB transaction attribute. These values typically can be set for a given enterprise bean using tools provided by the app server vendor.
Attribute value |
How enterprise bean is invoked |
| TX_NOT_SUPPORTED | Invoked without a transaction scope. |
| TX_BEAN_MANAGED | An enterprise bean can use the javax.jts.UserTransaction
interface to demarcate transaction boundaries. The UserTransaction interface
can be obtained using the javax.ejb.SessionContext.getUserTransaction()
method. An instance of a stateless session bean or an entity bean is not allowed to retain
an association with a transaction across multiple calls from a client. |
| TX_REQUIRED | If the client is associated with a transaction context, the enterprise bean is invoked in the same context, otherwise the container starts a new transaction before invoking a method on the enterprise bean and commits the transaction upon returning from the method. |
| TX_SUPPORTS | Invoked in the client's transaction scope, if it has one. Otherwise, invoked without a transaction context. |
| TX_REQUIRES_NEW | Always invoked in a new transaction. |
| TX_MANDATORY | Always invoked in the scope of the client's
transaction. If the client does not have one, javax.transaction.TransactionRequiredException
is thrown to the client. |
Table 3. Valid values for transaction attribute
EJB also provides support for transaction isolation levels, a concept that allows changes made by one transaction to be visible to other transactions. The valid values for EJB isolation levels, also set in the deployment descriptor (typically using vendor tools), are as follows:
For session beans and entity beans with bean-managed persistence, the specified isolation level is set in the database connection (for example, the JDBC isolation levels). For container-managed entity beans, the vendor must provide this functionality.
Relationship to JDBC 2.0
JDBC 2.0 introduces a standard extensions API (javax.sql package) that
includes support for distributed transactions in addition to features such as resource
pooling and rowsets. The support for distributed transactions lets developers write
enterprise beans that are transactional across multiple DBMS servers.
To provide a standard way of supporting distributed transactions in Java, JDBC ties
into the Java Transaction API (JTA) and Java Transaction Service (JTS). The JTS API
provides the necessary interfaces and classes for transaction management in Java. It can,
for example, attach a JDBC driver to an external transaction manager using the standard
X/Open XA interface. (JDBC 2.0 introduces the javax.sql.XADataSource and javax.sql.XAConnection
interfaces, which any drivers supporting distributed transactions must implement if the
driver vendor claims to support the standard JDBC extensions.)
Exception handling
The EJB 1.0 specifications define two types of exceptions: application-level and
system-level. Since a client accesses an enterprise bean's methods via its home
and remote interfaces, all methods defined in these interfaces must include a java.rmi.RemoteException.
When a RemoteExeption is thrown, a client can assume it is a system-level
failure. All other exceptions, including the javax.ejb.CreateException, javax.ejb.RemoveException,
and javax.ejb.FindException, are considered application-level failures.
In relation to transactions, a client can assume that a transaction was rolled back if
a javax.jts.TransactionRolledbackException is thrown. (Note: The javax.ejb.SessionContext.getRollbackOnly()
method can also be called to test whether or not a transaction was rolled back using the setRollbackOnly()
method.)
Security
EJB uses the java.security.Identity class to describe users and/or roles. The
app server (or EJB container) actually performs the mapping, usually in a
platform-specific way, and provides this information to the enterprise bean instance via
the getCallerIdentity and isCallerInRole(Identity ident) methods
in the javax.ejb.EJBContext class.
EJB security uses access control lists (ACLs) in the deployment descriptor to manage
security on behalf of the enterprise bean. EJB also provides attributes, RunAsMode
and RunAsIdentity, to define the security Identity to be associated with the
execution of methods in the enterprise bean and for any calls to other resource managers
(such as JDBC). The valid values for these attributes are SPECIFIED_IDENTITY,
CLIENT_IDENTITY, and SYSTEM_IDENTITY (privileged account).
Note that the class java.security.Identity was deprecated in Java 2 (aka
JDK 1.2). However, the EJB 1.0 specifications and the EJB APIs still refer to this class.
Hopefully, the next release of the EJB specifications (which most likely will be EJB 1.1,
due June of 1999) will rectify the situation.
Naming and directory service
EJB uses the Java Naming and Directory Interface (JNDI) for its naming service. In other
words, a client looks up an EJB's home interface using JNDI. It is the container's
responsibility to make the enterprise bean's classes available to the client via JNDI.
Wire protocol
The EJB specifications by default specify Java RMI Protocol (JRMP) as the default protocol
for invoking enterprise beans over the network. Additionally, the specifications provide
CORBA/IIOP mapping so CORBA clients can invoke enterprise beans. However, EJB isn't
limited to using the JRMP and IIOP wire protocols. In fact, EJB can use any wire protocol
(such as HTTP or DCOM) to support a variety of client types. Either way, the developer
doesn't have to worry about the protocol as EJB vendors handle the low-level details.
Figure 4 shows the various ways enterprise beans can be accessed; for example, the following sample architecture patterns are depicted in Figure 4:
|
Additionally, Java middleware could provide support for other protocols, such as DCOM or HTTP, to invoke enterprise beans.
While the default wire protocol for EJB is the Java RMI Protocol, the EJB 1.0 specification defines a CORBA mapping. Essentially, this is accomplished via the IDL files (such as ejb.idl) provided for the EJB classes and interfaces combined with an application-specific IDL for the bean-specific classes and interfaces.
The mapping for CORBA also covers propagation of the transaction, naming, and security contexts as defined by the CORBA Object Services protocols.
Attribute-based development
EJB enhances a developer's productivity not only by providing a simple server-side
component architecture but also by introducing declarative, or attribute-based
programming. For example, attributes for transactions, isolation levels, security, and
mapping to EJB-container data sources all can be handled at deployment time. Hence,
developers don't have to worry about these low-level details when developing components;
they can instead concentrate wholly on the business logic.
Deployment
Enterprise beans are deployed via a JAR file, which provides a nice, neat way to include
the following required and optional files:
javax.ejb.deployment.EntityDescriptor or javax.ejb.deployment.SessionDescriptor
object Name: divya/infoBookServer.ser Enterprise-Bean: True
Name: xyz/QuoteServer.ser Enterprise-Bean: True
Roles and responsibilities
Sun's EJB 1.0 specification defines six different roles involved in development and
deployment of EJB (see Table 4). Of course, these roles vary based on the size of your
project and/or company. For example, in a small project, the same person could be the
enterprise bean provider, application assembler, deployer, and system administrator.
Similarly, one vendor could be both the EJB server and the container provider (for
example, Information Builders includes several EJB containers with its EJB-compliant
application server).
| Role | Responsibilities |
| Enterprise bean provider |
|
| Application assembler |
|
| Deployer |
|
| EJB server provider |
|
| EJB container provider |
|
| System administrator |
|
Table 4. Roles and responsibilities
Programming restrictions
Below is a list of restrictions defined in the EJB 1.0 specifications that will generally
be enforced by the application server vendor.
javax.jts.UserTransaction interface
to demarcate transactions. java.security.Identity. Any
such attempt will result in the java.security.SecurityException being thrown.
commit()
and rollback() methods. An enterprise bean that is not transaction-enabled is
allowed to use the commit() and rollback() methods. Source: Enterprise JavaBeans 1.0 specification, Sun Microsystems Inc.
How do you develop, deploy, and manage EJB?
Now that we've covered pretty much everything there is know about what EJB is, let's look
at how you actually develop enterprise beans.
As I mentioned previously, the intention of this article is to provide you with the big picture of EJB, not a coding tutorial. Accordingly, the following sections provide an overview of what's required to develop EJB and some of the tools available for the job.
In general, developing and deploying enterprise beans includes the following steps:
Developing Enterprise JavaBeans
For every enterprise bean, three pieces must be developed: the actual enterprise bean
class; its home interface; and its remote Interface. You can develop all three using your
favorite text editor. Optionally, you can use an IDE such as Inprise's JBuilder 2, which
will generate skeleton code for you.
|
|
For example, Figure 5 shows JBuilder's EJB wizard, which prompts you for the package
name, class name, and enterprise bean type, then continues to generate a shell for you to
work with. Figure 6 shows the code generated by the wizard. Notice the special enterprise
bean methods that are generated with empty bodies (such as ejbCreate and ejbRemove).
The enterprise bean class contains business logic methods that will act on behalf of a
client. For example, the following sample session bean class provides a method, getLastName(int),
to look up and return a person's last name as a java.lang.String based on a
numeric (int) social security number:
import javax.ejb.*;
import java.rmi.*;
public class PeopleFinderBean
implements
SessionBean
{
SessionContext sessionContext;
public void ejbCreate() throws
CreateException, RemoteException {}
public void
setSessionContext(SessionContext sc)
throws
RemoteException
{
sessionContext = sc;
}
// Business methods
public String getLastName(int ssn)
{
String lastName = null;
// Get name from some
data source.
return lastName;
}
}
Since the instance of the above bean can exist on a remote machine (and most likely will in an n-tier app), clients don't actually work directly with the instance of the above class. Instead, through JNDI, the client obtains a sort of a remote handle to the actual instance and uses an enterprise bean class's remote interface to invoke its methods. The following is what the above bean class's remote interface would look like:
import javax.ejb.*;
import java.rmi.*;
public interface PeopleFinder
extends EJBObject
{
public String getLastName(int ssn) throws
RemoteException;
}
Once the enterprise bean class and its remote interface have been developed, the
developer must provide a home interface for the enterprise bean class. The home interface
is what the client first obtains through JNDI. Once the home interface has been obtained,
the client can use it to create instances of the remote enterprise bean and remove them;
for entity beans, the client can use the home interface to find existing beans. An entity
bean's home interface can define zero or more create() methods (with
different signature types), one for each method of creating an enterprise bean object. The
arguments of the create() methods typically are used to initialize the state
of the created enterprise bean object. The return type of a create() method
is the enterprise bean's remote interface. The home interface for the above enterprise
bean might look something like this:
import javax.ejb.*;
import java.rmi.*;
public interface PeopleFinderHome
extends EJBHome
{
public PeopleFinder create()
throws
CreateException, RemoteException;
}
Notice the naming convention of the enterprise bean class and its home interface. The use of the word bean at the end of the enterprise bean class's name and the word Home at the end of the home interface's name are naming conventions used in the EJB specification, and thus presumably are recommended practice.
Once the beans have been developed and deployed (see below), a client uses JNDI to find the remote bean's home interface, then uses the home interface to create an instance of the remote enterprise bean and simply call its business methods (via its remote interface) as shown here:
// Do one-time, initialization, stuff
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.TengahInitialContextFactory");
env.put(Context.PROVIDER_URL,
"t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "system");
env.put(Context.SECURITY_CREDENTIALS, "letmeout");
InitialContext ic = new InitialContext(env);
// Get enterprise bean's "Home" and
"Remote" Interface
PeopleFinderHome pfh =
(PeopleFinderHome)ic.lookup("statefulSession.PeopleFinder");
PeopleFinder pf = pfh.create();
// Call enterprise bean's method
System.out.println("Last name = " +
pf.getLastName(111223333));
Table 5 provides an overview of special methods, classes, and interfaces related to the two enterprise bean types, session and entity. For more details on these, refer to the EJB API documentation and specifications. I've merely listed them here to make you aware that they exist.
| Enterprise bean type | Special methods, classes, and interfaces |
| Session |
|
| Entity |
|
Table 5. Enterprise bean interfaces and special methods
By now you should have a general understanding of how to develop enterprise beans. The next section discusses how to deploy these beans using your favorite app server product.
Deploying Enterprise JavaBeans
Deploying an enterprise bean generally involves the following five steps:
containerManagedFields
deployment descriptor property to specify the list of instance fields for which the
container provider tools must generate access calls.
|
Figures 7 and 8 show screenshots of sample EJB compliant products available today. Figure 7 shows the WebLogic EJB Deployment wizard, part of BEA's WebLogic Application Server product. The wizard allows you to select a JAR (or deployment descriptor) file, modify the various deployment descriptor attributes (transaction and security for example) and let the tool generate the necessary class files and deploy the enterprise bean component for you. With the ease of tools such as this, the developer simply concentrates on writing the business logic and let the vendor products do the rest.
|
Figure 8 shows you Gemstone's J Console, part of its Gemstone/J product. This screenshot shows a file-open dialog box to select the enterprise bean JAR file (as described above) and deploy it. You can use the graphical interface (written in 100 percent pure Java, Swing to be exact) to configure all aspects of your system. This configuration is organized in a logical manner in property pages, as opposed to working with one large text file.
Managing Enterprise JavaBeans
While each vendor provides the same minimal functionality required by the EJB 1.0
specifications for developing enterprise beans, it's in the deployment and management of
these components that you begin to see some of the differences between the products. In
particular, the management tool (or console) serves as the heart of each application
server product.
For example, Figure 9 shows a screenshot of Novera's Management Console, part of the company's jBusiness4 Application Server product. To give you an idea of the features provided by these management tools, consider some of the options available in Novera's Management Console:
|
How do you integrate EJB with existing systems?
New and cool technologies, such as EJB, usually excite IT workers, who typically seek to
introduce these newfound technologies into their projects or organizations. However, one
of the immediate questions raised is, How do we access our existing systems using the new
technology? While many organizations want to use EJB because of its enormous benefits, the
obvious issues related to accessing existing data sources need to be addressed.
EJB vendors tackle the data access issue in different ways. Many bundle JDBC drivers for access to databases such as Oracle, Sybase, Informix, and MS SQL Server. Other vendors rely on existing ODBC drivers and presume developers will use the free JDBC-ODBC bridge from Sun to access these data sources from their Java classes. Then there are vendors that go one step further. For example, Parlay from Information Builders is an EJB-based application server with one of the strongest suites of enterprise beans for accessing mainframe CICS and IMS transactions and more than 70 databases (including VSAM and DB2), as well as integrating TN3270 sessions and MQSeries messaging services. Parlay also features an intuitive, drag-and-drop environment called Visual Configurator (see Figure 10) for developing, deploying, and managing strategic Java business applications. Additionally, Parlay is supposed to be available on more than 12 platforms ranging from NT to IBM OS/390. In any case, most of these EJB vendors will likely provide intuitive GUI-based EJB component-mapping tools for the data sources they support, and when and where these tools fall short, systems integration companies can be brought in to fill the gap.
|
Of course, if all else fails, the last resort for data access from Java is to use the Java Native Interface (JNI). In other words, if there are C/C++ libraries provided by a database vendor, Java classes can be written as "wrappers" to access these native libraries in an object-oriented fashion.
Where does EJB go from here?
EJB is a new and promising technology that should be around for a long time to come, given
the enormous industry backing it has already received. When the EJB 1.0 specification was
released last year, there were mentions of features deferred for release 2.0.
Additionally, the CORBA 3 specifications are supposed to include mapping to, and container
support for, enterprise beans. In other words, enterprise beans will most likely be
treated as CORBA components by object request broker (ORB) products mainly because these
two component models are so similar. (It is worth noting, however, that OMG believes CORBA
components will be a superset of EJB components.)
Table 6 provides an EJB roadmap for the next 9 to 12 months.
| Release name | Schedule | Features |
| Moscone | Expert Group Review: Early 1Q99 Public review: Late 1Q99 Final: 2Q99 Along with the specifications, Sun will produce a reference implementation and a set of compliance tests Technology preview: 2Q99 |
Tightening of spec requirements for compatibility, XML deployment info |
| Javits | 6 to 9 months after the release of Moscone | Connectors to existing systems |
| Milano | 6 to 9 months after the release of Javits | Complete definition of entities |
Table 6. EJB roadmap (Source: Sun Microsystems Inc.)
I predict we'll see more implementations of JTA for transaction support across multiple data sources. Also, the integration with JDBC 2 will get tighter, thereby providing benefits such as connecting pooling and transaction support in a nonproprietary fashion. Additionally, ORB/IIOP-based vendors will play an important role in EJB servers due to the inherent portability derived from CORBA. If EJB components reach their ultimate potential and become fully successful, they'll be used by sites such as Yahoo!, E*Trade, and Netscape NetCenter to provide services to their customers.
Conclusion
When JavaBeans was introduced in JDK 1.1, it immediately became the de facto GUI component
model for Java. With EJB, we now have a server-side component model for Java. Thanks to
Enterprise JavaBeans, we may soon see widespread proliferation of off-the-shelf components
for the server side, not just for the client side (as we have seen with JavaBeans and
ActiveX controls).
Having the same base functionality in all EJB-compliant products protects corporate investments, and we'll soon be seeing better middleware product as a result. There is no proprietary model, which means everyone can concentrate on the extra bells and whistles. Middleware developers will be able to provide us with the next generation of tools, which will be open to all manner of back-end data sources and will increase reusability of components across not only Java clients but also Windows clients and special devices yet to be invented. Speaking of proprietary versus open standards, EJB developers would do well to avoid vendor-specific features whenever possible and instead use the standard EJB APIs, including JNDI, JDBC, Servlets, and JSP.
The EJB and other standard APIs have made significant progress, and Java middleware vendors have also made advances. These tools still need much improvement, however, to ease the development process through GUI tools such as wizards and other integrated features (e.g., simple EJB deployment, JAR file creation, OR mapping, FTP capabilities, remote debugging, and client-server class hierarchy/relationship-type views). Additional improvements are needed to make the EJB environment not only easy to work with but also robust. Such reliability and scalability issues include transparent fault tolerance, load balancing, and clustering.
Most of all, tools vendors will have to simplify their tools and -- absolutely, positively -- standardize their user interfaces to win the votes of those corporations out there that embrace the look and feel of Microsoft products. Microsoft may have the most proprietary products, but Java middleware vendors would do well to adopt the clean, crisp, appealing, and consistent user interface Microsoft applies to its various products (think Outlook, Office, FrontPage, and SQL Server) and thus provide a pleasant experience for developers.
About the author
Anil Hemrajani is a senior consultant at Divya Inc., a consulting firm specializing in
Java/Internet software solutions. Anil Hemrajani provides Java/Internet-based
architecture, design, and development solutions to Fortune 500 companies, and occasionally
writes articles and lectures at conferences. He can be reached at
anil.hemrajani@javaworld.com.
Cliff Berg contributed to this article; he is the VP and CTO of Digital Focus, a leading Java and Internet technology system integrator.
Previous EJB features in JavaWorld
EJB features on the Java Developer Connection
 |
Middleware Glossary
|
(c) Copyright 1999 Web Publishing Inc., an IDG Communications company
Feedback: jweditors@javaworld.com
Technical difficulties: webmaster@javaworld.com
URL: http://www.javaworld.com/jw-04-1999/jw-04-middleware_p.html
Last modified: Thursday, July 01, 1999
