发信人: bali (阿奔), 信区: Java
标 题: EJB Faq
发信站: 哈工大紫丁香 (Fri Sep 22 14:39:47 2000) , 转信
GENERAL FAQ
What is Enterprise JavaBeansTM (EJBTM) Technology?
EJB, the widely-adopted server-side component architecture for JavaTM 2 Platfo
rm, Enterprise Edition (J2EETM), enables rapid development of mission-critical
application that are versatile, reusable and portable across middleware while
protecting IT investment and preventing vendor lock-in.
What is EJB technology's role in J2EE?
EJB technology is the core of J2EE. It enables developers to write reusable po
rtable server-side business logic for the J2EE platform.
Is EJB a product?
No, EJB is a specification, which defines the EJB component architecture and t
he interfaces between the Enterprise JavaBeans technology-enabled server and t
he component. Vendors like BEA, Sun, Oracle and IBM are providing commercial p
roducts that implement the EJB specification.
Are there commercial implementations of EJB technology?
Over 30 vendors are shipping server products implementing the EJB specificatio
n. Some of the key vendors providing implementations are: IBM, Sun/Netscape Al
liance, BEA, Oracle, Inprise, Iona, Fujitsu, Sybase, Gemstone, Persistence and
others.Read more.
Who owns the EJB specification?
The EJB specification is an industry initiative led and driven by Sun with par
ticipation from many key vendors in the industry. Sun owns the interactive and
iterative process of defining, creating and publishing the specification whil
e ensuring on-going incorporation of input and feedback from the industry and
the general public.
EJB 2.0, the version of the spec currently under development is being created
through the Java Community Process (JCP).
What are the key features of the EJB technology?
EJB components are server-side components written entirely in the Java program
ming language
EJB components contain business logic only - no System-level programming
System-level services (i.e. "plumbing") such as transactions, security, Life-c
ycle, threading, persistence, etc. are automatically managed for the EJB compo
nent by the EJB server
EJB architecture is inherently transactional, distributed, portable, multi-tie
r, scalable and secure
Components are declaratively customized. (Can customize: transactional behavio
r, security features, life-cycle, state management, persistence, etc.)
EJB components are fully portable across any EJB server and any OS
What are the key benefits of the EJB technology?
Rapid application development: The productivity benefits of writing components
in the Java programming language - Java technology productivity and component
reuse and outsourcing; Developer focuses on business logic only; Declarative
customization (not programmatic)
Broad industry adoption: Industry-wide collaboration on the spec yielded a sup
erior architecture and ensured adoption; Choice and flexibility in server sele
ction - no vendor lock-in; 3rd party components are widely usable across serve
rs - ISVs don't need to choose vendor-specific development platform
Application portability: Business logic that runs everywhere - Platform-indepe
ndence and middleware independence
Choice, not vendor lock-in: Architecture decisions are made at deployment, not
at development; Inter-server portability - code can be deployed on any EJB se
rver; Inter-server scalability - Servers can be transparently replaced to acco
mmodate changing needs for service level, performance or security; Any wire pr
otocol can be selected at deployment
Protection of IT investment: Wrap and embrace existing infrastructure, applica
tion and data stores; Existing middleware solutions are being adapted by the w
ell-established vendors to support the EJB technology via a thin portability l
ayer; Portable across multiple servers and databases; Serve multi-lingual clie
nts - Browsers, Java technology, ActiveX, or CORBA clients; EJB technology sim
plifies and enhances CORBA and DCOM.
How much does EJB sell for?
EJB technology is not a commercial product - It is a specification created and
published by Sun and freely available on Sun's web site.
What version of the EJB specification is currently available?
Final Release of version 1.1 of the specification was made available in Decemb
er 1999 as part of the first J2EE Final Release. During JavaOne 2000, Sun is r
eleasing the Public Draft of the EJB 2.0 specification which is being develope
d through the Java Community (JCP) process. This is the first time the EJB 2.0
specification is made available for public review.
What platforms does EJB technology run on?
Applications that are based on EJB components are not only platform independen
t but also middleware independent! They can run on any OS and any middleware t
hat support EJB.
Who is EJB technology for?
EJB technology benefits a number of audiences:
Enterprise customers that build and/or deploy EJB-based applications - gain de
velopment productivity, can choose from a wide selection of EJB servers, creat
e business logic that runs everywhere and is architecture independent, all thi
s while protecting their existing IT investment!
ISVs and SIs that develop EJB components or applications based on EJB componen
ts - Invest in business logic that is widely deployable, across any OS and mid
dleware, don't need to choose one vendor-specific server platform. Like enterp
rise customers they also benefit from productivity gains and architecture inde
pendence
The EJB specification itself is mostly targeted at the EJB server vendors - It
is the blueprint that instructs these vendors on how to build an EJB server t
hat EJB components can execute on successfully
Who is using EJB technology?
The adoption and momentum around EJB technology since its first public release
in 3/98 has been phenomenal. Vendors across the board, from the smallest star
t-up to the largest corporation, are adopting this technology and building EJB
servers, EJB tools and EJB components and applications. There are over 50 com
mercial products supporting the EJB technology. We are also seeing strong inte
rest and adoption among many enterprise customers such as: GTE, Instinet (Reut
ers), Qwest, Charles Schwab, NationsBank Montegomery, Celera Genomics, Ingram
Micro, Kaiser Permanente, Sprint, and many others.
Read more.
What tools are supporting EJB technology?
All leading tool vendors are incorporating support for EJB in their existing t
ools. There are also new tool vendors emerging with tools dedicated to EJB sup
port. Examples of supporting vendors include: Inprise, IBM, Oracle, Sun, Ratio
nal, Inline, Tendril and many others.
Read more.
What about all the existing investment in IT? Doesn't EJB technology require e
nterprise customers to replace their existing systems?
Absolutely not. EJB technology was designed with existing systems in mind. The
EJB architecture was designed to be layered on top of existing IT systems. Gi
ven the widespread industry adoption the vast majority of IT systems software
is being EJB technology enabled
Are there enterprise customers using EJB technology today?
Today we know of many large enterprise customers across the world that are imp
lementing EJB-based projects. Some examples are: GTE, Instinet (Reuters), Qwes
t, Charles Schwab, NationsBank Montegomery, Celera Genomics, Ingram Micro, Kai
ser Permanente, Sprint, Electric Boat, and many others.
Read more.
Are there commercial implementations of EJB technology?
Over 30 vendors are providing commerical implementation of the EJB technology
in their products.
What products that support EJB technology are available today?
There are over 40 EJB servers and tools commercially available today from vend
ors such as BEA, Sun/Netscape Alliance, Oracle, IBM Gemstone, Iona, Fujitsu, P
ersistence, Bluestone, Inprise, Sybase and others.
Read more.
Is EJB technology really going to fulfill the promise of true portability acro
ss middleware solutions?
Yes. EJB technology hides the details of the underlying middleware "plumbing",
allowing developers to focus on writing "pure" business logic which does not
contain server-specific code. The code can execute on top of any server implem
enting the EJB specification. Sun is providing a J2EE compliance program to gu
arantee portability across servers.
What compliance programs will Sun be providing?
Sun is providing a Compatibility Test Suite for products implementing the J2EE
Platform which includes testing for EJB implementation.
Read more.
Will there be a cost associated with Sun's compliance programs?
Yes.
Is Sun developing a reference implementation for EJB technology?
Yes, Sun is providing an EJB reference implementation as part of the J2EE refe
rence implementation
Read more.
What is the roadmap for EJB technology?
EJB 1.1 specification Final Release was provided in December 1999 as part of t
he first J2EE platform Final Release. During JavaOne 2000, Sun is releasing th
e Public Draft of the EJB 2.0 specification which is being developed through t
he JCP process. This is the first time the EJB 2.0 specification is made avail
able for public review. After the public review phase for the Public Draft is
complete, Sun is expecting to release the Final Draft of the EJB 2.0 specifica
tion in the fall of 2000. The Final Release of EJB 2.0 will be made available
as part of the J2EE 1.3 Final Release. The date is to be determined, largely b
ased on feedback from the marketplace.
What are the key enhancements included in EJB 1.1?
Mandatory support for entity beans which will improve the way EJB-based applic
ations connect to back-end data sources such as relational databases and great
ly simplify the process of application development by providing developers wit
h a higher level of abstraction.
Enhancements to the Deployment Descriptor, including support for XML text form
at and improved content organization, both of which will ease development and
deployment of EJB-based applications
Significant tightening of the specification which will greatly improve EJB-bas
ed application portability
Read more.
What are the key enhancements in EJB 2.0?
EJB 2.0 is currently in the Public Draft phase of the JCP specification develo
pment process. key enhancements are in the following areas:
JMS (Java Message Service) integration
Improved support for container-managed persistence (CMP)
Support for RMI/IIOP protocol for network interoperability
Management of beans relationships
Standard query language support
Doesn't EJB technology compete with CORBA?
No. In fact, EJB technology complements CORBA quite nicely. CORBA provides a g
reat Standards-based infrastructure on which to build EJB servers. EJB technol
ogy makes it easier to build application on top of a CORBA infrastructure. Add
itionally, the recently released CORBA components specification refers to EJB
as the architecture when building CORBA components in Java.
What about RMI/IIOP? Is that part of EJB specification?
The EJB specification mandates that you must use the RMI interfaces to communi
cate with an EJB component. The EJB 1.1 specification did not mandate which wi
re protocol to use. However, EJB 2.0 requires EJB implementations to Support
RMI/IIOP.
How does EJB compare with MTS (Microsoft Transaction Server) and Microsoft COM
+?
EJB is a widely endorsed and supported architecture. COM+ is a proprietary arc
hitecture. MTS is a proprietary product. EJB allows for choice. MTS and COM+ a
llow only one choice, Microsoft's.
Read more.
Why should people want to use products based on EJB technology when they can g
et MTS for free with Windows NT?
Because EJB technology eliminates platform lock, allows a user to move their a
pplication to any EJB server, eliminates dependencies on hardware, OS and midd
leware.
Read more.
TECHNICAL FAQ
GENERAL QUESTIONS
What are the design goals of the Enterprise JavaBeansTM architecture?
The Enterprise JavaBeans specification defines a standard architecture for imp
lementing the business logic of multi-tier applications as reusable components
. In addition to Enterprise JavaBeans components, the architecture defines thr
ee other entities: servers, containers, and clients. This architecture incorpo
rates several design goals:
Enterprise JavaBeans servers are designed to wrap around legacy systems to pro
vide fundamental services for containers and the components they contain.
Enterprise JavaBeans containers are designed to handle details of component li
fe-cycle, transaction, and security management. By interceding between clients
and components at the method call level, containers can manage transactions t
hat propagate across calls and components, and even across containers running
on different servers and different machines. This mechanism simplifies develop
ment of both component and clients.
Component developers are free to focus on business logic, since containers pro
vide services automatically by interceding in component method calls. A simple
set of callback interfaces are all that a developer needs to implement to par
ticipate in container provided services.
A client's view of an Enterprise JavaBean remains the same regardless of the c
ontainer it is deployed in. Any container in which an Enterprise JavaBean is d
eployed presents the same interfaces to the client. This extends to containers
from different vendors, running against different servers and different datab
ases, on diverse systems on a network. This client transparency ensures wide s
calability for multi-tier applications.
Along with container managed transactions, the Enterprise JavaBeans architectu
re enables component- and client-managed transactions. Containers can particip
ate in component or client initiated transactions to enforce transaction rules
across method call and component boundaries. Components can also specify tran
saction types by method, enabling them to mix transaction types within a singl
e object.
A variety of Enterprise JavaBean attributes, including the default component t
ransaction type, can be specified at either development or deployment time, an
d enforced through mechanisms built into the container architecture.
The Enterprise JavaBeans architecture is based on the Java programming languag
e, so enterprise Beans take full advantage of the "write once, run anywhereTM"
standard.
What's the client view of an Enterprise JavaBeans component?
The client view is provided through two interfaces -- the home interface and t
he remote interface. These interfaces are provided by classes constructed by t
he container when a bean is deployed, based on information provided by the bea
n. The home interface provides methods for creating a bean instance, while the
remote interface provides the business logic methods for the component. By im
plementing these interfaces, the container can intercede in client operations
on a bean, and offers the client a simplified view of the component.
Why doesn't the client interact with an Enterprise JavaBean directly?
To the client, there appears to be direct interaction with an Enterprise Java
Bean through the home and remote interfaces. However, Enterprise JavaBeans arc
hitecture is designed to enable clients and components to exist in different r
untimes on different systems on a network. The container intercedes between cl
ient and component, completely concealing both the bean instance and its own a
ctions from the clients.
What methods are developers required to implement the Enterprise JavaBeans arc
hitecture?
There are three categories of Enterprise JavaBeans methods. First, the bean im
plements methods corresponding to those in its home interface -- methods large
ly for creating, locating and accessing instances of the bean. Second, a bean
implements business logic methods corresponding to those provided by its remot
e interface. Finally, a bean implements methods for interacting with the conta
iner. Since these methods aren't intended for client access, they are hidden b
y the container.
What are the basic types of Enterprise JavaBeans?
There are two types of enterprise beans -- session beans and entity beans -- r
epresenting different types of business logic abstractions.
Session beans represent behaviors associated with client sessions -- they're g
enerally implemented to perform a sequence of tasks within the context of a tr
ansaction. A session bean is a logical extension of the client program, runnin
g processes on the client's behalf remotely on the server.
Entity beans represent specific data or collections of data, such as a row in
a relational database. Entity bean methods provide operations for acting on th
e data represented by the bean. An entity bean is persistent; it survives as l
ong as its data remains in the database.
How does a client find and connect to a specific enterprise bean?
A client accesses an Enterprise JavaBean by looking up the class implementing
its home interface by name through JNDI. It then uses methods of the home inte
rface to acquire access to an instance of the class implementing the remote in
terface.
Context initialContext = new InitialContext() AccountHome accountHome = javax.
rmi.PortableRemoteObject.narrow( initialContext.lookup("applications/ban
k/accounts"), AccountHome.class);
In addition to generating classes to implement both the home and remote interf
ace, the container is responsible for binding the home class to a JNDI name. T
his is generally handled automatically by the container tools at deployment ti
me, without any user intervention required.
What general services does a container provide for an Enterprise JavaBean comp
onent?
A container provides Enterprise Java Beans components with services of several
types. First, it provides services for lifecycle management and instance pool
ing, including creation, activation, passivation, and destruction. Second it i
ntercedes between client calls on the remote interface and the corresponding m
ethods in a bean to enforce transaction and security constraints. It can provi
de notification at the start and end of each transaction involving a bean inst
ance. Finally, it enforces policies and restrictions on bean instances, such a
s reentrance rules, security policies, and others.
SESSION BEANS
What classes and interfaces does a session bean developer define?
The session bean developer defines the home and remote interfaces that represe
nt the client view of the bean. Developers also create a class that implements
both the SessionBean and SessionSynchronization interfaces, as well as method
s corresponding to those in the bean's home and remote interfaces.
What specific services does a container provide for a session bean?
The tools for a container generate additional classes for a session bean at de
ployment time. These tools get information from the Enterprise JavaBeans archi
tecture at deployment time by introspecting its classes and interfaces. They u
se this information to dynamically generate two classes, implementing the home
and remote interfaces of the bean. These classes enable the container to inte
rcede in all client calls on the session bean. The container also generates a
serializable Handle class, providing a way to identify a session bean instance
within a specific life cycle. These classes can be implemented to mix in cont
ainer-specific code for performing customized operations and functionality.
In addition to these custom classes, each container provides a class to provid
e meta data to the client and implements the SessionContext interface to provi
de access to information about the environment in which a bean is invoked.
What's the distinction between a stateless and stateful session bean?
Stateless beans are beans that don't maintain state across method calls. They'
re generally intended to perform individual operations atomically. They're als
o amorphous, in that any instance of a stateless bean can be used by any clien
t at any time, at the container's discretion. They are the lightest weight and
easiest to manage of the various Enterprise JavaBeans component configuration
s.
Stateful session beans maintain state within and between transactions. Each st
ateful session bean is associated with a specific client. Containers can autom
atically save and retrieve a bean's state in the process of managing instance
pools of stateful session beans.
How do stateful session beans maintain consistency across transaction updates?
Stateful session beans maintain data consistency by updating their fields each
time a transaction is committed. To keep informed of changes in transaction s
tatus, a stateful session bean implements the SessionSynchronization interface
. The container then calls methods of this interface as it initiates and compl
etes transactions involving the bean.
Can't stateful session beans be persistent?
Session beans aren't designed to be persistent, whether stateful or stateless.
The data maintained by a stateful session bean is intended to be transitional
, solely for the purposes of a particular session with a particular client. A
stateful session bean instance typically can't survive system failures and oth
er destructuve events. While a session bean has a container-provided identity
(called its handle), that identity passes when the session bean is removed by
the client at the end of a session. If a client needs to revive a stateful ses
sion bean that has disappeared, it must provide its own means to reconstruct t
he bean's state.
ENTITY BEANS
What classes and interfaces does an entity bean developer provide?
The entity bean developer defines the home and remote interfaces that represen
t the client view of the bean. Developers also create a class that implements
the EntityBean interface, as well as methods corresponding to those in the bea
n's home and remote interfaces.
In addition to defining create methods in the EJBHome interface, the entity be
an developer must also implement finder methods.
What's a finder method?
A finder method provides a way to access an entity bean by its contents. Finde
r methods are designed to be introspected and displayed by development and dep
loyment tools. This enables a user to graphically manipulate entity beans in t
he process of developing applications.
The principal finder method that must be implemented by all entity beans is fi
ndByPrimaryKey. In addition to this method, the developer must also implement
a PrimaryKey class to provide each entity bean with a unique, serializable ide
ntity.
What specific services does a container provide for an entity bean?
As with session beans, the tools for a container generate additional classes f
or an entity bean at deployment time to implement the home and remote interfac
es. These classes enable the container to intercede in all client calls on the
same entity bean. The container also generates the serializable Handle class,
providing a way to identify the entity bean within a specific life cycle. The
se classes can be implemented to mix in container-specific code for performing
customized operations and functionality. In addition to these custom classes,
each container provides a class to provide metadata to the client. Finally, w
here specified by a particular bean, a container manages persistence of select
ed fields of the entity bean.
What's the difference between container-managed and bean-managed persistence?
In container-managed persistence, entity bean data is automatically maintained
by the container using a mechanism of its choosing. For example, a container
implemented on top of an RDBMS may manage persistence by storing each bean's d
ata as a row in a table. Or, the container may use Java programming language s
erialization for persistence. When a bean chooses to have its persistence cont
ainer managed, it specifies which of its fields are to be retained.
In bean-managed persistence, the bean is entirely responsible for storing and
retrieving its instance data. The EntityBean interface provides methods for th
e container to notify an instance when it needs to store or retrieve its data.
How is an entity bean created?
An entity bean can be created in two ways: by direct action of the client in w
hich a create method is called on the bean's home interface, or by some other
action that adds data to the database that the bean type represents. In fact,
in an environment with legacy data, entity objects may "exist" before an Enter
prise JavaBean is even deployed.
How does the client get a reference to an existing entity bean?
A client can get a reference to an existing entity bean in several ways:
receiving the bean as a parameter in a method call
looking the bean up through a finder method of the home interface
obtaining the bean as a handle, a runtime specific identifier generated for a
bean automatically by the container
How do you determine whether two entity beans are the same?
By invoking the EntityBean.isIdentical method. This method should be implement
ed by the entity bean developer to determine when two references are to the sa
me object. Note that the equals and hashCode methods of Object are undefined f
or entity beans, since clients don't directly access bean instances within a c
ontainer.
How does a container manage access from multiple transactions on an entity bea
n?
Containers manage multiple transactions in one of two ways. First, the contain
er can instantiate multiple instances of the bean and let the transaction mana
gement of the DBMS handle transaction processing issues. Or, the container can
acquire an exclusive lock on the instance's state in the database, and serial
ize access from multiple transactions to this instance.
How do enterprise beans handle concurrent and loopback calls on entity beans?
Concurrent calls in the same transaction context on the same Enterprise JavaBe
an component are illegal and may lead to unpredictable results. A bean can be
marked as non-reentrant by its deployment descriptor. This allows the containe
r to detect and prevent illegal concurrent calls from clients. On the other ha
nd, some entity beans may require loopback calls: that is, calls where bean A
is invoked, in turn invoking bean B, which then invokes a method call on bean
A. This kind of concurrency is tricky and is best avoided.
TRANSACTION SUPPORT
What are the transaction management benefits of the Enterprise JavaBeans archi
tecture?
The Enterprise JavaBeans architecture provides automatic support for distribut
ed transactions in component based applications. Such distributed transactions
can atomically update data in multiple databases, possibly even distributed a
cross multiple sites. The Enterprise JavaBeans model shifts the complexities o
f managing these transactions from the application developer to the container
provider.
Does Enterprise JavaBeans allow alternatives to container-managed transactions
?
In addition to container-managed transactions, an Enterprise JavaBean can part
icipate in client-managed and bean-managed transactions.
What transaction attributes do Enterprise JavaBean containers support?
A container supports the following values for the transaction attribute of an
Enterprise JavaBean.
Not Supported
The bean runs outside the context of a transaction. Existing transactions are
suspended for the duration of method calls.
Required
Method calls require a transaction context. If one exists, it will be used; if
none exists, one will be created.
Supports
Method calls use the current transaction context if one exists, but don't crea
te one if none exists.
Requires New
Containers create new transactions before each method call on the bean, and co
mmit transactions before returning.
Mandatory
Method calls require a transaction context. If none exists, an exception is th
rown.
Never
Method calls require that no transaction context be present. If one exists, an
exception is thrown.
How do bean-managed transactions work?
When a bean with bean managed transactions is invoked, the container suspends
any current transaction in the client's context. In its method implementation,
the bean initiates the transaction through the JTA UserTransaction interface.
In stateful beans, the container associates the bean instance with the same t
ransaction context across subsequent method calls until the bean explicitly co
mpletes the transaction. However, stateless beans aren't allowed to maintain t
ransaction context across method calls. Each method invocation must complete a
ny transaction it initiates.
ENTERPRISE JAVABEANS AND OTHER TECHNOLOGIES
What's the relationship between Enterprise JavaBeans component architecture an
d CORBA?
The Enterprise JavaBeans specification is intended to support compliance with
the range of CORBA standards, current and proposed.
A Bean's remote and home interfaces are RMI compliant, and thus can interact w
ith CORBA objects via RMI/IIOP, Sun and IBM's forthcoming adaptation of RMI th
at conforms with the CORBA-standard IIOP protocol.
As a companion to the Enterprise JavaBeans specification, Sun Microsystems has
defined a standard mapping from Enterprise Java Beans API to CORBA IDL.
JTA, the transaction API prescribed by the Enterprise JavaBeans specification
for bean-managed transactions, is designed to layer easily over the OMG OTS tr
ansaction standard.
What's the relationship between Enterprise JavaBeans component architecture an
d XML technology?
The two technologies are complementary: Enterprise JavaBeans defines a standar
d for portable business logic and XML technology defines a standard for portab
le data.
What's the relationship between the Enterprise JavaBeans architecture and JTA?
The Enterprise JavaBeans architecture is intended to conceal transactional com
plexities from the component developer. Thus, developers and deployers writing
to Enterprise JavaBeans architecture don't need to access transaction managem
ent programmatically. However, in the case of bean- or client-managed transact
ions, the developer can call methods of JTA to initiate and complete transacti
ons. JTA defines the Java programming language interfaces related to transacti
on management on the Java platform, conformant with the OMG/OTS standard.
The JTA UserTransaction interface is intended to be provided by containers to
enable both bean-managed and client-managed transactions.
What's the relationship between Enterprise JavaBeans and JDBC/SQLJ?
An entity bean can implement data persistence in one of two ways: bean-managed
or container-managed. In the case of bean-managed persistence, the implemento
r of an entity bean stores and retrieves the information managed by the bean b
y means of direct database calls. For these, the bean can use either JDBC or S
QLJ. The one tradeoff of this approach is that it makes it harder to adapt bea
n managed persistence to alternate data sources.
In the case of container-managed persistence, the container provider may imple
ment access to the database using these APIs. The container provider can offer
tools to map instance variable of an entity bean to calls to an underlying da
tabase. This approach makes it easier to use Beans with different databases.
Session beans also typically access the data they manage using JDBC or JSQL.
NEW FEATURES IN THE ENTERPRISE JAVABEANS 2.0 SPECIFICATION
How does the Enterprise JavaBeans 2.0 Specification support messaging?
The EJB 2.0 Specification defines JMS support through a new type of enterprise
bean, the message-driven bean. A message-driven bean is invoked by the EJB co
ntainer as the result of the arrival of a JMS message. To a client, the messag
e-driven bean is a JMS consumer that implements some business logic on the ser
ver. Clients communicate with message-driven beans by sending messages to a JM
S Destination (either a Queue or a Topic) for which the message-driven bean is
a MessageListener.
Message driven beans are distinct from both Entity and Session beans. They hav
e neither home nor remote interfaces. Instead, they implement the javax.jms.Me
ssageListener interface.
What new features are provided to support container-managed persistence for En
tity beans?
The EJB 2.0 Specification defines a new mechanism for modeling persistent data
with Entity beans, and a new query language for Entity beans.
Features to support persistent data models include new abstract classes for bo
th Entity beans and dependent objects. These classes can be implemented to def
ine complex models for persistent data. EJB 2.0 also defines new deployment de
scriptor elements to define the^Mabstract schema supported by a bean. These al
low the bean developer to specify the data model at development time, then all
ow a container's deployment tools to automatically^Mgenerate the appropriate h
elper classes at deployment time. This provides additional platform-independen
ce while supporting a richer representation of the data underlying an Entity b
ean.
In addition, EJB 2.0 defines the EJB QL, a query language that enables develop
ers^Mto traverse the data model of Entity beans independently of the language
used^Mby the underlying database. ^MEJB QL uses the abstract schema of entity
beans, their dependent objects, and the^Mrelationships between these objects f
or its data model. The syntax of EJB QL is similar to that of SQL.
EJB QL enables Bean Providers to write two types of query methods:
Finder methods in the home interface to enable entity bean clients to select s
pecific entity objects.
Select methods which allow a bean internal access to related data without expo
sing^Mthat data directly to the client.
How does EJB 2.0 improve support for interoperability between EJB containers a
nd other J2EE products?
The EJB 2.0 public draft specification includes requirements on EJB container/
server providers which enable interoperability for invocations on enterprise b
eans. These requirements enable communication with J2EE clients including Java
Server Pages, Servlets, Application Clients as well as with enterprise beans i
n other EJB containers. The goal of these features is to allow enterprise bean
invocations to work even when client components and enterprise beans are depl
oyed in J2EE products from different vendors. Support for interoperability bet
ween components includes transaction propagation, naming services and security
services.
The interoperability mechanisms in EJB 2.0 are based on the IIOP protocol from
the Object Management Group. The extensions supporting distributed transactio
n propagation, security (using SSL) and naming service access are all based on
OMG standards. J2EE container products may also use vendor-specific protocols
in addition to IIOP.
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)
附件:
(0 字节)