Java 版 (精华区)
发信人: bali (阿奔), 信区: Java
标 题: JavaBeans and Enterprise JavaBeans: What's the difference?
发信站: 哈工大紫丁香 (Thu Sep 21 18:08:36 2000) , 转信
JavaBeans and Enterprise JavaBeans: What's the difference?
Mike Day
IBM Object Middleware Marketing Team
July 1999
Executable components
An ActiveX object
Benefits
EJBs and IBM WebSphere Enterprise Edition
An example
Summary
About the author
Editor's Note: The following article is based on a roundtable discussion. Part
icipants included Ken Burgett from the IBM Component Broker beta support team,
and Liane Acker, Jim Knutson and David Morrill from the IBM Enterprise Java B
eans department.
You're probably already using JavaBeans today and don't know it. There are no
restrictions to having JavaBeans on your desktop if you have a Java-enabled br
owser. The Web pages you use may have beans as part of an applet. Soon, you wi
ll interact with JavaBeans as the visual portion of a browser, then those Java
Beans will interface to an EJB on the server. This capability also extends to
both the Internet and intranets.
A JavaBean and Server Bean, more commonly known as an Enterprise JavaBean (EJB
), have some basic similarities. They are objects or components created with a
set of characteristics to do their own specific job. They also have the abili
ty to take on other characteristics from the container on the server in which
they currently reside. This enables a bean to behave differently, depending on
the specific job and environment where it is placed.
This opens up a tremendous business possibility. Because JavaBeans are platfor
m-independent, solution providers in the future will be able to readily market
their client-side JavaBeans to a wide audience without having to create or ma
intain different versions. These JavaBeans can be paired with EJBs performing
business functions such as ordering, credit-card processing, electronic transf
ers, inventory allocation, shipping, and so on. There is great potential here,
and it is the kind of potential Component Broker (part of WebSphere Applicati
on Server, Enterprise Edition) is designed to deliver.
A JavaBean is a component that has interfaces in it or properties associated w
ith it so it can be interrogated by and integrated with other beans developed
by different people at different times. You can build a bean and tie it togeth
er later with other beans at construction time. This process provides a way to
build something and use it again later; that's the notion of a component. Thi
s single application can be deployed as a stand-alone program, as an ActiveX c
omponent, or within a browser.
A JavaBean is different from a pure object because of its external interface,
the properties interface. This interface allows a tool to read what the compon
ent is supposed to do, hook it up to other beans, and plug it into another env
ironment. JavaBeans are intended to be local to a single process, and they are
often visible at runtime. This visual component may be a button, list box, gr
aphic or chart—but it is not required.
Executable components
Server beans or EJBs are executable components or business objects deployed on
the server. They have a protocol that allows them to be accessed remotely and
installed or deployed on a particular server. They have a set of mechanisms t
hat allow them to delegate major factors of service—security, transactional b
ehavior, concurrency (the ability to be accessed by more than one client at a
time) and persistence (how their state can be saved)—to the container in whic
h they are placed on the EJB server. They get their behavior when installed in
a container, which provides the different qualities of service, so selecting
the right EJB server is critical. This is where IBM WebSphere Enterprise Editi
on excels.
An EJB is a nonvisual, remote object designed to run on a server and be invoke
d by clients. An EJB can be built out of multiple, nonvisual JavaBeans. They h
ave a deployment descriptor that is intended for the same purpose as JavaBean
properties: It's a description of the bean that can be read later by a tool. E
JBs also are platform independent; once a bean is written, it can be used on a
ny platform that supports Java—clients and servers, too.
Because they are generated by a toolset such as IBM VisualAge for Java, EJBs a
re server-based objects and are intended to be called remotely. They are insta
lled on the EJB server and get a remote interface to call just as other CORBA
remote objects are called.
An ActiveX object
A JavaBean can be deployed as an ActiveX object, but while a proxy to an EJB c
an do this, an EJB itself cannot be an ActiveX object, as ActiveX runs on the
desktop. To do this on a platform-dependent, Windows-only platform, a develope
r could have the JavaBean rendered as an ActiveX component.
Benefits
The major benefit of an EJB is that the bean developer can stipulate, when the
bean is built, what kind of behavior is needed, but not how it's done. Develo
pment is in two parts: The programmer develops the bean and verifies that it w
orks with the build tools and includes a deployment descriptor that identifies
the kinds of quality-of-service behaviors needed. In the next step, another p
rogrammer can take that bean and use a deployment tool that reads the EJB depl
oyment descriptor and installs the bean into a container on an enterprise Java
server. In this second step, the deployment tool takes some action—this may
mean generating codes such as state saving codes, putting in transactional hoo
ks or doing security checks. All this action is generated by the deployment to
ol; the bean developer and deployer can be different people.
Any platform-independent JavaBean can be adapted, through the use of a deploym
ent tool, into a platform-specific EJB with the correct qualities of services
available to meet the specific requirements of existing business systems and a
pplications. This is why an EJB server is so important to integrating systems,
networks and architectures.
EJBs and IBM WebSphere Enterprise Edition
As used in IBM WebSphere Enterprise Edition, EJBs can be configured as a manag
ed business object. The container they delegate services to is the Component B
roker container in which they are installed. The persistence part of an EJB is
mapped in what we call the Data or State Object. The EJB server provides diff
erent qualities of service for the EJB, and choosing the right EJB server may
be critical to meeting the complete business requirements. The Component Broke
r function is extremely robust, providing high level functions such as workloa
d balance and support across multiple machines in a server group. It has syste
m management capabilities that go well beyond what the Enterprise Java Server
(EJS) specifications call for. Therefore, a JavaBean or EJB written to the bas
ic standards can run on WebSphere Enterprise Edition using the Component Broke
r function and gain all that additional value.
There are unique features and service qualities provided by the EJB server, an
d they are not all the same. IBM Component Broker has some powerful features—
for example, scalability lets the developer deploy EJBs across many types of s
ervers, from small systems to large networks. Developers can start small, for
example, in a single department, deploying first on a Java server on a LAN, kn
owing the JavaBeans and EJBs created there can be deployed on a global network
whenever ready. Then, the developer can test it, get the feel of it, run a pi
lot, do a prototype, and so on. When satisfied with it, the developer can scal
e it up dramatically by moving it to a high-performance server. The JavaBeans
and EJBs are not constrained by any computer architectural boundaries. They ar
e written in Java and can run on anything with a Java virtual machine availabl
e, and any Enterprise Java Server (EJS) can be used to deploy the object. So d
evelopers can build on what's convenient today, deploy on what's convenient la
ter, and it doesn't have to be the same machine or even the same kind of machi
ne.
IBM WebSphere Enterprise Edition supports deploying a business object across m
ultiple servers. EJBs are integrated into the Component Broker function as bus
iness objects and are handled as any other business object. Therefore, the EJB
s can connect to the back-end system of choice to do whatever is necessary to
meet their business needs. That becomes the persistence infrastructure that Co
mponent Broker provides for the EJB. Developers will be able to keep using cur
rent legacy systems and provide them with an e-business interface by utilizing
Component Broker as an EJB server.
For an EJB to work in the WebSphere Component Broker environment, you can use
the Component Broker deployment tool to install it on one or more servers, and
then add it to the naming server so it can be found universally. Anyone with
access to the common naming server can find it, can find the home and can exec
ute a method on the home, creating an EJB. This is exactly what you do with Co
mponent Broker.
An example
Let's take the example of an electronic shopping cart seen on a catalog-shoppi
ng Web site. Your cart is a JavaBean. You fill it up with items from the catal
og shelves and these items are JavaBeans themselves. It is all visual and user
-oriented. When you check out, the items in your cart are sent to an EJB on th
e server that executes the business operations necessary for checking the cred
it card for authorization and available credit, producing a packing slip or sp
ecial directions to the shipping department for which items to pull and where
to send them—all the activities your business programs are already doing.
Summary
The whole thrust is not so much the capabilities of beans as it is the competi
tive potential they can provide your business. IT architects and application d
evelopers now can focus their attention strictly on business logic and leave t
he infrastructure—such as transactions, persistence and security—up to the s
erver. WebSphere's Component Broker function provides all this—and back-
--
在时间面前,没有永恒
------一个热爱自由的人
※ 来源:.哈工大紫丁香WWW bbs.hit.edu.cn. [FROM: 211.99.237.26]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:3.259毫秒