Red Hat Application Server, Руководство пользователя

Страница: 13 / 296

Chapter 1. Java Open Application Server (JOnAS): a J2EE Platform 5
1.3.1. Communication and Naming Service
The Communication and Naming Service (also called Registry ) is used for launching the RMI reg-
istry, the CosNaming, and/or the CMI registry, depending on the JOnAS configuration (that is, the
CAROL configuration, which specifies which communication protocols are to be used). There are
different registry launching modes, such as using the same JVM or not, and launching automatically
if not already running. CAROL enables multi-protocol runtime support and deployment, which avoids
having to redeploy components when changing the communication protocol.
The Communication and Naming Service provides the JNDI (Java Naming and Directory Interface)
API to application components and to other services in order to bind and look up remote objects
(for example, EJB Homes) and resource references (JDBC DataSource, Mail, and JMS connection
factories, etc.).
1.3.2. EJB Container Service
The EJB Container Service is in charge of loading the EJB components and their containers. EJB
containers consist of a set of Java classes that implement the EJB specification and a set of interposi-
tion classes that interface the EJB components with the services provided by the JOnAS application
server. Interposition classes are specific to each EJB component and are generated by the deployment
tool called GenIC.
JOnAS configuration provides a means for specifying that this service be launched during JOnAS
initialization.
Enterprise JavaBeans (EJB) are software components that implement the business logic of an appli-
cation (while the servlets and JSPs implement the presentation). There are three types of Enterprise
JavaBeans:
•
Session beans are objects associated with only one client; they are short-lived (one method call or a
client session) and represent the current state of the client session. They can be transaction-aware,
stateful, or stateless.
•
Entity beans are objects that represent data in a database. They can be shared by several clients
and are identified by means of a primary key. The EJB container is responsible for managing the
persistence of such objects. The persistence management of such an object is entirely transparent
to the client that will use it, and may or may not be transparent to the bean provider who develops
it. This depends on if it is one of the following:
•
For an Enterprise Bean with Container-Managed Persistence, the bean provider does not de-
velop any data access code; persistence management is delegated to the container. The mapping
between the bean and the persistent storage is provided in the deployment descriptor, in an ap-
plication server-specific way.
•
For an Enterprise Bean with Bean-Managed Persistence, the bean provider writes the database
access operations in the methods of the Enterprise Bean that are specified for data creation, load,
store, retrieval, and remove operations.
•
Message-driven Beans are objects that can be considered as message listeners. They execute
on receipt of a JMS Java Message Service message; they are transaction-aware and
stateless. They implement some type of asynchronous EJB method invocation. (Refer to
http://java.sun.com/products/jms/.)
JOnAS configuration provides a means for specifying a set of EJB-JAR files to be loaded. EJB-JAR
files can also be deployed at server runtime using the JOnAS administration tools.
For implementing Container-Managed Persistence of EJB 2.0 and EJB 2.1 (CMP2), JOnAS relies
on the ObjectWeb JORM (Java Object Repository Mapping http://jorm.objectweb.org/) and MEDOR
(Middleware Enabling Distributed Object Requests http://medor.objectweb.org/) frameworks. JORM