New York
University
Computer
Science Department
Courant
Institute of Mathematical Sciences
The Enterprise
JavaBeans (EJB) Server Component Model
Course Title: Application Servers Course Number: g22.3033-011
Instructor: Jean-Claude Franchitti Session: 6
Table of Contents
Introduction
Scenario
Enterprise
Java Platform
Illustration: Money Makers Account
Management System
Table: Enterprise Java APIs
Component-Based
Computing
Multitier Application Architecture
Overview of Components
Server Components
Enterprise
JavaBeans Component Model
Overview of Enterprise JavaBeans
Technology
Architecture
Details
The Big Picture
Illustration: Enterprise
JavaBeans Container
Distribution Services
State Management
Persistence Management
Transaction Management
Security
Enterprise JavaBeans Deployment
Industry
Support
EJB Competition
Benefits
and Conclusions
Introduction
Enterprise
JavaBeans Technology
Enterprise JavaBeansTM (EJB) technology
defines a model for the development and deployment of reusable JavaTM
server components. Components are pre-developed pieces of application code that
can be assembled into working application systems. Java technology currently
has a component model called JavaBeansTM, which supports reusable
development components. The EJB architecture logically extends the JavaBeans
component model to support server components.
Server
Components
Server components are application components that
run in an application server. EJB technology is part of Sun's Enterprise Java
platform, a robust Java technology environment that can support the rigorous
demands of large-scale, distributed, mission-critical application systems. EJB
technology supports application development based on a multitier, distributed
object architecture in which most of an application's logic is moved from the
client to the server. The application logic is partitioned into one or more
business objects that are deployed in an application server.
Java
Application Servers
A Java application server provides an optimized
execution environment for server-side Java application components. By combining
traditional OLTP technologies with new distributed object technologies, a Java
application server delivers a high-performance, highly scalable, robust
execution environment specifically suited to support Internet-enabled
application systems.
WORA
The Enterprise JavaBeans architecture defines a
standard model for Java application servers to support "Write Once, Run
AnywhereTM" (WORA) portability. WORA is one of the primary
tenets of Java technology. The Java virtual machine (JVM)* allows a Java
application to run on any operating system. But server components require
additional services that are not supplied directly by the JVM. These services
are supplied either by an application server or by a distributed object
infrastructure, such as CORBA or DCOM. Traditionally, each application server
supplied a set of proprietary programming interfaces to access these services,
and server components have not been not portable from one application server to
another. For example, a server component designed to run in BEA Tuxedo could
not execute in IBM TXSeries without significant modification. The EJB server
component model defines a set of standard vendor-independent interfaces for all
Java application servers.
Component
Portability
Enterprise JavaBeans technology takes the WORA
concept to a new level. Not only can these components run on any platform, but
they are also completely portable across any vendor's EJB-compliant application
server. The EJB environment automatically maps the component to the underlying
vendor-specific infrastructure services.
Scenario
Stock Fund
Account
For example, Money Makers, a large brokerage house,
is using Enterprise JavaBeans technology to implement an application system to
manage stock fund accounts. Money Makers wants to provide clients with a
self-service electronic trading system. To effectively support both broker and
client users, the application is implemented using a thin-client, distributed
object architecture. The architecture of the application is depicted in
Illustration 1.
Multiple
Client Support
The stock fund application can support a variety of
client devices, including desktop workstations, Web browsers, telephones,
kiosks, smartcards, or other Internet-enabled appliances.
Communication
Protocols
Client applications can communicate with the stock
fund application using a variety of protocols. Java technology clients invoke
the application using the native Java Remote Method Invocation (RMI) interface.
RMI requests currently are transferred using the Java Remote Method Protocol
(JRMP). In the future, RMI will be extended to support the industry-standard
Internet InterORB Protocol (IIOP). Native language clients can invoke the
application using CORBA IDL running over IIOP or a COM/CORBA internetworking
service running over IIOP. The RMI client proxy could also be rendered as an
ActiveX control to provide easy integration with any Windows application.
Browsers can invoke the application through a servlet running on the HTTP
server. The browser communicates with the servlet using HTTP, and the servlet
communicates with the application using RMI.
Server
Execution Environment
Money Makers has millions of clients and expects
that the transaction volume on this system will be very high. Therefore, the
company selected an EJB-compliant server from Big Guns System Software deployed
on a fault-tolerant cluster of high-speed multiprocessors. The Big Guns system
is based on an enterprise-class transaction processing (TP) monitor noted for
its efficient use of resources. Big Guns supports transparent distribution and
replication of application components.
Purchased
Application
Rather than building the entire application from
scratch, Money Makers purchased from Portfolio Incorporated, an application
software vendor, a stock fund account management system that is implemented as
a set of Enterprise JavaBeans components. Portfolio developed and tested the
application using an EJB environment provided by a database vendor.
Customization
and Enhancement
The Portfolio application provides the functionality
to manage client accounts and organize portfolios. However, it does not use
up-to-the-minute stock prices to calculate the current account value, nor does
it support online trading.
Money Makers customized the stock component to make
it retrieve the most recent stock price from a live data feed. The company used
an EJB-compliant stock feed component from Garage Enterprises, a startup
company that operates on a fairly tight budget. The component was developed and
tested using an EJB-compliant application server from the public domain.
Money Makers elected to implement the online trading
function by encapsulating the existing trading system and integrating it with
the Portfolio system using CORBA.
Enterprise JavaTM Platform
Enabling
Portability
The portability characteristics of EJB components
are made possible by the Enterprise Java platform. The Enterprise Java platform
consists of several standard Java application programming interfaces (APIs)
that provide access to a core set of enterprise-class infrastructure services.
(See the accompanying table for a description of the Enterprise Java APIs.) The
term "enterprise" implies highly scalable, highly available, highly
reliable, highly secure, transactional, distributed applications. Enterprise
applications require access to a variety of infrastructure services, such as
distributed communication services, naming and directory services, transaction
services, messaging services, data access and persistence services, and
resource-sharing services. These infrastructure services are frequently
implemented on different platforms using different products and technologies,
making it difficult to build portable enterprise-class application systems. The
Enterprise Java APIs provide a common interface to the underlying
infrastructure services, regardless of the actual implementation.
Existing
Infrastructure Integration
Sun could have defined a new set of infrastructure
services especially to support the Enterprise Java platform. It's been fairly
standard practice in the past for standards organizations to define new
services to support new environments. For example, X/Open defined the
Distributed Transaction Processing (DTP) model and the XA standard, OSF defined
the Distributed Computing Environment (DCE) services, and OMG defined the CORBA
Object Services (COS, also known as CORBAservices). Microsoft has defined a set
of integrated NT services to support DCOM. Meanwhile, every TP Monitor and
application server vendor generally provides its own proprietary set of
infrastructure services. Many of these infrastructure services perform similar
but non-interoperable functions.
Illustration
1. The Money Makers account management system combines applications from two
vendors and integrates with an existing application system. The application
supports a variety of client devices through a variety of protocols.
Rather than re-inventing the wheel, Sun took a
different route. The Enterprise Java platform defines a set of standard Java
APIs that provide access to existing infrastructure services. Using these Java
technology APIs, a developer can implement an application system that makes use
of whatever enterprise services happen to exist on the platform in use. For
example, an application that uses IBM TXSeries, DCE services, and Oracle on one
system could be moved to a different system and automatically use BEA Systems
M3, LDAP, and Sybase instead. No porting effort would be required.
Platform- and
Vendor-Neutral
The Enterprise Java APIs are completely platform-
and vendor-neutral. The APIs are designed to layer on multivendor heterogeneous
infrastructure services. Each API provides a common programming interface to a
generic type of infrastructure service. If each vendor that supplies this type
of service implements this API, then an application could access any service
provider through the common interface.
ODBC Metaphor
The Enterprise Java APIs take Microsoft's ODBC
metaphor-one common interface to all relational databases-and apply it to all
infrastructure services. For example, the Java Naming and Directory Interface
(JNDI) provides a standard interface to naming and directory services. The JNDI
API could be used to access any vendor's directory service, such as Microsoft
Active Directory, Novell NDS, Sun NIS+, or any LDAP directory.
Enterprise
Java APIs |
|
API |
Description |
EJB |
The Enterprise JavaBeans API defines a server
component model that provides portability across application servers and
implements automatic services on behalf of the application components. |
JNDI |
The Java Naming and Directory Interface API
provides access to naming and directory services, such as DNS, NDS, NIS+,
LDAP, and COS Naming. |
RMI |
The Remote Method Invocation API creates remote
interfaces for distributed computing on the Java platform. |
Java IDL |
The Java Interface Definition Language API creates
remote interfaces to support CORBA communication in the Java platform. Java
IDL includes an IDL compiler and a lightweight, replaceable ORB that supports
IIOP. |
Servlets and JSP |
The Java Servlets and Java Server Pages APIs
support dynamic HTML generation and session management for browser clients. |
JMS |
The Java Messaging Service API supports
asynchronous communications through various messaging systems, such as
reliable queuing and publish-and-subscribe services. |
JTA |
The Java Transaction API provides a transaction
demarcation API. |
JTS |
The Java Transaction Service API defines a
distributed transaction management service based on CORBA Object Transaction
Service. |
JDBCTM |
The JDBC Database Access API provides uniform
access to relational databases, such as DB2, Informix, Oracle, SQL Server, and
Sybase. |
Table 1. The Enterprise
Java APIs. |
Industry
Acceptance
In order to be successful, this approach requires
widespread buy-in from the vendor community. The APIs will be useless if the
infrastructure vendors don't implement support for the APIs in their existing
infrastructure products. Sun was quite diligent to ensure that the Enterprise
Java platform conforms to the most prevalent de jure and de facto standards.
Sun also recruited expertise from the most elite players in each area of infrastructure
services to ensure that the Enterprise Java APIs are suitable for high-volume,
mission-critical application development. Industry leaders in transaction
management (IBM, Compaq/Tandem, BEA Systems, etc.), persistence management
(Oracle, Sybase, Informix, etc.), and directory services (HP, IBM, Novell,
etc.) participated in the development of the Enterprise Java APIs. According to
early indications, the industry has embraced Enterprise Java technology with as
much gusto as it embraces Java technology itself. A staggering number of
vendors have announced their intent to support the Enterprise Java APIs, and
many vendors have already delivered compatible products.
Component-Based Computing
Multitier Application Architecture
Scalability
The Enterprise Java platform has been designed to
provide an environment that is suitable for the development and deployment of
fully portable Java technology-based enterprise-class application systems. The
true measure of an enterprise application system often comes down to system
scalability and total throughput. How many users can concurrently use the
system? How many objects can be instantiated in a given time frame? How many
transactions can be processed per second?
Next-Generation
Client/Server
Enterprise application systems support high
scalability by using a multitier, distributed application architecture. A
multitier application is an application that has been partitioned into multiple
application components. Multitier applications provide a number of significant
advantages over traditional client/server architectures, including improvements
in scalability, performance, reliability, manageability, reusability, and
flexibility.
Application
Partitioning
In a traditional client/server application, the client
application contains presentation logic (window and control manipulation),
business logic (algorithms and business rules), and data manipulation logic
(database connections and SQL queries)-a "fat client." The server is
generally a relational database management system (which is actually not a part
of the application.) In a multitier architecture, the client application
contains only presentation logic-a "thin client." The business logic
and data access logic are partitioned into separate components and deployed on
one or more servers.
Increased
Scalability and Performance
Moving the business and data manipulation logic to a
server allows an application to take advantage of the power of multithreaded
and multiprocessing systems. Server components can pool and share scarce
resources, such as processes, threads, database connections, and network
sessions. As system demands increase, highly active components can be
replicated and distributed across multiple systems. Although modern
client/server systems can easily support hundreds of concurrent users, their
scalability has limits. Multitier systems can be built with essentially no
scalability limits. If the design is efficient, more or bigger servers can be
added to the environment to boost performance and to support additional users.
Multitier systems can scale to support hundreds of thousands or millions of
concurrent users.
Increased
Reliability
A multitier environment can also support many levels
of redundancy. Through replication and distribution, a multitier architecture
eliminates any bottlenecks or single points of failure. The multitier approach
supports high reliability and consistent system availability to support
critical business operations.
Increased
Manageability
A thin-client application is easier to manage than
traditional client/server applications. Very little code is actually deployed
on the client systems. Most of the application logic is deployed, managed, and
maintained on the servers. Fixes, upgrades, new versions, and extensions can
all be administered through a centralized management environment.
Increased
Flexibility
The multitier application architecture supports
extremely flexible application systems. The majority of the application logic
is implemented in small modular components. The actual business logic in the
components is encapsulated behind an abstract, well-defined interface. The code
within an individual component can be modified without requiring a change to
the interface. Therefore, a component can be changed without impacting the
other components within the application. Multitier applications can easily
adapt to reflect changing business requirements.
Reusability
and Integration
By the nature of its interface, a server component
is a reusable software building block. Each component performs a specific set
of functions that are published and accessible to any other application through
the interface. A particular business function can be implemented once and then
reused in another application that requires the function. If an organization
maintains a comprehensive library of components, application development
becomes a matter of assembling the proper components into a configuration that
performs the required application functions.
Multi-Client
Support
Any number of client environments can access the
same server component through its interface. A single multitier application
system can support a variety of client devices, including traditional desktop
workstations, Web clients, or more esoteric clients, such as information
appliances, smartcards, or personal data assistants.
Multitier
Impetus
Although server components and multitier concepts
have been around for nearly a decade, relatively few organizations have put
them to use. Until recently, most organizations did not feel the scalability
pressures that required a multitier architecture. But the impetus of Web-based
computing is driving a growing interest in the multitier approach. Web-based
business applications require a thin-client application architecture to support
massive scalability and to support browser-based clients and rapid applet
downloads.
More Difficult
Development
Unfortunately, building multitier applications isn't
quite as easy as building client/server. Multitier applications have to
interact with a variety of middleware services. In order to attain the
scalability, performance, and reliability characteristics of multitier
computing, the applications must support multithreading, resource sharing,
replication, and load balancing.
Application
Servers
An application server automates some of the more
complex features of multitier computing. An application server manages and
recycles scarce system resources, such as processes, threads, memory, database
connections, and network sessions on behalf of the applications. Some of the
more sophisticated application servers offer load-balancing services that can
distribute application processing across multiple systems. An application
server also provides access to infrastructure services, such as naming,
directory, transactions, persistence, and security. Until recently, though,
every application server used a proprietary set of interfaces. Each enterprise
application had to be implemented with a specific runtime environment in mind,
and applications were not portable across application servers_not even Java
applications.
Enterprise
JavaBeans Specification
The Enterprise JavaBeans specification defines a
standard model for a Java application server that supports complete
portability. Any vendor can use the model to implement support for Enterprise
JavaBeans components. Systems, such as TP monitors, CORBA runtime systems, COM
runtime systems, database systems, Web server systems, or other server-based
runtime systems can be adapted to support portable Enterprise JavaBeans
components.
Overview of Components
Components
A component is a reusable software building block: a
pre-built piece of encapsulated application code that can be combined with
other components and with handwritten code to rapidly produce a custom
application.
Containers
Components execute within a construct called a
container. A container provides an application context for one or more
components and provides management and control services for the components. In
practical terms, a container provides an operating system process or thread in
which to execute the component. Client components normally execute within some
type of visual container, such as a form, a compound document, or a Web page.
Server components are non-visual and execute within a container that is
provided by an application server, such as a TP monitor, a Web server, or a
database system.
Component
Model
A component model defines the basic architecture of
a component, specifying the structure of its interfaces and the mechanisms by
which it interacts with its container and with other components. The component
model provides guidelines to create and implement components that can work
together to form a larger application. Application builders can combine
components from different developers or different vendors to construct an
application.
Granularity
Components come in a variety of shapes and sizes. A
component can be very small, such as a simple GUI widget (e.g., a button), or
it can implement a complex application service, such as an account management
function.
Standard
Interface
In order to qualify as a component, the application
code must provide a standard interface that enables other parts of the
application to invoke its functions and to access and manipulate the data
within the component. The structure of the interface is defined by the
component model.
Customization
without Source Code
An application developer should be able to make full
use of the component without requiring access to its source code. Components
can be customized to suit the specific requirements of an application through a
set of external property values. For example, the button component has a
property that specifies the name that should appear on the button. The account
management component has a property that specifies the location of the account
database. Properties can be used to support powerful customization services.
For example, the account management component might allow a user to add a
special approval process for withdrawals over a certain dollar amount. One
property would be used to indicate that special approval functions are enabled,
a second property would identify the conditions that require special approvals,
and a third property would indicate the name of the approval process component
that should be called when the condition exists.
Component
Marketplace
One of the promises of component technology is a
world in which customized business solutions can be assembled from a set of
off-the-shelf business objects. Software vendors could produce numerous
specialized business components, and organizations could select the appropriate
components to match their business needs. Thus far, there is a fairly rich
supply of off-the-shelf, third-party, client-side development components. For
the moment, the market for server-side components is still very young. As more
and more organizations adopt the server component architecture, the market is
likely to mature rapidly. Application software companies are already beginning
to implement applications using server components. Some e-commerce vendors are
beginning to supply individual application functions, such as a shopping cart
and a credit validation service, as customizable components.
Server Components
Shared Servers
In order to achieve the most benefit from the
multitier architecture, server components should be implemented as shared
servers. But building a shared server is harder than building a single-user
application function. Highly scalable shared servers need to support concurrent
users, and they need to efficiently share scarce system resources, such as
threads, processes, memory, database connections, and network connections. For
business operations, shared servers must participate in transactions. In many
cases, a shared server needs to enforce security policies.
Plug-and-Play
Assembly
A component builder doesn't especially want to
implement multithreading, concurrency control, resource-pooling, security, and
transaction management in every component. If these services were implemented
in each component, achieving true plug-and-play application assembly would be
very difficult. A component model standardizes and automates the use of these
services, thereby enabling easy application development.
Container
An application server provides a container to manage
the execution of a component. When a client invokes a server component, the
container automatically allocates a process thread and initiates the component.
The container manages all resources on behalf of the component and manages all
interactions between the component and the external systems.
Example
Application Servers
There are many different types of application
servers in common use today, and each provides a container for some type of
server-based request. For example:
·
A
TP monitor contains transactions and manages shared resources on behalf of a
transaction. Multiple transactions can work together and rely on the TP monitor
to coordinate the extended transaction.
·
A
database management system (DBMS) contains database requests. Multiple database
clients can submit requests to the database concurrently and rely on the DBMS
to coordinate locks and transactions.
·
A
Web server contains Web page requests. Multiple Web clients can submit
concurrent page requests to the Web server. The Web server serves up HTML pages
or invokes server extensions or servlets in response to requests.
Portability
across Containers
The operations and behaviors of a container are
defined by its component model. Unfortunately, each container implements its
own set of services with its own service interfaces. As a result, components
developed for one type of environment are usually not portable to any other
type of environment. The Enterprise JavaBeans component model, however, is
designed to deliver a portability layer for these container systems.
Enterprise JavaBeans Component Model
Overview of Enterprise JavaBeans Technology
JavaBeans
Development Components
The Enterprise JavaBeans component model logically
extends the JavaBeans component model. The JavaBeans component model defines a
standard mechanism to develop portable, reusable Java technology development
components, such as widgets or controls. JavaBeans technology can be used in
any visual Java technology integrated development environment (IDE), such as
IBM Visual Age, Inprise JBuilder, Sybase PowerJ, and Symantec Visual Café. Java
developers use a visual Java IDE to build Java classes, Java applets, Java
applications, or Java technology components. A JavaBeans component (a bean) is
a specialized Java class that can be added to an application development
project and then manipulated by the Java IDE. A bean provides special hooks
that allow a visual Java development tool to examine and customize the contents
and behavior of the bean without requiring access to the source code. Multiple
beans can be combined and interrelated to build Java applets or applications or
to create new, more comprehensive, or specialized JavaBeans components.
Enterprise
JavaBeans Component Model
The Enterprise JavaBeans component model logically
extends the JavaBeans component model to support server components. Server
components are reusable, prepackaged pieces of application functionality that
are designed to run in an application server. They can be combined with other
components to create customized application systems. Server components are
similar to development components, but they are generally larger grained and
more complete than development components. Enterprise JavaBeans components
(enterprise beans) cannot be manipulated by a visual Java IDE in the same way
that JavaBeans components can. Instead, they can be assembled and customized at
deployment time using tools provided by an EJB-compliant Java application
server.
Simplifying
Development
The Enterprise JavaBeans architecture provides an
integrated application framework that dramatically simplifies the process of
developing enterprise-class application systems. An EJB server automatically
manages a number of tricky middleware services on behalf of the application
components. EJB component-builders can concentrate on writing business logic
rather than complex middleware. The results are that applications get developed
more quickly and the code is of better quality.
Implicit
Services
The EJB model supports a number of implicit
services, including lifecycle, state management, security, transactions, and
persistence.
·
Lifecycle.
Individual enterprise beans do not need to explicitly manage process
allocation, thread management, object activation, or object destruction. The
EJB container automatically manages the object lifecycle on behalf of the
enterprise bean.
·
State
Management. Individual enterprise beans do not need to explicitly save or restore
conversational object state between method calls. The EJB container
automatically manages object state on behalf of the enterprise bean.
·
Security.
Individual enterprise beans do not need to explicitly authenticate users or
check authorization levels. The EJB container automatically performs all
security checking on behalf of the enterprise bean.
·
Transactions.
Individual enterprise beans do not need to explicitly specify transaction
demarcation code to participate in distributed transactions. The EJB container
can automatically manage the start, enrollment, commitment, and rollback of
transactions on behalf of the enterprise bean.
·
Persistence.
Individual enterprise beans do not need to explicitly retrieve or store
persistent object data from a database. The EJB container can automatically
manage persistent data on behalf of the enterprise bean.
Portability
Layer
The Enterprise JavaBeans model defines the
interrelationship between an enterprise bean component and an enterprise bean
container. Enterprise JavaBeans components do not require the use of any
specific container system. A vendor can adapt any application server to support
Enterprise JavaBeans technology by adding support for the services defined in
the specification. The services define a contract between an enterprise bean
and the container, effectively implementing a portability layer. Any enterprise
bean can run in any application server that supports the Enterprise JavaBeans
contracts.
Execution
Services
An Enterprise JavaBeans-compliant application
server, called an EJB server, must provide a standard set of services to
support enterprise bean components. Enterprise JavaBeans components are
transactional; therefore, an EJB server must provide access to a distributed
transaction management service. The EJB server must also provide a container
for the enterprise beans, which is called an EJB container. The EJB container
implements the management and control services for one or more classes of
Enterprise JavaBean objects. The EJB container also provides lifecycle
management, implicit transaction control, persistence management, transparent
distribution services, and security services on behalf of the enterprise bean.
In most circumstances, a single vendor would provide both an EJB server and an
associated EJB container, although the specification allows the separation of
these services. For example, a third-party vendor may provide an add-on
container that implements persistence through object/relational mapping.
Potential
Enterprise JavaBeans Systems
The exact natures of process management,
thread-pooling, concurrency control, and resource management are not defined
within the scope of the Enterprise JavaBeans specification. Individual vendors
can differentiate their products based on the simplicity or sophistication of
the services. A software vendor might elect to develop a new application server
specifically to support Enterprise JavaBeans components. It is more likely,
however, that vendors will simply adapt their existing systems. A number of
application servers are currently available, and any of these systems could be
extended to support a container for Enterprise JavaBeans components. An
impressive number of vendors are extending a wide variety of products,
including:
·
TP
monitors, such as IBM TXSeries and IBM CICS/390
·
Component
transaction servers, such as Sybase Jaguar CTS
·
CORBA
systems, such as BEA Systems M3, IBM WebSphere Advanced Edition, and Inprise
VisiBroker/ITS
·
Relational
database systems, such as IBM DB2, Informix, Oracle, and Sybase
·
Object
database systems, such as GemStone GemStone/J
·
Object/relational
caching systems, such as Persistence PowerTier and Secant Extreme
·
Web
application servers, such as BEA WebLogic, Bluestone Sapphire, IBM WebSphere,
Netscape Application Server, Oracle Application Server, Progress Apptivity,
SilverStream Application Server, and Sun NetDynamics.
Versatility
The Enterprise JavaBeans model enables a much higher
level of integration and interoperability than ever existed before. Enterprise
JavaBeans applications can be developed using any Enterprise JavaBeans
technology-compliant environment, and users can deploy the applications in any
other environment. As requirements for higher performance, increased
scalability, or tighter security arise, users can move the applications to an
environment with more comprehensive and sophisticated services.
Architectural Details
The Big
Picture
Enterprise
JavaBeans Server
The EJB server provides an environment that supports
the execution of applications developed using Enterprise JavaBeans technology.
It manages and coordinates the allocation of resources to the applications.
EJB Container
Illustration 2 shows a representation of an EJB
container. The EJB server must provide one or more EJB containers, which
provide homes for the enterprise beans. An EJB container manages the enterprise
beans contained within it. For each enterprise bean, the container is
responsible for registering the object, providing a remote interface for the object,
creating and destroying object instances, checking security for the object,
managing the active state for the object, and coordinating distributed
transactions. Optionally, the container can also manage all persistent data
within the object.
Installing
Enterprise Beans in an EJB Container
Any number of EJB classes can be installed in a
single EJB container. A particular class of enterprise bean is assigned to one
and only one EJB container, but a container may not necessarily represent a
physical location. The physical manifestation of an EJB container is not
defined in the Enterprise JavaBeans specification. An EJB container could be
implemented as a physical entity, such as a multithreaded process within an EJB
server. It also could be implemented as a logical entity that can be replicated
and distributed across any number of systems and processes.
Transient and
Persistent Objects
Enterprise JavaBeans technology supports both
transient and persistent objects. A transient object is called a session bean,
and a persistent object is called an entity bean.
SESSION BEANS
A session bean is created by a client and in most
cases exists only for the duration of a single client/server session. A session
bean performs operations on behalf of the client, such as accessing a database
or performing calculations. Session beans can be transactional, but (normally)
they are not recoverable following a system crash. Session beans can be
stateless, or they can maintain conversational state across methods and transactions.
The container manages the conversational state of a session bean if it needs to
be evicted from memory. A session bean must manage its own persistent data.
Enterprise
JavaBeans Container
Illustration
2. Enterprise beans are deployed in an EJB container within an EJB server. The
EJB container acts as a liaison between the client and the enterprise bean. At
deployment time, the container automatically generates an EJB Home interface to
represent the enterprise bean class and an EJB Object interface for each
enterprise bean instance. The EJB Home interface identifies the enterprise bean
class and is used to create, find, and remove enterprise bean instances. The
EJB Object interface provides access to the business methods within the bean.
All client requests directed at the EJB Home or EJB Object interfaces are
intercepted by the EJB container to insert lifecycle, transaction, state,
security, and persistence rules on all operations.
ENTITY BEANS
An entity bean is an object representation of persistent
data that are maintained in a permanent data store, such as a database. A
primary key identifies each instance of an entity bean. Entity beans can be
created either by inserting data directly into the database or by creating an
object (using an object factory Create method). Entity beans are transactional,
and they are recoverable following a system crash.
Container-Managed
Persistence
Entity beans can manage their own persistence, or
they can delegate persistence services to their container. If the bean
delegates persistence to the container, then the container automatically
performs all data retrieval and storage operations on behalf of the bean.
Entity Objects
Are Optional
In Release 1.0 of the Enterprise JavaBeans
specification, support for session beans is required, but support for entity
beans and container-managed persistence is optional. Mandatory support for
these features will be required in a future version of the specification.
Standard
Contracts
An enterprise bean can be deployed in any EJB
server, even though different servers implement their services in different
ways. The EJB model ensures portability across different EJB servers using a
set of standard contracts between the EJB container and the enterprise bean.
Each enterprise bean is required to implement a specific set of interfaces that
allows the EJB container to manage and control the object. The EJB container is
required to invoke these interfaces at particular stages of execution.
Wrapping and
Interception
An EJB container manages the enterprise beans that
are deployed within it. Client applications do not directly interact with an
enterprise bean. Instead, the client application interacts with the enterprise
bean through two wrapper interfaces that are generated by the container: the
EJB Home interface and the EJB Object interface. As the client invokes
operations using the wrapper interfaces, the container intercepts each method
call and inserts the management services.
EJB Home
The EJB Home interface provides access to the bean's
lifecycle services. Clients can use the Home interface to create or destroy
bean instances. For entity beans, the Home interface also provides one or more
finder methods that allow a client to find an existing bean instance and retrieve
it from its persistent data store.
Naming and
Registration
For each class installed in a container, the
container automatically registers the EJB Home interface in a directory using
the Java Naming and Directory Interface (JNDI) API. Using JNDI, any client can
locate the EJB Home interface to create a new bean instance or to find an
existing entity bean instance. When a client creates or finds a bean, the
container returns an EJB Object interface.
EJB Object
The EJB Object interface provides access to the
business methods within the enterprise bean. An EJB Object represents a client
view of the enterprise bean. The EJB Object exposes all of the
application-related interfaces for the object, but not the interfaces that
allow the EJB container to manage and control the object. The EJB Object
wrapper allows the EJB container to intercept all operations made on the
enterprise bean. Each time a client invokes a method on the EJB Object, the
request goes through the EJB container before being delegated to the enterprise
bean. The EJB container implements state management, transaction control,
security, and persistence services transparently to both the client and the
enterprise bean.
Declarative
Attributes
The rules associated with the enterprise bean
governing lifecycle, transactions, security, and persistence are defined in an
associated Deployment Descriptor object. These rules are defined declaratively
at deployment time rather than programmatically at development time. At
runtime, the EJB container automatically performs the services according to the
values specified in the deployment descriptor object associated with the
enterprise bean.
Context Object
For each active enterprise bean instance, the EJB
container generates an instance context object to maintain information about
the management rules and the current state of the instance. A session bean uses
a SessionContext object, and an entity bean uses an EntityContext object. The
context object is used by both the enterprise bean and the EJB container to
coordinate transactions, security, persistence, and other system services. Also
associated with each enterprise bean is a properties table called the
Environment object. The Environment object contains the customized property
values set during the application assembly process or the enterprise bean
deployment process.
Distribution
Services
Remote Method
Invocation
Enterprise JavaBeans technology uses the Java Remote
Method Invocation API to provide access to enterprise beans. An enterprise bean
developer must define an RMI Remote interface for each enterprise bean. The
container generates the EJB Object interface from the Remote interface
definitions.
Location
Transparency
RMI is a high-level programming interface that makes
the location of the server transparent to the client. The RMI compiler
generates a stub object for each remote interface. The stub object is installed
on the client system (or can be downloaded at runtime) and provides a local
proxy object for the client. The stub implements all the remote interfaces and
transparently delegates all method calls across the network to the remote
object.
Protocols
The Enterprise JavaBeans specification asserts no
requirements for a specific distributed object protocol. RMI can support
multiple communications protocols. The Java Remote Method Protocol is the RMI
native protocol. It supports all functions within RMI. The next release of RMI
will add support for communications using the CORBA standard communications
protocol, Internet InterORB Protocol. IIOP supports almost all functions within
RMI. Enterprise beans that rely only on the RMI/IIOP subset of RMI are portable
across both protocols. Third-party implementations of RMI support other
protocols, such as Secure Sockets Layer (SSL).
Native
Language Integration
By using IIOP, enterprise beans can interoperate
with native language clients and servers. IIOP allows easy integration between
CORBA systems and EJB systems. Enterprise beans can access CORBA servers, and
CORBA clients can access enterprise beans. Using a COM/CORBA Internetworking
service, ActiveX clients can also access enterprise beans and enterprise beans
can access COM servers. Potentially, there could also be a DCOM implementation
of Enterprise JavaBeans technology.
State
Management
Resource
Optimization
Individual EJB server systems can implement
different policies to manage scarce resources, such as memory and threads. Some
EJB servers might maintain all active objects in memory, while others might
evict every object after every method call. Some EJB servers might use a
least-recently-used (LRU) policy to evict objects when resources get tight.
Regardless of the policies used, each EJB server must provide state management
for objects.
Stateful
Session Beans
A session bean represents work being performed by an
individual client. In some cases, that work can be performed entirely within a
single method call. In other cases, the work may span multiple method requests.
If the work spans multiple methods, the object must maintain the user's object
state between method calls. For example, in an e-commerce application, the
CheckCreditAuthorization method performs an entire unit of work and requires no
maintained state. The ShoppingCart object, on the other hand, must keep track
of all the items selected while the customer is browsing until the customer is
ready to buy the items. The state management options for a session bean are
defined in the StateManagementType attribute in the Deployment Descriptor
object. All entity beans are inherently stateful.
Automatic
State Management
If an object is stateless, the container
automatically resets the state within an object instance after each method
call. If the object is stateful, the container automatically maintains the
object conversational state until the session object is destroyed, even if the
object is temporarily evicted from memory. The Enterprise JavaBeans
architecture provides a simple programming model to allow developers to perform
specific functions whenever objects are loaded or evicted from memory. The
Enterprise JavaBeans model isolates these functions in the ejbLoad, ejbStore,
ejbActivate, and ejbPassivate methods in each enterprise bean class.
Stateless vs.
Stateful Servers
Stateless servers use fewer resources and can be
more easily recycled than stateful servers. Since each instance of a stateless
object class is identical, the instances can be pooled and reused repeatedly.
Therefore, many transaction processing experts claim that stateless servers
scale better and are more appropriate for high-volume transaction systems. But
if application requirements dictate an extended, multi-method conversation, it
may be more efficient to use stateful servers.
Persistence
Management
Persistent
Objects
An entity bean represents persistent data. An entity
object generally exists for an extended period of time, and it can be used by
many clients.
Persistence
Programming Model
Enterprise JavaBeans technology provides a simple
programming model for managing object persistence. Persistence functions must
be performed whenever objects are created or destroyed or whenever objects are
loaded or evicted from memory. The Enterprise JavaBeans model isolates these
functions in the ejbCreate, ejbPostCreate, ejbRemove, ejbLoad, ejbStore,
ejbActivate, and ejbPassivate methods in each enterprise bean class.
Entity Object
Persistence
An entity object can manage its own persistence, or
it can delegate its persistence to its container. The persistence options for an
entity bean are defined in the ContainerManagedFields attribute in the
deployment descriptor object.
Bean-Managed
Persistence
If the entity object manages its own persistence,
then the enterprise bean developer must implement persistence operations (e.g.,
JDBC or embedded SQL calls) directly in the enterprise bean class methods.
Container-Managed
Persistence
If the entity object delegates persistence services,
the EJB container transparently and implicitly manages the persistent state.
The enterprise bean developer does not need to code any database access
functions within the enterprise bean class methods. The first release of the
Enterprise JavaBeans specification does not define how the EJB container must
manage object persistence. A vendor may implement a basic persistence service
in the EJB container that simply serializes the enterprise bean's state and
stores it in some persistent storage. Alternatively, a vendor may implement a
more sophisticated persistence service that, for example, transparently maps
the object's persistent fields to columns in an underlying relational database.
A vendor may also implement persistence using an embedded object database.
Session Object
Persistence
Session objects, by definition, are not persistent,
although they may contain information that needs to be persisted. As with
bean-managed entity objects, session objects can implement persistence
operations directly in the methods in the enterprise bean. Session objects also
often maintain a cache of database information that must be synchronized with
the database when transactions are started, committed, or aborted. An
enterprise bean developer can implement transaction synchronization methods
directly in the enterprise bean class using the optional SessionSynchronization
interface. The afterBegin, beforeCompletion, and afterCompletion notifications
signal transaction demarcation points, allowing the object to read or write
data to the database as needed.
Transaction
Management
Distributed
Transactions
Although Enterprise JavaBeans technology can
certainly be used to implement nontransactional systems, the model was designed
to support distributed transactions. Enterprise JavaBeans technology requires
the use of a distributed transaction management system that supports two-phase
commit protocols for flat transactions.
JTS
The Enterprise JavaBeans specification suggests but
does not require transactions based on the Java Transaction Service (JTS) API.
JTS is the Java technology binding of the CORBA Object Transaction Service
(OTS). JTS supports distributed transactions that can span multiple databases
on multiple systems coordinated by multiple transaction managers. By using JTS,
an Enterprise JavaBeans Server ensures that its transactions can span multiple
Enterprise JavaBeans servers.
JTA
Enterprise JavaBeans applications communicate with a
transaction service using the Java Transaction API (JTA). JTA provides a
programming interface to start transactions, join existing transactions, commit
transactions, and roll-back transactions.
Simplicity
Although transaction demarcation in a centralized
application is fairly straightforward, it gets a lot trickier when an
application consists of a variable number of autonomous application components
that call back and forth to each other. Enterprise JavaBeans technology
dramatically simplifies application development by automating the use of
distributed transactions. All transaction functions can be performed implicitly
by the EJB container and the EJB server. Individual enterprise beans need not
make any transaction demarcation statements within their code. Since no
transaction code is required within the application logic, the enterprise beans
are simpler to write and are portable across different transaction managers.
Declarative
Transaction Rules
The transaction semantics for an enterprise bean are
defined declaratively rather than programmatically. At runtime, the EJB
container automatically implements transaction services according to the
TransactionAttribute attribute specified in the deployment descriptor object.
Transaction
Attributes
The Enterprise JavaBeans model supports six
different transaction rules:
·
TX_BEAN_MANAGED.
The TX_BEAN_MANAGED setting indicates that the enterprise bean manually manages
its own transaction control. EJB supports manual transaction demarcation using
the Java Transaction API.
·
TX_NOT_SUPPORTED.
The TX_NOT_SUPPORTED setting indicates that the enterprise bean cannot execute
within the context of a transaction. If a client (i.e., whatever called the
method_either a remote client or another enterprise bean) has a transaction
when it calls the enterprise bean, the container suspends the transaction for
the duration of the method call.
TX_SUPPORTS. The TX_SUPPORTS
setting indicates that the enterprise bean can run with or without a
transaction context. If a client has a transaction when it calls the enterprise
bean, the method will join the client's transaction context. If the client does
not have a transaction, the method will run without a transaction.
·
TX_REQUIRED.
The TX_REQUIRED setting indicates that the enterprise bean must execute within
the context of a transaction. If a client has a transaction when it calls the
enterprise bean, the method will join the client's transaction context. If the
client does not have a transaction, the container automatically starts a new
transaction for the method.
·
TX_REQUIRES_NEW.
The TX_REQUIRES_NEW setting indicates that the enterprise bean must execute
within the context of a new transaction. The container always starts a new
transaction for the method. If the client has a transaction when it calls the
enterprise bean, the container suspends the client's transaction for the
duration of the method call.
·
TX_MANDATORY.
The TX_MANDATORY setting indicates that the enterprise bean must always execute
within the context of the client's transaction. If the client does not have a
transaction when it calls the enterprise bean, the container throws the
TransactionRequired exception and the request fails.
Security
Java Security
The Enterprise JavaBeans model utilizes the Java
security services supported in Java Development Kit (JDKTM) 1.1.x.
Java platform security supports authentication and authorization services to
restrict access to secure objects and methods.
Enterprise
JavaBeans Security
Enterprise JavaBeans technology automates the use of
Java platform security so that enterprise beans do not need to explicitly code
Java security routines. The security rules for each enterprise bean are defined
declaratively in a set of AccessControlEntry objects within the deployment
descriptor object. An AccessControlEntry object associates a method with a list
of users that have rights to invoke the method. The EJB container uses the
AccessControlEntry to automatically perform all security checking on behalf of
the enterprise bean.
Enterprise
JavaBeans Deployment
Packaging
Enterprise JavaBeans components can be packaged as
individual enterprise beans, as a collection of enterprise beans, or as a
complete application system. Enterprise JavaBeans components are distributed in
a Java Archive File called an ejb-jar file. The ejb-jar file contains a
manifest file outlining the contents of the file, plus the enterprise bean
class files, the Deployment Descriptor objects, and, optionally, the
Environment Properties objects.
Deployment
Descriptors
The Deployment Descriptor objects are used to
establish the runtime service settings for an enterprise bean. These settings
tell the EJB container how to manage and control the enterprise bean. The
settings can be set at application assembly or application deployment time.
The DeploymentDescriptor object specifies how to
create and maintain an Enterprise Bean object. This object defines, among other
things, the enterprise bean class name, the JNDI namespace that represents the
container, the Home interface name, the Remote interface name, and the
Environment Properties object name. The DeploymentDescriptor object contains an
array of ControlDescriptor objects, which specify the transaction semantics
that should be applied to the enterprise bean, and an array of
AccessControlEntry objects, which specify the security rules that should be
applied to the enterprise bean.
Session beans and entity beans have slightly
different requirements; therefore, there are two different types of deployment
descriptors.
·
The
SessionDescriptor object extends the DeploymentDescriptor object and adds
attributes to indicate whether or not a session bean is stateless or stateful.
·
The
EntityDescriptor object extends the DeploymentDescriptor object and adds
attributes to indicate which fields within the object should be persisted
automatically by the container.
Environment
Properties
An enterprise bean developer can provide an
Environment Properties object to allow the application developer to customize
the bean to suit the needs of the application. For example, a property might be
used to specify the location of a database or to specify a default language.
Industry Support
Tremendous
Buy-In
The industry has shown tremendous support for the
Enterprise JavaBeans technology initiative. Most major vendors-including IBM,
Oracle, Sybase, Netscape, and BEA Systems-have participated in the definition
of the Enterprise JavaBeans specification. These vendors are in the process of
implementing support for Enterprise JavaBeans technology in their products.
EJB Servers
The first EJB-compliant application servers began to
appear in August 1998. Products that are shipping or in beta as of this writing
include:
·
BEA
WebLogic Tengah
·
Bluestone
Sapphire/Web
·
GemStone
GemStone/J
·
IBM
WebSphere Advanced Edition
·
Novera
jBusiness
·
Oracle8i
·
Oracle
Application Server
·
OrchidSoft
Vanda
·
Persistence
PowerTier
·
Progress
Apptivity
·
Secant
Extreme
·
Valto
Ejipt
Additional EJB-compliant application servers should
be available in early 1999 from vendors, such as Forte, Fujitsu, Haht, Inprise,
Informix, Netscape, Sun, Sybase, and Vision.
Application
Vendors
Application software vendors have also expressed
their support for Enterprise JavaBeans technology. The model increases the
versatility of packaged application solutions. Applications implemented using
Enterprise JavaBeans components can be deployed on a much broader array of systems.
In addition, they support easier customization and integration with existing
application systems. EJB-compliant applications and components are available or
in development from the following companies:
·
Athena
Design Integer (a collaborative spreadsheet)
·
Digital
Harbor personal productivity application components
·
EC-Cubed
electronic commerce components
·
IBI
EDA components (to provide integration with host data and applications)
·
IBM
San Francisco Frameworks (General Ledger, Order Management, etc.)
·
NovaSoft
Novation (an Electronic Document Management System)
·
Oracle
Applications (ERP)
·
Seven
Mountains personal productivity application components
·
TradeEx
procurement components
EJB
Competition
Microsoft
Hold-Out
The primary hold-out against Enterprise JavaBeans
technology is Microsoft. Although Microsoft Transaction Server (MTS) could be
adapted to support Enterprise JavaBeans components, Microsoft is not likely to
make the effort. The Java portability message would undermine Microsoft's
message of tight integration based on the NT platform. Microsoft is pushing
developers to build component-based application systems based on the COM
component model. MTS provides a container system for COM server components,
providing transactional and security services similar to those provided in
Enterprise JavaBeans servers. COM+, the next generation of MTS, will provide a
few additional capabilities, such as dynamic load-balancing and queued
request-processing.
MTS
Limitations
Although COM components provide many of the same
benefits as Enterprise JavaBeans components, there are some significant
differences.
·
Platform
Limitations. COM components rely on a COM runtime system and the DCOM
communication protocol. Although COM and DCOM have recently been ported to
Solaris and other Unix platforms, COM container systems are not available on
these platforms. COM server components can realistically be deployed only on
Windows 95 or NT. Enterprise JavaBeans components are platform independent.
·
Vendor
Limitations. Very few vendors provide container systems for COM and DCOM
components. At the moment, COM containers are available from only two vendors:
Microsoft and Sybase. The COM model does not extend far enough to support
interoperability and transparent portability across these two environments. Any
number of container systems can be adapted to support Enterprise JavaBeans
components, and many vendors have announced their intentions to support the
model, including BEA Systems, Fujitsu, IBM, Oracle, Sybase, and Netscape. The
Enterprise JavaBeans model ensures interoperability and portability across all
of these environments.
·
Client
Limitations. COM and DCOM services are generally not available on non-Windows
clients, such as network computers, information appliances, or smartcards.
Enterprise JavaBeans components can support any Internet-enabled client device.
·
Limited
State and Persistence Management. MTS does not support a distinction between
transient and persistent objects. All MTS components are the equivalent of
stateless session objects. MTS automatically flushes all object state at the
end of every transaction, and developers are responsible for managing all
conversational state. MTS does not support automatic persistent objects.
Developers are responsible for managing all persistent data. Enterprise
JavaBeans technology supports stateless and stateful transient objects and
persistent objects.
·
More
Restrictive Transaction Management. Although MTS supports declarative
transaction management, COM components must still implement some transaction
demarcation code within the application logic. Even so, MTS applications don't
have as much flexibility to override the automatic MTS transaction services.
Enterprise JavaBeans technology requires no transaction demarcation code within
the application logic, but, if a developer chooses, the enterprise bean can
completely control its transaction behavior.
Benefits and Conclusions
Component
Portability
The Enterprise JavaBeans architecture provides a
simple and elegant server component container model. The model ensures that
Java platform server components can be developed once and deployed anywhere, in
any vendor's container system. Even though the container systems implement
their runtime services differently, the Enterprise JavaBeans interfaces ensure
that an enterprise bean can rely on the underlying system to provide consistent
lifecycle, persistence, transaction, distribution, and security services.
Architecture
Independence
The Enterprise JavaBeans architecture is completely
independent from any specific platform, protocol, or middleware infrastructure.
Applications that are developed for one platform can be picked up, moved, and
redeployed to another platform. EJB applications can scale from a small
single-processor, Intel-based Novell environment to a large multiprocessor,
UltraSPARCTM environment to a massive Sysplex IBM mainframe
environment-all without modification.
Developer
Productivity
The Enterprise JavaBeans architecture improves the
productivity of application developers. The Enterprise JavaBeans environment
automates the use of complex infrastructure services, such as transactions,
thread management, and security checking. Component developers and application
builders do not need to implement complex service functions within the
application programming logic.
Highly
Customizable
Enterprise JavaBeans applications are highly
customizable. The underlying component model supports customization without
requiring access to source code. Application behaviors and runtime settings are
defined through a set of attributes that can be changed at deployment time.
Wrap and
Embrace
The Enterprise JavaBeans architecture is an
extremely compatible evolutionary environment. The Enterprise Java services
layer over existing infrastructure services. Organizations are not required to
implement yet another incompatible set of middleware technologies. Enterprise
JavaBeans technology enhances, enables, and simplifies popular systems, such as
CORBA or DCOM.
Versatility
and Scalability
The Enterprise JavaBeans model is based on an
extremely versatile and powerful multitier, distributed object architecture
that relies on industry-standard protocols. The model is appropriate for
small-scale applications or large-scale business transactions. As application
requirements grow, applications can migrate to progressively more powerful
operating environments. The environment inherently supports Web-based
applications and a variety of other Internet-enabled client devices. Additional
client systems can be added at any time without modification of the core
application systems. Enterprise JavaBeans technology provides an environment
that is designed to grow with the industry to support new technologies as they
emerge.