Developing Calculator

application with EJB

Professor: Sheau-Ling Hsieh , Ph.D
Team : Chi-Hua Chen 9634501 Chang-Min Chen 9634508
Ying-Yu Lin 9634509 Hsin-Ying Hsieh 9634512
Ming-Chia Li 9634519 Chia-Wei Hsu 9634524
Yin-Lung Lu 963452

Institute of Information Management,

National Chiao Tung University, Hsinchu, Taiwan.
Developing Calculator application with EJB 2007/12/23

Contents
1. Introduction ................................................................................ 3
2. Objectives ................................................................................... 4
3. Hardware / Software environment ........................................ 5
3.1 Hardware ................................................................................. 5
3.2 Software ................................................................................... 5
4. Approaches (Design)................................................................ 5
5. Implementation (Development and Deployment) ............ 7
6. Results ........................................................................................ 12
7. Alternatives ............................................................................... 14
8. Discussion and Conclusion (Problem Encountered)......... 15

頁 2
Developing Calculator application with EJB 2007/12/23

1. Introduction

Enterprise Java Beans is a managed, server-side component architecture for modular

construction of enterprise applications. The EJB specification is one of the several
Java APIs in the Java Platform, Enterprise Edition. EJB is a server-side component
that encapsulates the business logic of an application. The EJB specification was
originally developed in 1997 by IBM and later adopted by EJB 1.0 and 1.1 and
enhanced under the Java Community Process as EJB 2.0, EJB 2.1 and EJB 3.0.The
EJB specification intends to provide a standard way to implement the back-end
'business' code typically found in enterprise applications. Such code was frequently
found to reproduce the same types of problems, and it was found that solutions to
these problems are often repeatedly re-implemented by programmers. Enterprise Java
Beans were intended to handle such common concerns as persistence, transactional
integrity, and security in a standard way, leaving programmers free to concentrate on
the particular problem at hand.

Accordingly, the EJB specification details how an application server provides:

Persistence

Transaction processing

Concurrency control

Events using Java Message Service

Naming and directory services (JNDI)

Security ( Java Cryptography Extension (JCE) and JAAS )

Deployment of software components in an application server

Remote procedure calls using RMI-IIOP.
Exposing business methods as Web Services.

An EJB container holds two major types of beans:

Session Beans, which can be either "Stateful" or "Stateless"

Message Driven Beans (also known as MDBs or Message Beans)
Stateful Session Beans are distributed objects having state: that is, they keep track of
which calling program they are dealing with throughout a session. For example,
checking out in a web store might be handled by a stateful session bean, which would
use its state to keep track of where the customer is in the checkout process. On the
other hand, sending an e-mail to customer support might be handled by a stateless
bean, since this is a one-off operation and not part of a multi-step process. Stateful
session beans' state may be persisted, but access to the bean instance is limited to only

頁 3
Developing Calculator application with EJB 2007/12/23

one client.
Stateless Session Beans are distributed objects that do not have state associated with
them thus allowing concurrent access to the bean. The contents of instance variables
are not guaranteed to be preserved across method calls.
The lack of overhead to maintain a conversation with the calling program makes them
less resource-intensive than stateful beans.
Message Driven Beans were introduced in the EJB 2.0 specification.
which is supported by Java 2 Platform, Enterprise Edition 1.3 or higher. The message
bean represents the integration of JMS (Java Message Service) with EJB to create an
entirely new type of bean designed to handle asynchronous JMS messages. Message
Driven Beans are distributed objects that behave asynchronously.
That is, they handle operations that do not require an immediate response.
For example, a user of a website clicking on a "keep me informed of future updates"
box may trigger a call to a Message Driven Bean to add the user to a list in the
company's database. These beans subscribe to JMS message queues or message topics.
They were added in the EJB 2.0 specification to allow event-driven processing inside
EJB Container. Unlike other types of beans, MDB does not have a client view
(Remote/Home interfaces), i.e. clients can not look-up an MDB instance. It just listens
for any incoming message on a JMS queue and processes them automatically.
Previous versions of EJB also used a type of bean known as an Entity Bean. These
were distributed objects having persistent state. Beans in which their container
managed the persistent state were said to be using Container-Managed Persistence,
whereas beans that managed their own state were said to be using Bean-Managed
Persistence . Entity Beans were replaced by the Java Persistence API in EJB 3.0,
though as of 2007, CMP 2.x style Entity beans are still available for backward
compatibility.

2. Objectives

Understand the structure of EJB in depth and use EJB to develop an example
application to describe the development process for creating distributed, object-based
applications for Java. Learn the process of middleware development, and understand
the EJB infrastructure and how it works.

頁 4
Developing Calculator application with EJB 2007/12/23

3. Hardware / Software environment

3.1 Hardware
AMD Semprom(tm) 1.00 GHz
512 MB RAM, Physical Address Extension

3.2 Software
JBOSS、Eclipse

4. Approaches (Design)

EJBs are deployed in an EJB container within the application server. The
specification describes how an EJB interacts with its container and how client code
interacts with the container/EJB combination. The EJB classes used by applications
are included in the javax.ejb package. The EJB container created instances of the Java
implementation class to provide the EJB implementation. The Java interfaces were
used by client code of the EJB. The two interfaces, referred to as the Home and the
Component interface, specified the signatures of the EJB's remote methods.

The methods were split into two groups:

Class methods
Not tied to a specific instance, such as those used to create an EJB instance (factory
method) or to find an existing entity EJB (see EJB Types, above). These were
declared by the Home interface.

Instance methods
I.e. methods tied to a specific instance. These are placed in the Component interface.
Because these are merely Java interfaces and not concrete classes, the EJB container
must generate classes for these interfaces that will act as a proxy in the client. Client
code invokes a method on the generated proxies, which in turn places the method
arguments into a message and sends the message to the EJB server.

Remote Communication
The EJB specification requires that EJB containers support accessing the EJBs using
RMI-IIOP. EJBs may be accessed from any CORBA application or provide Web
Services.

頁 5
Developing Calculator application with EJB 2007/12/23

Transactions
EJB containers must support both container managed ACID transactions and bean
managed transactions. Container-managed transactions use a declarative syntax for
specifying transactions in the deployment descriptor.

Events
JMS is used to send messages from the beans to client objects, to let clients receive
asynchronous messages from these beans. MDB can be used to receive messages
from client applications asynchronously using either a JMS Queue or a Topic.

Naming and Directory Services

Clients of the EJB locate the Home Interface implementation object using JNDI. The
Home interface may also be found using the CORBA name service. From the home
interface, client code can find entity beans, as well as create and delete existing EJBs.

Security
The EJB Container is responsible for ensuring the client code has sufficient access
rights to an EJB.

Deploying EJBs
The EJB Specification also defines a mechanism that lets EJBs be deployed in a
similar manner regardless of the specific EJB platform that is chosen. Information
about how the bean should be deployed (such as the name of the Home or Remote
interfaces, whether and how to store the bean in a database, etc.) are specified in the
deployment descriptor. The deployment descriptor is an XML document having an
entry for each EJB to be deployed.

This XML document specifies the following information for each EJB:

Name of the Home interface

Java class for the Bean (business object)

Java interface for the Home interface

Java interface for the business object

Persistent store (only for Entity Beans)

Security roles and permissions

Stateful or Stateless (for Session Beans)

EJB containers from many vendors require more deployment information than that in
the EJB specification. They will require the additional information as separate XML

頁 6
Developing Calculator application with EJB 2007/12/23

files, or some other configuration file format. An EJB platform vendor generally
provides their own tools that will read this deployment descriptor, and possibly
generate a set of classes that will implement the Home and Remote interfaces.
A project for EJB 3.0 is much simpler than for earlier versions of EJB.

To implement the EJB we need to implement:

A local interface
The bean implementation
To configure Resin to be a server for the EJB we need to:

Configure the ejb-server

Configure the client
In this project, a simple " Calculator " EJB is created and deployed within Resin.

Files in this project:

CalculatorLocal .java local business interface

CalculatorRemote .java remote business interface

The local interface for the stateless session
Calculator .java
bean
The implementation for the stateless
CalculatorBean .java
session bean

Client. java The client for the stateless session bean

5. Implementation (Development and Deployment)

Calculator Implementation:

Step1:Calculator .java

The remote interface defines the client view of the bean. It declares all the business
methods. Our all business method is located in the file.
Calculator.java

import java.util.Vector;
public interface Calculator

頁 7
Developing Calculator application with EJB 2007/12/23

public double add(double a, double b);

public double sub(double a, double b);

public double mul(double a, double b);

public double div(double a, double b);

public double exp(double a);

public double log(double a);

public double sqrt(double a);
}

Step2:Calculatorbean.java

The second class for EJBs is the bean implementation class. It implements the
functionality provided by the remote interface. A stateless session bean that
implements a simple java interface instead of an EJB component interface like
EJBObject , EJBLocalObject or java.rmi.Remote . By annotating this class as a
@Stateless session there is no need for a deployment descriptor to describe it
separately. This class implements both a local and remote business interface, namely
CalculatorLocal and CalculatorRemote.
Calculatorbean.java

import java.util.Vector;

import javax.ejb.Stateless;
@Stateless

public class CalculatorBean implements CalculatorLocal, CalculatorRemote {

public double add(double a, double b) {return a + b;}

public double sub(double a, double b) {return a - b;}
public double mul(double a, double b) {return a * b;}

public double div(double a, double b) {return a / b;}

public double exp(double a){return Math.exp(a);}

public double log(double a){return Math.log(a);}

public double sqrt(double a){return Math.sqrt(a);}}

Step3:CalculatorLocal.java:

Since this is a local business interface, it is optional that the coder marks this class
with a @Local annotation. A business interface which is not annotated with @Local
or @Remote is assumed to be Local.

CalculatorLocal.java

import javax.ejb.Local;

頁 8
Developing Calculator application with EJB 2007/12/23

@Local

public interface CalculatorLocal extends Calculator{

Step4:CalculatorRemote.java

Since this is a remote business interface, it must be annotated with the @Remote
annotation.

CalculatorRemote.java

Import javax.ejb.Remote;
@Remote
public interface CalculatorRemote extends Calculator{

Step5:client.java

client.java

Import java.awt.event.*;

import java.awt.*;

import javax.swing.*;
import java.rmi.Naming;
import java.rmi.RemoteException;

import java.net.MalformedURLException;
import java.rmi.NotBoundException;

import javax.naming.InitialContext;

//import javax.swing.AbstractButton;
//import javax.swing.ImageIcon;
public class Client extends JFrame implements ActionListener{

JTextField message;

JButton

jb7,jb8,jb9,jbdiv,jbsqrt,jb4,jb5,jb6,jbmul,jblog,jb1,jb2,jb3,jbsub,jbconvert,jb0,jbPN,jbpoi

nt,jbadd,jbequal,jbc;

boolean isPoint=false;

boolean isCalculate=false;

double tempNumber1=0, tempNumber2=0, result=0;

char tempSymbal='0';

Calculator cal;

JPanel calculatorPanel;

頁 9
Developing Calculator application with EJB 2007/12/23

public Client() {

super("簡易計算機");

try

{
//呼叫CalculatorServer，使用它的服務

InitialContext ict = new InitialContext();

Calculator cal = (Calculator)ict.lookup("CalculatorBean/remote");

.
.
.
public static void main(String[] args) {
Client frame = new Client();
frame.setSize(310, 250);

//frame.setResizable(false);

frame.setTitle("CalculatorGUI");
frame.setVisible(true);

Step6:build.xml

We will use the build.xml to envelop all java to .jar and deploy all service to server .
The JAR file is referenced to provide the functionality of this deployable. Information
about the project (e.g. module's unique identification, any dependencies) is described
inside the <environment> tag. In this case, there are no dependencies so there is
nothing to be listed. However, it is a good idea to give this module some sort of
unique identification, so that it can later be referenced by some other deployable
application.

Build.xml

<?xml version="1.0" ?>

- <project default="ejbjar" basedir=".">

<property name="src.dir" value="${basedir}/src" />

<property name="build.dir" value="${basedir}/build" />

<property name="build.classes.dir" value="${build.dir}/classes" />

<property name="build.lib.dir" value="${build.dir}/lib" />

<property name="jboss.server.config" value="all" />

頁 10
Developing Calculator application with EJB 2007/12/23

<property environment="env" />

- <!--

定義standard classpath ，使用 <classpath refid="standard.classpath"/>

-->
- <path id="standard.classpath">

<pathelement location="${basedir}" />

- <fileset dir="${env.JAVA_HOME}/lib">
<include name="**/*.jar" />

</fileset>
<pathelement location="${build.classes.dir}" />

</path>

- <!--
定義jboss classpath，使用<classpath refid="jboss.classpath"/>
-->
- <path id="jboss.classpath">

- <fileset dir="${env.JBOSS_HOME}/lib">

<include name="**/*.jar" />

</fileset>

- <fileset dir="${env.JBOSS_HOME}/server/${jboss.server.config}/lib">
<include name="**/*.jar" />

</fileset>

- <fileset dir="${env.JBOSS_HOME}/client">

<include name="**/*.jar" />

</fileset>

- <fileset dir="${env.JBOSS_HOME}/server/${jboss.server.config}/deploy">

<include name="**/*.jar" />

</fileset>

- <fileset dir="${env.JBOSS_HOME}/server/${jboss.server.config}/deploy/ejb3.deployer">

<include name="**/*.jar" />

</fileset>

</path>

.
.
.

頁 11
Developing Calculator application with EJB 2007/12/23

6. Results

Step1: input “run –c all –host=140.113.73.38” to start jboss server

、clean、
Step2: input “ant” to build、 、prepare、
、compile file

Step3: input “ant run” to execute

頁 12
Developing Calculator application with EJB 2007/12/23

Step4: You can press buttons and server will return result

頁 13
Developing Calculator application with EJB 2007/12/23

7. Alternatives

To mention the alternatives of EJB, the very first one we thought is the Spring
Framework. Spring Framework is an open source application framework for the Java
platform. It is a truly lightweight alternative to EJB. Using Spring, you can take
advantage of many of the features offered by EJB, such as declarative transaction
management, object pooling, and simple ORM (object role modeling) functionality.
By design, the framework offers a lot of freedom to Java developers yet provides
well-documented and easy to use solutions for common practices in the industry.

Key features

Spring is a JavaBeans-based configuration management, applying

Inversion-of-Control principles, specifically using the Dependency Injection
technique. This aims to reduce dependencies of components on specific
implementations of other components.

Generic abstraction layer for database transaction management.

A core bean factory, which is globally usable.

Comparison of EJB and Spring

By reading some article and web site, we are now describing the difference between
EJB and Spring:

Scope: EJB claims to be a component architecture for the development and
deployment of object-oriented, distributed, enterprise-level applications. The
Spring web site defines Spring as a layered Java/J2EE application framework.
Both of them intend to operate in the enterprise Java development space. But
Spring claims to be an application framework but EJB claims to be an
architecture.

Persistence: Spring doesn't re-implement a persistence framework but rather
integrates with many popular ones including JDBC, Hibernate, JDO, iBatis, and
(as of Spring 2.0) the Java Persistence API (JPA).

頁 14
Developing Calculator application with EJB 2007/12/23

Table.1 Summation of Persistence Comparison between Spring and EJB

8. Discussion and Conclusion (Problem Encountered)

The proposals made in EJB 3.0 drafts look very promising for enterprise Java
developers. This should be a great time for EJB developers to work with the
long-awaited new version. Now it's time for application server vendors to implement
these specifications and provide a good option for enterprise application development.
The underpinning of EJB is very robust. But also this is the biggest problem of EJB.
Its large, complicated specification makes developer facing an increased development
time. Therefore, just like the technique we mentioned, the Spring Framework may be
the alternative we can try when developing an enterprise Java development scope.

頁 15