EJBW

Deploying Enterprise JavaBeans™ using JDeveloper
™
2.0
An Oracle Technical White Paper
November 1998

Deploying Enterprise JavaBeans
using JDeveloper 2.0
INTRODUCTION
Enterprise developers face a formidable task today. The creation of a distributed business application
is not a simple endeavour. The actual creation of any large application is problematic. This
development process is made more so when an application is distributed, or if that application resides
in multiple pieces across a network. Compounded when an Enterprise application must be consistent
and reliable across multiple platforms that are scattered across the Web
An issue many enterprises face is the use of applications that are primarily standalone. These
applications must be created and launched as quickly as possible without being locked into one
platform. The ideal enterprise application would be one that was written once and which would run on
all platforms.
A second issue concerns how such applications are deployed. On the one hand, the changes are being
driven by the rapid growth of business on the Internet, which has created new business models,
reduced time to market, and significantly changed the way corporations look at developing and
deploying enterprise applications. On the other hand, the Internet also provides the medium for
accelerated adoption of distributed computing. It provides standard protocols, like HTTP and IIOP,
built on TCP/IP using the World Wide Web browser as its interface, and it allows universal access to
these applications. The Internet has created several new classes of applications, such as electronic
commerce and self-service applications, that need to be integrated with traditional enterprise
applications.
COMPONENTS AND COMPONENT-BASED APPLICATION DEVELOPMENT
Components allow the development of low-cost, high quality products, with a lightning-fast
turnaround time, due to the modular character of component development. Since transactional code is
taken care of on the server side of the Enterprise JavaBean (EJB) architecture, and is resident in the
EJB code only as flags, the emphasis on the application development is on better and more compact
components which address specific application-level tasks.
Benefits of Component-based Development
Component-based application development offers several benefits that make application development
more productive:
1. Better Design and Code Reuse - Component-based software allows developers to reuse business
logic. Instead of attempting to reuse applications at the class-level, server-oriented business logic
is much more effectively captured as coarse-grained reuasable components.
2. Easier to Maintain - Component-based software improves applications, since they are structured as
reusable modules with clean interfaces.

Deploying Enterprise JavaBeans using JDeveloper 2.0, An Oracle Technical White Paper
3
3. Easier to Deploy Across Tiers - Component-based software simplifies deployment, because
components can be transparently distributed across networked servers in a multi-tier environment.
This allows considerable deployment flexibility.
Over the last few years, we have witnessed the rapidly increasing popularity of client-side
components. JavaBeans and COM components are already being widely used to assemble GUI-based
applications. A large number of vendors supply tools for developers, to help them rapidly assemble
client-side applications, using beans or ActiveX controls. However, there was still a lack of a robust,
scalable server-side component model.
Server components encapsulate business logic that can be deployed on a variety of servers that
provide services, like transactions, security, and the messaging needed to manage these components.
Server components are easily adaptable to changing business rules, and can be deployed across a
variety of servers for high availability and scalability. Unlike client-side components, server-side
components allow developers to rapidly assemble enterprise applications from pre-fabricated
components. These components are typically transactional, and need to run in a server environment
that can scale to meet the challenging needs of today’s mission-critical applications.
One model, that is used predominantly by Java programmers, and is rapidly eclipsing many other
models for server-side components, is the Enterprise JavaBeans (EJB) model; a cross-platform,
server-side component model for Java, Enterprise JavaBeans extend the JavaBeans architecture to
provide a distributed component architecture. It enables developers to focus on developing business
logic, and packaging them as components that can be transparently deployed in servers that support
the EJB platform. Developers do not need to worry about low-level system programming using
session management, remote invocation, transaction, security, and multithreading. EJBs also enable
developers to develop applications on one platform without worrying about how and where the EJBs
will be deployed.
Emphasis can now be placed on the design of integral, reusable chunks of business logic, known as
Enterprise JavaBeans. These relatively coarse-grained units of logic are provided with clearly
specified interfaces that interact with server infrastructures provided by EJB Transaction Servers,
providing distributed transaction services, and thereby shifting the burden of management of
transactional behavior to the server. The Enterprise JavaBean technology can be used to construct
applications that access multiple, distributed databases, across multiple EJB servers.
Security is managed either through a security descriptor in the Enterprise JavaBean's EJB-JAR file, or
by using the java.security package to manage it.
Enterprise JavaBeans (EJBs) are communication protocol-neutral. This frees the application developer
to implement the client side of his application in the protocol of their choice. It also allows the
Enterprise JavaBean server builder to implement protocols that best serve the customer base.
EJBs can be developed for and deployed to Oracle8I, using Oracles' JDeveloper to create an EJB as a
new class, or, alternatively, to create an EJB by extending an existing class, or by transforming an
existing class into an EJB. JDeveloper provides convenient code generation features that simplify
creating new EJBs from scratch and as extensions or transformations of existing classes.
Creating EJBs by extending classes or transforming existing classes allows you to use the investment
in application business logic included in the original class. Use the JDeveloper source editor to add to
an EJB's business logic; use the JDeveloper EJB Wizard to expose this business logic through EJB

4
interfaces. Future releases of JDeveloper will include additional development tools that simplify the
development of EJB business logic.
Another benefit provided by the Java platform, is that any application that is constructed using the
EJBs will launch and run anywhere an Enterprise JavaBean server is running. This is especially
beneficial in terms of scalability. If an Enterprise JavaBean application is pushing the performance
envelope on its current server, it can be moved in its entirety to a higher performance Enterprise
JavaBean server. .
Despite several attempts by the software industry, the promise of assembling business applications
from pre-fabricated components has remained unfulfilled, until recently. Object oriented
programming languages promised much reuse, but failed to deliver, because they did not enable the
interoperability of components at the binary level. However, there is renewed hope that application
developers will be able to assemble applications from pre-fabricated components. Component
technologies, such as JavaBeans, CORBA, and Microsoft’s COM, provide the infrastructure that
enables developers to assemble applications from components that different vendors have developed.
This component model relies on the development and deployment of applications that are based upon
a multi-tier, distributed object architecture. In this paper we show you how to develop and deploy
EJBs in the Oracle8i database server, using Oracle's JDeveloper product.
ORACLE8i’S FEATURES
Java’s promise of “write once, run anywhere” has made it the language of choice for developing and
deploying intranet/Internet applications. More than 400 applications have already been certified as
100 percent Pure Java™
. Java is enabling network computing solutions that can execute on a simpler,
lower cost, network-centric IT infrastructure. While Java is helping IT lower the cost of ownership of
business applications, it is also a very popular choice among application developers, because of its
productivity benefits. Apart from being a modern, object oriented, platform-independent, and safe,
Java offers a component model that enables application developers to build applications from
components. Several tools available in the market today allow building client-side Java applications
by dragging and dropping JavaBeans. However, until now, little progress has been made in
leveraging these strengths to develop server-side applications. To succeed as a language for
developing server-side applications, the Java Virtual Machine (VM) needs to be scalable, secure,
manageable, and highly available.
Java’s initial popularity came because of its ability to add dynamic content, in the form of applets, to
web pages. However, Java is rapidly evolving toward its primary use in the future, writing enterprise
and Internet applications that can be deployed in either client-server, or intranet/Internet
configurations. Several factors account for Java’s popularity as a server language.
Java is a safe language and is, therefore, ideally suited for database integration. The database is a safe
environment that provides the foundation for several mission-critical applications. Therefore, Oracle
does not allow application code that could compromise the integrity of the database (code written in
C) to run inside the database. Java is a strongly typed language, has native support for arrays and
strings, and has built in support for memory management. The garbage collection mechanism built
into the Java language frees developers from allocating and de-allocating memory, thereby eliminating
problems of memory corruption and memory leaks.
Apart from being a safe language, Java enables true application partitioning in a multi-tier
environment. Since Java is platform-independent, application logic developed in Java can be

5
deployed on any server that supports Java. Applications written in Java can be easily used on another
server, without having to be rewritten. Enterprises can leverage these benefits to improve time-to-
market, and to lower system development and administration costs.
Although Java is an ideal language for developing enterprise and Internet applications, there are no
enterprise class Java servers available in the market today. Most server-side Java applications run
with JavaSoft’s Java Virtual Machine, or some variant of it. The Java VM from JavaSoft was
developed as a client-side VM that focuses on a single-user environment. It was not designed to run
enterprise applications, and it does not meet the requirements of an enterprise server. It uses built-in
multithreading to provide limited scalability. It does not offer the performance, scalability,
robustness, and high availability needed for deploying enterprise applications. Client-side VMs do not
scale for several reasons:
• Single Object Memory All objects are created in one type of “object memory,” and, thus, need
to be scanned by the garbage collector, which slows down performance and results in
poor scalability.
• Multi-User Scaling Via Threads The JDK Java VM achieves multi-user scalability, by using
lightweight threads. This model does not scale very well when the number of concurrent users
becomes very large, to the order of 10,000+.
• Dynamic Compilation Java is an interpreted language, so it is slow. Several vendors have tried
to improve the performance of Java programs, by using clever optimizations and just-in-time
(JIT) compilers that compile the bytecodes just before execution. Since JIT compilers compile a
class at a time, as they are downloaded into a browser, they provide limited performance
improvements. JIT compilers focus more on fast compilation techniques, and less on the
performance of the compiled applications. Again, these optimizations do not work well in a
server environment, where most of the code that needs to be optimized is known much before
deployment time. In this case, coarse-grained optimizations, beyond the reach of JIT compilers,
can be used to improve performance.
Implementing a scalable Java Virtual Machine is a challenge, because it has to deal with automatic
storage management, multithreading, and dynamic loading. Oracle8i’s server side Java VM is
compliant with Sun’s Java specification, to provide the best-in-class server platform on which to
deploy enterprise and Internet Java applications.
Oracle8i’s Java Virtual machine was designed with the following features:
• High Performance For transaction processing and decision support applications.
• Scalability To support very large numbers of users.
• High Availability To meet the 24 x 365 availability of enterprise and Internet applications.
• Manageability To lower the total cost of ownership, and deliver high quality of service.
• Compliance With Standards To enable any standard Java program to be deployed in
the database.

6
With the Oracle8i release, Oracle has delivered a server side Java Virtual Machine that is 100 percent
compatible with JavaSoft’s specification. It also meets the requirements for deploying mission-critical
server-side applications: it is a highly scalable, highly available, easily manageable, secure and high
performance Java Virtual Machine. Using Oracle8i’s Java VM, businesses can realize Java’s true
potential, by developing business logic in Java and deploying it on a scalable Java platform.
Oracle8i’s Java Virtual Machine runs in its database engine (Figure 1), giving developers the
flexibility of creating their applications in a variety of programming models. While application
developers can still use the conventional stored procedures to develop their application logic,
developers familiar with component-based programming can write their applications as CORBA
objects, or as EJBs, and deploy them in Oracle’s Java platform.
Figure 1: Oracle’s Java Virtual Machine
Java is also suited to completely new classes of software being written by independent software
vendors to provide many new services on the Internet. Oracle’s enterprise Java platform will provide
an ideal deployment vehicle for such applications, ensuring the widest availability of application
solutions to Oracle’s customers.
CORBA 2.0 Compliant Java Object Request Broker (ORB)
The Oracle8i database server integrates a Java-based CORBA 2.0 compliant Object Request Broker
[ORB]—Visibroker—that provides users with the ability to call-into and out of the database server
using CORBA’s IIOP protocol. CORBA Servers and EJBs in release 8i can be invoked from clients
using IIOP - the database server then behaves as a CORBA server. Similarly, IIOP call-outs from
release 8i allows the database to serve as a standard CORBA client. The ORB is used efficiently in
release 8i - the Visigenics ORB components are used purely for IIOP protocol interpretation and
object activation while the RDBMS’s Multithreaded configuration provides a number of services
including load balancing, failover, transactions, security, data dependent routing, connection pooling,
and shared memory management.
The SQL-oriented listener/dispatcher architecture has been extended to support CORBA/IIOP. The
ORB is used only for IIOP protocol interpretation and object activation, while the database’s
multithreaded server (MTS) kernel is leveraged to deliver scalability. The MTS architecture has
previously demonstrated scalability into the tens of thousands of concurrent users. Thus, our purpose
was to support open-systems Java APIs on an existing, highly scalable infrastructure. The Java ORB
enables users to call into and out of the database server using CORBA’s IIOP protocol. CORBA
objects deployed in the Oracle8i database can be invoked using the industry standard IIOP protocol.
The database server then behaves as a CORBA server. Similarly, IIOP callouts from the database
allow it to serve as a standard CORBA client and invoke CORBA objects in other servers. Further,
the CORBA facilities in the RDBMS are both Java-friendly with a number of automated tools, such as
the automated “Caffeine” Java-to-IDL compiler.

7
ENTERPRISE JAVA BEANS
Enterprise JavaBeans (EJB) technology seeks to redress this problem, by streamlining the
development process, and by providing tools that will shorten and flatten out what is now a very steep
development curve for application developers.
To reiterate, an Enterprise JavaBeans component or application is a relatively coarse-grained set of
Java application logic defined as a component with clearly specified interfaces that can be efficiently
executed on a server infrastructure that provides it with a number of services. EJBs provides Java
application programmers a very convenient and highly productive component model for server-side
business logic facilitating application code-reuse and multi-tier application development. Oracle8i
provides a highly scalable and high performance execution environment for EJBs while complying
completely with the Enterprise JavaBeans 1.0 Specification.
The Enterprise JavaBeans facilities in Oracle8I, while complying with the standard Enterprise
JavaBeans specification, provide a number of important benefits including a very easy to use
development and deployment environment, with a number of automated tools, a highly secure
environment, and unmatched performance and scalability.
The EJB architecture has been designed to allow enterprise developers to focus their energies on
actually writing business logic. Much of the implementation code (i.e., transactional behavior,
threading, security, etc.), previously an additional responsibility of the application developer, is now
taken care of by the Enterprise JavaBeans architecture, which delegates this task to the server vendor.
EJBs use a component model for the development and deployment of Java applications, one that is
based on a multi-tier, distributed object architecture. These component objects are reusable across
different applications. The objects are pre-written and tested chunks of application code that an
application developer can use as building blocks in putting together functioning application systems.
Oracle8i’s Java VM provides a number of Enterprise JavaBeans services. It provides a Java
Transaction Service API via the embedded JDBC driver which has been extended to support Java
Transaction Service -visible transactions. The Oracle8i Java Transaction Service provides
transactional properties to EJB components on the Java VM. It exposes a Java Naming and Directory
Interface interface to any industry standard LDAP-enabled directory service. EJB components in the
server can be placed in the directory service from which they can be accessed via Java Naming and
Directory Interface. It provides a stringent security framework using Internet standard security
mechanisms such as SSL over IIOP for encryption, coupled with traditional database authentication
and multiple layers of access control.
Enterprise JavaBeans Benefits
Enterprise JavaBeans offer a flexible and portable component solution. Because they are targeted at
server-side, reusable business logic, they provide the benefits of the EJBs approach, for both
application users and developers.
Portability
Enterprise JavaBeans technology is independent of the underlying middleware. The developer sees
only the Java platform. In addition to the ability to write one application that will work across
platforms, the architectural independence of EJBs allows the server vendor to rewrite the middleware
layer and take advantage of evolving technology, without disturbing the overlying EJB applications.

8
Any server that provides Enterprise JavaBeans APIs will run an EJB.
Productivity and Ease of Use
Enterprise developers are more productive when using the EJB technology. Not only do they reap the
productivity gained by employing the Java platform; they start a step ahead, by only having to focus
on writing business logic. The Enterprise JavaBean is also customizable, without affecting its
transactional behavior. It provides a secure and scalable transactional environment where the bean can
operate.
Reduced Investment
EJB technology builds on systems that currently exist. Many forthcoming EJB products are built on
established enterprise systems.
Industry Support
Customers building systems employing EJBs have a wide range of solutions available that Enterprise
JavaBeans supports; solutions adopted and implemented by such companies as…(list of companies)
ENTERPRISE JAVABEAN ARCHITECTURE
The Enterprise JavaBeans (EJB) architecture provides a server-side environment that reduces and
simplifies the process of building distributed applications. It has done so by transforming features that
were previously hand-coded into simple declarative properties of the Enterprise JavaBeans objects
themselves.
EJB Architecture
The EJB component is the server side object which contains the business logic. The EJB container,
which is part of the EJB server, provides a number of runtime services to the bean. These include
transaction services, synchronization services, and security. The availability of these easy-to-use
services allows the bean developer to focus on implementing the business logic.
These declarative properties generate an increase in development efficiency because transactional
behavior such as security are not actually written into the code explicitly, but are declared as "flags"
on the Enterprise JavaBeans themselves. This feature allows the application developer time to focus
on writing crack business logic.
The Enterprise JavaBeans architecture supplies an infrastructure for "plumbing"support (transactions,
security, threading, naming, object-life cycle, resource pooling, remote access, and persistence). It
provides simplified access to existing applications, and a uniform application development model for
tool creation and use.
The Server and the EJB Container
An EJB container provides a home for EJB components. A container is where a Bean lives and
conducts its business. It provides a secure and scalable transactional environment where the bean can
operate. It is the container that handles the object life cycle.
The EJB server must provide an Enterprise JavaBeans Container (EJB container) for an enterprise
bean. EJBs are deployed within that bean container which is within an Enterprise JavaBeans Server,
for the entire life cycle of that Enterprise JavaBean. The bean container supplies an interface for

9
creating new instances of that bean and a Finder interface for locating existing instances of entity
beans. This container also generates an EJB object interface, which is a client view of the enterprise
bean. All client requests that are directed at an Enterprise JavaBean object are intercepted by the EJB
container for the insertion of transaction, state, and security rules on all operations.
The EJB container is responsible for managing a class of Enterprise JavaBean objects. Not only does
it manage the life cycle of that Enterprise JavaBean object, it also implements security for that object,
and it coordinates all distributed transactions. The EJB container also provides a naming context for
the object. One class of enterprise bean is assigned to a single EJB container. One EJB container
contains a single Enterprise JavaBean class. The EJB container is not defined in the Enterprise
JavaBeans specification. It can be implemented as a physical entity, such as a multithreaded process
within an EJB server. It can also be implemented as a logical entity that can be replicated and
distributed across any number of systems and processes.
The bean container is transparent to the client. There is no client API to it. When a Bean is installed in
its container, that container then provides two kinds of implementations: an implementation of the
Enterprise JavaBean's Home interface, and the Enterprise JavaBean's remote interface.
Home Interfaces and Remote Interfaces
When it is necessary to create an instance of a bean, this is done by creating a Home Interface that
takes no parameters. This interface is created by the container class itself, and specifies one or more
Create() methods which take only the parameters that are passed in from the remote interface (see
below) of the client, when an instance of a bean is created.
For each Create() method in the home interface, a corresponding method must exist in the Remote
Interface, which are public interfaces that the developers must write for each Enterprise JaveBean in
their application. These interfaces specify the business methods that the Enterprise JavaBean contains.
Each method in the EJB that the client is needs to have access to must be specified in the remote
interface. The signatures for these methods must match the corresponding signature in the bean's
implementation. The bean instance code implements the methods that are passed in from the remote
interface.
Client-side Code
The Client-side Application must contain the following code:
1. Downloaded Java code
2. A Java application program (this program must contain a Main() method
3. An Enterprise JavaBean
The application must be able to locate the EJB in the Home Interface, and invoke methods on it.
State Management
The Enterprise JavaBean container manages the state of the object. The state of an Enterprise
JavaBean refers to the data contained within that bean. Often, this data is transient and pertains only to
the execution of a specific method invocation. At other times, this data is persistent and pertains to
multiple method invocations. EJBs support both transient and persistent objects. A transient object is
called a session object, and a persistent object is called an entity object.

10
Session Beans and Entity Beans
There are currently two models for building enterprise applications. In the first model, the client
begins a session with an object that acts like an application, and executes a unit of work on behalf of
the client, which may include multiple database transactions. This is a Session bean.
A Session Bean is an object that represents a transient conversation with a client. Session beans
perform operations on behalf of the client, such as accessing databases or performing calculations.
These database accesses can be in the context of a transaction. A Session Bean's fields contain the
state of the conversation and are transient. This model is typically used with database programming
languages such as PL/SQL. A session bean is created by a client and usually exists only for the
duration of a single client/server session. These objects are usually transactional, but are not
recoverable subsequent to a system crash. Session beans can be stateless, or they can maintain a
transitional, conversational state across methods and transactions. The bean container manages the
conversational state of a session bean if it has to be evicted from memory. A session bean manages its
own persistent data.
In the second model, the client accesses a bean that represents an entity in a database. Entity Beans
cover the second model. An Entity Bean represents data in a database, along with the methods to act
on that data. In a relational database context, for a table of employee information, there is one Bean
for each row in the table. Entity Beans are transactional, and are long-lived. As long as the data
remains in the database, the entity Bean exists. This model is most typically used today in the object-
oriented database market.
In the EJB specification, support for Session Beans is mandatory. Support for Entity Beans is
currently optional, but will become mandatory for version 2.0 of the specification.
Transactions
Although EJBs can be used in the implementation of nontransactional systems, the Enterprise
JavaBean model is designed for the support of distributed transactions. These transactions are based
on a subset of the Java Transaction Service (JTS) API, which is the Java binding of the CORBA
Object Transaction Service (OTS). These distributed transactions can span multiple databases on
multiple systems that are coordinated by multiple transaction managers. By using JTS, an Enterprise
JavaBeans Server ensures its transactions can interoperate with other EnterpriseJavaBeans Servers.
Transaction functions are performed automatically and implicitly by the EJB container and the EJB
server. Individual EJBs are not required to include transaction demarcation statements in their code.
Since this transaction code is not required within the Enterprise JavaBean application logic, these
beans are easier to write and portable across multiple platforms and transaction managers.
Rules for Enterprise JavaBean transactions are defined either at an application's assembly or
deployment time. The semantics are defined declaratively rather than programmatically. At runtime,
the Enterprise JavaBean container will automatically implement transaction services according to a
transaction attribute that is specified in the deployment descriptor that is associated with each
Enterprise JavaBean.
Security
Enterprise JavaBeans currently utilize Java security services that are supported in (JDK) 1.1.x. This
security supports authentication and authorization services that restrict access to all secure objects and
their methods. Typically, Object users are represented by correlative Identity objects. These users can

11
then be authenticated using passwords, certificates, public keys, and other credentialling methods. A
user can assume the identity of other users to act by proxy. Objects and their methods are secured
using SecurityDescriptor objects. These objects then identify which users have access to a given
object.
Enterprise JavaBeans automate the use of Java Security so that the beans are not required to code to
the Java Security API directly. Security rules for each enterprise bean are defined declaratively in the
SecurityDescriptor object. The Enterprise JavaBean container then uses the SecurityDescriptor to
automatically perform all security checking on behalf of the enterprise bean.Oracle8i is a container
provider for EJBs that are produced by JDeveloper. EJBs deployed to Oracle8i can become servers
using the container framework provided in Oracle8i. Oracle8i supports the standard EJB 1.0
specification, but provides a number of database specializations that ensure its implementation is fast,
highly scalable, and secure. To reiterate, here are some salient features of Enterprise JavaBeans:
• Higher Level of Abstractions EJBs offer a higher level of abstraction than CORBA, which does
not require advanced systems programming skills.
• No Foreign IDL EJBs are simplest for Java developers, since they have a pure Java definition
that avoids dependency upon systems, such as CORBA and DCOM. Java developers do not
have to learn another interface definition language (IDL) to define the interfaces of the
components they are developing.
• Execute In a Container An EJB executes inside a container. Simply stated, 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 or a web page. Server
components are non-visual and execute within a container supplied by an application execution
environment, such as a transaction processing (TP) monitor, a web server, or a database system.
• Declarative Programming Model Further, EJB has a simple declarative transaction model that
allows users to specify transactional boundaries declaratively. They happen automatically when
JavaBeans methods are executed.
• Portable Across Servers In addition, EJBs are portable across a range of Java VMs. The EJB
transaction server concept allows platform vendors to add value in the form of scalability,
reliability, and atomic transactions.

12
HOW TO DEVELOP AND DEPLOY ENTERPRISE JAVABEANS USING JDEVELOPER 2.0
Now that we have described Oracle8i’s Java VM and the Enterprise JavaBean component model, let’s
look at how to implement EJBs in the Oracle environment. This section will give you complete step-
by-step demonstration on developing and deploying an EJB in the Oracle8i database, using the
JDeveloper product. Since EJBs have pure Java definition, users do not need to use an IDL to define
the object interfaces. All interfaces are defined using Java.
EJB Development Roles
The EJB specification describes enterprise bean development in terms of roles. There are six roles in
the EJB universe:
1. The EJB developer writes the code that implements individual EJBs. This code is the business
logic of the application, usually involving database access. The EJB developer is a Java
applications programmer, and is familiar with both SQL and with database access using SQLJ or
JDBC.
2. The EJB deployer installs the EJBs in the EJB server. The EJB deployer writes the deployment
descriptor files that specify the properties of each bean to be deployed.
3. The EJB server vendor implements the framework in which the EJB containers run.
4. The EJB container vendor supplies the services that support the EJB at runtime.
5. The application developer writes the client-side application that calls methods on server EJBs
Oracle 8i provides the EJB runtime environment via the EJB server and container while Oracle
JDeveloper 2.0 plays the role of the EJB developer and deployer. Additionally , application
developers could use Oracle JDeveloper to create client-side applications that use EJBs.
Specifcally, Oracle JDeveloper 2.0 provides support for EJBs by
∑ Encapsulating business logic in EJBs using the EJB Wizard
∑ Deploying EJBs to the EJB Server in Oracle 8i using the EJB Deployment Profile Wizard
When you deploy an EJB, you must have a deployment descriptor that provides information
regarding the EJB to the EJB container.
The deployment descriptor is a text file; in the current version of JDeveloper, information
provided in the default deployment descriptor file is generated by the EJB Profile Wizard. The
default deployment descriptor name is EJBname.dd.
When you run the EJB Profile Wizard, instead of generating a deployment descriptor, you can
actually specify an existing deployment descriptor. If you choose to use an existing deployment
descriptor, you must use a text file that is formatted as described in the "Deployment" section, in
Chapter 3, "Enterprise JavaBeans" in the Oracle8i Enterprise JavaBeans and CORBA Developer's
Guide.
6. EJBs require one home interface and one remote interface. These home and remote interfaces
include different methods. The EJB Wizard makes these different methods eligible to the home
and remote interfaces. For the home interface, all create() and find() methods are eligible. create()
methods are derived by the EJB Wizard from ejbCreate() methods coded in the bean. For the
remote interface, all public methods except those eligible as home interfaces (create() and
findxxx() methods) are eligible.

13
If you have EJBs which do not include any methods for home or remote interfaces, you must use
the JDeveloper source editor to add at least one eligible method for the home interface and as
many eligible methods for remote interfaces as are required for your deployment.
OVERVIEW OF EJBS
Before we dive into the EJB example, let’s briefly overview some concepts regarding state,
persistence, and the different types of Enterprise JavaBeans.
• Persistent Data Data that resides in the persistent store. It is transactional and shared.
Examples of persistent stores are a relational database and an object oriented database.
Examples of persistent data are a row in a table of a relational database or a page of objects in an
object oriented database. The transactional sharing of persistent data is handled by the persistent
store, and the transactional services of the EJB runtime are used to ensure the ACID properties
of the persistent data.
• Transient Data Data that resides only in the enterprise bean itself. Transient data is not
reflected in the persistent store and is private to the enterprise bean instance.
• The Persistent State Cache The cache that the enterprise bean uses to manipulate the data in the
persistent store. Thus, the persistent cache represents persistent data, but is not the persistent
data. The developer uses hooks that demarcate the beginning and end of a transaction to provide
a coherent view of the persistent data.
• The Conversation State A composite of both the cached persistent data and the transient data.
The Enterprise JavaBeans specification describes three types of beans (stateless session beans, stateful
session beans, and entity beans), primarily related to how the beans persist in their state. The EJB
container manages the state of the bean that is referring to the data contained within the 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, also known as transient beans, can be
transactional, but they cannot be recovered after a system crash. There are two kinds of session beans:
• A Stateless Session Bean A bean that maintains no conversational state across methods
and transactions. The EJB server transparently reuses instances of the bean to service
different clients.
• A Stateful Session Bean A bean that maintains conversational state across methods and
transactions. As a result, the EJB server binds the Enterprise Bean instances to clients directly.
Session beans, by definition, are not persistent, although they may contain information that
needs to be kept. Session beans can implement persistence operations directly in the methods in
the enterprise bean. Session beans often maintain a cache of database information that must be
synchronized with the database when transactions are started, committed, or aborted. With
Oracle8i, such state synchronization occurs using JDBC or SQLJ. SQLJ is a standard way of
embedding static SQL statements in Java programs.

14
Figure 2: How Clients Access Session Beans
Entity Beans
Also known as persistent beans, entity beans have an identity that, in general, survives the crash and
restart of the container in which they are created. Transparent to the client, the container provides
security, concurrency, transactions, persistence, and other services for the EJB objects that live in the
container. Multiple clients can access an entity object concurrently. The container in which the entity
bean is installed synchronizes access to the entity state.
Entity Beans are an optional part of the Enterprise JavaBeans specification, and this part of the
specification has not been completely standardized. As a result, Oracle8i does not support them. It
only supports Session Beans. Oracle plans to support entity beans in a future release.

15
USING JDEVELOPER 2.0
The following scenario will walk you through the typical step-by-step development of an EJB, using
JDeveloper 2.0.
1. In an 8.1.4 or higher database, create a travel user account with a password of travel. (i.e. Bring up
SQLPLUS, connect as system/manager and enter : create user travel identified by travel;).
2. Grant appropriate privileges to the account (i.e. grant connect,resource to travel;).
3. Import the travel schema dump file (Open a command shell and enter : imp81
travel/travel@<yourDatabase> file=<fullpath>simpletravel.dmp fromuser=travel touser=travel).
4. Unzip TravelEJBDemo.zip into your %jdeveloper%myprojects directory. This will add the
Workspace file, TravelLogic.jws, and two sub-directories: TravelClientEJB and TravelLogicEJB
to the 'myprojects' directory. Both sub-directories contain a JDeveloper project with the .jpr
extension. The Workspace, TravelLogic.jws, is the parent level object which contains the two
projects.
5. Start JDeveloper.
6. To Open the TravelLogic.jws Workspace:
∑ Select from the menu: File|Open
∑ This shows the contents of the %jdeveloper%myprojects directory (if you do not see the
'myprojects' directory by default then navigate through the directories displayed in the
File|Open dialog till you reach the 'myprojects' directory)
∑
Double-click the TravelEJB.jws. This will open the TravelEJB.jws WorkSpace in the Navigator
Pane. The Workspace contains two projects , TravelClientEJB and TravelLogicEJB.
The screenshot below shows JDeveloper with the Workspace Open
7. To change the <HostID> in JFlightFrame.javaof TraveClientEJB.jpr:
∑ Double-Click JFlightFrame.java to view it in the code editor
(Screen shot)
∑

16
In line 41 i.e
( String ejb_test_URL = "sess_iiop:/" + "/<HostId>:2222/test/TravelEJBRemote";)
replace <HostId> by the hostid or IP address of your Oracle 8i machine. The modified URL will
read: String ejb_test_URL = "sess_iiop:/" + "/my8iHost:2222/test/TravelEJBRemote";
8. To change the path for ImageIcon to point to your location of JDeveloper:
∑ Double-Click JFlightFrame.java to view it in the code editor
(Screen shot)
∑ In line 44 make the following changes:
Original - new ImageIcon
("C:Program FilesOracleJDeveloper 2.0myprojectsTravelClientEJBsmallplane.gif");
Modified - new ImageIcon
("C:<YOUR_JDEVELOPER_DIRECTORY>myprojectsTravelClientEJBsmallplane.gif");
Note that '' is used as the separator
∑ Similarly, in line 45
Original - new ImageIcon
("C:Program FilesOracleJDeveloper 2.0myprojectsTravelClientEJBtravel.gif");
Modified - new ImageIcon
("C:<YOUR_JDEVELOPER_DIRECTORY>myprojectsTravelClientEJBtravel.gif");
Note that '' is used as the separator
The bold lettering on TravelLogicEJB.jpr means that it is the 'Active Project' . In case it is not the
active project, then click the right-mouse over TravelLogicEJB.jpr and select 'Set As Active
Project.' You will see the screen as shown below:
9.
Right-mouse click on FlightJDBC.java and Select Make to compile the file . The status bar at the
bottom of the AppBrowser should now read as below:
10. Now follow Steps 1-52 prior to performing the demo with the particular instance of 8i. (This is
done so that steps 41-52 can be skipped while during the actual demo.)

17
DEFINING AND DEPLOYING BEANS: A DEMO
The following demo is based on the Travel theme. The client application provides an interface to
determine the next available flight between two cities based on the user input for the cities of 'Origin'
and 'Destination'. The demo is divided into two parts, and will demonstrate the following:
1. Developing and Deploying EJBs using JDeveloper
∑ Developing EJBs using the EJB wizard in JDeveloper
∑ Deploying EJBs to Oracle 8i using the EJB deployment profile wizard
2. Reusing the deployed EJB from a client application
Developing EJBs using the EJB wizard in JDeveloper
In this section, we start with an existing Java class which implements some business logic.
1. Double-Click on FlightJDBC.java
The file appears in a code editor, and contains the business logic to encapsulate in an EJB.
(Screen shot)
2. Scroll down the file, FlightJDBC.java, and point at the SQL query.
The 'Next' method in this class accepts the names of the origin and destination airports as Strings
and returns the next available flight between the two cities based on a SQL query.
(Screen shot)
3. Select File|New
The Object Gallery appears. The Gallery contains various wizards to increase productivity.
(Screen shot)
4. Double-Click on the Enterprise JavaBeans icon.
The 'Welcome' page of the EJB Wizard appears. The EJB Wizard will generate the Enterprise
JavaBean and its home and remote interfaces. These are two of the four items that an EJB
developer must define for client applications to be able to invoke methods of the bean that contain
the business logic. Their characteristics are as follows:
∑ The Remote Interface
Since Enterprise JavaBeans can be invoked remotely, the first thing that a developer needs to do is
define the remote interface of the EJB. The remote interface lists all the methods or public interfaces
of the bean that clients can call. While the bean remote interface is defined as a standard Java RMI
(Remote Method Invocation) interface in the EJB specification, the actual communication is
independent of RMI. Oracle8i uses IIOP as the wire protocol for communication. The remote
interface definition is similar to the IDL definition of a CORBA object. The following is an example
of the definition of a remote interface for a bean:
// Bean Remote Interface extends javax.ejb.EJBObject
// All methods throw java.rmi.RemoteException
public interface Travel extends javax.ejb.EJBObject {
float getBalance () throws java.rmi.RemoteException;
void debit (float amount) throws java.rmi.RemoteException
}

18
∑ The Home Interface
Because beans can be invoked in a remote server, just using Java ‘new’ is not sufficient enough
to create objects in a remote server. Beans have to provide a mechanism for clients to be able to
create an instance of the bean. Conventionally, these interfaces are called object or bean
factories. The home interface serves as the factory interface of the EJB. A home interface
defines zero or more create(...) methods, one for each way to create an EJB object. Clients
invoke this factory interface to create instances of the bean. Developers only need to define the
factory interfaces, and not implement any methods of the factory interface. At deployment time,
the server-side implementation classes for the bean home interface, which are EJB server-
specific, are generated automatically. With Oracle8i, they are generated when the EJB is loaded
into the database through an automated facility
Oracle provides. The following is an example of the definition of a home interface for a bean:
// Bean Home Interface extends the javax.ejb.EJBHome interface
public interface TravelHome extends javax.ejb.EJBHome {
Travel create (String account) throws
java.rmi.RemoteException,
javax.ejb.CreateException;
}
5. Click on the Next button
Step 1 of 3 appears:
6. Enter the name of the EJB (including the package name) to be created in the
Enterprise Bean Class Name field : TravelLogicEJB.TravelEJB
7.
Enter the name of the class that the EJB will extend: TravelLogicEJB.FlightJDBC
8. Choose the Session Bean radio button
.
(Screen shot)
This dialog displays the name of the Home Interface for the EJB and the methods that are
employed in this interface. In this case we have the create() method which will be used to create
the EJB.
10.

19
Click on the Next button
(Screen shot)
This dialog displays the name of the Remote Interface for the EJB and the methods in the
interface. In this case, we have the Next() method which will be called to execute the business
logic that is contained in the EJB.
11. Click on the Next button. The 'Finish' pane appears.
(Screen shot)
12. If the 'Create a new Deployment Profile...' checkbox is currently selected, then deselect it and
click on the Finish button. Now the EJB file and the interfaces will be generated and added to the
project.
13. Select File|Save All or Click on the Save All button in the toolbar.
14. Expand the TravelLogicEJB Folder to show its contents:
The EJB Wizard automatically generates the EJB (TravelEJB.java), and its Home
(TravelEJBHome.java) and Remote (TravelEJBRemote.java) interfaces.
You have now completed the third of the four items that an EJB developer must define for client
applications to be able to invoke methods of the bean that contain the business logic. You have
defined the Bean itself. It's characteristics are as follows:
∑ The Enterprise Java Bean
The bean itself is a standard Java application that implements the business logic written by the
bean developer. The user does not need to describe the bean’s transactional and security
semantics in the application code. They can be described declaratively, using the bean’s
deployment descriptor. Since Oracle8i supports session beans, users need to explicitly persist the
state of their bean. Since the Oracle8i EJB server is tightly integrated with the Oracle RDBMS,
users manage the bean’s persistent state via JDBC or SQLJ. The following is an example of the
definition of a bean:
// The Bean Itself - This is the place where you implement all
your business logic.
public class TravelBean implements javax.ejb.SessionBean {
// Bean Interface methods
public float getBalance () {
// ADD YOUR IMPLEMENTATION HERE
…
}
public void debit (float amount) {
// ADD YOUR IMPLEMENTATION HERE
…
}
// Home Interface methods. These methods should have a 1:1
correspondence with the methods
// defined in the home interface. These methods are

20
implemented by the application developer.
public void ejbCreate (String account) {…}
}
15.
Now, to compile the java files. First, select the Project|Rebuild Project, or
click on the Rebuild icon:
The status bar at the bottom of the AppBrowser should read: 'Compiler: Successful, with no errors.'

21
Deploying EJBs to Oracle 8i using the EJB Deployment Profile Wizard
In this section, we are ready to deploy the EJB to Oracle 8i. Deployment is a two-step process:
1. Creation of the EJB Deployment Profile :
∑ In this step you specify the database connection information, and you archive the Java class
files which need to be deployed to the database.
2. Deployment of the EJB using the Deployment profile
Deploying the EJB
1. Select File|New
The Object Gallery appears
(Screen shot)
2. Click on the deployment tab. The following screen appears:
3. Double Click on the EJB Profile icon to invoke the EJB profile 'Welcome' pane of EJB Profile
Wizard appears
(Screen shot)
(Screen shot)
The EJB files are archived in a .jar file and are subsequently installed in Oracle 8i.
5. In the Archive Path text field , Replace 'Untitled1.jar' with 'TravelEJB.jar,' so that the complete
path now reads as
C:%YourJDeveloperInstall%myclassesTravelEJB.jar
6. With the default jar radio button selected for the delivery option, Click on the Next button
(Screen shot)
In this step it is necessary to indicate which are the core set of files that are required for
deployment to the database (By default , all the files in the package are picked up).
7. Double click on the TravelEJBRemote folder to display its contents. Then, click on the Next
button
(Screen shot)
This is the step where you can choose to deploy any other dependent classes.
(Screen shot)
In this step you can provide the security info and the database connect info, and select the EJB
definition file(.ejb) which was previously generated by the EJB wizard.

22
9. In the Username field , enter 'travel.' In the Password field , enter 'travel.' To supply the EJB
definition, click on the browse button and double-click on the file TravelEJBRemote.ejb, in the
file dialog box. This fills in the complete path for the .ejb file and also automatically selects a
descriptor file (.dd), which was generated by the EJB wizard.
(Screen shot)
You have now defined the last of the four items that are required for client applications to be able to
invoke methods of the bean that contain the business logic. It's characteristics are as follows:
∑ The Bean Deployment Descriptor
Once you have defined the above interfaces and classes, that’s all the code you need for your
beans. The bean deployment descriptor ties the various components of the bean together. The
deployment descriptor is a Java serialized object that extends the base deployment descriptor
class. It allows the user to specify the bean’s transactional and security attributes declaratively,
simplifying the process of building transactional applications with the database. The bean
attributes can be specified at the bean level, or the user can use method descriptors to specify finer
grained transaction and security at the method level of the bean. Oracle offers special syntax to
specify the deployment descriptor for beans. The EJB specification requires that the deployment
descriptor be stored as a serialized object. It is tedious to create a serialized instance of a
deployment descriptor, so our tools accept the deployment descriptor as text, and create the
serialized object automatically. The syntax of the textual form has been designed to look like a
Java class, and begins with a SessionBean statement. The statement is followed by the full
qualified class name of the Enterprise JavaBean. The descriptor is a list of bean attributes, which
have the general form:
<attribute-name> = <attribute-value>;
There are three types of bean attributes:
• Attributes of the Bean Itself – For example, its transaction and security attributes, JNDI name, and
the name of its remote and home interfaces. Some attributes are required (for a detailed list of
required attributes, see the Oracle documentation).
• Attributes of the Bean Methods – The transaction and security related attributes can also be
specified for individual methods of the bean. In the textual form, you identify the method
signature, using standard Java syntax, but you replace the method body with a set of method
attributes. The method qualifiers, such as public or static, the method return type, and the
method argument name are optional and ignored.
• Environment Properties For the Bean – You can also specify the Bean environment properties,
with an entry named EnvironmentProperties inside the bean descriptor. The parser builds
Property Object from the list, and makes it available as the EnvironmentProperties attribute of
the bean descriptor.
Here is an example of how you can create the deployment descriptor:
// Bean Deployment Descriptor for Travel Bean
SessionBean TravelBean {
BeanHomeName = "bn=myTravel"; // Required
Attribute
RemoteInterfaceClassName = Travel; // Required
Attribute

23
HomeInterfaceClassName = TravelHome; // Required
Attribute
AllowedIdentities = {PUBLIC};
SessionTimeout = 3000;
StateManagementType = STATELESS_SESSION;
TransactionAttribute = TX_MANDATORY;
IsolationLevel = TRANSACTION_READ_UNCOMMITTED;
public void getDestination ()
{
RunAsIdentity = CUSTOMER;
}
}
10. In the Hostname field , enter the HostName (or IP address) of your 8i database (e.g
mydatabase.us.oracle.com or 144.25.84.1 ). Click on the Next button. Now you are ready to
deploy the EJB to the database.
(Screen shot)
11. With the Deploy Now... checkbox selected , click on the Finish button. If you have already gone
through this process previously, then you might be prompted by an Overwrite? dialog. Enter
'Yes'. The 'Deployment' dialog will be visible now.
(Screen shot)
12. When deployment is finished , select File|Save All or click on the Save All button in the toolbar.
The deployment process accomplished several things:
1. It installed the EJB in the EJB Server (Oracle 8i)
2. It generated the Client side stubs that are required to remotely access the EJB
(TravelEJB_generated.jar in %jdeveloperInstall%/myclasses).The client side stubs will be used by
other applications as a proxy for the actual EJB in the server. Business Applications will talk
directly to the proxy classes and the proxy classes will handle the communication with the real
EJB in the Server.
3. It generated a profile file in the project (EJBProfile.prf)

24
Reusing the deployed EJB from a client application
After development and deployment of the EJB, it can now be used in the server from your client
application. The EJB component is now accessible to any client possessing the appropriate privileges.
To reuse your deployed EJB, employ the following steps:
1. Collapse TravelLogicEJB.jpr by clicking on the '-' node
2. Right-Mouse over TravelClientEJB.jpr and select Set As Active Project.
To include the the generated EJB jar file in the classpath of TravelClientEJB project:
3. Right Mouse over TravelClientEJB.jpr and select Properties... or Select Project|Project
Properties.
The TravelClientEJB.jpr Properties dialog appears.
(Screen shot)
4. Click on the Libraries button. The Available Java Libraries dialog appears.
5. Select TravelEJB in the listbox:
6.
Click on the Edit button. Then, lick on the '...' button next to the 'Class path' field:
7.
Click on the button:
This will open up a file dialog allowing you a view into the 'myclasses' directory.
8. Double Click on TravelEJB_generated.jar (this is the that was file generated during the
deployment process).
(Screen shot)
9.

25
Click on OK. Then click on File|Save All.
(Screen shot)
10.
Double Click on JFlightFrame.java to view it in the code editor. This file provides the visual
interface to our client application. The visual interface can be displayed in the Designer.
11. With the JFlightFrame.java file selected in the Navigation Pane, click on the Design tab at the
bottom of the AppBrowser.
(Screen shot)
12. The code triggered by double-clicking on the Next button executes the method, in order to
calculate the next available flight between the two cities. Double Click on the Next button in the
Designer and display the call to the 'Next' method of the EJB; this displays the lines:
TravelEJBRemote travel = home.create(); jResultField.setText(travel.Next(origin, dest));
The simple call: travel.Next(origin, dest), executes the business logic. This logic can be
simultaneously accessed by multiple clients.
(Screen shot)
13.
Run the application: To accomplish this, Right-Mouse over FlightApplication.java and select Run,
or click on the Run icon:
14.

26
Choose the 'Origin' and the 'Destination' and click on the Next Flight button.
The 'Next' method of the EJB is called and the results are displayed, as below:
TroubleShooting:
∑ Cannot View Images ? - Check ImageIcon path in line 44 and 45 of JFlightFrame.java in
TravelClientEJB.jpr
∑ Invalid URL Exception during runtime? - Check if you replaced <HostID> by the HostID of
your Oracle 8i database
∑ Cannot view the Project Navigator( pane on the left side)? - Select View|Project Navigator or
Alt-Z
∑ Cannot view Inspector ? - Select View|Inspector
∑ When you click on the Design tab, nothing happens (source code is still visible) : - Try two
things:
a) If the 'Inspector' window is overlapping the 'Design' window then close the Inspector
(Click on
the 'x' icon)
b)Click on the Source tab and click on the Design tab again
∑ If you want to alter the font size in the code editor- Right-Click anywhere in the Code Editor
and select properties; the 'Display' tab contains the font settings.
SUMMARY
Enterprise JavaBeans (EJBs) can be developed for and deployed to Oracle8i. Use JDeveloper to create
EJBs as new classes, or extensions of existing classes. Jdeveloper provides convenient code
generation features that simplify creating new EJBs from scratch and as extensions or transformations
of existing classes. This technology allows you to use the investment in application business logic
included in the original class.
Oracle8i is a container provider for EJBs that are produced by JDeveloper. EJBs deployed to Oracle8i
can become servers using the Oracle8I's container framework. For information on the container and
server architecture of EJBs deployed in Oracle8i, refer to the Oracle8i CORBA and Enterprise
JavaBeans Developer's Guide and Reference.

EJBW

More Related Content

What's hot

Viewers also liked

Similar to EJBW

EJBW