CS 483 Enterprise and Web Application Programming

1
CS 483 Enterprise and Web Application Programming

• Week 3
• Enterprise JavaBeans

2
Topics

• J2EE Overview
• Enterprise JavaBeans Overview
• Enterprise Entity Beans Case Study
• How to build them
• We will get to deployment next week

3
Distributed Multitiered Applications

• The J2EE platform uses a distributed multitiered
  application model for enterprise applications
• Application logic is divided into components
  according to function, and the various
  application components that make up a J2EE
  application are installed on different machines
  depending on the tier in the multitiered J2EE
  environment to which the application component
  belongs.

4
Multitiered Applications
5
J2EE Components

• J2EE applications are made up of components
• A J2EE component is a self-contained functional
  software unit that is assembled into a J2EE
  application with its related classes and files
  and that communicates with other components.
• The J2EE specification defines the following J2EE
  components
• Application clients and applets are components
  that run on the client.
• Java Servlet and JavaServer Pages (JSP)
  technology components are web components that run
  on the server.
• Enterprise JavaBeans (EJB) components
  (enterprise beans) are business components that
  run on the server.

6
J2EE Server Communications
7
J2EE Clients

• Web Clients
• A web client consists of two parts
• (1) Dynamic web pages containing various types of
  markup language (HTML, XML, and so on), which are
  generated by web components running in the web
  tier, and
• (2) Web browser, which renders the pages received
  from the server.

8
J2EE Clients

• Applets
• A web page received from the web tier can include
  an embedded applet.
• Anapplet is a small client application written in
  the Java programming language that executes in
  the Java virtual machine installed in the web
  browser.
• Application Clients
• An application client runs on a client machine
  and provides a way for users to handle tasks that
  require a richer user interface than can be
  provided by a markup language.
• It typically has a graphical user interface (GUI)
  created from the Swing API, but a command-line
  interface is certainly possible.

9
Why use EJB?

• EJB provides developers architectural
  independence
• EJB insulates developers from the underlying
  middleware because the only environment an EJB
  developer sees is the Java environment. It also
  helps the EJB server/container vendor to change
  and make improvements on the underlying
  middleware layer without affecting a users
  existing enterprise applications.
• WORA (Write-once-run-anywhere) for server-side
  components
• Because EJB is based on Java technology, both the
  developer and the user are guaranteed that their
  components are Write Once, Run Anywhere (WORA).
  As long as an EJB server faithfully conforms to
  the EJB specification, any third-party EJB
  component should run within that server.
• EJB establishes roles for application development
• The EJB specification assigns specific roles for
  project participants charged with enterprise
  application development using EJBs.

10
Why use EJB?

• EJB takes care of transaction management
• The EJB container vendor is required to provide
  transaction control. The EJB developer who is
  writing the business functionality need not worry
  about starting and terminating transactions.
• EJB provides distributed transaction support
• EJB provides transparency for distributed
  transactions. This means a client can begin a
  transaction and then invoke methods on EJBs
  present within two different servers, running on
  different machines, platforms, or Java virtual
  machines. Methods in one EJB can call methods in
  the other EJB with the assurance they will
  execute in the same transaction context.
• EJB helps create portable and scalable solutions
• EJBs conforming to the EJB API will install and
  run in a portable fashion on any EJB server.

11
Why use EJB?

• EJB seamlessly integrates with CORBA
• EJB and CORBA are a natural combination that
  complement each other. For example, EJBs may
  provide CORBA/IIOP for a robust transport
  mechanism or pure CORBA clients can access EJBs
  as EJB clients. Currently, a highlight of OMGs
  CORBAServices is the wide range of features they
  provide to an enterprise application developer.
  In the future, rather than trying to rewrite
  these services, EJB server vendors may simply
  wrap them with a simplified API, so EJB
  developers can use them without being CORBA
  experts.
• EJB provides for vendor specific enhancements
• Because the EJB specification provides
  considerable flexibility for the vendors to
  create their own enhancements, the EJB
  environment may end up being feature-rich.

12
The JavaBeans Component Architecture

• The server and client tiers might also include
  components based on the Java-Beans component
  architecture (JavaBeans components) to manage the
  data flow between an application client or applet
  and components running on the J2EE server, or
  between server components and a database.
• JavaBeans components are not considered J2EE
  components by the J2EE specification.
• JavaBeans components have properties and have get
  and set methods for accessing the properties.
• JavaBeans components used in this way are
  typically simple in design and implementation but
  should conform to the naming and design
  conventions outlined in the JavaBeans component
  architecture.

13
Web Tier and J2EE Applications
14
Web Components

• J2EE web components are either servlets or pages
  created using JSP technology (JSP pages).
• Servlets are Java programming language classes
  that dynamically process requests and construct
  responses.
• JSP pages are text-based documents that execute
  as servlets but allow a more natural approach to
  creating static content.
• Static HTML pages and applets are bundled with
  web components during application assembly but
  are not considered web components by the J2EE
  specification.
• Server-side utility classes can also be bundled
  with web components and, like HTML pages, are not
  considered web components

15
Business and EIS Tiers
16
Business Components

• Business code, which is logic that solves or
  meets the needs of a particular business domain
  such as banking, retail, or finance, is handled
  by enterprise beans running in the business tier.
  
• Previous slide shows how an enterprise bean
  receives data from client programs, processes it
  (if necessary), and sends it to the enterprise
  information system tier for storage.
• An enterprise bean also retrieves data from
  storage, processes it (if necessary), and sends
  it back to the client program.

17
Types of Enterprise Beans

• Three kinds of enterprise beans session beans,
  entity beans, and message-driven beans.
• A session bean represents a transient
  conversation with a client.
• When the client finishes executing, the session
  bean and its data are gone.
• An entity bean represents persistent data stored
  in one row of a database table.
• If the client terminates or if the server shuts
  down, the underlying services ensure that the
  entity bean data is saved.
• A message-driven bean combines features of a
  session bean and a Java Message Service (JMS)
  message listener, allowing a business component
  to receive JMS messages asynchronously.

18
Enterprise Information System Tier

• The enterprise information system tier handles
  EIS software and includes enterprise
  infrastructure systems such as
• enterprise resource planning (ERP)
• mainframe transaction processing
• database systems, and
• other legacy information systems.
• For example, J2EE application components might
  need access to enterprise information systems for
  database connectivity.

19
J2EE Containers

• Normally, thin-client multitiered applications
  are hard to write because they involve many lines
  of intricate code to handle transaction and state
  management, multithreading, resource pooling, and
  other complex low-level details.
• The component-based and platform-independent J2EE
  architecture makes J2EE applications easier to
  write because business logic is organized into
  reusable components.
• In addition, the J2EE server provides underlying
  services in the form of a container for every
  component type.
• Because you do not have to develop these services
  yourself, you are free to concentrate on solving
  the business problem at hand.

20
Container Services

• Containers are the interface between a component
  and the low-level platformspecific functionality
  that supports the component.
• Before a web component, enterprise bean, or
  application client component can be executed, it
  must be assembled into a J2EE module and deployed
  into its container.
• The assembly process involves specifying
  container settings for each component in the J2EE
  application and for the J2EE application itself.
• Container settings customize the underlying
  support provided by the J2EE server, including
  services such as security, transaction
  management, Java Naming and Directory Interface
  (JNDI) lookups, and remote connectivity

21
Container Services - Highlights

• The J2EE security model lets you configure a web
  component or enterprise bean so that system
  resources are accessed only by authorized users.
• The J2EE transaction model lets you specify
  relationships among methods that make up a single
  transaction so that all methods in one
  transaction are treated as a single unit.
• JNDI lookup services provide a unified interface
  to multiple naming and directory services in the
  enterprise so that application components can
  access naming and directory services.
• The J2EE remote connectivity model manages
  low-level communications between clients and
  enterprise beans. After an enterprise bean is
  created, a client invokes methods on it as if it
  were in the same virtual machine.

22
Container Types
23
Container Types

• J2EE server
• The runtime portion of a J2EE product. A J2EE
  server provides EJB and web containers.
• Enterprise JavaBeans (EJB) container
• Manages the execution of enterprise beans for
  J2EE applications. Enterprise beans and their
  container run on the J2EE server.
• Web container
• Manages the execution of JSP page and servlet
  components for J2EE applications. Web components
  and their container run on the J2EE server.
• Application client container
• Manages the execution of application client
  components. Application clients and their
  container run on the client.
• Applet container
• Manages the execution of applets. Consists of a
  web browser and Java Plugin running on the client
  together.

24
Packaging Applications
25
What are Transactions?

• To a user, a transaction is a single change event
  that either happens or does not happen
• To the system implementers, a transaction is a
  programming style that enables them to code
  modules that can participate in distributed
  computations
• Ex transferring money from a checking to a
  savings bank accout
• Sounds easy but in a distributed environment need
  transaction control
• Java Transaction Service
• Transaction manager keeps track of the progress
  of a transaction
• Commits or rolls back the ENTIRE transactions
  which can be updates to multiple database tables
  in multiple databases...

26
What is a Naming Service?

• A naming system provides a natural,
  understandable way of indentifying and
  associating names with data
• Enable humans to interact with complex computer
  addressing systems by associating data and
  objects with simple names
• Independent from computer systems that use them
• Can serve any system that can connect to them and
  understands their protocol

27
Java Naming Directory Interface (JNDI)
28
Enterprise Java Beans

• Written in the Java programming language, an
  enterprise bean is a server-side component that
  encapsulates the business logic of an
  application. The business logic is the code that
  fulfills the purpose of the application (Sun,
  2006).
• For example, in a university student services
  application, this logic would include the
  registration of students, but not the underlying
  networking code allowing registration via a web
  browser.
• An enterprise bean typically contains business
  logic that operates on the enterprises data
• An enterprise beans instances are created and
  managed at runtime by a container
• An enterprise bean can be customized at
  deployment time by editing its environment
  entries.
• Various service information, such as transaction
  and security attributes, are separate from the
  enterprise bean class and can be configured
  without changes to the software

29
Basic Enterprise Java Bean Architecture
30
EJB Server

• EJB server provides an organized framework or
  execution environment in which EJB containers can
  run.
• Makes available system services for
  multiprocessing, load balancing, and device
  access for EJB containers.
• EJB server also makes EJB containers running
  within them visible to the outside world.
• It may also provide vendor-specific features like
  an optimized data access interface, additional
  CORBAServices, SSL support, a JNDI-accessible
  naming service, and transaction management
  services.

31
The Home Interface and Home Object

• Contains Factory methods for locating, creating
  and removing instances of EJBs
• EJB developer defines the Home Interface for his
  bean
• Home Object is generated by tools provided by the
  Container vendor
• Home Object is the implementation of the Home
  Interface

32
The Remote Interface and the EJBObject

• Remote Interface lists the business methods
  present in the EJB class
• Remote Interface is defined by the EJB developer
• EJBObject which is the concrete class for the
  Remote Interface is generated by tools provided
  by the container vendor
• EJB Clients use the methods present in the Remote
  Interface to invoke business methods of the EJB

33
EJB Containers

• An EJB container acts as the interface between an
  enterprise bean and low-level, platform-specific
  functionality that supports the bean.
• Container vendor is also free to provide
  additional services implemented at either the
  container or the server level.
• EJB client never accesses a bean directly.
• Any bean access is done through the methods of
  the container-generated classes, which, in turn,
  invoke the bean's methods.
• Having the container interpose on all bean
  invocations allows the container to manage
  transactions, load bean instances, if necessary,
  and, in general, to do all the wonderful things
  EJBs do.
• Two types of containers exist
• session containers that may contain transient,
  nonpersistent EJBs whose states are not saved
• entity containers that contain persistent EJBs
  whose states are saved between invocations.

34
The Enterprise JavaBean

• Real enterprise bean itself is contained within
  an EJB container and is never directly accessed
  by anyone but the container
• EJB container mediates all EJBs
• Does not implement the remote interface within
  the bean itself uses skeleton

35
The Enterprise JavaBean
36
Two Types of EJBs we will use in this class...
37
The EJB Client

• Finds EJB containers using JNDI
• Uses EJB containers to invoke EJB methods
• EJB Client only gets a reference to an EJBObject
  instance not actual bean
• Uses the Home Object to locate, create or destroy
  an EJB class
• Uses the EJBObject instance to invoke business
  methods of the EJB instance

38
The EJB Lifecycle Roles in EJB

• EJB Server Provider creates EJB Servers
• EJB Container Provider creates EJB container
  and tools
• EJB Developer creates EJBs
• EJB Deployer deploys the EJBs on a Server
• Application Assembler uses the EJBs

39
Major Components of the EJB Architecture
40
Developing EJBs

• Define your Home Interface
• Define your Remote Interface
• Develop your Entity or Session Bean
• In the case of Entity Beans, define a Primary Key
  class
• Write your Deployment Descriptor
• Compile your classes and generate the Container
  code using the tools provided
• Set up your Data Source to the Database
• Develop the client code
• Startup your Server execute your client

41
The Contents of an Enterprise Bean

• To develop an enterprise bean, you must provide
  the following files
• Deployment descriptor An XML file that specifies
  information about the bean such as its
  persistence type and transaction attributes.
• The deploytool utility creates the deployment
  descriptor when you step through the New
  Enterprise Bean wizard.
• Enterprise bean class
• Implements the methods defined in the following
  interfaces.
• Interfaces The remote and home interfaces are
  required for remote access.
• For local access, the local and local home
  interfaces are required.
• For access by web service clients, the web
  service endpoint interface is required. (Please
  note that these interfaces are not used by
• Helper classes
• Other classes needed by the enterprise bean
  class, such as exception and utility classes.

42
The Contents of an Enterprise Bean
43
Naming Conventions for Enterprise Beans
44
The Life Cycles of Enterprise Beans

• An enterprise bean goes through various stages
  during its lifetime, or life cycle.
• Each type of enterprise beansession, entity, or
  message-drivenhas a different life cycle.

45
The Life Cycle of an Entity Bean
46
The Life Cycle of an Entity Bean

• After the EJB container creates the instance, it
  calls the setEntityContext method of the entity
  bean class.
• The setEntityContext method passes the entity
  context to the bean.
• After instantiation, the entity bean moves to a
  pool of available instances.
• While in the pooled stage, the instance is not
  associated with any particular EJB object
  identity.
• All instances in the pool are identical.
• The EJB container assigns an identity to an
  instance when moving it to the ready stage.

47
The Life Cycle of an Entity Bean

• There are two paths from the pooled stage to the
  ready stage.
• On the first path, the client invokes the create
  method, causing the EJB container to call the
  ejb-Create and ejbPostCreate methods.
• On the second path, the EJB container invokes the
  ejbActivate method.
• While an entity bean is in the ready stage, its
  business methods can be invoked.
• There are also two paths from the ready stage to
  the pooled stage.
• First, a client can invoke the remove method,
  which causes the EJB container to call the
  ejbRemove method.
• Second, the EJB container can invoke the
  ejbPassivate method.
• At the end of the life cycle, the EJB container
  removes the instance from the pool and invokes
  the unsetEntityContext method.

48
J2EE and EJB Resources

• Suns Resources
• EJB Specification
• http//java.sun.com/products/ejb/ - Want the EJB
  2.1 Spec
• J2EE 1.4 Tutorial (Update 7)
• http//java.sun.com/j2ee/1.4/docs/tutorial/doc/ind
  ex.html
• J2EE Documentation
• http//java.sun.com/j2ee/1.4/docs/index.html
• API
• http//java.sun.com/j2ee/1.4/docs/api/index.html
• Bean Training
• http//java.sun.com/developer/onlineTraining/Beans
  /bean01/index.html
• Other
• http//my.execpc.com/gopalan/java/ejb.html
• www.javaworld.com

49
Additional RMI

• http//my.execpc.com/gopalan/java/java_rmi.html