Participating Guests: Ken Burgett from the IBM Component Broker beta support
team, and Liane Acker, Jim Knutson and David Morrill from the IBM Enterprise
Java Beans department.
This group was asked to help us distinguish the basic differences between
JavaBeans and Enterprise Java Beans. Here's what they had to say:
Notable Quote: "The whole thrust of this is not so much the
capabilities of beans as it is the competitive potential they can
provide your business."
"First let's explain what a bean is because both a JavaBean
and Server Bean, more commonly known as an Enterprise Java Bean or EJB,
have some basic similarities. They are objects or components created
with a set of characteristics to do their own specific job, and they
have the ability 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 you place it."
"A JavaBean is a component that has interfaces in it or properties
associated with it so it can be interrogated by and integrated
with other beans that were developed by different people at different
times. You can build a bean and tie it together with other beans later
at construction time. This provides a way to build something and use
it again later; that's the notion of a component. This single
application can be deployed stand-alone, within a browser and
also as an ActiveX component."
"What makes it different from pure objects is that it has an
external interface, called the properties interface which allows
a tool to read what the component is supposed to do and hook it up
to other beans and plug it into another environment. That's true of
JavaBeans and EJBs. 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, graphic or chart, for example, but it is
not a requirement."
"An EJB is a non-visual, remote object designed to run on a
server and be invoked by clients. You can build an EJB out of
multiple, non-visual JavaBeans if you choose. EJBs are intended
to live on one machine and be invoked remotely from another
machine. They have a deployment descriptor that is intended for
the same purpose as JavaBean properties. It is a description
about the bean that can be read later by a tool. They are also
platform independent. Once a bean is written it can be used on
any platform that supports Java and this is true of clients and
servers as well."
"In regards to ActiveX, a JavaBean can be deployed as an ActiveX
object. A proxy to an EJB can also be an ActiveX object, but an EJB
will not be an ActiveX object because ActiveX runs on the desktop. If
you really want to do this on a platform dependent, Windows-only platform,
then you could have the JavaBean rendered as an ActiveX component."
"Server beans or EJBs are remotely executable components or
business objects deployed on the server. They have a protocol that
allows them to be accessed remotely and this protocol also allows them
to be installed or deployed on a particular server. They have a set of
mechanisms that allow them to delegate major qualities of service,
security, transactional behavior, concurrancy (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 which they are placed
on the EJB server. They get their behavior from being installed in
a container. Containers provide the different qualities of service
so selecting the right EJB server is critical. This is where Component
Broker excels."
"The major benefit is that the bean developer can stipulate,
when the bean is built, what kind of behavior is needed, but not
how it's done. Development is in two parts. You develop the bean
and verify that it works with the build tools and you include a
deployment descriptor which identifies the kinds of quality of
service behaviors needed. In the next step, another person can
take that bean and use a deployment tool that reads the EJB deployment
descriptor and installs the bean into a container on an enterprise
Java server. In this second step, the deployment tool takes some
action and this may mean generating codes like state saving codes,
putting in transactional hooks, or doing security checks. All this
action is generated by the deployment tool. The bean developer and
deployer can be different people."
"To state this simply, any platform independent JavaBean can be
adapted, through the use of a deployment tool, into a platform
specific EJB that has the correct qualities of services available
to meet the specific requirements of your existing business
systems and applications. This is why an EJB server is so important
to integrating your systems, networks and architectures."
"As used in IBM Component Broker, EJBs can be configured
as a managed business object. The container they delegate services
to is the Component Broker 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 different qualities of service for
the EJB and choosing the right EJB server may be critical to meeting
your complete business requirements. IBM Component Broker is very
robust, providing very high levels of functions like workload balancing
and support across multiple machines in a server group. It has system
management capabilities that go well beyond what the Enterprise Java
Server (EJS) specifications call for. Therefore a JavaBean or EJB
written to the basic standards can run on Component Broker and gain
all that additional value."
"EJBs, as they are generated by a toolset like IBM VisualAge
for Java, are server based objects and are intended to be called
remotely. They're installed on the EJB server and they get a remote
interface to call just as other CORBA remote objects are called."
"For an EJB to work in the Component Broker environment, you
can use the Component Broker deployment tool to install it on one
or more servers, 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 execute a method on the home, creating
an EJB. This is exactly what you do with Component Broker."
"You're probably already using JavaBeans today and don't know
it. There are no restrictions to having JavaBeans on your desktop
today if you have a Java enabled browser. The web pages you use may
have beans as part of an applet. In the very near future, you will
interact with JavaBeans as the visual portion of a browser, then
those JavaBeans will interface to an EJB on the server. This
capability extends to both the Internet and intranets as well."
"In fact, this opens up a tremendous business possibility. Because
JavaBeans are platform 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 maintain different versions. Then
these JavaBeans can be paired with EJBs doing the business functions
like ordering, credit card processing, electronic transfers, inventory
allocation, shipping, etc. There is a great potential here, and it is
the kind of potential Component Broker is designed to deliver."
"Let's take the example of an electronic shopping cart you
may see on a catalog shopping web site. Your cart is a JavaBean. You
fill it up with items from the catalog shelves and these items are
JavaBeans themselves. It is all very visual and user oriented. When
you check out, the items in your cart are sent to an EJB on the server
which executes the business operations necessary for checking the
credit card for authorization and available credit, producing a picking
slip or special directions to the shipping department for which items
to pull and where to send them - all the activities your business
programs are already doing."
"But now we're getting into the unique features and quality
of services that are provided by the EJB server and they are not
all the same. IBM Component Broker has some very powerful features,
for example, scaleability. This lets you deploy EJBs across many
types of servers, from small systems to very large networks. So
you can start very small, like in a single department if you like
deploying on a Java server on a local LAN, knowing the JavaBeans
and EJBs you create there can be deployed on a global network
whenever you're ready. Then you can test it, get the feel of
it, run a pilot, do a prototype, etc. When you're satisfied
with it, you can scale it up dramatically by moving it up
to a high performance server. You are not constrained by any
computer architectural boundaries. It's written in Java and
can run on anything where a Java virtual machine is available
and any EJS can be used to deploy the object. So you can build
on what's convenient today, deploy on what is convenient later
and it doesn't have to be the same machine or even the same
kind of machine."
"Component Broker supports deploying a business object
across multiple servers and EJBs are integrated into Component
Broker as business objects and are handled as any other business
object. Therefore, the EJBs can connect to the backend system
of your choice to do whatever is necessary to meet your business
needs. That will become the persistence infrastructure Component
Broker provides for the EJB. So you will be able to keep using
your current legacy systems and provide them with an e-business
interface by utilizing Component Broker as an EJB server."
"The whole thrust of this is not so much the capabilities
of beans as it is the competitive potential they can provide
your business. Your IT architects and application developers
can now focus their attention strictly on your business logic
and leave the infrastructure, such as transactions, persistence,
and security up to the server. Component Broker provides all that
for us, with the object transaction manager, and all the backend
access as well. In fact, at JavaOne '98 we are demonstrating
the full functionality of EJBs in containers and EJBs as managed
objects. If you have the opportunity to attend you will see some
of our customers showing and sharing their successes."
Mike Day is a member of
IBM's Object Middleware Marketing Team. He conducts round tables
that focus on topics of general interest suggested by our readers. Round
table guests are selected based on their relative background,
experience, or immediate activities in the topic area. If you
would like to suggest a topic, write to us
at compbrok@us.ibm.com.