Download J2FinalReport

J2EE – ENTERPRISE DEVELOPMENT AND
INTEROPERABILITY WITH NON-J2EE CLIENTS
Sudha Balla, Betsy Cherian, and Lance Fiondella
CSE 333 – Distributed Component Systems
Dr. Steven A. Demurjian
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
J2EE - ENTERPRISE DEVELOPMENT AND INTEROPERABILITY
WITH NON-J2EE CLIENTS
Table of Contents
TABLE OF CONTENTS ............................................................................................................ 2
1. INTRODUCTION .................................................................................................................................... 5
2. MOTIVATION ......................................................................................................................................... 6
3. JAVA TECHNOLOGY SURVEY .......................................................................................................... 8
3.1 SERVER-SIDE COMPONENT ARCHITECTURES ......................................................................... 8
3.1.1 Software Components .................................................................................................................. 9
3.1.2 Server-side Components .............................................................................................................. 9
Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) ........................................................ 11
3.1.3 Server-side Component Architecture Solutions ..........................................................................14
Figure 3.1.3.a The .Net Server-side Architecture ............................................................................................ 15
Figure 3.1.3.b The J2EE Server-side Architecture .......................................................................................... 15
Table 3.1.3.c A comparison of J2EE vs Microsoft .NET ................................................................................ 16
3.2 J2EE PLATFORM OVERVIEW ...............................................................................................................18
Figure 3.2.a: J2EE Environment .........................................................................................................18
Figure 3.2.b: J2EE Components and Containers ................................................................................19
Figure 3.2.c: The J2EE Technology Suite ...........................................................................................20
3.2.1 Java Servlet Technology .............................................................................................................21
3.2.2 JavaServer Pages ........................................................................................................................22
3.2.3 Enterprise JavaBean Components ..............................................................................................23
3.2.3.1 Session Beans ...................................................................................................................................... 24
3.2.3.2 Entity Beans ........................................................................................................................................ 24
3.2.3.3 Message-Driven Beans ........................................................................................................................ 25
3.2.4 J2EE Standardized Services........................................................................................................25
3.2.4.1 Communications Services ................................................................................................................... 26
3.2.4.2 Enterprise Services .............................................................................................................................. 28
3.2.4.3 Internet Services .................................................................................................................................. 29
3.3 EJB/CORBA INTEROPERABILITY ................................................................................................30
3.3.1 CORBA OVERVIEW ............................................................................................................................ 30
Fig 3.3.1.a CORBA Architecture .................................................................................................................... 32
3.3.2 RMI-IIOP ....................................................................................................................................33
Fig 3.3.2.a RMI client - CORBA server .......................................................................................................... 34
Fig 3.3.2.b CORBA client - RMI server ......................................................................................................... 35
Table 3.3.2.c Possible combinations in RMI-IIOP .......................................................................................... 37
3.3.3 ADVANTAGES OF EJB-CORBA INTEROPERABILITY ...........................................................37
3.3.4 INTEROPERABILITY SCENARIOS ...........................................................................................37
Fig 3.3.4.a CORBA client - EJB server........................................................................................................... 38
3.4 APPLICATION OF PATTERNS........................................................................................................39
3.4.1 Pattern Functionality ..................................................................................................................40
Figure 3.4.1.1: Presentation Tier Patterns ....................................................................................................... 41
Figure 3.4.1.2: Business Tier Patterns ............................................................................................................. 42
Figure 3.4.1.3: Integration Tier Patterns ......................................................................................................... 42
Figure 3.4.1.4: J2EE Pattern Relationships ..................................................................................................... 43
Figure 3.4.1.5: J2EE Patterns Framework ....................................................................................................... 44
3.4.2 Uses of Patterns in the DMVApp ................................................................................................45
3.4.2.1 Front Controller ................................................................................................................................... 45
3.4.2.2 View Helper ........................................................................................................................................ 45
3.4.2.3 Session Façade .................................................................................................................................... 45
3.4.2.4 Transfer Object.................................................................................................................................... 46
3.4.2.5 Transfer Object Assembler .................................................................................................................. 46
3.4.2.6 Data Access Object ............................................................................................................................. 47
2
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
4. THE MOTOR VEHICLES DEPARTMENT PROTOTYPE ..............................................................47
4.1 LOGIN ..................................................................................................................................................48
4.2 MANAGE REGISTRATION/LICENSE.......................................................................................................48
4.3 REPORTS ..............................................................................................................................................49
4.4 ACCESS TO NON-JAVA CLIENTS (EJB / CORBA INTEROPERABILITY) .................................................49
4.5 APPLICATION ARCHITECTURE AND PATTERNS ....................................................................................49
Fig. 4.1 MVC Architecture in the DMV Prototype ......................................................................................... 49
5. CONCLUSION AND FUTURE WORK ...............................................................................................51
5.1 MILESTONES ACHIEVED ......................................................................................................................52
5.1.1 Individual overseeing document submitted .................................................................................52
5.1.2 Individuals collaborating on specific topic research ..................................................................53
5.1.3 Individual responsible for writing specific sections of report .....................................................53
5.1.4 Individual responsible for module implementation .....................................................................53
5.2 OBSERVED EXTENSIBILITY ..................................................................................................................53
5.3 TEAM EXPERIENCE ..............................................................................................................................54
REFERENCES ............................................................................................................................................56
BOOKS .......................................................................................................................................................56
INTERNET ..................................................................................................................................................58
APPENDIX ..................................................................................................................................................60
A.1 APPLICATION FLOW (SCREENWISE) ....................................................................................................60
A.1.1 Login.jsp .....................................................................................................................................60
A.1.2 MainMenu.jsp .............................................................................................................................60
A.1.3 RegMenu.jsp ...............................................................................................................................60
A.1.4 LicenseMenu.jsp .........................................................................................................................61
A.1.5 ReportMenu.jsp ..........................................................................................................................61
A.1.6 RegEdit.jsp..................................................................................................................................61
A.1.7 LicenseEdit.jsp............................................................................................................................61
A.1.8 RegReport.jsp .............................................................................................................................62
A.1.9 LicenseReport.jsp .......................................................................................................................62
A.2 PACKAGE STRUCTURE AND CLASSES ..................................................................................................63
A.2.1 CommonServices Module ...........................................................................................................63
A.2.2 Login Module..............................................................................................................................63
A.2.3 Registration Module ...................................................................................................................64
A.2.4 License Module ...........................................................................................................................64
A.2.5 Reports Module ..........................................................................................................................65
A.3 PROTOTYPE FIGURES ..........................................................................................................................66
A.3.1: DMVApp Automaton node label key .........................................................................................66
A.3.2: DMVApp Automaton .................................................................................................................66
A.3.3: DMVApp Automaton table ........................................................................................................67
A.3.4: DMVApp Data model ................................................................................................................68
A.3.5: DMVApp queries: type, state, and tables involved ....................................................................68
A.4 UML DIAGRAMS ................................................................................................................................69
A.4.1 Component Diagram ..................................................................................................................69
A.4.2 Use-Case Diagram .....................................................................................................................70
A.4.3 Deployment Diagram .................................................................................................................71
A.4.4 Class Diagram..........................................................................................................................72
A.4.4 Sequence Diagram – 1 ................................................................................................................73
A.4.4 Sequence Diagram – 2 ................................................................................................................74
A.4.5 DMVEJBModule.........................................................................................................................75
A.5 PROTOTYPE SCREEN SHOTS ......................................................................................................76
A.5.1 Login Screen ..............................................................................................................................76
A.5.2 Main Menu.................................................................................................................................77
3
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.3
A.5.4
A.5.5
A.5.6
A.5.7
A.5.8
A.5.9
Registration Menu .....................................................................................................................78
Registration Screen....................................................................................................................79
License Menu .............................................................................................................................80
License Screen ...........................................................................................................................81
Report Menu ..............................................................................................................................82
Pending Registrations Report ....................................................................................................83
Non-Java Client (C++ Application) Accessing Ejb In The Dmv Application ..........................84
List of Tables and Figures
Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture) ......................................................11
Figure 3.1.3.a The .Net Server-side Architecture ............................................................................................................ 15
Figure 3.1.3.b The J2EE Server-side Architecture .......................................................................................................... 15
Table 3.1.3.c A comparison of J2EE vs Microsoft .NET ................................................................................................ 16
Figure 3.2.a: J2EE Environment ..................................................................................................................................... 18
Figure 3.2.b: J2EE Components and Containers ............................................................................................................. 19
Figure 3.2.c: The J2EE Technology Suite ....................................................................................................................... 20
Fig 3.3.1.a CORBA Architecture .................................................................................................................................... 32
Fig 3.3.2.a RMI client - CORBA server ......................................................................................................................... 34
Fig 3.3.2.b CORBA client - RMI server ......................................................................................................................... 35
Fig 3.3.4.a CORBA client - EJB server .......................................................................................................................... 38
Figure 3.4.1.1: Presentation Tier Patterns ....................................................................................................................... 41
Figure 3.4.1.2: Business Tier Patterns............................................................................................................................. 42
Figure 3.4.1.3: Integration Tier Patterns ......................................................................................................................... 42
Figure 3.4.1.4: J2EE Pattern Relationships ..................................................................................................................... 43
Figure 3.4.1.5: J2EE Patterns Framework ....................................................................................................................... 44
A.3.1: DMVApp Automaton node label key .................................................................................................................. 66
A.3.2: DMVApp Automaton .......................................................................................................................................... 66
A.3.3: DMVApp Automaton table .................................................................................................................................. 67
A.3.4: DMVApp Data model .......................................................................................................................................... 68
A.3.5: DMVApp queries: type, state, and tables involved .............................................................................................. 68
A.4.1 Component Diagram ............................................................................................................................................. 69
A.4.2 Use-Case Diagram ................................................................................................................................................ 70
A.4.3 Deployment Diagram ............................................................................................................................................ 71
A.4.4 Class Diagram ....................................................................................................................................................... 72
A.4.4 Sequence Diagram – 1 .......................................................................................................................................... 73
A.4.4 Sequence Diagram – 2 .......................................................................................................................................... 74
A.4.5 DMVEJBModule .................................................................................................................................................. 75
A.5.1 Login Screen ......................................................................................................................................................... 76
A.5.2 Main Menu ............................................................................................................................................................ 77
A.5.3 Registration Menu ................................................................................................................................................. 78
A.5.4 Registration Screen ............................................................................................................................................... 79
A.5.5 License Menu ........................................................................................................................................................ 80
A.5.6 License Screen ...................................................................................................................................................... 81
A.5.7 Report Menu ......................................................................................................................................................... 82
A.5.8 Pending Registrations Report ................................................................................................................................ 83
A.5.9 Non-Java Client (C++ Application) Accessing Ejb In The Dmv Application……………………….84
4
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
1. Introduction
Enterprise software development has been steadily maturing for nearly a
decade now. Technology advances have been made to improve server-side
component architectures, the most popular standards[36] being Microsoft’s
Distributed interNet Applications Architecture (DNA)[62], Sun Microsystems’
Java2 Platform Enterprise Edition (J2EE)[45,50] and Object Management
Group’s CORBA standard[64]. 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[7,33], in which portable, objectoriented, enterprise-class applications may be built. Many of the quality services
offered by EJB[19,29,37] (an integral part of J2EE) and CORBA are nearly
identical in functionality. EJB includes both Java/RMI and Java – IIOP[25] as
middleware options. Sun and OMG[66] support EJB/CORBA interoperability and
have produced standards for the same. The EJB/CORBA mapping specification
and RMI-IIOP relieve EJB from being restricted to the Java platform, thus
enabling EJB components to be exposed as CORBA objects making them well
suited for cross-language interoperability.
The team’s effort has been to focus on an in-depth analysis of the different
technologies offered by J2EE for enterprise software development. And
exploration of the interoperability of EJB with CORBA was conducted. A small
prototype of a J2EE application was implemented as a proof-of-concept of these
technologies and was developed on the Borland Enterprise Server v.5[63].
5
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The remainder of this paper is organized as follows: In section 2, an
accelerated discussion of the factors in mastering J2EE and Java in general are
given.
Section 3 begins by introducing server-side architectures, provides a
detailed assessment of the spectrum of Java technologies, covers important
aspects of EJB and CORBA, and details some specific design pattern techniques
utilized in the construction of the prototype application. Section 4 presents the
Department of Motor Vehicles prototype application that implements some of the
technologies surveyed in section 3, and is given in the form of a tutorial.
Technical discussion is given wherever appropriate observations regarding
development have been made.
Section 5, the conclusion assesses Java2
Enterprise Edition for generic development tasks. A discussion of milestones
achieved, observed extensibility, and the team experience are also provided.
2. MOTIVATION
It has been over seven years since Java was introduced to the world of
computing and many large organizations now have solutions developed on the
foundation of J2EE technologies[10].
Sun promotes the free availability of
learning resources and makes a significant proportion of their publications
available to developers via the web[48].
In addition, several well-known
publishers also have excellent series for the individual programmer’s personal
learning preference[44,48,68]. Sun’s core learning path[8,9,38] is a compact set
of their online series and facilitates the pursuit of corporate certification[21]. The
developer must possess solid Java Standard Edition skills[3,14,22,40] in order to
make the successful transition to the J2EE technology suite.
6
Additional
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
references further reinforce the necessary skills for this ever growing and
evolving language[11,12,23].
Like other corporate entities, Sun produces a
comprehensive
technical
set
of
material
and
J2EE
training
texts[2,7,18,19,29,33,37] that serve as a comprehensive introduction to core
functionality of the language.
When attempting to look beyond distributed object computing in faulttolerant networking environments, it is important that individuals assessing J2EE
technologies maintain an objective opinion about general language facilities.
Sun has grown into many popular niches of commercial computing, providing
Java with a growing set of diverse libraries[28] that can be integrated with J2EE
technologies, and this has further reinforced the popularity of the language. It is
perhaps most promising that the scientific capacities of Java are also maturing,
gaining the approval of the computer science community in areas including:
architecture[17], compiler theory[6,16,17,41], 3D graphics[4,24,32,34,35,39],
security[13], and Real-time[5].
It is important to maintain an objective research perspective on the state of
development of Java2 Enterprise Edition and the Java technologies in general.
This project has had the beneficial effect of determining the role Java plays as an
educational language, problem-solving skill for the workplace, and research tool
for academia. The J2EE Technologies are a rich set of solutions for all three of
these domains and focus on the classical facilities has provided insight into the
true maturation of Java.
7
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
3. JAVA TECHNOLOGY SURVEY
This section presents a survey of J2EE technologies. Server-side
component architectures[67] are presented followed by an introduction to
Servlets and Java Server Pages[7]. Enterprise Java Bean components[19] are
described, providing a discussion of Session and Entity Beans.
The J2EE
Standardized Services are broken down into three categories: Communication,
Enterprise, and Internet services. Special attention is given to Remote Method
Invocation[25] a member of the Communication services. The focus centers on
CORBA Interoperability[31,64] and Exposing EJB to non-Java Clients[26,30].
Other Communication, Enterprise, and Internet services of J2EE are treated with
a uniform level of detail[46], and design patterns[1] utilized in the prototype are
illustrated.
3.1 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.
8
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
3.1.1 Software Components
A software component is code that implements a set of well-defined
interfaces, a manageable, discrete chunk of logic that cannot run alone but can
be used as a puzzle piece to solve some larger problem. A well-defined
component architecture supplies the standards necessary for developing the
components, container that manages the deployed components and tools for
deploying and maintaining the components thus enabling developers to employ a
“divide-and-conquer” approach to programming. This approach has the following
advantages:

Vendors can provide a set of common services that most components will
need, thus saving development and deployment time

Component developers can simply outsource the services needed to other
products written by professionals who are experts in writing these services

Users save time by buying instead of building

Deployment is strengthened as these common products are written by
domain experts
3.1.2 Server-side Components
A server-side deployment is software written to support concurrent users
performing operations simultaneously, securely, reliably and efficiently. A wellwritten deployment has a 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. A typical layer partitioning is as follows:
9
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients

Presentation layer: Components dealing with user interfaces and user
interaction are placed in this layer. This layer of a web-based application
in Java would use servlets, JSPs and/or applets.

Business logic layer: Components that work together to solve business
problems are in this layer.

Data layer: One or more databases that contain the stored state of data
required by the application is in this layer.
An N-tier architecture deployment is one where there is a physical separation
between each of the layers discussed above. A three-tiered web-based
application as shown in Figure 3.1.2.a is an example for this architecture. Each of
the above-mentioned layers could further be decomposed to allow various parts
of the system to scale independently.
10
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Presentation
layer
WEB SERVER
I
n
s
e
c
u
r
e
Firewall + Tier boundary
APPLICATION SERVER
WITH COMPONENT
CONTAINER
Business logic
Layer
Tier boundary
Data layer
Database
Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture)
11
S
e
c
u
r
e
z
o
n
e
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
N-tier architectures have the following characteristics:

Deployment costs are low – it is cheaper to deploy and configure software
in a controlled server-side environment than to deploy software on all the
user terminals

Database switching costs are low

Low costs in business logic migration

Securing deployments using firewalls is possible

Resource pooling is possible

Performance slowdown is localized

Errors are localized

Communication performance suffers

Maintenance costs are high
But multi-tier deployments need code that would:

Broker method requests

Perform resource pooling

Handle lifecycle of the components

Handle the logic to load-balance communications between each tier

Deal with ramifications of two or more clients concurrently accessing the
same component

Reroute client requests to other machines in case of failure

Provide secure environment and deal with unauthorized accesses
12
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Application servers provide these middleware services, thus allowing
enterprises to purchase 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 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 advantages of such a standard
architecture would be:

Components could be managed in a portable way

Component vendors could be relieved of issues about external overhead
such as resource pooling, networking, security etc.

Necessary elements of enterprise-class deployments are externalized to
application server vendors, providing common services to all component
developers

Components could be switched between various application servers
13
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
3.1.3 Server-side Component Architecture Solutions
The three major standards that evolved as server-side component architectures
are,

OMG’s CORBA Standard[64]

Sun Microsystem’s J2EE Standard[50]

Microsoft’s .NET Architecture[62]
Of the above three, CORBA is an open distributed object-computing
infrastructure and is a specification based on technologies proposed by the
software industry. It is the most used middleware in the non-Windows market.
The CORBA Component Model (CCM) is the component model extension of
CORBA. The CCM can be summarized as the multi-language form of EJB,
but .Net and J2EE are a suite of technologies. They enable organizations to
simplify complex problems with the development, deployment, and management
of multi-tier enterprise solutions. The following figures 3.1.3.a and 3.1.3.b are
brief descriptions, and Table 3.1.3.c is a comparison of both the technologies.
14
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Business System
Rich Client Application
Web Client
Container
ASP.NET
.Net Managed Components
Host
Integration
Server 2000
Legacy Systems or Databases or Other Business Systems
Figure 3.1.3.a The .Net Server-side Architecture
Java Client Application
Business System
Web Client
Container
Servlets and JSPs
EJBs
Connectors
Legacy Systems or Databases or Other Business Systems
Figure 3.1.3.b The J2EE Server-side Architecture
15
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Table 3.1.3.c A comparison of J2EE vs Microsoft .NET
Feature
J2EE
.Net
Type of technology
Standard
Product
Dynamic Web Pages
JSP
ASP.NET
Middle Tier Components
EJB
.Net Managed
Components
Database Access
JDBC SQL/J
ADO.NET
SOAP, WSDL, UDDI
Yes
Yes
Implicit Middleware (load
balancing, etc.)
Yes
Yes
Middleware vendors
30+ vendors – IBM, BEA,
Inprise etc.
Microsoft
Interpreter
JRE
CLR
State Management
Services
Provided. Helps in less
coding and RAD
Not provided
Persistence Servives
(Entity Beans)
Provided. Enables
developers to write
applications without
coding data access logic,
resulting in leaner,
database-independent
applications that are
easier to build and
maintain.
Not provided
Single-vendor Solution
Many legacy systems are
written by J2EE vendors
like IBM or BEA. J2EE
offers a single-vendor
solution from the legacy
integration perspective,
since you can re-use
existing relationships with
those vendors.
Users with existing
Microsoft-based systems
– it is easy to go ahead
with .Net
16
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Support for existing
systems
Specifies the JCA producing a marketplace
of adapters that will
greatly ease enterprise
application integration.
Integration with
packaged applications
and legacy systems such
as Siebel, Oracle, or SAP
without ever leaving the
Java programming
environment.
There is no analog to the
JCA of J2EE, but some
legacy integration is
possible through the Host
Integration Server 2000,
COM Transaction
Integrator, MSMQ and
BizTalk Server 2000.
Portability
Runs on a variety of
platforms
Only runs on Windows
Tools
Sun’s Forte, WebGain’s
Visual Café, IBM’s
VisualAge for Java,
Borland’s JBuilder, etc.
are available but are not
as powerful as VS.NET.
Visual Studio.NET is a
very powerful IDE
Scalability
No restriction of the
hardware and hence
easier for organizations
to maintain when they
use different hardware
than Win32.
Supports Win32 only, a
greater number of
machines are needed
than a comparable J2EE
deployment due to
processor limitations.
This multitude of
machines may be difficult
for organizations to
maintain.
From the Table 3.1.3.c we can summarize J2EE to be advantageous over .NET
in the following ways:

J2EE is a proven platform while .NET is a rewrite of Microsoft’s previous
technologies and introduces risk as with any first-generation technology

J2EE lets enterprises take advantage of existing hardware they may have

J2EE gives platform neutrality, including Windows and good portability.
17
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients

J2EE has a better legacy integration through the Java Connector
Architecture (JCA)

J2EE lets the use of any operating system enterprises prefer, such as
Windows, UNIX, or mainframe. Developers can use the environment they
are most productive in.
In conclusion, while both platforms will have their own market-share, we feel
most customers will reap greater wins with J2EE. We feel the advantages
outweigh those offered by Microsoft.NET.
3.2 J2EE Platform Overview
The J2EE platform has been designed to provide server-side and clientside support for developing enterprise, multi-tier applications.
Figure 3.2.a: J2EE Environment
18
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
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 3.2.a illustrates the various components and
services that make up a typical J2EE environment. One sees from the illustration
that clients negotiate with a web or EJB container to access data stored in an
enterprise information system.
It is this middle-tier that provides J2EE the
desired neutrality in encapsulation of client data.
Figures 3.2.b and 3.2.c show in much greater detail the technologies that
form the J2EE suite and how they interact. There are many APIs[46], which go
into the web and EJB containers from the middle-tier of Figure 3.2.a.
Figure 3.2.b: J2EE Components and Containers
19
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
RMI (Communication)
- Simple Distributed
Communications API
- RMI-IIOP adds CORBA
interoperability
J2SE (Core service)
- Core Java platform
language and services
such as io, util, applets,
and JFC
EJB (Core service)
- Component Standard
- Defines the overall
server-side architecture
JNDI (Enterprise)
- Provides a namespace for
finding components and
resources
JMS (Communication)
- Asynchronous invocations
- Publish/ subscribe or
Point-to-point
- Transactional messages
JDBC (Enterprise)
- Provides unified API for
accessing relational
databases
JTA / JTS (Enterprise)
- JTA defines the high-level
interface for demarcating
transactional boundaries
- JTS defines the low-level
interfaces between
transaction participants
J2EE
JavaMail (Communication)
- Allows E-mail operations
in a cross-platform, crossprotocol fashion
Servlets and JSPs (Core service)
- Request/ Response oriented
network components
- Used in web server for clientside interaction
JCA (Enterprise)
- Provides access to EIS
Java IDL (Communication)
- CORBA provides
language interoperability
- Integration with existing
systems
XML (Internet)
- Describes EJB components
- Format for JSP scripts
Figure 3.2.c: The J2EE Technology Suite
20
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
One also sees that Java2 Standard Edition is a foundation for all of these
solutions.
The J2EE technology suite’s ability to facilitate enterprise application
development is detailed in forthcoming sections.
3.2.1 Java Servlet Technology
Java Servlets[15,20] are the mechanism for generating dynamic web
content. They may be thought of as Java applets for servers. Servlets are
platform independent unlike CGI scripts, and enable the development of more
pleasant user interfaces. Servlets exhibit better performance than CGI scripts as
they are persistent. In addition, more complex interaction with requesting clients
is possible because of the well-defined API, enabling a higher degree of
flexibility.
Servlets run in a container, which manages its interaction with clients
simultaneously enabling the servlet to access services from Java including the
entire set of Standard Edition APIs. Some of the most important of this include
JDBC, JNDI, RMI and JavaBean technologies. Information about specific clients
or sessions may be implemented to defeat the challenges of the stateless HTTP
protocol.
Commonly, a web browser makes a request to a web server through
HTTP. The web server processes the request by giving the request to the servlet
container, which in turn gives the request to a specific servlet.
receives this request object.
The servlet
Once the servlet has processed the input
parameters it may return a response object. During this process, the servlet may
21
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
use a context object to save information usable by other servlets, and read a
session object to determine a client state.
The servlet specification defines the concept of a web application, which is
a collection of servlets, JavaServer Pages, HTML pages, and supporting content
such as images when deployed together make a complete solution. JavaServer
Pages another important aspect of the web application shall now be discussed.
3.2.2 JavaServer Pages
JavaServer Pages(JSP)[27,43] utilize Java Servlet technology to simplify
well organized dynamic web content.
Static and dynamic web content is
separated by JSP pages, which define the static HTML template, and embeds
invocations to Java code.
The four elements of a JSP and their roles are as follows:
1. Text elements may be standard HTML or XML content and represent the
static portion of the page.
2. Directives are instruction to the JSP processor, which compiles them for
efficiency.
3. Tags
invoke
computations.
JavaBeans
to
generate
dynamic
content
or
perform
Tags encapsulate functionality and provide the power and
extensibility of the JSP paradigm.
The may do such useful and routine
operations as embedding dynamic distributed database queries and
generation of their associated reports.
4. Scripting elements enable the developer to go beyond standard tags and
define additional interaction and functionality.
22
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The JSP model hides the complexity of programming in Java from the
page designer enabling them to develop sophisticated web-sites with little or no
knowledge of programming.
This clean layering allows servlet developers to
focus on functionality, and JSP designers to concentrate on web-site layout.
3.2.3 Enterprise JavaBean Components
Enterprise JavaBean(EJB) Components[18,19,29,37] are at the center of
the J2EE framework. The EJB component model is a server-side technology for
developing and deploying components containing the business logic of an
enterprise application. Enterprise beans are scalable, transactional, and multiuser secure. EJBs further promote the layering of development from the layers
already specified by JSPs and Servlets.
EJB technology is a stable business logic solution and removes the
computer science performance issues of transaction processing, security, load
balancing, connection pooling, and other application server issues from the
development process.
These details are implemented by a J2EE product
provider and allow encapsulation of legacy technologies. By clearly specifying
the division of clients and components at the method level, containers are able to
manage transactions that occur among components and servers. EJB is a clientneutral standard.
Developers may therefore concentrate on business logic
implementing a set of callback interfaces. Deployment descriptors are XML files
describing how transactions, security, and installation specific details are to be
handled by an EJB application that give them their “Write Once, Run Anywhere”
property, and provides client transparency.
23
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A client’s view of an Enterprise Bean is provided through its home and
remote interfaces. A bean’s home interface provides methods for instantiating a
bean. A bean’s remote interface implements the business logic methods for the
component. A client may invoke a home interface, while the remote interface
performs the computationally intensive data processing at the server where the
data resides.
Transactions come in several varieties. They may take place external to a
transaction. They may be forced to perform a transaction upon invocation. They
may also participate in the transaction of a calling Bean. In addition to container
and client managed transactions they may supervise transaction through the
Java Transaction API(JTA)[61].
3.2.3.1 Session Beans
As the name suggests, Session beans have a limited lifetime. Stateless
session beans do not preserve state between calls. Any client can use any
instance of a stateless bean at any time under the control of the container. Their
lightweight attributes make managing them very easy. Stateful session beans
keep track of session data and are associated with specific clients. Saving and
restoring state are properties of stateful session beans.
3.2.3.2 Entity Beans
Entity beans represent persistent objects like database entries.
Entity
beans are design to be robust. The EJB specification indicates that a bean and
its references survive a crash of its container. This is achieved by storing the
state in the database. Each container provides a class in order to provide meta-
24
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
data to the client.
Persistence is either container or bean managed. In the
former, the DBMS may be responsible or Java serialization may be relied upon.
In the latter, retained fields must be explicitly indicated and the bean is
responsible for storage and retrieval.
3.2.3.3 Message-Driven Beans
Message-driven beans were introduced in the EJB 2.0 standard, and have
been available since J2EE 1.3. They provide a means of constructing loosely
coupled applications that are capable of communicating indirectly using the
queuing and subscription models supported by JMS. This is a more flexible way
of supporting some application configurations, and is more realistic for heavily
congested networks.
3.2.4 J2EE Standardized Services
The containers supporting the J2EE components provide three types of
services: communication, enterprise, and Internet services.
Communication services include:




Remote Method Invocation over Internet Inter-ORB Protocol(RMI-IIOP)[52]
Java Interface Definition Language(Java IDL)[51]
Java Message Service(JMS)[57,58]
JavaMail[54,55]
Enterprise services include:




Java Database Connectivity(JDBC)[40,49,56]
Java Transaction API(JTA)[61]
Java naming and directory services(JNDI)[59,60]
Java Connector Architecture(JCA)
Internet services include:

HyperText Transfer Protocol(HTTP)
25
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients



Transport Control Protocol/Internet Protocol(TCP/IP)
Secure Socket Layer(SSL)
Extensible Markup Language(XML)
3.2.4.1 Communications Services
To support distributed applications with containers running on multiple
machines and enable more efficient communication J2EE has a set of
communication technologies: Remote Method Invocation over Internet Inter-ORB
Protocol(RMI-IIOP), Java Interface Definition Language(Java IDL),
Java
Message Service(JMS), and JavaMail. These provide facilities for performing
network communication, sending messages and invoking services.
The J2EE platform supports the JRMP protocol, the use of which
guarantees interoperability with CORBA servers[26,30,31] 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. JavaIDL is
now required as part of both the J2SE and J2EE environments.
RMI-IIOP is an easier alternative to JavaIDL. JavaIDL allows interfaces to
be defined in the Java instead of the Interface Definition Language. The remote
interface may be converted to IDL and implemented or invoked in another
language if desired. RMI-IIOP is Java Remote Method Invocation technology run
over Internet Inter-Orb Protocol, and delivers CORBA distributed computing
capabilities to the Java2 platform. It attempts to combine the best features of
Java RMI technology with those of CORBA technology. It provides flexibility by
allowing developers to pass any serializable Java object between application
26
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
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[66]. 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 specifications[53] state 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 greatly enhances capacity for the integration of the J2EE
environment into existing corporate infrastructures, many of which are already
significantly CORBA intensive. Also, EJBs have the ability to be exposed as
CORBA components that may be accessed by non-Java Clients, thus relieving
the EJBs of the constraint that they remain Java based. Our technology review
effort, has attempted to explain how this interoperability is achieved attempts
were made to use this technique in our prototype application by exposing an EJB
component as a CORBA component to be accessed by a non-Java client.
Unlike JavaIDL and RMI-IIOP, Java Message Service is an asynchronous
message service. This permits the queuing of messages. JMS also supports
publish-and-subscribe messaging where subscribers may request and publishers
may send messages respectively.
The JavaMail API supports a form of
asynchronous messaging known as electronic mail. JavaMail supports the most
commonly used Internet mail protocols.
27
Programming with this API permits
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
developers to provide services that send mail messages (e.g. notify a user of the
progress of an online book order).
3.2.4.2 Enterprise Services
To facilitate DBMS access and enterprise computing resources, J2EE
supports
a
set
of
enterprise
services
including:
Java
Database
Connectivity(JDBC), Java Transaction API(JTA), Java naming and directory
services(JNDI), Java Connector Architecture(JCA).
JDBC is Java’s Database Connectivity specification.
Users write
Structured Query Language(SQL) statements to manipulate database data from
and to their Java solutions.
JDBC supports stored procedures, transactions,
connections, and user authentication.
Other optional portions of the API’s
specification provide for more robust fault-tolerance when performing database
related operations.
JTA, the transaction API for J2EE provides support for transaction integrity
for EJB containers. Transactions have beginnings, commitments, and roll-back
checkpoints. It also enables coordination of distributed transaction on replicated
and fragmented systems.
JNDI, Java naming and directory services, exposes an interface for
performing directory operations, including association of attributes with objects
and locating objects using their attributes. JDBC data sources and JTA objects
are stored in a JNDI naming environment. The JNDI naming context allows a
container to provide an environment to its components. JNDI promotes sharing
of corporate directory services.
28
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The J2EE connector architecture defines an integration standard for J2EE
components with other enterprise resources. Connectors are intended to solve
the problem of integrating m EJB container implementations with n enterprise
information system products without building m x n separate bridges. The
connector architecture assists with integration of security and transaction
contexts and the flow of control between the two systems.
3.2.4.3 Internet Services
J2EE
supports
Hypertext
Transfer
Protocol(HTTP),
Transport
Control
Protocol/Internet Protocol(TCP/IP), and Secure Socket Layer(SSL) to access
Internet services. TCP/IP (Transport Control Protocol over Internet Protocol)
provides a mechanism to establish connections and reliably deliver streams of
data between Internet hosts. HTTP (HyperText Transfer Protocol) is the basis of
Internet browsers and Web servers. A client makes an HTTP request to a server,
and HTML hypertext is returned via HTTP. SSL (Secure Socket Layer) provides
a secure mechanism for clients to access hosts on the Internet, without someone
eavesdropping or tampering with the messages.
Extensible Markup Language(XML) has been supported since J2EE 1.3.
This self-describing data format facilitates exchange of information, and this new
technology is being used in applications from data exchange between
businesses over the Internet to advanced multi-agent research in academia and
government.
29
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
3.3 EJB/CORBA INTEROPERABILITY
Any Server-side component technology would be incomplete if it did not
support integration with legacy systems. EJB enables rapid development of
portable, enterprise-class server-side applications. On the other hand, CORBA is
a very important technology and is quite useful for advanced middleware
development, cross-language support and legacy integration. Many of the
concepts in EJB came out of CORBA. CORBA offers a much broader suite of
middleware features, but learning the complex APIs is very difficult. Combining
the advantages of EJBs with those of CORBA allows existing applications written
in non-Java languages such as C++, COBOL etc. to access the EJB
components. In this section we would try to bring out

how EJB and CORBA complement each other,

where EJB gets its edge over CORBA,

where CORBA would be still depended on,

benefits of EJB / CORBA interoperability,

interoperability scenarios
3.3.1 CORBA OVERVIEW
CORBA is a standard for developing distributed object systems formulated by
OMG, a consortium of companies that began in 1989. The well-known CORBAcompliant products that implement the CORBA specification available in the
market are Borland’s VisiBroker and Iona’s Orbix.
30
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The advantages of CORBA are

It is not controlled by one organization. Many organizations have invested
in its success. So any changes in the specification is with the consent of
this group of companies, preventing it from become a standard for any
specific product or architecture.

It is language-independent. This enables legacy integration and crosslanguage support.
The disadvantages of CORBA could be summarized as

Slow-moving: As it is under the control of many organizations, the time
taken to adopt a new feature is too long.

Steep learning curve: The standard is so vast that to master it takes great
effort and time.
Apart from being a standard to writing distributed object systems, there is a set of
services that CORBA offers, published by OMG as the CORBA Object Services
(CORBAServices or COS). Some of the services are

COS Naming, the CORBA Naming Service is a technology similar to JNDI
that enables looking up CORBA objects by name, allowing identification of
objects across the network by a human-readable string.

CORBA Event Service allows asynchronous communications between
CORBA object. An object can subscribe to certain types of events through
this service and be notified when such events occur.

Object Transaction Service (OTS) enables transactions to be performed
by CORBA objects.
31
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients

Concurrency Control Service enables multiple clients concurrently interact
with a resource by obtaining locks on it.

Security Service adds security features to CORBA systems through
mechanisms such as user and object identification, authorization, access
control, confidentiality etc.
The CORBA architecture can be depicted as follows:
CLIENT
CORBA Object
Implementation
CORBA Object Interface
CORBA Stub
CORBA Skeleton
ORB
ORB
Network via IIOP
Fig 3.3.1.a CORBA Architecture
A specification for CORBA components(CCM) is now available that adds
component features to CORBA objects, allowing them to function similar to EJBs.
32
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The CCM specification has been formulated with an intention that CORBA
components and EJBs can reside together, thus making it possible that

A CORBA component could appear as if it were an EJB

An EJB could appear as if it were a CORBA component
Thus CORBA is important for the following reasons:

Legacy Integration: Existing legacy systems written in languages like C++
and COBOL could be preserved and reused by wrapping them as CORBA
objects allowing them to be called from any application.

Advanced middleware services: CORBA standard provides for many
advanced middleware services not available in EJB under the J2EE.

EJBs exposed to CORBA clients: Clients written using CORBA APIs in
languages such as C++ or Smalltalk could access EJBs, thus making
EJBs available to non-Java applications. Our EJB-CORBA interoperability
section focuses on this feature as this lifts the restriction that EJBs must
be solely Java-based. It in fact generalizes EJBs and makes them well
suited for cross-language interoperability. We explain how this is achieved
in the following sub-sections and give its implementation in our prototype
application.
3.3.2 RMI-IIOP
Remote Method Invocation(RMI) is a communications package for
performing distributed computing in Java. The default protocol layer for
communication used by RMI behind the scenes is Java Remote Method
Protocol(JRMP). On the other hand, CORBA uses Internet Inter-ORB
33
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Protocol(IIOP) as its default protocol layer for communications. CORBA ORBs
use the IIOP to communicate with each other, as shown in Fig 3.3.1.a.
RMI and CORBA are very similar technologies, with RMI being built specifically
for very simple distributed applications in Java and CORBA as a robust
distributed object standard to allow language interoperability. Unfortunately,
these two technologies have been highly incompatible. A major portion of a
program coded for the RMI API needs to be rewritten if there is a need to switch
to CORBA and vice versa. This prohibits code reuse. Ideally it would be desirable
to
RMI CLIENT
CORBA Object
Implementation
RMI Remote Object Interface
RMI Stub
CORBA Skeleton
ORB
ORB
Network via IIOP
Fig 3.3.2.a RMI client - CORBA server
34
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
CORBA CLIENT
RMI Object
Implementation
CORBA Object Interface
CORBA Stub
RMI Skeleton
ORB
ORB
Network via IIOP
Fig 3.3.2.b CORBA client - RMI server

Combine client-side Java RMI with server-side CORBA (Fig. 3.3.2.a) and

Combine client-side CORBA with server-side JavaRMI.(Fig. 3.3.2.b)
This necessitates a bridge between RMI and CORBA. The RMI-IIOP (RMI over
IIOP) is the unification of RMI and CORBA to achieve this bridge. It is Java
Remote Method Invocation technology run over Internet Inter-Orb Protocol and
delivers CORBA distributed computing capabilities to the Java2 platform. It
combines the best features of Java RMI technology with those of CORBA
technology. Like Java RMI, RMI over IIOP speeds distributed application
development by allowing developers to work completely in the Java programming
35
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
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 advantages of RMI-IIOP could be summarized as follows:

Code reusability of programs coded with the RMI API and the CORBA
API, lessening the impact of switching between the two technologies.

Code written in any CORBA compliant language could call the RMI object
implementations.

RMI clients can be integrated to legacy systems.

IIOP makes RMI more robust

RMI object implementations can be invoked dynamically using CORBA’s
Dynamic Invocation Interface(DII).
Table 3.3.2.c shows the possible combinations using RMI-IIOP.
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
36
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
could be accessed by non-Java Clients, thus relieving the EJBs of the constraint
that they could be only Java based.
CLIENT
SERVER
RMI client with RMI-IIOP Stub
RMI Server with RMI-IIOP skeleton
RMI client with RMI-IIOP Stub
CORBA object implementation
CORBA client
RMI Server with RMI-IIOP skeleton
CORBA client
CORBA object implementation
Table 3.3.2.c Possible combinations in RMI-IIOP
3.3.3 ADVANTAGES OF EJB-CORBA INTEROPERABILITY
There are several advantages that come with the interoperability between
EJBs and CORBA. Some of them are:

Non-Java clients written in any CORBA compliant language can call the
EJBs

In a single transaction clients can mix calls to both CORBA objects and
EJBs.
3.3.4 INTEROPERABILITY SCENARIOS
Typical interoperability scenarios are:

EJBs integrated with legacy applications in CORBA compliant languages
– In this scenario, the client application is wrapped with a CORBA layer
thus
exposing
them
as
CORBA
object
implementations.
EJBs
communicate with these CORBA objects through the IIOP.

EJBs exposed as CORBA components to non-Java clients – In this
scenario, the client is written in a language that is CORBA compliant. The
clients access the EJBs through the IIOP. Our prototype application
37
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
exposes one of its EJB (TrafficViolationSB – a session bean) to a nonJava application (C++ client application).
Fig. 3.3.4.a shows the interoperability scenario of a CORBA client with an EJB
server.
CORBA CLIENT
EJB Object
Implementation
EJB Remote Interface
CORBA Stub
RMI-IIOP
Skeleton
ORB
ORB
Network via IIOP
Fig 3.3.4.a CORBA client - EJB server
CORBA / EJB Client Example:
The following code sample shows the C++ CORBA client accessing the
TrafficViolationSB session bean that enables points to be accrued to a specified
Driver’s License whenever a ticket is issued for violating the rules of the road.
38
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
try {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
CORBA::LongLong lic;
CORBA::Long pts;
cout << "Enter License Number: ";
cin >> lic;
cout << "Enter Points: ";
cin >> pts;
cout << "Accessing the naming service" << endl;
CORBA::Object_ptr o = orb->resolve_initial_references("NameService");
cout << "Getting the naming context" << endl;
CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(o);
cout << "Assigning name" << endl;
CosNaming::Name name;
name.length(1);
name[0].id = CORBA::string_dup("TrafficViolationSB");
name[0].kind = CORBA::string_dup("");
cout << "Resolving the home interface" << endl;
CORBA::Object_var object = context->resolve(name);
com::uconn::dmv::lic::beans::TrafficViolationSBHome_var ctvsbhome =
com::uconn::dmv::lic::beans::TrafficViolationSBHome::_narrow(object);
cout << "Creating a new instance" << endl;
com::uconn::dmv::lic::beans::TrafficViolationSB_ptr ctvsb = ctvsbhome->create();
cout << "Calling method on TrafficViolationSB" << endl;
CORBA::Long r = ctvsb->incrementPointsAccrued(lic,pts);
if(r==0) cout << "Points successfully accrued" << endl;
else cout << "Points accrual failed" << endl;
}
catch(const CORBA::Exception& e) {
cout << "Exception: " << e << endl;
}
3.4 APPLICATION OF PATTERNS
The J2EE Patterns[1,42] are a collection of J2EE-based solutions to
common problems encountered by enterprise application developers. A pattern is
a recurring solution to a problem in a context. It factors central issues of a set of
similar problems, offering insight into general solutions that represent an clear
distillation of theory and variation in practice.
A pattern is documented in a
template form. Several have been compiled together into a collection called the
Sun Java Center J2EE Patterns Catalog[47], which uses a tiered approach to
divide the J2EE patterns according to functionality. The "Rule of Three", as it is
39
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
known in the pattern community serves as a guide for transitioning a candidate
pattern into the pattern catalog. According to this rule, a solution remains a
candidate pattern until it has been verified in at least three different systems.
3.4.1 Pattern Functionality

Presentation Tier patterns(Figure 3.4.1.1) contain the patterns related to
Servlets[15,20] and JSP[27,43] technology.

Business Tier patterns(Figure 3.4.1.2) contain the patterns related to the
enterprise beans technology[19,29,37].

Integration Tier patterns(Figure 3.4.1.3) contain the patterns related to
JMS[57,58] and JDBC[40,49,56].
Patterns are documented at an appropriately 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. The patterns catalog provides prosaic
code fragments and advice for implementing these patterns.
The following
figures provide brief descriptions of the Presentation, Business, and Integration
Tiers respectively, and Figure 3.4.1.4 shows the interconnections among them.
40
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Figure 3.4.1.1: Presentation Tier Patterns
Pattern
Name
Brief Synopsis
Decorating
Filter
Facilitates pre and post-processing of a request
Front
Controller
Provides a centralized controller for managing the
handling of a request
View Helper
Encapsulates logic that is not related to presentation
formatting into Helper components
Composite
View
Creates an aggregate View from atomic subcomponents
Service To
Worker
Combines a Dispatcher component in coordination with
the FrontController and View Helper Patterns.
Dispatcher
View
Combines a Dispatcher component in coordination with
the FrontController and View Helper Patterns, deferring
many activities to View processing.
41
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Figure 3.4.1.2: Business Tier Patterns
Business
Delegate
Decouples presentation and service tiers, and
provides a façade and proxy interface to the
services.
Value Object
Exchanges data between tiers.
Session Facade
Hides business object complexity, centralizes
workflow handling.
Aggregate
Entity
Represents a best practice for designing coarsegrained entity beans.
Value Object
Assembler
Builds composite value object from multiple data
sources.
Value List
Handler
Manages query execution, results caching and result
processing.
Service Locator
Hides complexity of business service lookup and
creation, locates business service factories.
Figure 3.4.1.3: Integration Tier Patterns
Data Access
Object
Abstracts data sources, provides transparent access
to data.
Service Activator
Facilitates asynchronous processing for EJB
components.
42
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Figure 3.4.1.4: J2EE Pattern Relationships
43
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Figure 3.4.1.5: J2EE Patterns Framework
Figure 3.4.1.5 above shows each J2EE pattern and the connection
between the roles of each pattern clarifying how the patterns connect together to
form a framework. The dotted and solid lines between patterns indicate
relationship dependencies. The dotted lines show optional dependencies, while
the solid lines indicate required dependencies. The primary theme of the pattern
catalog is its support of the J2EE platform. For the project, the Patterns Catalog
was explored in detail 6 patterns were identified which served as a basis for the
prototype application developed.
44
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
3.4.2 Uses of Patterns in the DMVApp
The following patterns have been used in the construction of the prototype
application. The application is a small subset of the functionality an Department
of Motor Vehicles office requires. Selected patterns are listed below:
3.4.2.1 Front Controller
For the Front Controller, the J2EE Patterns catalog advocates using:
“a Controller as the initial point of contact for handling a request. The
Controller manages the handling of the request, including invoking security
services such as authentication and authorization, delegating business
processing, managing the choice of an appropriate view, handling errors, and
managing the selection of content creation strategies. The Controller provides a
centralized entry point that controls and manages web request handling.”
The Front Controller is implemented in the prototype as a Servlet and serves as
the single entry point to the entire application.
3.4.2.2 View Helper
This promotes the separation of presentation formatting logic and data
access logic.
“A view contains formatting code, delegating its processing responsibilities
to its helper classes, implemented as JavaBeans or custom tags. Helpers also
store the view's intermediate data model and serve as business data adapters.”
The View Helper is implemented with a JSP. Business logic is encapsulated
inside scriptlets and through the creation of custom-tags.
3.4.2.3 Session Façade
The Session Façade is intended to provide a simpler interface to the
clients by encapsulating all the complex interactions between business
components. This assists in the prevention of tight coupling among these
components, which would lead to direct dependence between clients and
45
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
business objects. It helps in the reduction of method invocations between client
and server resulting in improved network performance, while also preventing
misuse of business objects. The Catalog specifies
“Use a session bean as a facade to encapsulate the complexity of
interactions between the business objects participating in a workflow. The
Session Facade manages the business objects, and provides a uniform coarsegrained service access layer to clients.”
A Session Bean implements the Session Façade.
3.4.2.4 Transfer Object
The Transfer Object is used to exchange data between tiers. In EJB
Applications, every method call to the Bean is remote; therefore using multiple
calls to get methods that return single attribute values degrades network
performance and is inefficient for obtaining data values from an enterprise bean.
The Catalog suggests
“Use a Transfer Object to encapsulate the business data. A single method call is
used to send and retrieve the Transfer Object. When the client requests the
enterprise bean for the business data, the enterprise bean can construct the
Transfer Object, populate it with its attribute values, and pass it by value to the
client.”
3.4.2.5 Transfer Object Assembler
The Transfer Object Assembler is used to build composite value objects
from multiple data sources.
“Use a Transfer Object Assembler to build the required model or submodel. The
Transfer Object Assembler uses Transfer Objects to retrieve data from various
business objects and other objects that define the model or part of the model.”
46
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The Transfer Object Assembler constructs a composite Transfer Object that
represents data from different business components. The Transfer Object caries
the data for the model to the client in a single method call.
3.4.2.6 Data Access Object
J2EE Applications typically use persistent data at some point.
“The DAO is used to abstract data sources and provide transparent access to
data. Use a Data Access Object (DAO) to abstract and encapsulate all access to
the data source. The DAO manages the connection with the data source to
obtain and store data.”
The DAO implements the access mechanism required to work with the data
source. The data source could be of any kind, however the business component
that relies on the DAO uses the simpler interface exposed by the DAO for its
clients. The DAO completely hides the data source implementation details from
its clients.
4. THE MOTOR VEHICLES DEPARTMENT PROTOTYPE
As a proof-of-concept, a small prototype application has been developed,
and provides a few common services provided by the Department of Motor
Vehicles (DMV)[65]. The DMV application (DMVApp) enables authenticated
users to manage common tasks such as vehicle registration, issuance of
licenses, and generation of pertinent reports.
This section is presented in the
form of a “first-use” tutorial for the DMVApp which implements some of the
technologies surveyed in section 3.
In addition to the tutorial, technical
discussion is given wherever appropriate observations regarding development
have been made
47
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
4.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.
4.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 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.
48
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
4.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.4 Access to non-Java Clients (EJB / CORBA Interoperability)
The application allows its non-Java Client (assumed to be Traffic Violation
Control Department’s application that manages road violations – a C++
application) to increment points to Driver’s Licenses whenever a ticket is issued
for a violation.
4.5 Application Architecture and Patterns
The J2EE technologies used to develop each tier of the architecture are
Java Server Pages (JSP), Servlet, EJBs and Java Classes. Model-View
Controller(MVC) architecture is adopted in the design of the application with the
Servlet and the Handler classes acting as the Controller, the JSPs and the View
helper classes as the View and the EJBs and Domain classes as the Model (Fig.
4.1).
CONTROLLER
(SERVLET & HANDLER)
VIEW
(JSPs & VIEW HELPER)
MODEL
(EJBs & Domain classes)
Fig. 4.1 MVC Architecture in the DMV Prototype
49
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
The J2EE design patterns used in the application are:

Front Controller – The DMVControlServlet in the application acts as the
Front Controller. All the client requests arrive at this servlet and its service
method processes these requests by delegating it to appropriate handlers
of the different modules namely – login, registration, license and report.
The result of such processing is the next view(JSP) that has to be sent as
the response to the client browser. The servlet dispatches a forward to the
corresponding view. Thus the DMVControlServlet serves as the Front
Controller for the application.

View Helper – The classes LoginView, RegView, LicView and RepView in
the application act as the View helpers. They contain within themselves
relevant information on login, registration, license and report modules
respectively that the JSPs retrieve while generating responses to the client
requests.

Session Façade – The session beans in the application act as the Session
Façade. All interaction between the handler classes and the entity beans
or the data access object happen through the session beans. This allows
a coarse grained approach thus reducing the network overheads that
would arise by way of adopting a fine grained approach.

Transfer Object – By using domain classes (Value Object) in the
application, the return values from the session beans are not handles to
the Entity beans anymore, but the value object themselves. Thus, the
handlers need not make network calls to retrieve data but could instead
50
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
use the data set in the value objects. This again results in a coarse
grained approach.

Transfer Object Assembler – The session beans act as the Transfer
Object Assemblers in the prototype as they retrieve data from the entity
bean and set them onto Transfer Objects.

Data Access Object – The RepDAO class in the application is the data
access object that serves the report module to retrieve multiple records
from the database. This class contains the appropriate methods with the
necessary data logic to access and retrieve data from the database using
JDBC. The performance is sacrificed by the use of entity beans where
multiple records are retrieved from the database. The use of the DAO
eliminates this drawback.
5. CONCLUSION AND FUTURE WORK
Our analysis of the server-side component architectures gave us a clear
insight of the competing standards. We understood that CORBA accommodates
a wide range of languages and offers sophisticated middleware services in its
specification, but its vast APIs and complexity in programming would be major
hurdles for this standard to monopolize the distributed computing environment
and also for enterprises to depend entirely on it for their application development.
While J2EE and .NET have a suite of similar technologies under them, for the
reason that .NET is marketed as a product and is not platform independent, it
has many disadvantages when compared with J2EE in the real world of
enterprises having heterogeneous infrastructure.
51
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Our survey of the J2EE technology suite enabled us to visualize the
demands of development of enterprise class applications, the numerous
technologies that play a part in fulfilling the need of different legacy, information
systems integration and interoperability scenarios that need to bridge between
different vendor technologies. We could understand the purpose of each of the
APIs in the J2EE suite, the issues each of these APIs address and the vital role
they play in enterprise application development.
The attempt to expose EJBs to non-Java client gave us the opportunity to
explore and understand the importance of the CORBA to J2EE and the vision
behind the origin of RMI-IIOP.
J2EE design patterns are proven ways of application design and gave us
an insight into practical implementation. We were able to understand the role of a
good design and the pitfalls of wrong approaches.
5.1 Milestones Achieved
Individual and team-work is broken down in several ways:
1.
2.
3.
4.
Individual overseeing document submitted
Individuals collaborating on specific topic research
Individual responsible for writing specific sections of report
Individual responsible for module implementation
5.1.1 Individual overseeing document submitted
Semester Project Requirements and Specification
Mid-Semester Project Report
Final Project Report
Final Presentation
52
Sudha
Betsy
Lance
Sudha
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
5.1.2 Individuals collaborating on specific topic research
Primary contributor in bold:
Server-side Component Architectures
Sudha
The J2EE Technologies
Lance, Betsy and Sudha
EJB/CORBA Interoperability and Exposing EJB to Sudha and Lance
non-Java Clients
J2EE Patterns
Betsy
Prototype Application
Sudha and Betsy
5.1.3 Individual responsible for writing specific sections of report
This includes body sections of the final report and its appendicies:
3.1 Server-side component architectures
3.2 J2EE Platform Overview
3.3 EJB/CORBA
3.4 Applications of Patterns
4. The Motor Vehicles Department
Prototype
A.1 Application Flow (Screenwise)
A.2 Package structure and classes
A.3 Prototype figures
A.4 UML diagrams
A.5 Prototype screenshots
Sudha
Lance
Sudha
Betsy
Sudha
Sudha
Sudha
Lance
Sudha
Sudha
5.1.4 Individual responsible for module implementation
Sudha and Betsy
5.2 Observed Extensibility
While our team looked into specific component based technologies under
the J2EE suite like the Servlets, JSPs (web components) and EJBs(business
components), we were unable to critically analyze the use of other technologies
in the suite. Given the numerous enterprise issues that J2EE addresses, we
53
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
believe that it would be appropriate if each of these technologies are dealt with in
detail as a separate project by itself. Otherwise, we were able to complete what
we had planned for as the scope of this project.
Our implementation has a Win32 console based C++ application client for
the demonstration of EJB exposed to non-Java client. This could be extended if
this client is a COM+ component developed in C++ or C#, in which case the EJB
would be exposed to a wide range of Microsoft specific application clients
(developed in VB, C++, ASPs etc.).
With the fact that both Microsoft and Sun Microsystems promoting web
services, it would be a topic of great interest to look into as it would simplify
interoperability issues between the two techology suites. However, this is at its
infant stages and the transformations it goes through has to be carefully
observed.
5.3 Team Experience
The team had significantly different backgrounds, and this made
coordination of the project difficult at times though the entire process was
educational for all. Communication was in general open and honest and this
proved very useful in allocation of work. Had this not been the case there could
have been significant problems with the completion of the work. So this diversity
had both positive and negative influences, though overall a significant amount of
learning and cooperation took place.
individual was different.
The technical background of each
There were several problems encountered when
attempting to utilize enterprise tools that not all members were familiar with. This
54
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
combined with the lack of professional programming experience in Java by
certain team members made the programming work significantly unbalanced.
Everyone learned a significant amount for his or her own sake, and in general the
project served a unique purpose for each individual.
55
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
REFERENCES
Books
[1] Alur, D., Malks, D., Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall
Professional Technical, June 2001.
[2] Austin, C., Pawlan, M., Advanced Programming for the Java™ 2 Platform, Addison-Wesley,
August 2000.
[3] Barker, J., Beginning Java Objects: From Concepts to Code, Wrox Press, 2000.
[4] Barrilleaux, J., 3D Users Interfaces with Java 3D, Manning, 2001.
[5] Bellella G. et al., The Real-Time Specification for Java™, Addison-Wesley, June 2000.
[6] Bloch, J., Effective Java™ Programming Language Guide, Addison-Wesley , June 2001.
[7] Bodoff, S., Pawlan, M., Haase, K., Jendrock, E., The J2EE Tutorial with Cdrom, AddisonWesley, March 2002.
[8] Campione M., Walrath K., Huml A., The Java™ Tutorial Third Edition, Addison-Wesley, April
2001.
[9] Campione M., Walrath K., Huml A., The Java™ Tutorial Continued: The Rest of the JDK™,
Addison-Wesley, January 2001.
[10] Cattell, R., Inscore, J., Enterprise Partners, J2EE™ Technology in Practice: Building
Business Applications with the Java™ 2 Platform, Enterprise Edition, Addison-Wesley, June
2001.
[11] Chan, P., The Java™ Developers Almanac 2000, Addison-Wesley, 2000.
[12] Chan, P., Lee, R., Kramer, D., The Java™ Class Libraries, Second Edition, Volume 1:
Supplement for the Java™ 2 Platform, Standard Edition, v1.2, Addison-Wesley, May 1999.
[13] Gong, L., Inside Java™ 2 Platform Security: Architecture, API Design, and Implementation,
Addison-Wesley, June 1999.
[14] Hart, J., Java J2SE 1.4: Core Platform Update, Wrox Press, March 2002.
[15] Hunter, J., Crawford, W., Java Servlet Programming, O'Reilly & Associates, Incorporated,
April 2001.
[16] Kanerva, J., The Java™ FAQ, Addison-Wesley, July 1997.
[17] Lindholm T., The Java™ Virtual Machine Specification, Second Edition, Addison-Wesley,
April 1999.
[18] Matena, V., Stearns, B., Applying Enterprise JavaBeans™: Component-Based Development
for the J2EE™ Platform, Addison-Wesley, December 2000.
[19] Monson-Haefel, R. Loukides, M. Ed., Enterprise JavaBeans, O'Reilly & Associates,
Incorporated, August 1999.
56
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
[20] Moss, K., Java Servlets, The McGraw-Hill Companies, June 1999.
[21] Mughal K., Rasmussen, R., A Programmer’s Guide to Java™ Certification: A Comprehensive
Primer, Addison-Wesley, 1999.
[22] Mukhar, K., Lauinger T. Carnell, J. et al., Beginning Java Databases: JDBC, SQL, J2EE,
EJB, JSP, XML, Wrox Press, 2001.
[23] Palmer, G., Java Programmer’s Reference, Wrox Press, 2000.
[24] Palmer, I., Essential Java 3D fast, Springer, 2001.
[25] Pitt, E., McNiff, K., java.rmi: The Remove Method Invocation Guide, Addison-Wesley, 2001.
[26] Pritchard, J., COM and CORBA, Side by Side: Architectures, Strategies, and
Implementations, Addison-Wesley, June 1999.
[27] Professional JSP, various authors, ISBN 81-7366-211-8
[28] Riggs, R., Taivalsaari, A., VandenBrink M., Programming Wireless Devices with the Java™ 2
Platform, Micro Edition, Addison-Wesley, June 2001.
[29] Roman, E., Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition,
Wiley, John & Sons, Incorporated, September 1999.
[30] Rosen, M., Curtis, D., Foody, D., Integrating CORBA and COM Applications, Wiley, John &
Sons, Incorporated, September 1998.
[31] Rosenberger, J. L., Sams Teach Yourself CORBA in 14 Days, Sams, December 1997.
[32] Selman, D., Java 3D Programming, Manning, 2002.
[33] Singh, I., Johnson, M., Stearns, B., Designing Enterprise Applications with the J2EE Platform
2nd ed., Addison-Wesley, April 2002.
[34] Sowizral, H., Rushforth, K.,Deering, M., The Java 3D™ API Specification, Second Edition,
Addison-Wesley, December 2000.
[35] Sun Microsystem, Inc., Java™ Look and Feel Design Guidelines, Addison-Wesley, August
1999.
[36] Sørensen, C.-F., A Comparison of Distributed Object Technologies, The Norwegian
University of Science and Technology, 2001.
[37] Valesky, T. C., Enterprise JavaBeans: Developing Component-Based Distributed
Applications, Addison-Wesley, May 1999.
[38] Walrath K., Campione M., The JFC Swing Tutorial: A Guide to Constructing GUIs, AddisonWesley, July 2001.
[39] Walsh, A. Java 3D™: API Jump-Start, Prentice Hall, 2002.
[40] White S., Fisher M., Cattell R., Hamilton G., Hapner M., JDBC API Tutorial and Reference,
Second Edition Universal Data Access for the Java 2 Platform, Addison-Wesley, September
1999.
57
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
[41] Wilson, S., Java™ Platform Performance: Strategies and Tactics, Addison-Wesley, June
2000.
Internet
[42]
http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
[43]
http://j2ee.masslight.com/
[44]
http://java.oreilly.com
[45]
http://java.sun.com
[46]
http://java.sun.com/apis.html
[47]
http://java.sun.com/blueprints/patterns/catalog.html
[48]
http://java.sun.com/docs/books/
[49]
http://java.sun.com/docs/books/tutorial/jdbc/index.html
[50]
http://java.sun.com/j2ee/
[51]
http://java.sun.com/j2se/1.3/docs/guide/idl/index.html
[52]
http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/index.html
[53]
http://java.sun.com/products/ejb/docs.html
[54]
http://java.sun.com/products/javamail/FAQ.html
[55]
http://java.sun.com/products/javamail/index.html
[56]
http://java.sun.com/products/jdbc/faq.html
[57]
http://java.sun.com/products/jms/faq.html
[58]
http://java.sun.com/products/jms/tutorial/index.html
[59]
http://java.sun.com/products/jndi/faq.html
[60]
http://java.sun.com/products/jndi/tutorial/
[61]
http://java.sun.com/products/jta/index.html
[62]
http://msdn.microsoft.com/
[63]
http://www.borland.com/besappserver/index.html
[64]
http://www.corba.org/
[65]
http://www.dmv.org
[66]
http://www.omg.org
58
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
[67]
http://www.theserverside.com/home/index.jsp
[68]
http://www.wrox.com
59
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
APPENDIX
A.1 Application Flow (screenwise)
A.1.1 Login.jsp
Login Screen
 User submits username and
password
 After check, if user is an
authenticated user then
MainMenu.jsp is the
response
 Else response is Login.jsp
2
A.1.2 MainMenu.jsp
Main Menu Screen
 User chooses one of the
three menu options
Registration
License
Reports
 The response is 3, 4 or 5
respectively
3
4
5
A.1.3 RegMenu.jsp
Registration Menu Screen
 User chooses one of the two
menu options
New Registration
Edit existing
Registration
 The response is RegEdit.jsp
60
6
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.1.4 LicenseMenu.jsp
License Menu Screen
 User chooses one of the two
menu options
New License
Edit existing License
 The response is LicenseEdit.jsp
7
A.1.5 ReportMenu.jsp
Report Menu Screen
 User chooses one of the two menu
options
Pending Registrations
Expired Licenses
 The response is LicenseEdit.jsp
8
A.1.6 RegEdit.jsp
Registration Screen
 User enters all the details for a
registration (if new) or changes
any detail on a registration (if
existing)
 The response is RegMenu.jsp
(with an appropriate message of
success or failure of the operation
performed – insert or update)
3
A.1.7 LicenseEdit.jsp
License Screen
 User enters all the details for a
license (if new) or changes any
detail on a license (if existing)
 The response is LicenseMenu.jsp
(with an appropriate message of
success or faiure of the operation
performed – insert or update)
61
4
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.1.8 RegReport.jsp
Pending Registration Report Screen
A report on pending registrations
appears.
A.1.9 LicenseReport.jsp
Expired Licenses Report Screen
A report on expired licenses
appears.
62
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.2 Package Structure and Classes
Package structure and the classes with their public methods are hereunder. As of now
only the public methods are mentioned.
A.2.1 CommonServices Module
Package : com.uconn.dmv.common.view
Class: CommonView
Method : set and get methods for the common view data like a message on screen
etc.
Package : com.uconn.dmv.common.handler
Class: CommonHandler
Method : some methods required in common by all Handler classes (eg.)
saveObjectInSession() and getObjectFromSession() when we want to store
some objects in session and retrieve them.
Package : com.uconn.dmv.common.util
Class: CommonServices
Method : some methods required in common by all Handler classes (eg.) some date
manipulation methods etc.
A.2.2 Login Module
Package : com.uconn.dmv.login.servlets
Class: LoginServlet
Method : service()
Package : com.uconn.dmv.login.beans
Class: LoginSB, LoginEB
Package : com.uconn.dmv.login.view
Class: LoginView extends CommonView
Method : set and get methods for the data member LoginInfo object
Package : com.uconn.dmv.login.domain
Class: LoginInfo
Method : set and get methods for the username and password data members
Package : com.uconn.dmv.login.handler
Class: LoginHandler extends CommonHandler
Method : processRequest()
JSPs for this module will be Login.jsp and MainMenu.jsp
63
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.2.3 Registration Module
Package : com.uconn.dmv.reg.servlets
Class: RegServlet
Method : service()
Package : com.uconn.dmv.reg.beans
Class: RegSB, RegEB, VehicleEB
Package : com.uconn.dmv.reg.view
Class: RegView extends CommonView
Method : set and get methods for the data member Registration object
Package : com.uconn.dmv.reg.domain
Class: Registration, Vehicle
Method : set and get methods for the data members of each of the classes
Registration Class attributes:
regNo, Vehicle, dateOfIssue, dateOfCancellation, status (pending, active, expired,
cancelled)
Vehicle Class attributes:
vin, make, model, year, color, etc.
Package : com.uconn.dmv.reg.handler
Class: RegHandler extends CommonHandler
Method : processRequest()
createRegistration()
editRegistration()
updateRegistration()
JSPs for this module will be RegMenu.jsp and RegEdit.jsp
A.2.4 License Module
Package : com.uconn.dmv.license.servlets
Class: LicenseServlet
Method : service()
Package : com.uconn.dmv.license.beans
Class: LicenseSB, LicenseEB, PersonEB
Package : com.uconn.dmv.license.view
Class: LicenseView extends CommonView
Method : set and get methods for the data member License object
64
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Package : com.uconn.dmv.license.domain
Class: License, Person
Method : set and get methods for the data members of each of the classes
License Class attributes:
licenseNo, Person, dateOfIssue, validity, status (valid, invalid), pointsAccured
Person Class attributes:
ssn, lname, fname, mname, dob, address, phone
Package : com.uconn.dmv.license.handler
Class: LicenseHandler extends CommonHandler
Method : processRequest()
createLicense()
editLicense()
updateLicense()
JSPs for this module will be LicenseMenu.jsp and LicenseEdit.jsp
A.2.5 Reports Module
Package : com.uconn.dmv.reports.servlets
Class: ReportServlet
Method : service()
Package : com.uconn.dmv.reports.beans
Class: ReportSB
Package : com.uconn.dmv.reg.view
Class: ReportView extends CommonView
Method : set and get methods for the ArrayList - reportList (of Registration or
License objects)
Package : com.uconn.dmv.reports.dao
Class: ReportDAO
Method : data access methods to retrieve registrations or licenses for the reports
with the respective user criteria
Package : com.uconn.dmv.reports.handler
Class: ReportHandler extends CommonHandler
Method : processRequest()
getRegistrationReport()
getLicenseReport()
JSPs for this module will be RegReport.jsp and LicenseReport.jsp
65
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.3 Prototype Figures
Figures A.3.1, A.3.2, and A.3.3 formally illustrate the application as a finite
state automaton where Prototype Figure A.3.1 is a legend for the states at the
level of the Java Server Pages:
1:Login.jsp
3:RegMenu.jsp
5:ReportMenu.jsp
7:LicenseEdit.jsp
9:LicenseReport.jsp
2:MainMenu.jsp
4:LicenseMenu.jsp
6:RegEdit.jsp
8:RegReport.jsp
10:Farewell.jsp
A.3.1: DMVApp Automaton node label key
Figure A.3.2 is the automaton at the level of the Java Server Pages:
A.3.2: DMVApp Automaton
1
2
3
6
10
4
7
5
8
9
66
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
Figure A.3.3 is the related transition table describing the user interface
events generating the actions. This transition table encompasses how rejected
user input and query failure are to be handled by exceptions in a graceful
fashion.
A.3.3: DMVApp Automaton table
State
1
1
1
2
2
2
2
3
3
3
4
4
4
5
5
5
6
6
7
7
8
9
Event
failed login
successful login
exit
logout
registration
license
reports
main menu
edit/query failed
new or edit/query successful
main menu
edit/query failed
new or edit/query successful
main menu
pending registrations
expired licenses
submit
UI validation or query failed
submit
UI validation or query failed
dismiss
dismiss
Next State
1
2
10
1
3
4
5
2
3
6
2
4
7
2
8
9
3
6
4
7
5
5
Figures A.3.4 and A.3.5 depict the data model of the application and a list
of the queries executed respectively. Figure A.3.5 specifies 9 queries that the
system will implement, the type of query, the state of the automaton in which this
occurs, and the tables involved in the query.
67
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.3.4: DMVApp Data model
A.3.5: DMVApp queries: type, state, and tables involved
Query #
1.
2.
3.
4.
5.
6.
7.
8.
9.
I
S
x
x
U
x
x
x
x
x
x
x
D
state
1
3
6
6
4
7
7
5
5
68
tables
user
registration, vehicle
registration
registration
license, person
license
license
registration, vehicle
license, person
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4 UML Diagrams
A.4.1 Component Diagram
69
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.2 Use-Case Diagram
70
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.3 Deployment Diagram
71
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.4 Class Diagram
72
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.4 Sequence Diagram – 1
73
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.4 Sequence Diagram – 2
74
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.4.5 DMVEJBModule
75
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5
PROTOTYPE SCREEN SHOTS
A.5.1 LOGIN SCREEN
76
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.2 MAIN MENU
77
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.3 REGISTRATION MENU
78
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.4 REGISTRATION SCREEN
79
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.5 LICENSE MENU
80
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.6 LICENSE SCREEN
81
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.7 REPORT MENU
82
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.8 PENDING REGISTRATIONS REPORT
83
J2EE - Enterprise Development and Interoperability With Non-J2EE Clients
A.5.9 NON-JAVA CLIENT (C++ APPLICATION) ACCESSING EJB IN THE DMV APPLICATION
84