figure 3.1.2.a n-tier architecture (three-tier application

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..........................................................................83.1.1 Software Components....................................................................................................................93.1.2 Server-side Components................................................................................................................9

Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture)..........................................................113.1.3 Server-side Component Architecture Solutions...........................................................................14

Figure 3.1.3.a The .Net Server-side Architecture..............................................................................................15Figure 3.1.3.b The J2EE Server-side Architecture............................................................................................15Table 3.1.3.c A comparison of J2EE vs Microsoft .NET..................................................................................16

3.2 J2EE PLATFORM OVERVIEW................................................................................................................18Figure 3.2.a: J2EE Environment..........................................................................................................18Figure 3.2.b: J2EE Components and Containers.................................................................................19Figure 3.2.c: The J2EE Technology Suite............................................................................................203.2.1 Java Servlet Technology..............................................................................................................213.2.2 JavaServer Pages.........................................................................................................................223.2.3 Enterprise JavaBean Components...............................................................................................23

3.2.3.1 Session Beans........................................................................................................................................243.2.3.2 Entity Beans...........................................................................................................................................243.2.3.3 Message-Driven Beans..........................................................................................................................25

3.2.4 J2EE Standardized Services........................................................................................................253.2.4.1 Communications Services.....................................................................................................................263.2.4.2 Enterprise Services................................................................................................................................283.2.4.3 Internet Services....................................................................................................................................29

3.3 EJB/CORBA INTEROPERABILITY.................................................................................................303.3.1 CORBA OVERVIEW..............................................................................................................................30Fig 3.3.1.a CORBA Architecture......................................................................................................................32

3.3.2 RMI-IIOP.....................................................................................................................................33Fig 3.3.2.a RMI client - CORBA server............................................................................................................34Fig 3.3.2.b CORBA client - RMI server............................................................................................................35Table 3.3.2.c Possible combinations in RMI-IIOP............................................................................................37

3.3.3 ADVANTAGES OF EJB-CORBA INTEROPERABILITY............................................................373.3.4 INTEROPERABILITY SCENARIOS............................................................................................37

Fig 3.3.4.a CORBA client - EJB server.............................................................................................................383.4 APPLICATION OF PATTERNS........................................................................................................39

3.4.1 Pattern Functionality...................................................................................................................40Figure 3.4.1.1: Presentation Tier Patterns.........................................................................................................41Figure 3.4.1.2: Business Tier Patterns...............................................................................................................42Figure 3.4.1.3: Integration Tier Patterns............................................................................................................42Figure 3.4.1.4: J2EE Pattern Relationships.......................................................................................................43Figure 3.4.1.5: J2EE Patterns Framework.........................................................................................................44

3.4.2 Uses of Patterns in the DMVApp.................................................................................................453.4.2.1 Front Controller.....................................................................................................................................453.4.2.2 View Helper...........................................................................................................................................453.4.2.3 Session Façade.......................................................................................................................................453.4.2.4 Transfer Object......................................................................................................................................46

2


3.4.2.5 Transfer Object Assembler....................................................................................................................463.4.2.6 Data Access Object................................................................................................................................47

4. THE MOTOR VEHICLES DEPARTMENT PROTOTYPE..............................................................47

4.1 LOGIN...................................................................................................................................................484.2 MANAGE REGISTRATION/LICENSE.......................................................................................................484.3 REPORTS...............................................................................................................................................494.4 ACCESS TO NON-JAVA CLIENTS (EJB / CORBA INTEROPERABILITY)................................................494.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.......................................................................................................................525.1.1 Individual overseeing document submitted..................................................................................525.1.2 Individuals collaborating on specific topic research...................................................................535.1.3 Individual responsible for writing specific sections of report.....................................................535.1.4 Individual responsible for module implementation.....................................................................53

5.2 OBSERVED EXTENSIBILITY...................................................................................................................535.3 TEAM EXPERIENCE...............................................................................................................................54

REFERENCES.............................................................................................................................................56

BOOKS........................................................................................................................................................56INTERNET...................................................................................................................................................58

APPENDIX...................................................................................................................................................60

A.1 APPLICATION FLOW (SCREENWISE).....................................................................................................60A.1.1 Login.jsp......................................................................................................................................60A.1.2 MainMenu.jsp..............................................................................................................................60A.1.3 RegMenu.jsp................................................................................................................................60A.1.4 LicenseMenu.jsp..........................................................................................................................61A.1.5 ReportMenu.jsp...........................................................................................................................61A.1.6 RegEdit.jsp...................................................................................................................................61A.1.7 LicenseEdit.jsp.............................................................................................................................61A.1.8 RegReport.jsp..............................................................................................................................62A.1.9 LicenseReport.jsp........................................................................................................................62

A.2 PACKAGE STRUCTURE AND CLASSES..................................................................................................63A.2.1 CommonServices Module............................................................................................................63A.2.2 Login Module...............................................................................................................................63A.2.3 Registration Module....................................................................................................................64A.2.4 License Module............................................................................................................................64A.2.5 Reports Module...........................................................................................................................65

A.3 PROTOTYPE FIGURES...........................................................................................................................66A.3.1: DMVApp Automaton node label key..........................................................................................66A.3.2: DMVApp Automaton..................................................................................................................66A.3.3: DMVApp Automaton table.........................................................................................................67A.3.4: DMVApp Data model.................................................................................................................68A.3.5: DMVApp queries: type, state, and tables involved....................................................................68

A.4 UML DIAGRAMS.................................................................................................................................69A.4.1 Component Diagram...................................................................................................................69A.4.2 Use-Case Diagram......................................................................................................................70A.4.3 Deployment Diagram..................................................................................................................71A.4.4 Class Diagram...........................................................................................................................72A.4.4 Sequence Diagram – 1.................................................................................................................73A.4.4 Sequence Diagram – 2.................................................................................................................74A.4.5 DMVEJBModule..........................................................................................................................75

A.5 PROTOTYPE SCREEN SHOTS......................................................................................................76

3


A.5.1 Login Screen...............................................................................................................................76A.5.2 Main Menu..................................................................................................................................77A.5.3 Registration Menu......................................................................................................................78A.5.4 Registration Screen....................................................................................................................79A.5.5 License Menu..............................................................................................................................80A.5.6 License Screen............................................................................................................................81A.5.7 Report Menu...............................................................................................................................82A.5.8 Pending Registrations Report.....................................................................................................83A.5.9 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 ....................................................................................................................... 42 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


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] and 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, object-

oriented, 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


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. Additional

6


references further reinforce the necessary skills for this ever growing and

evolving language[11,12,23]. Like other corporate entities, Sun produces a

comprehensive set of technical 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 fault-

tolerant 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


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


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 well-

written 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


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


Firewall + Tier boundary

Tier boundary

Figure 3.1.2.a N-Tier Architecture (Three-tier application architecture)

11

Presentation layer

Business logicLayer

Data layer

WEB SERVER

APPLICATION SERVERWITH COMPONENT

CONTAINER

Database

Secure zone

Insecure


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


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


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


Figure 3.1.3.a The .Net Server-side Architecture

Figure 3.1.3.b The J2EE Server-side Architecture

15

Java Client Application Business System Web Client

Container

Servlets and JSPs

EJBs

Connectors

Legacy Systems or Databases or Other Business Systems

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


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


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 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 client-

side support for developing enterprise, multi-tier applications.

Figure 3.2.a: J2EE Environment

18


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

Figure 3.2.c: The J2EE Technology Suite

20

RMI (Communication)Simple Distributed Communications APIRMI-IIOP adds CORBA interoperability

J2SE (Core service)- Core Java platform language and services such as io, util, applets, and JFC

EJB (Core service)Component StandardDefines the overall server-side architecture

JNDI (Enterprise)- Provides a namespace for finding components and resources

JDBC (Enterprise)- Provides unified API for accessing relational databases

JavaMail (Communication)- Allows E-mail operations in a cross-platform, cross-protocol fashion

Servlets and JSPs (Core service)- Request/ Response oriented network components- Used in web server for client-side interaction

Java IDL (Communication)- CORBA provides language interoperability- Integration with existing systems

XML (Internet)- Describes EJB components- Format for JSP scripts

JMS (Communication)- Asynchronous invocations- Publish/ subscribe or Point-to-point- Transactional messages

JTA / JTS (Enterprise)- JTA defines the high-level interface for demarcating transactional boundaries- JTS defines the low-level interfaces between transaction participants

JCA (Enterprise)- Provides access to EIS


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. The servlet

receives this request object. Once the servlet has processed the input

parameters it may return a response object. During this process, the servlet may

21


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 JavaBeans to generate dynamic content or perform

computations. 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


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 multi-

user 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 client-

neutral 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


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


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


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


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. Programming with this API permits

27


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


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


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 CORBA-

compliant products that implement the CORBA specification available in the

market are Borland’s VisiBroker and Iona’s Orbix.

30


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 cross-

language 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

CLIENT

CORBA Stub

ORB ORB

CORBA Skeleton

CORBA Object Implementation


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:

CORBA Object Interface

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.

The CCM specification has been formulated with an intention that CORBA

components and EJBs can reside together, thus making it possible that

32


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

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.

33

RMI CLIENT

RMI Stub

ORB ORB

CORBA Skeleton

CORBA Object Implementation

CORBA CLIENT RMI Object Implementation


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 Remote Object Interface

Network via IIOP

Fig 3.3.2.a RMI client - CORBA server

34

CORBA Stub

ORB ORB

RMI Skeleton


CORBA Object Interface

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

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

35


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 could be accessed by non-Java Clients, thus

relieving the EJBs of the constraint that they could be only Java based.

CLIENT SERVERRMI client with RMI-IIOP Stub RMI Server with RMI-IIOP skeletonRMI client with RMI-IIOP Stub CORBA object implementationCORBA client RMI Server with RMI-IIOP skeletonCORBA client CORBA object implementation

36

CORBA CLIENT EJB 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

exposes one of its EJB (TrafficViolationSB – a session bean) to a non-

Java application (C++ client application).

Fig. 3.3.4.a shows the interoperability scenario of a CORBA client with an EJB

server.

37

CORBA Stub

ORB ORB

RMI-IIOP Skeleton


EJB Remote Interface

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.

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;

38


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

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.

39


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


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 sub-components

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

http://developer.java.sun.com/developer/restricted/patterns/DispatcherView.html

http://developer.java.sun.com/developer/restricted/patterns/DispatcherView.html

http://developer.java.sun.com/developer/restricted/patterns/ServiceToWorker.html

http://developer.java.sun.com/developer/restricted/patterns/ServiceToWorker.html

http://developer.java.sun.com/developer/restricted/patterns/CompositeView.html

http://developer.java.sun.com/developer/restricted/patterns/CompositeView.html

http://developer.java.sun.com/developer/restricted/patterns/ViewHelper.html

http://developer.java.sun.com/developer/restricted/patterns/FrontController.html

http://developer.java.sun.com/developer/restricted/patterns/FrontController.html

http://developer.java.sun.com/developer/restricted/patterns/DecoratingFilter.html

http://developer.java.sun.com/developer/restricted/patterns/DecoratingFilter.html


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 coarse-grained 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.

Figure 3.4.1.4: J2EE Pattern Relationships

42

http://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.html

http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject.html

http://developer.java.sun.com/developer/restricted/patterns/DataAccessObject.html

http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html

http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.html

http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.html

http://developer.java.sun.com/developer/restricted/patterns/ValueObjectAssembler.html

http://developer.java.sun.com/developer/restricted/patterns/ValueObjectAssembler.html

http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html

http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html

http://developer.java.sun.com/developer/restricted/patterns/SessionFacade.html

http://developer.java.sun.com/developer/restricted/patterns/ValueObject.html

http://developer.java.sun.com/developer/restricted/patterns/BusinessDelegate.html

http://developer.java.sun.com/developer/restricted/patterns/BusinessDelegate.html


43


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


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


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 coarse-grained 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


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


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


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).

Fig. 4.1 MVC Architecture in the DMV Prototype

The J2EE design patterns used in the application are:

49

CONTROLLERCONTROLLER(SERVLET & HANDLER)(SERVLET & HANDLER)

MODELMODEL(EJBs & Domain classes)(EJBs & Domain classes)

VIEWVIEW(JSPs & VIEW HELPER)(JSPs & VIEW HELPER)


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


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


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. Individual overseeing document submitted2. Individuals collaborating on specific topic research3. Individual responsible for writing specific sections of report4. Individual responsible for module implementation

5.1.1 Individual overseeing document submitted

Semester Project Requirements and Specification Sudha Mid-Semester Project Report Betsy Final Project Report Lance Final Presentation Sudha

52


5.1.2 Individuals collaborating on specific topic research

Primary contributor in bold:

Server-side Component Architectures SudhaThe J2EE Technologies Lance, Betsy and SudhaEJB/CORBA Interoperability and Exposing EJB to non-Java Clients

Sudha and Lance

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 Sudha3.2 J2EE Platform Overview Lance3.3 EJB/CORBA Sudha3.4 Applications of Patterns Betsy4. The Motor Vehicles Department Prototype

Sudha

A.1 Application Flow (Screenwise) SudhaA.2 Package structure and classes SudhaA.3 Prototype figures LanceA.4 UML diagrams SudhaA.5 Prototype screenshots 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


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. The technical background of each

individual was different. There were several problems encountered when

attempting to utilize enterprise tools that not all members were familiar with. This

54


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


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, Addison-Wesley, 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


[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 2 nd 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, Addison-Wesley, 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


[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

http://www.omg.org/

http://www.dmv.org/

http://www.corba.org/

http://www.borland.com/besappserver/index.html

http://msdn.microsoft.com/

http://java.sun.com/products/jta/index.html

http://java.sun.com/products/jndi/tutorial/

http://java.sun.com/products/jndi/faq.html

http://java.sun.com/products/jms/tutorial/index.html

http://java.sun.com/products/jms/faq.html

http://java.sun.com/products/jdbc/faq.html

http://java.sun.com/products/javamail/index.html

http://java.sun.com/products/javamail/FAQ.html

http://java.sun.com/products/ejb/docs.html

http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/index.html

http://java.sun.com/j2se/1.3/docs/guide/idl/index.html

http://java.sun.com/j2ee/

http://java.sun.com/docs/books/tutorial/jdbc/index.html

http://java.sun.com/docs/books/

http://java.sun.com/blueprints/patterns/catalog.html

http://java.sun.com/apis.html

http://java.sun.com/

http://java.oreilly.com/

http://j2ee.masslight.com/

http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/


[67] http://www.theserverside.com/home/index.jsp

[68] http://www.wrox.com

59

http://www.wrox.com/

http://www.theserverside.com/home/index.jsp


APPENDIX

A.1 Application Flow (screenwise)

A.1.1 Login.jsp

A.1.2 MainMenu.jsp

A.1.3 RegMenu.jsp

60

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

Main Menu Screen User chooses one of the

three menu optionsRegistrationLicenseReports

The response is 3, 4 or 5 respectively

4

3

5

Registration Menu Screen User chooses one of the two

menu optionsNew RegistrationEdit existing Registration

The response is RegEdit.jsp

6


A.1.4 LicenseMenu.jsp

A.1.5 ReportMenu.jsp

A.1.6 RegEdit.jsp

A.1.7 LicenseEdit.jsp

61

License Menu Screen User chooses one of the two menu

optionsNew LicenseEdit existing License

The response is LicenseEdit.jsp

7

Report Menu Screen User chooses one of the two menu

optionsPending RegistrationsExpired Licenses

The response is LicenseEdit.jsp

8

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

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)

4


A.1.8 RegReport.jsp

A.1.9 LicenseReport.jsp

62

Pending Registration Report Screen

A report on pending registrations appears.

Expired Licenses Report Screen

A report on expired licenses appears.


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.viewClass: CommonViewMethod : set and get methods for the common view data like a message on screen

etc.

Package : com.uconn.dmv.common.handlerClass: CommonHandlerMethod : 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.utilClass: CommonServicesMethod : 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.servletsClass: LoginServletMethod : service()

Package : com.uconn.dmv.login.beansClass: LoginSB, LoginEB

Package : com.uconn.dmv.login.viewClass: LoginView extends CommonViewMethod : set and get methods for the data member LoginInfo object

Package : com.uconn.dmv.login.domainClass: LoginInfoMethod : set and get methods for the username and password data members

Package : com.uconn.dmv.login.handlerClass: LoginHandler extends CommonHandlerMethod : processRequest()

JSPs for this module will be Login.jsp and MainMenu.jsp

63


A.2.3 Registration Module

Package : com.uconn.dmv.reg.servletsClass: RegServletMethod : service()

Package : com.uconn.dmv.reg.beansClass: RegSB, RegEB, VehicleEB

Package : com.uconn.dmv.reg.viewClass: RegView extends CommonViewMethod : set and get methods for the data member Registration object

Package : com.uconn.dmv.reg.domainClass: Registration, VehicleMethod : 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.handlerClass: RegHandler extends CommonHandlerMethod : 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.servletsClass: LicenseServletMethod : service()

Package : com.uconn.dmv.license.beansClass: LicenseSB, LicenseEB, PersonEB

Package : com.uconn.dmv.license.viewClass: LicenseView extends CommonViewMethod : set and get methods for the data member License object

64


Package : com.uconn.dmv.license.domainClass: License, PersonMethod : 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.handlerClass: LicenseHandler extends CommonHandlerMethod : 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.servletsClass: ReportServletMethod : service()

Package : com.uconn.dmv.reports.beansClass: ReportSB

Package : com.uconn.dmv.reg.viewClass: ReportView extends CommonViewMethod : set and get methods for the ArrayList - reportList (of Registration or

License objects)

Package : com.uconn.dmv.reports.daoClass: ReportDAOMethod : data access methods to retrieve registrations or licenses for the reports

with the respective user criteria

Package : com.uconn.dmv.reports.handlerClass: ReportHandler extends CommonHandlerMethod : processRequest()

getRegistrationReport()getLicenseReport()

JSPs for this module will be RegReport.jsp and LicenseReport.jsp

65


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 2:MainMenu.jsp3:RegMenu.jsp 4:LicenseMenu.jsp5:ReportMenu.jsp 6:RegEdit.jsp7:LicenseEdit.jsp 8:RegReport.jsp9:LicenseReport.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

66

10

9

85

74

6321


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 Event Next State1 failed login 11 successful login 21 exit 102 logout 12 registration 32 license 42 reports 53 main menu 23 edit/query failed 33 new or edit/query successful 64 main menu 24 edit/query failed 44 new or edit/query successful 75 main menu 25 pending registrations 85 expired licenses 96 submit 36 UI validation or query failed 67 submit 47 UI validation or query failed 78 dismiss 59 dismiss 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


A.3.4: DMVApp Data model

A.3.5: DMVApp queries: type, state, and tables involved

Query # I S U D state tables1. x 1 user2. x 3 registration, vehicle3. x 6 registration4. x 6 registration5. x 4 license, person6. x 7 license7. x 7 license8. x 5 registration, vehicle9. x 5 license, person

68


A.4 UML Diagrams

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

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