Download J2MTReport

CSE 333 – DISTRIBUTED COMPONENT SYSTEMS
SEMESTER PROJECT
J2EE - ENTERPRISE DEVELOPMENT AND INTEROPERABILITY
WITH NON-J2EE CLIENTS
MID SEMESTER PROJECT REPORT
DATE: OCTOBER 22, 2002
PROJECT TEAM
SUDHA BALLA, BETSY CHERIAN AND LANCE FIONDELLA
INSTRUCTOR
STEVEN A. DEMURJIAN
OVERVIEW
There have been extraordinary changes happening in the field of enterprise
software development during the past few years. Technology advances have
been made to improve server-side component architectures, the most popular
standards
evolved
being
Microsoft’s
Distributed
interNet
Applications
Architecture (DNA), Sun Microsystems’ Java 2 Platform Enterprise Edition
(J2EE) and Object Management Group’s CORBA standard. While Microsoft’s
DNA is a product, J2EE and CORBA are standards that enable service-based
architectures for the enterprise. J2EE is a collection of enterprise technologies, in
which portable, object-oriented, enterprise-class applications in Java may be
built. Many of the quality services offered by EJB (an integral part of J2EE) and
CORBA are the same in functionality. EJB includes both Java/RMI and Java IIOP as middleware options. Sun and OMG support EJB/CORBA interoperability
and have produced standards for the same. The EJB/CORBA mapping
specification and RMI-IIOP relieve EJB off the restriction that it should be solely
Java-based, thus facilitating EJB components to be exposed as CORBA objects.
This makes it well suited for cross-language interoperability.
Our team’s effort in this project would be to focus on an in-depth analysis of the
different technologies offered by J2EE for enterprise software development. We
shall also be exploring the interoperability of EJB with CORBA. We aim to create
a small prototype of a J2EE application as a proof-of-concept of the above topics,
to be developed on the Borland Enterprise Server v.5.
2
PROJECT SCOPE
The project was divided into 5 major sections, which are described in some detail
below:
Server-side Component Architectures
In this section, we present issues surrounding server-side development,
emphasize the need for a standardized architecture, analyze the most popular
Server-side Component Architecture standards that exist and conclude where
J2EE fits in the whole scenario. The purpose is to show the similarities and the
differences between J2EE and the other competing technologies and to what
situations each of these technologies are suitable in enterprise application
development.
A server-side deployment is software written to support concurrent users
performing operations simultaneously, securely, reliably and efficiently. A well
written deployment has logical software partitioning into layers. Each layer has a
different role in the overall deployment, and within each layer there can be one or
more components. These layers are pure abstractions and may or may not
correspond to physical distribution.
An N-tier architecture deployment is one where there is a physical separation
between each of these layers. A three-tiered web-based application as shown in
Figure 1 is an example for this architecture. Each of these mentioned layers
could further be decomposed to allow various parts of the system to scale
independently.
3
Figure 1: N-Tier Architecture (Three-tier application architecture)
WEB SERVER
Presentation
layer
APPLICATION SERVER
WITH COMPONENT
CONTAINER
Business logic
Layer
Data layer
I
n
s
e
c
u
r
e
S
e
c
u
r
e
z
o
n
e
Database
But multi-tier deployments need code that would take care of the middleware
services. Application servers provide these middleware services, thus allowing
enterprises to buy these services and focus on the application development. But
each application server available in the market had been providing these
middleware services in a non-uniform, proprietary way as there has never been a
4
clear definition of what middle-tier components are. This results in the following
disadvantages to enterprises:

Once an application sever is chosen the code is locked to that particular
vendor’s solution

Reduces portability

Hampers commerce of components as a customer cannot combine a
component written to one application server with another written for a
different application server.
Thus, there arises a need for a standard architecture for the server-side
components that would describe a well-formed interface between the application
server and the components themselves. The three major standards that evolved
as server-side component architectures are,

OMG’s CORBA Standard

Sun Microsystem’s J2EE Standard

Microsoft’s .NET Architecture
Of the above three, CORBA is an open distributed object computing
infrastructure and is a specification based on technologies proposed by the
software industry, while .Net and J2EE are a suite of technologies. Our effort
would be to bring out the similarities and the differences between these
standards and to conclude why and to what scenarios the J2EE standard would
be useful in developing enterprise applications.
5
J2EE Platform Overview
The J2EE platform is designed to provide server-side and client-side support for
developing enterprise, multitier applications. Such applications are typically
configured as a client tier to provide the user interface, one or more middle-tier
modules that provide client services and business logic for an application, and
backend enterprise information systems providing data management. Figure 2
illustrates the various components and services that make up a typical J2EE
environment.
Figure 2: J2EE Environment
This section focuses on the various technologies that form the J2EE suite.
Appendix A and B shows the technologies that form the J2EE suite and how they
interact. The purpose of the existence of these technologies under J2EE and
how they facilitate enterprise application development will be discussed.
6
Enterprise JavaBeans Components
This is the core of J2EE framework. The EJB architecture is a server-side
technology for developing and deploying components containing the business
logic of an enterprise application. Enterprise beans are scalable, transactional,
and multi-user secure. There are two types of enterprise beans: session beans
and entity beans.
Remote Method Invocation Protocols
The J2EE platform supports the JRMP protocol, the use of which guarantees
interoperability with CORBA servers written in almost any supported language.
J2EE also includes a mandatory RMI-IIOP bridge that makes J2EE application
servers able to talk to both CORBA and RMI clients and servers. It uses the Java
IDL as the API for calling CORBA services.
Other API’s
The J2EE platform also has a number of APIs to access existing enterprise
information systems (EIS). Access to these systems is provided by these APIs:

JDBC is the API for accessing relational data from Java.

The Java Transaction API (JTA) is the API for managing and
coordinating transactions across heterogeneous EIS.

The Java Naming and Directory Interface (JNDI) is the API for
accessing information in enterprise name and directory services.

The Java Message Service (JMS) is the API for sending and receiving
messages via enterprise messaging systems

JavaMail is the API for sending and receiving email.
7
EJB / CORBA Interoperability and Exposing EJB to non-Java Clients
RMI-IIOP is Java Remote Method Invocation technology run over Internet InterOrb Protocol and delivers CORBA distributed computing capabilities to the Java2
platform. It combines the best features of Java RMI technology with the best
features of CORBA technology. Like Java RMI, RMI over IIOP speeds distributed
application development by allowing developers to work completely in the Java
programming language. It provides flexibility by allowing developers to pass any
serializable Java object between application components. Like CORBA, RMI
over IIOP is based on open standards defined with the participation of hundreds
of vendors and users in the Object Management Group. It uses IIOP as its
communication protocol. IIOP eases legacy application and platform integration
by allowing application components written in C++, Smalltalk, and other CORBA
supported languages to communicate with components running on the Java
platform.
The EJB 2.0 specification states that EJB components must be able to run over
both RMI and RMI-IIOP. The addition of RMI-IIOP as an on-the-wire protocol for
EJB components would greatly assist the integration of the J2EE environment
into existing corporate infrastructures, most of which are quite CORBA intensive.
Also, EJBs could be exposed as CORBA components that could be accessed by
non-Java Clients, thus relieving the EJBs of the constraint that they could be only
Java based. In our effort, we would explain how this interoperability is achieved
and also use this technique in our prototype application to expose our EJB
component as a CORBA component to be accessed by non-Java Clients.
8
J2EE Patterns
The J2EE Patterns are a collection of J2EE-based solutions to common
problems encountered by enterprise application developers. They extract the
core issues of each problem, offering solutions that represent an applicable
distillation of theory and practice. These have been compiled together into a
collection called the Sun Java Center J2EE Patterns Catalog which uses a
tiered approach to divide the J2EE patterns according to functionality.

The Presentation Tier patterns contain the patterns related to Servlets
and JSP technology.

The Business Tier patterns contain the patterns related to the enterprise
beans technology.

The Integration Tier patterns contain the patterns related to JMS and
JDBC.
Patterns are documented at a relatively high level of abstraction. At the same
time, each pattern includes various strategies that provide lower-level
implementation details. Through the strategies, each pattern documents a
solution at multiple levels of abstraction.
Appendix C: J2EE Patterns Overview
Appendix D: J2EE Pattern Relationships
Appendix E: J2EE Patterns Framework
For this project, we explored the Patterns Catalog in some detail and identified 6
patterns which we shall use in the prototype application which we shall develop.
Appendix F: Use of Patterns in the DMV Application
9
Prototype Application
As a proof-of-concept, we shall develop a small prototype application which
provides a few common services provided by the Department of Motor
Vehicles (DMV). The DMV application (DMVApp) enables authenticated users
to manage common tasks such as vehicle registration, issuance of licenses, and
generation of pertinent reports.
The main functionalities are as listed below:
1. Login: The user is first required to login to the system where an initial
authentication/verification is performed. After successful login, the user is
presented with a menu of choices from which he must select a task to
perform. These include managing registration data, managing license
data, and the generation of reports.
2. Manage Registration/License: When managing data, the user may
choose to add new records for the appropriate type of data, or update
existing records. To maintain simplicity of implementation, while retaining
user-friendliness, when the user is performing and update they may
merely enter the appropriate key value via the user interface and select an
edit option. Both edit and add selections transition the user to the same
data management screen, however, in the case when the user is updating
an existing record the pertinent data returned from a successful query is
displayed within the appropriate fields, otherwise the fields are naturally
blank.
Since the type of data manipulation (add/edit) has been pre-
specified and is maintained unknown to the user, once finished with the
10
record the submit event performs the appropriate query, executing the
original appropriate behavior as specified by the user. The user may add
and/or edit any number of records in the registration and license
management portions of the application. This activity effectively entails
associating vehicles with a registration, and people with a license while
preserving related integrity constraints. When finished managing data the
user may return to a main menu and generate reports.
3. Reports: Two reports have been incorporated and are demonstrative of
the functionality offered by the application. These are registration and
license renewal mailing reminders.
4. Integration with CORBA: There will be a non-Java application (in VB)
which will attempt to access the EJB using CORBA .
Appendix G: DMVApp prototype specification
Appendix H: DMVApp automaton, Data Model
UML Diagrams:
Component Diagram
Use-Case Diagram
11
PROJECT PROGRESS
The project was divided into 5 sections with team members focusing on exploring
different areas as shown below:

Server-side Component Architectures (Betsy and Lance)

The J2EE Technologies (Lance and Sudha)

EJB/CORBA Interoperability and Exposing EJB to non-Java Clients
(Betsy, Lance and Sudha)

J2EE Patterns (Betsy and Sudha)

Prototype Application (Betsy, Lance and Sudha)
Each person explored a facet of the J2EE technology framework, and prepared
individual reports of the same. Weekly meetings were held once a week for 1.5
hrs at the library, in which new findings were discussed & details of the prototype
application were discussed and finalized. These have been described in the
section “Prototype Application” above.
There have been no significant changes in the project scope or focus. One minor
change is in the prototype application. Initially we had also intended to illustrate
the interaction between a pure Java application and the EJB components.
However, since this would be internally the same as the interaction by a browser
based Java client, we decided to omit the pure Java client from the prototype.
12
PROPOSED PLAN
As per our original schedule, developing the prototype application is the next
task. This will be split among the team members on a use-case basis, with each
member being completely responsible (i.e. for all 3 tiers – presentation, business
and integration) for their respective use-case.
The schedule for the remaining project will be as follows:

October 23rd to October 30th: Design: Finalize Class Diagrams and
Sequence Diagrams which will be used as the basis for coding.

October 31st to November 13th: Implementation: Complete individual usecases (including JSPs, Servlets, EJBs, Helper Classes, etc.)

November 14th to November 20th: Integration and Testing.

November 21st to December 2nd: Prepare final report

December 2nd: Submit Final Report and Presentation

December 3rd or 5th: Give presentation.
Activity Flow Diagram
13
REFERENCES
Books:
[1] Bodoff, S., Pawlan, M., Haase, K., Jendrock, E., The J2EE Tutorial with
Cdrom, Addison-Wesley, March 2002.
[2] Singh, I., Johnson, M., Stearns, B., Designing Enterprise Applications with the
J2EE Platform 2nd ed., Addison-Wesley, April 2002.
[3] Roman, E., Mastering Enterprise JavaBeans and the Java 2 Platform,
Enterprise Edition, Wiley, John & Sons, Incorporated, September 1999.
[4] Alur, D., Malks, D., Core J2EE Patterns: Best Practices and Design
Strategies, Prentice Hall Professional Technical, June 2001.
[5] Professional JSP, various authors, ISBN 81-7366-211-8
[6] Valesky, T. C., Enterprise JavaBeans: Developing Component-Based
Distributed Applications, Addison-Wesley, May 1999.
[7] Monson-Haefel, R. Loukides, M. Ed., Enterprise JavaBeans, O'Reilly &
Associates, Incorporated, August 1999.
[8] Hunter, J., Crawford, W., Java Servlet Programming, O'Reilly & Associates,
Incorporated, April 2001.
[9] Moss, K., Java Servlets, The McGraw-Hill Companies, June 1999.
[10] Rosenberger, J. L., Sams Teach Yourself CORBA in 14 Days, Sams,
December 1997.
[11] Pritchard, J., COM and CORBA, Side by Side: Architectures, Strategies, and
Implementations, Addison-Wesley, June 1999.
14
[12] Rosen, M., Curtis, D., Foody, D., Integrating CORBA and COM Applications,
Wiley, John & Sons, Incorporated, September 1998.
Web links:
[12] http://java.sun.com
[13] http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
[14] http://www.theserverside.com/home/index.jsp
[15] http://java.oreilly.com
[16] http://j2ee.masslight.com/
15