<?xml version="1.0" encoding="utf-8"?> | |
<!--Arbortext, Inc., 1988-2005, v.4002--> | |
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> | |
<concept id="cearch" xml:lang="en-us"> | |
<title>EJB architecture</title> | |
<shortdesc>This topic provides a high-level overview of the distributed component | |
architecture defined in the Sun Microsystems Enterprise <tm tmclass="special" | |
tmowner="Sun Microsystems, Inc." tmtype="tm" trademark="JavaBeans">JavaBeans</tm> (EJB) | |
architecture specification.</shortdesc> | |
<prolog><metadata> | |
<keywords><indexterm>EJBs<indexterm>architecture overview</indexterm></indexterm> | |
<indexterm>architecture<indexterm>EJBs</indexterm></indexterm></keywords> | |
</metadata></prolog> | |
<conbody> | |
<p>The complete Enterprise <tm tmclass="special" tmowner="Sun Microsystems, Inc." | |
tmtype="tm" trademark="JavaBeans">JavaBeans</tm> specifications and descriptions | |
of the technology are available from the <xref format="html" href="http://java.sun.com/products/ejb/docs.html#specs" | |
scope="external">java.sun.com<desc></desc></xref> Web site.</p> | |
<p>Enterprise beans provide several benefits for application developers: </p> | |
<ul> | |
<li>They allow you to build distributed applications by combining components | |
developed using tools from different vendors. </li> | |
<li>They make it easy to write applications. You do not have to deal with | |
low-level details of transaction and state management, multithreading, resource | |
pooling, and other complex low-level APIs. However, if necessary, expert programmers | |
can still gain direct access to the low-level APIs.</li> | |
<li>They can be developed once and then deployed on multiple platforms without | |
recompilation or source code modification. </li> | |
<li>The EJB specification that governs the use of enterprise beans is compatible | |
with other <tm tmclass="special" tmowner="Sun Microsystems, Inc." tmtype="tm" | |
trademark="Java">Java</tm> APIs and CORBA. It also provides for interoperability | |
between enterprise beans and non-Java applications.</li> | |
</ul> | |
<dl><dlentry> | |
<dt><b>Enterprise beans</b></dt> | |
<dd>An <i>enterprise bean</i> is a non-visual component of a distributed, | |
transaction-oriented enterprise application. Enterprise beans are typically | |
deployed in EJB containers and run on EJB servers. You can customize them | |
by changing their deployment descriptors and you can assemble them with other | |
beans to create new applications. There are three types of enterprise beans: <i>session | |
beans</i>, <i>entity beans</i>, and <i>message-driven</i> beans.<p><lq> <ul> | |
<li><b>Session beans</b>: <i>Session beans</i> are non-persistent enterprise | |
beans. They can be stateful or stateless. A <i>stateful session bean</i> acts | |
on behalf of a single client and maintains client-specific session information | |
(called conversational state) across multiple method calls and transactions. | |
It exists for the duration of a single client/server session. A <i>stateless | |
session bean</i>, by comparison, does not maintain any conversational state. | |
Stateless session beans are pooled by their container to handle multiple requests | |
from multiple clients.</li> | |
<li><b>Entity beans</b>: <i>Entity beans</i> are enterprise beans that contain | |
persistent data and that can be saved in various persistent data stores. Each | |
entity bean carries its own identity. Entity beans that manage their own persistence | |
are called <i>bean-managed persistence (BMP) entity beans</i>. Entity beans | |
that delegate their persistence to their EJB container are called <i>container-managed | |
persistence (CMP) entity beans</i>.</li> | |
<li><b>Message-driven beans</b>: <i>Message-driven beans</i> are enterprise | |
beans that receive and process JMS messages. Unlike session or entity beans, | |
message-driven beans have no interfaces. They can be accessed only through | |
messaging and they do not maintain any conversational state. Message-driven | |
beans allow asynchronous communication between the queue and the listener, | |
and provide separation between message processing and business logic.</li> | |
</ul></lq></p></dd> | |
</dlentry></dl> | |
<dl><dlentry> | |
<dt><b>Remote client view</b></dt> | |
<dd>The <i>remote client view</i> specification became available beginning | |
with EJB 1.1. The remote client view of an enterprise bean is location independent. | |
A client running in the same JVM as a bean instance uses the same API to access | |
the bean as a client running in a different JVM on the same or different machine.<ul> | |
<li><b>Remote interface</b>: The <i>remote interface</i> specifies the remote | |
business methods that a client can call on an enterprise bean.</li> | |
<li><b>Remote home interface</b>: The <i>remote home interface</i> specifies | |
the methods used by remote clients for locating, creating, and removing instances | |
of enterprise bean classes.</li> | |
</ul></dd> | |
</dlentry></dl> | |
<dl><dlentry> | |
<dt><b>Local client view</b></dt> | |
<dd>The <i>local client view</i> specification is available in EJB 2.0 or | |
later. Unlike the remote client view, the local client view of a bean is location | |
dependent. Local client view access to an enterprise bean requires both the | |
local client and the enterprise bean that provides the local client view to | |
be in the same JVM. The local client view therefore does not provide the location | |
transparency provided by the remote client view. Local interfaces and local | |
home interfaces provide support for lightweight access from enterprise bean | |
that are local clients. Session and entity beans can be tightly couple with | |
their clients, allowing access without the overhead typically associated with | |
remote method calls.<ul> | |
<li><b>Local interface</b>: The <i>local interface</i> is a lightweight version | |
of the remote interface, but for local clients. It includes business logic | |
methods that can be called by a local client.</li> | |
<li><b>Local home interface</b>: The <i>local home interface</i> specifies | |
the methods used by local clients for locating, creating, and removing instances | |
of enterprise bean classes.</li> | |
</ul></dd> | |
</dlentry><dlentry> | |
<dt><b>Web service client view</b></dt> | |
<dd>In the EJB 2.1 specification, the EJB architecture introduced the support | |
for Web services. A client for a session bean can be a Web service client. | |
A Web service client can make use of the Web service client view of a stateless | |
session bean, which has a corresponding service endpoint interface.<dl><dlentry> | |
<dt><b>Service endpoint interface</b></dt> | |
<dd>The <i>service endpoint interface</i> for a stateless session bean exposes | |
the functionality of the session bean as a Web service endpoint. The Web Service | |
Description Language (WSDL) document for a Web service describes the Web service | |
as a set of endpoints operating on messages. A WSDL document can include the | |
service endpoint interface of a stateless session bean as one of its endpoints. | |
An existing stateless session bean can be modified to include a Web service | |
client view, or a service endpoint interface can be mapped from an existing | |
WSDL to provide the correct interface.<p>A Web service client view is independent | |
of location and can be accessed through remote calls.</p></dd> | |
</dlentry></dl></dd> | |
</dlentry></dl> | |
<dl><dlentry> | |
<dt><b>EJB client JAR file</b></dt> | |
<dd>An EJB client JAR file is an optional JAR file that can contain the client | |
interfaces that a client program needs to use the client views of the enterprise | |
beans that are contained in the EJB JAR file. If you decide not to create | |
an EJB client JAR file for an EJB module, all of the client interface classes | |
will be in the EJB JAR file. By default, the workbench creates EJB client | |
JAR projects for each corresponding EJB project.</dd> | |
</dlentry></dl> | |
<dl><dlentry> | |
<dt><b>EJB container</b></dt> | |
<dd>An <i>EJB container</i> is a runtime environment that manages one or more | |
enterprise beans. The EJB container manages the life cycles of enterprise | |
bean objects, coordinates distributed transactions, and implements object | |
security. Generally, each EJB container is provided by an EJB server and contains | |
a set of enterprise beans that run on the server.</dd> | |
</dlentry><dlentry> | |
<dt><b>Deployment descriptor</b></dt> | |
<dd>A <i>deployment descriptor</i> is an XML file packaged with the enterprise | |
beans in an EJB JAR file or an EAR file. It contains metadata describing the | |
contents and structure of the enterprise beans, and runtime transaction and | |
security information for the EJB container.</dd> | |
</dlentry><dlentry> | |
<dt><b>EJB server</b></dt> | |
<dd>An <i>EJB server</i> is a high-level process or application that provides | |
a runtime environment to support the execution of server applications that | |
use enterprise beans. An EJB server provides a JNDI-accessible naming service, | |
manages and coordinates the allocation of resources to client applications, | |
provides access to system resources, and provides a transaction service. An | |
EJB server could be provided by, for example, a database or application server.</dd> | |
</dlentry></dl> | |
</conbody> | |
</concept> | |
<?Pub *0000008938?> |