Enterprise Java Beans

1
Chapter 15, 16

• Enterprise Java Beans

2
What Is A JavaBean

• JavaBeans are independent application components,
  that normaly do a single thing.
• Beans can exist on
• The Client (presentation layer)
• Listbox
• Calculator
• The Server (application / business layer)
• Datasource provider for the listbox
• Calculator logic / functions

3
What Is A JavaBean

• Conventional JavaBeans are used for a single
  application (although - may exist many times for
  that application).
• A common Bean, such as a server-side data source
  provider to a listbox, may be reused in many
  applications, but each application has its own
  instance (or extension) of the Bean.

4
Enterprise JavaBeans

• If a particular server-side Bean instance can be
  shared across more then one application (across
  the Enterprise) - then this is a candidate for
  an Enterprise JavaBean, or EJB.
• Example If a datasource provider Bean accesses
  a Registered Users table, then assuming most of
  a companys applications use this common table,
  each application may simply want to use this
  Beans current instance, instead of each app.
  using its own.

5
What Are Enterprise JavaBeans

• EJBs are used mainly for n-tier applications,
  where presentation logic is separate from
  business logic and the database.
• Applications utilizing EJBs are often
  distributed, taking advantage of many servers for
  scaling and better performance.
• The same EJB can have several instances existing
  on different servers, all managed by the EJB
  Server (not by the developer).

6
EJB Servers

• EJBs can take advantage of other Java services,
  from JDBC to JNDI.
• Enterprise Java Beans are served by an
  application server that is supports EJBs. These
  are not web servers that host objects called by
  HTTP (such as JSP or Java Servlets). Apache, to
  date, doesnt do it.

7
EJB Servers

• These application servers use a container for
  each bean, which is responsible for publicizing
  the beans methods and how clients can access it.
• A Container provides an API into the Bean that
  includes
• Connection Pooling (db access, in general)
• Transaction Management
• Security
• Bean Instances Lifecycle

8
Clients Access To EJBs

• Clients access an EJB object in a similar way to
  accessing an RMI object. JNDI is used to lookup
  the object and receive an instance of it.
• This instance is used just like any other class -
  calling its public methods - which are actually
  calls made to the real instance running on the
  server.

9
EJB Categories

• Enterprise Java Beans come in two flavors, ENTITY
  Beans and SESSION Beans.
• Entity Beans are tied directly to a data source
  (RDB, ODB, etc...). Ex An entity bean could be
  Stock Room table. Each instance of the bean may
  be a row of that table (each item in the stock
  room).
• Session Beans are instanstiated for each user,
  and provide session-specific services. Ex A
  shopping cart would use a session bean.

10
Session Beans

• Used to communicate directly with clients (most
  of the time). Session beans can be used to allow
  stateless protocols (such as HTTP) to establish a
  single user session that carries throughout an
  application that could be HTML or JSP based.
• There are two categories of Session Beans
  Statefull and Stateless.

11
Session Beans

• Statefull session beans hold a single clients
  state throughout an entire application session.
  This means each client has its own session bean.
  
• Stateless session beans are typically used by
  either clients or stateful beans for common
  functionality that do not need to save a clients
  state between calls.EX Lookups or Calculator
  functions

12
Session Beans

• Session beans are usually modeled after
  application functionality, and encapsulate common
  business logic.
• A Session Beans is used by only a single client
  at a time. As long as a client has an instance
  instantiated on the client side, no other client
  will use that particular instance on the server.
• Session beans should not hold persistent data,
  but can be serialized so the server can cache the
  bean on high load times if the clients access is
  low.

13
Entity Beans

• Used for accessing persistent data. The most
  common use is for accessing an enterprise
  database (such as Oracle) through JDBC.
• Entity beans can be used from clients directory,
  from session beans, or other entity beans. Each
  bean is typically a data type, such as a Table.
  Each instance would then be a Row in that table.
• The most important part of entity beans are how
  they manage their persistence.

14
Entity Beans

• Bean persistence can be categorized as
• Container Managed
• Bean Managed
• Container-Managerd Entity Beans use the container
  (or EJB Server) to manage the transactional
  functionality of the data. No code is needed to
  be written for saving or retrieving data.

15
Entity Beans

• Bean-Managed Entity Beans expect the developer to
  handle all transactions or data access. This
  means writing the code (JDBC/SQL) to access the
  database directly. There is more flexibility this
  way. For instance, each instance of a bean may
  not be a row in the table, but a grouping of rows
  defined by a custom SQL statement.

16
Entity Beans

• Clients do not each have their own entity bean
  (as with stateful session beans). Several clients
  may access the same bean (such as Employee
  table), and possibly the same instance (such as a
  particular Manager).
• Multiple access to the same instance is handled
  in similar fashion to how an RDBMS handles
  multi-user access.

17
The EJB Environment

• Enterprise Java Beans live in an Application
  Servers EJB Container that has access to a
  number of services that are used by ejbs.
• EJB Servers can also provide support JSP,
  Servlets, and even non-java objects such as
  COM/C through the use of a wrapper.

18
EJB Application Services

• State and Life-Cycle Management
• Server will provide information on a beans
  current state and context.
• The server is responsible for the life-cycle of
  a bean. That is, clients to not directly
  instantiate a bean on the server. Nor do they
  directly kill them.

19
EJB Application Services

• Security
• Each bean is associated with an Identity.
• Identities are similar to user names or roles in
  a database, where certain privs can be assigned
  to an identity, and individual users are given
  access to an identity - which in turn allows
  access to the beans that use them.

20
EJB Application Services

• Persistence
• For stateful session beans, an service must be
  responsible for storing beans when necessary.
• For container-managed entity beans, services must
  provide all persistent functionality necessary.
• Communication
• RMI (JRMP) is normally used, unless CORBA is
  supported, in which case RMI over IIOP may be
  used.

21
EJB Application Services

• Transaction Management
• Transactions, when managed by the container, must
  be reliable and fully supported by this service.
• This includes insuring a transaction is a single
  atomic action, regardless if the transaction is
  distributed (across more then one bean).

22
EJB Application Services

• Pooling
• This is an important service for ejb servers,
  that allow for better performance and
  scalability.
• Pooling requires a set number (or pool) of a
  particular resource (such as 10 threads, or 20
  database connections).
• Clients connect to the connection pool, then wait
  for an available resource.
• This means each new client doesnt have to wait
  for the server to always create a new resource
  (1000 clients ! 1000 db connections).

23
EJB Containers

• Containers are referred to as the environment
  that ejbs run in. These provide all the services
  that beans have access to.
• Containers also provide the access to services
  such as JDBC, JTS, RMI, JNDI, etc
• Containers are transparent to the client. A
  developer will instantiate an ejb object on the
  client without referring the container directly.

24
Bean Context

• Each bean can retrieve environmental and context
  information through an ejbContext object.
• Session beans can retrieve an SessionContext
  object.
• Entity beans can retrieve information such as
  their primary key through an EntityContext object.

25
EJBHome EJBObject

• Each bean exists in a bean Factory, called
  EJBHome.
• EJBHome is responsible for creating new instances
  of the bean, and removing them when no longer
  needed (via the Container, which manages this).
• EJBObject is a proxy that is implemented by a
  remote interface. Through this object, ejbHome
  can be accessed.

26
Creating EJBs

• The following steps are normally taken in the
  development / deployment of EJBs
• Create a Remote Interface
• Create a Home Interface
• Development the Bean
• Create the deployment descriptors
• Compile and Package the Bean (with descriptors)
  as a .jar.
• Deploy the bean in the Application Server

27
Remote Interface

• Extends the EJBObject and Remote interfaces.
• This class is used by the client to communicate
  with the Bean (through JNDI, usually).
• Any public methods implemented in the bean will
  be defined in this interface.
• public interface StatelessId extends EJBObject,
  Remote
• public int getId() throws Remote Exception

28
Home Interface

• Extends the EJBHome interface.
• Must define at least one create() method that is
  used by the server (Container) to instantiate the
  bean.
• For entity beans, there will also be one or more
  find() methods for looking up particular data
  points (rows in a table, for instance).

29
Session and Entity Beans

• Each type extends its appropriate class.
• Several methods are required, and are used by the
  Container to manage the bean.
• ejbCreate()
• ejbActivate()
• ejbRemove()
• setSessionContext()

30
Session and Entity Beans

• public class StatelessIdBean implements
  SessionBean
• public void ejbCreate() id nextId()
• public void ejbActivate()
• public void ejbRemove()
• public void setSessionContext (SessionContext
  ctx )
• context ctx
• // BUSINESS LOGIC GOES HERE

31
Deployment Descriptors

• Configuration class that provides information
  about the bean to the container.
• Java 1.1 used a serialized java class, Java 2
  uses an XML object.
• These classes are then installed in the .jar file
  along with the ejbs for a particular package.
• An application server will use this .jar file to
  install an enterprise bean.