Docstoc

PROJECT NO -() STATE DOTS AND e-BUSINESS CONCEPTUAL DESIGN FOR AN e-TRANSACTION SYSTEMPDF

Document Sample
PROJECT NO -() STATE DOTS AND e-BUSINESS CONCEPTUAL DESIGN FOR AN e-TRANSACTION SYSTEMPDF Powered By Docstoc
					PROJECT NO. 20-24(19)



                        STATE DOTS AND e-BUSINESS


          CONCEPTUAL DESIGN FOR AN e-TRANSACTION SYSTEM

                          (TASK 3 FINAL REPORT)




                                Prepared for

              National Cooperative Highway Research Program
                       Transportation Research Board
                         National Research Council




                          Booz Allen Hamilton Inc.
                             McLean, Virginia


                              September 2004
                     ACKNOWLEDGMENT OF SPONSORSHIP

      This work was sponsored by the American Association of State Highway and
Transportation Officials, in cooperation with the Federal Highway Administration, and
was conducted in the National Cooperative Highway Research Program, which is
administered by the Transportation Research Board of the National Research Council.


                                     DISCLAIMER

       This is an uncorrected draft as submitted by the research agency. The opinions
and conclusions expressed or implied in the report are those of the research agency.
They are not necessarily those of the Transportation Research Board, the National
Research Council, the Federal Highway Administration, the American Association of
State Highway and Transportation Officials, or the individual states participating in the
National Cooperative Highway Research Program.
NCHRP Project No. 20-24(19)                                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business




                                                       Table of Contents

1   Introduction.......................................................................................................................... 1-1
    1.1      Document Purpose ....................................................................................................... 1-1
    1.2      Research Background .................................................................................................. 1-1
             1.2.1 Objectives.......................................................................................................... 1-1
             1.2.2 Approach........................................................................................................... 1-2
    1.3      Purpose of the Conceptual Design............................................................................... 1-3
    1.4      Summary of the Conceptual Design Decision ............................................................. 1-4
    1.5      Contents of Document ................................................................................................. 1-5
2   J2EE Platform technology .................................................................................................. 2-1
    2.1      J2EE Platform Overview ............................................................................................. 2-1
    2.2      Model-View-Controller Architecture .......................................................................... 2-3
    2.3      J2EE Platform Benefits................................................................................................ 2-4
3   Design of the e-transaction system ..................................................................................... 3-1
    3.1      Business Processes and Work Flows ........................................................................... 3-1
    3.2      Roles and Responsibilities ........................................................................................... 3-2
    3.3      UML Models................................................................................................................ 3-3
             3.3.1 Use Case Diagram............................................................................................ 3-3
             3.3.2 Class Diagram .................................................................................................. 3-4
             3.3.3 Statechart Diagram........................................................................................... 3-4
4   The Architecture of the e-transaction system ................................................................... 4-1
    4.1      Basic Architecture Consideration ................................................................................ 4-1
             4.1.1 Application Tiers............................................................................................... 4-1
             4.1.2 Distributed Architecture ................................................................................... 4-1
    4.2      Architecture Overview................................................................................................. 4-2
    4.3      Application Web Site Architecture.............................................................................. 4-3
             4.3.1 Functional Modules .......................................................................................... 4-4
             4.3.2 View Layer ........................................................................................................ 4-6
             4.3.3 Model Layer ...................................................................................................... 4-7
             4.3.4 Controller Layer ............................................................................................... 4-8
    4.4      Process Workflow Architecture................................................................................... 4-8
             4.4.1 Overview of the Application Process Center Workflow ................................... 4-9
             4.4.2 Implementation Considerations ...................................................................... 4-10
5   Integration with Enterprise Portals ................................................................................... 5-1
    5.1      Enterprise Portal Concept ............................................................................................ 5-1
    5.2      Integration at the Presentation Tier.............................................................................. 5-2
    5.3      Integration at the Application Tier............................................................................... 5-5
    5.4      Integration at the Data Service Tier ............................................................................. 5-6


Booz Allen Hamilton Inc.                                             i                                                    September 2004
NCHRP Project No. 20-24(19)                                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business


6   Financial Transactions ........................................................................................................ 6-1
    6.1      Overview of the Current Financial Transactions ......................................................... 6-1
    6.2      Design Approach in the e-Transaction System............................................................ 6-3
    6.3      Credit Card Processing Architecture ........................................................................... 6-5
             6.3.1 Authorization..................................................................................................... 6-5
             6.3.2 Settlement.......................................................................................................... 6-6
             6.3.3 Implementation Approaches ............................................................................. 6-7
    6.4      PayPal Processing Architecture ................................................................................... 6-8
             6.4.1 Overview of the PayPal Payment Process........................................................ 6-9
             6.4.2 Using PayPal Buy Now Button ......................................................................... 6-9
             6.4.3 Using PayPal Instant Payment Notification ................................................... 6-10
             6.4.4 Using PayPal Web Service ............................................................................. 6-11
7   The Prototype ....................................................................................................................... 7-1
    7.1      Prototype Overview ..................................................................................................... 7-1
    7.2      Open Source Tools....................................................................................................... 7-2
    7.3      Installing the Prototype ................................................................................................ 7-3
    7.4      Using the Prototype...................................................................................................... 7-3
    7.5      Screens Shots ............................................................................................................... 7-4




Booz Allen Hamilton Inc.                                             ii                                                   September 2004
NCHRP Project No. 20-24(19)                                                  Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business


                                                            List of Figures

Figure 1-1. Research Tasks and Sequences..........................................................................................1-3
Figure 2-1. J2EE Environment ...............................................................................................................2-2
Figure 2-2. The Model-View-Controller Architecture .......................................................................2-4
Figure 3-1. Overview of Processes and Work Flows..........................................................................3-2
Figure 3-2. Use Case Diagram ...............................................................................................................3-5
Figure 3-3. Class Diagram......................................................................................................................3-6
Figure 3-4. Statechart Diagram..............................................................................................................3-6
Figure 4-1. Distribution Architecture of the e-Transaction System ................................................4-2
Figure 4-2. Architecture of the e-Transaction System........................................................................4-3
Figure 4-3. Functional Modules of the e-Transaction System...........................................................4-5
Figure 4-4. Model-View-Controller Architecture for the e-Transaction System............................4-6
Figure 4-5. An Example of Page Layout for the e-Transaction System...........................................4-7
Figure 4-6. Application Process Center Workflow Architecture......................................................4-9
Figure 5-1. An Overview of an Enterprise Portal ...............................................................................5-2
Figure 5-2. An Example of Page Layout for an Enterprise Portal ....................................................5-3
Figure 5-3. An Enterprise Portal Interface to the e-transaction System ..........................................5-4
Figure 5-4. Application of Portlets in an Enterprise Portal ...............................................................5-4
Figure 5-5. Approaches of Enterprise Information System Integration ..........................................5-6
Figure 6-1. Use Cases of Financial Transactions in the e-Transaction System ...............................6-4
Figure 6-2. Credit Authorization Process ............................................................................................6-5
Figure 6-3. Credit Settlement Process...................................................................................................6-6
Figure 6-4. Credit Card Processing—Using the State’s FMS as a Gateway....................................6-7
Figure 6-5. Credit Card Processing—Incorporating the Third-Party Software .............................6-8
Figure 6-6. Credit Card Processing—Using the Third-Party Host Service.....................................6-8
Figure 6-7. Overview of Payment Flow Using PayPal Buy Now Button........................................6-9
Figure 6-8. Integrating with the PayPal Instant Payment Notification .........................................6-11
Figure 6-9. Architecture of Integrating with PayPal Web Service .................................................6-12
Figure 7-1. Overview of the e-Transaction Prototype........................................................................7-2




                                                             List of Tables

Table 6-1. Overview of Payment Methods Used in DOT Environment..........................................6-3
Table 7-1. Open Source Tools Used in Prototype ...............................................................................7-2




Booz Allen Hamilton Inc.                                               iii                                                    September 2004
NCHRP Project No. 20-24(19)                           Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business



                                       Acknowledgement
The research reported herein was preformed under NCHRP Project 20-24(19) by Booz Allen Hamilton
Inc. Booz Allen Hamilton Inc. was the contractor for this study. Dr. Zongwei Tao was the principal
investigator. The other team members include Edward Dangerfield, John Wiegmann, Rajesh Badam, Ravi
Nagarajan, and Pete Luongo.

The work was done under the guidance of the NCHRP Project 20-24(19) panel which consists of the
following members:

Mr. Chuck Baird                                       Mr. Charles "Chuck" Bristow
Michigan DOT                                          Chief Information Officer
Dept. of Information Technology                       Maryland DOT
425 West Ottawa Street, PO Box 30050                  Box 548, 7201 Corporate Center Drive
Lansing, MI 48909                                     Hanover, MD 21076
Phone: (517) 335-2404                                 Phone: (410) 865-1040
Email: Bairdc@michigan.gov                            Email: cbristow@mdot.state.md.us

Mr. Steven C. Brown, P.E.                             Ms. Jan Edwards
Applications Development Manager                      Project Director
Nebraska DOR                                          AASHTO
1500 NE Highway 2, PO Box 94759                       444 North Capitol Street, Suite 249
Lincoln, NE 68509                                     Washington, DC 20001
Phone: (402) 479-3966                                 Phone: (202) 624-5800
Email: sbrown@dor.state.ne.us                         Email: jedwards@aashto.org

Ms. Paula Ewen                                        Mr. N. Ben Nelson
Federal Highway Administration                        Chief of Computer Services
400 Seventh Street, SW                                Kansas DOT
HAIM-1, Room 4423                                     Docking State Office Bldg, 915 Harrison
Washington, DC 20590                                  Topeka, KS 66612-1568
Phone: (202) 493-3175                                 Phone: (785) 296-0310
E-mail: paula.ewen@fhwa.dot.gov                       Email: Ben@ksdot.org

Mr. Craig Stender                                     Mr. Jeff Western
13330 W Edgemont Avenue                               Deputy Director
Goodyear, AZ 85338                                    Wisconsin DOT
Phone: (602) 217-2833                                 4802 Sheboygan Avenue, PO Box 7910
Email: cstender@us.ibm.com                            Madison, WI
                                                      Phone: (608) 264-8712
                                                      Email: jeffery.western@dot.state.wi.us

Mr. Thomas Palmerlee                                  Mr. Ray Derr
TRB Liaison                                           NCHRP Project Manager
Senior Program Officer                                Transportation Research Board
Transportation Research Board                         500 Fifth Street NW, 4th Floor
500 Fifth Street NW, 4th Floor                        Washington, DC 20001-2721
Washington, DC 20001-2721                             Phone: (202) 334-3231
Phone: (202) 334-2907                                 Email: rderr@nas.edu
Email: tpalmerlee@nas.edu



Booz Allen Hamilton Inc.                         iv                                          September 2004
NCHRP Project No. 20-24(19)                      Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                1. Introduction


1     INTRODUCTION

1.1     Document Purpose

This document presents the conceptual design of an e-transaction system as a product
from the National Cooperative Highway Research Program (NCHRP) project 20-
24(19) “State DOT and e-Business.” The e-transaction system addresses common
transactional processes and workflow issues from many e-businesses, i.e., application
filing from customers, Department of Transportation (DOT) staff review, and financial
transactions. This design document describes the architecture and design principles
employed in building the e-transaction system and explores the specific approach to
addressing critical technical issues. In particular, it addresses how such a system can be
implemented under an enterprise portal architecture. For purposes of illustration, the
conceptual design uses the permit application process as an example.

A prototype was also developed to illustrate this conceptual design. It used J2EE design
patterns and open sources software. This document describes this prototype in detail
and provides instructions on how to install and configure the prototype.

It is recommended that readers relate this design document with the prototype to
comprehend the entire conceptual design. This document together with the prototype
of the e-transaction system constitutes the deliverable for Task 3 “Develop Conceptual
Design” of the NCHRP project.

1.2     Research Background

1.2.1    Objectives

The first wave of e-business focused largely on Internet presence—merely having a
functioning Web site. In the 21st century, e-business has evolved to place a greater focus
on “customer” and “value.” Today, e-business represents a complex fusion of business
processes, enterprise applications, and organizational structures to create high-
performance business models. It is essentially redefining the old business model, with
the aid of technology, to maximize customer value and benefits.

The focus of e-business on “customer” and “value” has radically impacted and brought
new perspectives on how state DOTs assess their e-business opportunities, design e-
business application architectures, and implement e-business applications. The concept
of a “customer” in a state DOT e-business is broadly defined as essentially anyone who
uses the results of what the agency does. “Value” in government e-business also has
special meanings; it is described and measured by how much benefit an e-business
system provides to external customers and savings to internal customers.




Booz Allen Hamilton Inc.                   1-1                                          September 2004
NCHRP Project No. 20-24(19)                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                 1. Introduction


While many e-business applications are currently implemented in state DOTs, some
have either not delivered the anticipated values to external and internal customers or
have imposed great risk to organizations. Senior managers are challenged with two key
questions:

•   Why are some state DOTs successful at e-business while others struggle? What are
    the successful agencies doing differently to solve customer problems?

•   How are successful e-business applications moving from traditional applications to
    the new breed of Internet-based application architectures? Is there a successful
    architecture design pattern that can be followed?

The objective of this NCHPR project is to provide research results to answer these two
questions. To answer the first question, the Task 2 best practice report describes how
best practices of e-business applications successfully fit into their DOT business models.
To address the second question, the conceptual design for a common e-business
application provides a design patterned after the JAVA Enterprise Blueprints that can
be applied repeatedly by similar e-business applications within a state DOT context.

1.2.2   Approach

The research effort was divided into four major tasks:

•   Task 1—Conduct survey of e-business applications in state DOTs. The objective of
    this task is to determine what e-business applications are currently in use by state
    DOTs.

•   Task 2—Compile survey results and develop best practices. The objective of this task
    is to identify responses from the survey that represent best practices and develop
    concise descriptions of each e-business application.

•   Task 3—Develop a conceptual design. The objective of this task is to develop a
    patterned conceptual design for one selected e-business application and
    demonstrate how it could be effectively implemented by state DOTs to save costs
    and minimize risks.

•   Task 4—Consolidate project results. The objective of this task is to consolidate the
    results from Task 2 and Task 3 into a report that is suitable for a chief executive
    audience.

Figure 1-1 illustrates key steps and sequences that were followed to accomplish the
project objectives.



Booz Allen Hamilton Inc.                    1-2                                          September 2004
NCHRP Project No. 20-24(19)                                                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                                                  1. Introduction




                          Def ine E-Business                                      Identify                             Describe
                          Ev aluation Criteria                                 Best Practices                        Best Practices




      Kick-off                                    Prepare and                                           NCHRP                               Consolidate
      Project                                    Conduct Surv ey                                        Rev iew                               Results




                                Def ine                                                                                Perf orm
                                                                               Select Design
                            Best Practice                                                                             Conceptual
                                                                                 Candidate
                          Ev aluation Method                                                                            Design




                 Task 1 Activ ities                     Task 2 Activ ities                      Task 3 Activ ities                 Task 4 Activ ities




                                            Figure 1-1. Research Tasks and Sequences


1.3     Purpose of the Conceptual Design

Task 3, Performing a Conceptual Design, was an effort parallel to Task 2, Identify and
Describe Best Practices. Task 2 focused on describing business models, technology
impacts, implementation strategies, and other areas for individual best practice cases.
Task 3 focused on providing a “best practice” technology solution through a conceptual
design. Specifically, such a conceptual design should provide value to state DOTs by
doing the following:

•     Demonstrating the best practices of applying and implementing certain technologies
      that are commonly used or emerging in transportation-related e-business
      applications. Such best practices would help state DOTs save resources and
      minimize implementation risks.

•     Supporting one of the state DOTs’ common near-term priorities in designing and
      implementing its e-business applications. Such a priority could address a need in
      either a critical technology area or a business functional area.

•     Providing an easily implemented solution by being based on open source
      technology and not being restricted by a particular software product or an operation
      system/platform. This would help state DOTs implement the conceptual design
      with potentially minimum obstacles and constraints.




Booz Allen Hamilton Inc.                                                     1-3                                             September 2004
NCHRP Project No. 20-24(19)                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                   1. Introduction


1.4     Summary of the Conceptual Design Decision

During the course of this project, AASHTO provided its 2004 IT survey results that
contained information from 30 states regarding priority applications they planned to
develop in the next year or two. The following trends in IT development were observed
in this survey:

•     The enterprise-level systems integration is a major common theme across most of
      the state DOT near-term IT initiatives.

•     State DOTs are moving toward a “portal” architecture at the enterprise level.
      However, most of these efforts are focused on providing streamlined information
      repositories. Few state DOTs have yet used a portal architecture to integrate their e-
      business applications.

•     Three out of a total of thirty responses indicated a plan to implement a new truck-
      permitting system.

•     Other “hot” IT projects include
            –      Implementing a document management system
            –      Integrating highway maintenance management with asset
                   management systems and fleet management systems
            –      Replacing legacy payroll and human resources systems with ERP
            –      Implementing electronic bidding systems.

The AASHTO 2004 IT survey actually echoes some of the initial findings from the
research, that is, state DOTs are increasingly turning to an enterprise-level framework
to foster more integrated, Web-based user experiences for employees, customers, and
vendors. An enterprise portal architecture is emerging as one of the major frameworks
for this purpose.

From an operational perspective, portals allow businesses to better acquire, serve, and
retain customers and empower their staff with instant access to critical information.
From a development perspective, instead of having separate development and
implementation efforts for individual applications, state DOTs can now design their e-
business applications based on the same backbone architecture. In addition, because
individual applications within a portal follow a similar technology implementation
approach, state DOTs can significantly save resources and minimize implementation
risks.

The research was also conducted to determine whether a common business area or a
specific system exists that most state DOTs plan to develop in the near term. Both the
AASHTO 2004 IT survey data and our best practice survey data indicate that state
DOTs are spreading their resources and efforts across a variety of e-business

Booz Allen Hamilton Inc.                      1-4                                          September 2004
NCHRP Project No. 20-24(19)                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                 1. Introduction


applications. There does not appear to be a single common application that is being
pursued by all state DOTs at this time. Actually, implementing a new permit system is a
relatively common near-term priority among state DOTs as reflected in both surveys.

It is found that a conceptual design that provides an emerging technology solution
applicable to different applications would be more valuable than one that focuses on a
particular business or application. Particularly, a more generic approach to illustrating
the key aspects of a typical transaction process may be more desirable to the conceptual
design. However, a specific example would still be needed to make it relevant.

Based on all the collected data and considerations described above, a conceptual design
was recommended for an e-transaction system based on an enterprise portal
architecture using the permit application as an example.

1.5   Contents of Document

The remaining part of this document consists of the following sections:

Section 2 presents an overview of J2EE technology and how it becomes an effective
solution for many e-businesses. It will also introduce the J2EE’s Model-View-Controller
architecture that will be followed by the e-transaction system design.

Section 3 presents the design of the e-transaction system that includes a business
process models, descriptions of participating roles and their responsibilities, and a set of
UML models.

Section 4 describes the architecture of the e-transaction system including the
architectures of its presentation layers, application layer, and the database layer.

Section 5 focuses on how to implement the conceptual design with an enterprise portal
architecture.

Section 6 focuses on how to implement various financial transaction services to the e-
transaction system. These services include both internal DOT financial transaction
capabilities as well as external third party’s services.

Section 7 introduces the software prototype for the e-transaction system and also
discusses the strategies to use and expand this conceptual design. It also provides with
the instructions on how to install and configure the prototype.




Booz Allen Hamilton Inc.                    1-5                                          September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                    1. Introduction




                              This Page Is Intentionally Left Blank




Booz Allen Hamilton Inc.                       1-6                                          September 2004
NCHRP Project No. 20-24(19)                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                           2. J2EE Platform Technology


2     J2EE PLATFORM TECHNOLOGY

This section presents an overview of the Java 2 Platform Enterprise Edition (J2EE)
technologies and describes the high-level benefits of the J2EE platform. It does NOT
intent to repeat a lot of J2EE technical contents that can be found in many online sites
and Java books. Instead, it aims to explore some of the design motivations behind the
J2EE platform and to lay the foundation for the remaining part of this document.

Readers can find J2EE documentation at the Sun Microsystems web at
http://java.sun.com/j2ee/docs.html. Other valuable references are:

•     “Designing Enterprise Applications with the J2EE Platform” by Inderjeet Singh, Beth Stearns, Mark
      Johnson, Enterprise Team
•     “Core J2EE Patterns: Best Practices and Design Strategies”, Second Edition by Deepak Alur, Dan
      Malks, John Crupi
•     “J2EE Design Patterns” by William Crawford, Jonathan Kaplan


2.1     J2EE Platform Overview

The J2EE platform represents a single standard for implementing and deploying
enterprise applications. Since it became available, it has transformed the marketplace
for distributed computing products. This success is largely due to fact that the J2EE
platform has been designed through an open process, engaging a range of enterprise
computing vendors to ensure that it meets the widest possible range of enterprise
application requirements. As a result, the J2EE platform addresses the core issues that
impede organizations’ efforts to maintain competitively in the information world of e-
business. Organizations have recognized this and quickly adopted the new platform
standard.

The J2EE platform is designed to provide server-side and client-side support for
developing distributed, multi-tier applications. Such applications are typically
configured as a client tier to provide the user interface, one or more middle-tier
modules that provide client services and business logic for an application, and back-end
enterprise information systems providing data management. Figure 2-1 illustrates the
various components and services that make up a typical J2EE environment.




Booz Allen Hamilton Inc.                           2-1                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                              2. J2EE Platform Technology




                                      Figure 2-1. J2EE Environment
* This figure is downloaded from the Sun Microsystems’s J2EE web site.

Multi-tier Model

The architecture of the J2EE platform is best represented by the multi-tier model.
Basically, it enables various parts of an application to run on different devices. It
includes: client tier, a middle tier, and a back-end tier.
•   The client tier supports a variety of client types, both outside and inside of corporate
    firewalls. It can be a Web client or an application client.
•   The middle tier supports client services through Web containers in the Web tier and
    supports business logic component services through Enterprise JavaBeans containers
    in the EJB tier.
•   The enterprise information system (EIS) tier handles EIS software and includes
    enterprise infrastructure systems such as enterprise resource planning (ERP),
    mainframe transaction processing, database systems, and other legacy information
    systems.

Container Services

Central to the J2EE component-based development model is the notion of containers.
Containers are standardized runtime environments that provide specific services to



Booz Allen Hamilton Inc.                              2-2                                          September 2004
NCHRP Project No. 20-24(19)                           Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                        2. J2EE Platform Technology


components. As a result, agencies do not have to develop these services themselves,
they are free to concentrate on solving the business problem at hand.

The Enterprise JavaBeans (EJB) container and the Web containers are the two most
common types of containers for the J2EE platform. The EJB container manages the
execution of enterprise beans for J2EE applications. The Web container manages the
execution of JSP page and servlets components for J2EE applications.

Web Services Support

Web services are Web-based enterprise applications that use open, XML-based
standards and transport protocols to exchange data with calling clients. The J2EE
platform provides the XML APIs and tools needed to quickly design, develop, test, and
deploy Web services and clients that fully interoperate with other Web services and
clients running on Java-based or non-Java-based platforms.

2.2     Model-View-Controller Architecture

The Model-View-Controller architecture is a widely used architectural approach for
interactive applications. It divides functionality among objects involved in maintaining
and presenting data to minimize the degree of coupling between the objects. The
Model-View-Controller architecture divides applications into three layers--model, view,
and controller--and decouples their respective responsibilities. Each layer handles
specific tasks and has specific responsibilities to the other areas.

•     A model represents business data and business logic or operations that
      govern access and modification of this business data. The model notifies
      views when it changes and provides the ability for the view to query the
      model about its state. It also provides the ability for the controller to access
      application functionality encapsulated by the model.

•     A view renders the contents of a model. It accesses data from the model and
      specifies how that data should be presented. It updates data presentation
      when the model changes. A view also forwards user input to a controller.

•     A controller defines application behavior. It dispatches user requests and
      selects views for presentation. It interprets user inputs and maps them into
      actions to be performed by the model.

Figure 2-2 presents the overview of the architecture and the relationships among
the view, model, and controller.




Booz Allen Hamilton Inc.                        2-3                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                              2. J2EE Platform Technology




                           Figure 2-2. The Model-View-Controller Architecture
* This figure is downloaded from the Sun Microsystems’s J2EE web site.



2.3     J2EE Platform Benefits

With features designed to expedite the process of developing distributed applications,
the J2EE platform offers several benefits:

•     Simplified architecture and development - The J2EE platform provides a
      variety of ways to configure the architecture of an application, depending on
      such things as client types required, level of access required to data sources,
      and other considerations. Enables assembly- and deploy-time behaviors--
      Because of the high level of service standardization, much of the code of a
      J2EE application can be generated automatically by tools, with minimal
      developer intervention. In addition, components can expect standard services
      to be available in the runtime environment and can dynamically connect to
      other components by means of consistent interfaces.

•     Freedom of choice in servers, tools, and components - Organizations can
      expect J2EE branded platforms from a variety of vendors, providing a range
      of choices in hardware platforms, operating systems, and server
      configurations. Both J2EE server providers and third-party tool developers
      have developed tools that conform to J2EE standards and support various
      application development tasks and styles.

•     Integration with existing information systems - The J2EE platform includes
      a number of industry standard APIs for accessing existing enterprise

Booz Allen Hamilton Inc.                              2-4                                          September 2004
NCHRP Project No. 20-24(19)                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                    2. J2EE Platform Technology


    information systems such as the J2EE Connector architecture for interacting
    with a variety of Enterprise Information System types, including ERP, CRM,
    and other legacy systems.

•   Scalability to meet demand variations - J2EE containers provide a
    mechanism that supports simplified scaling of distributed applications, with
    no application development effort. Because J2EE containers provide
    components with transaction support, database connections, life cycle
    management, and other features that influence performance, they can be
    designed to provide scalability in these areas.

•   Flexible security model - J2EE provides both flexibility and better security
    control. Security requirements can be specified at the component level to
    ensure that only users with appropriate permissions can access specific data
    operations. At the same time, the basic role-based security mechanism (where
    groups of users share specific permissions) is specified entirely at application
    deployment time.




Booz Allen Hamilton Inc.                    2-5                                          September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                       2. J2EE Platform Technology




                              This Page Is Intentionally Left Blank




Booz Allen Hamilton Inc.                       2-6                                          September 2004
NCHRP Project No. 20-24(19)                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                            3. Design of the e-Transaction System


3     DESIGN OF THE E-TRANSACTION SYSTEM

This section presents business and system design models for a customer-oriented
transaction process as commonly seen in many e-businesses in state DOTs. The models
involve an external customer, a DOT business staff, and a DOT financial staff. The
purpose of these models is to illustrate the business processes, the participating roles
and their responsibilities, and how they are represented in a system architecture design.

The system models presented in this section include a series of Universal Modeling
Language (UML) diagrams together with explanations of how to interpret them. UML
is the current industry standard for visual modeling of software development,
especially for system architecture design.

3.1     Business Processes and Work Flows

The e-transaction system is to represent a typical e-commerce application among state
DOTs. The application has a Web site through which it presents an interface to
customers such as truck companies for filing applications, receiving notifications, and
reviewing past records. DOT staff use different application interfaces for processing
applications, conducting financial transactions, tracking applications, notifying
customers of their application status, and issuing DOT documents to external
customers, such as permits. Each class of user has access to specific categories of
functionality, and each interacts with the application through a specific user interface
mechanism.

Figure 3-1 presents an overview of the processes and work flows for this generic
business process. Conceptually, this e-transaction system is divided into these
functional units:
•     The Web site presents an online application interface to the customer. The customer
      selects the type of application to be filed through this interface. When a customer
      completes an application, the interface sends the application to the backend of the
      system.

•     The system receives the application and sends it to the DOT business staff for
      review. The staff either rejects the application or approves it. Upon approval, the
      application is sent to the DOT financial staff for financial transactions.

•     The DOT financial staff reviews the application and initiates the financial transaction
      process using either an internal system like the financial management system or
      external third-party service, i.e., PayPal. The DOT financial staff then forwards the
      outcome of the transaction to the DOT business staff.




Booz Allen Hamilton Inc.                      3-1                                         September 2004
NCHRP Project No. 20-24(19)                                    Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                       3. Design of the e-Transaction System


•     Depending on the outcome of the financial transaction, the DOT business staff either
      rejects the application or approves it and issues the document, such as a permit to
      the customer

•     All these activities are coordinated by the backend of the system. Its processing is
      triggered by an action that occurs in the Web site portion.




                                          File an                                    Review the
                                        application                                  application




                                        Reject the                        No         Approve the
                                        application                                  application



       External                                                                               Yes
      Customer


                                                                                     Process the
                                                                                      Payment




                                                                           No       Complete the
                                                                                     transaction


                                          Issue the                                 Yes
                                         Document
                                        (i.e., permit)




       External Customer Process             DOT Business Staff Process                   DOT Financial Staff Process




                             Figure 3-1. Overview of Processes and Work Flows


3.2     Roles and Responsibilities

As shown in Figure 3-1, the business model includes three types of roles: Customer,
DOT Business Staff, and DOT Financial Staff. Their responsibilities are explained as
the following using the permit application process as an example:

Booz Allen Hamilton Inc.                                 3-2                                            September 2004
NCHRP Project No. 20-24(19)                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                            3. Design of the e-Transaction System



Customer—An external person or company who is required to file an application, i.e.,
an oversize vehicle permit, to do business with a state DOT. A customer usually
performs the following activities:
•     Apply for a permit
•     Check application status
•     Receive a permit
•     Create and edit a profile
•     Review application filed in the past.

DOT Business Staff—An authorized staff in a state DOT who is responsible for
reviewing, approving, and rejecting the application from the customer. The staff
reviews all contents of the application except the payment portion. A business staff
usually performs the following activities:
•     Review applications
•     Approve an application for financial processing
•     Reject an application
•     Issue an approval/certification to the customer.

DOT Financial Staff—An authorized staff in a state DOT who manages the financial
transaction, i.e., processing of the payment, for the application filed by the external
customers. A financial staff usually performs the following activities:
•     Review applications pending for financial processing
•     Initiate the financial transaction process
•     Approve/reject the application based on the outcome of financial processing.


3.3     UML Models

Designing an application starts with assessing different kinds of requirements and then
determining an optimal software implementation to meet those requirements. There are
numerous analysis tools for gathering and assessing application requirements. The
UML is one such tool. It is the current industry standard for visual modeling of
software development, especially for system architecture design.

A series of UML diagrams are presented in this subsection to describe the system
requirements and architecture as derived from the business model.

3.3.1    Use Case Diagram

The use case diagram as shown in Figure 3-2 provides an overview of all or part of the
usage requirements for the e-transaction system. The diagram addresses the static use-
case views of the e-transaction system through a set of use cases and actors and their

Booz Allen Hamilton Inc.                      3-3                                         September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                           3. Design of the e-Transaction System


relationships. These diagrams are developed from the point of view of the system
stakeholders and not from the point of view of developers. Use case analysis identifies
the actors in a system and the operations they may perform.

Figure 3-2 shows a high-level use case diagram for the sample application and the
potential system actors and their actions:
•   A customer files an application, manages his or her account, and receives e-mails
    about the status of the application.
•   A DOT business staff rejects or approves the application and issues the document to
    the customer if necessary.
•   A DOT financial staff reviews the application and initiates the financial transaction
    process.
•   A DOT financial management system handles the financial transaction.
•   A third-party payment processing service handles the financial transaction.

It is noteworthy that this use case diagram includes a fully automated process
represented by the line connecting the “File Application” use case to the “ Third-Party
Payment Processing Service” actor. This is to illustrate that state DOTs are moving
toward automating certain types of applications by using the third-party services
without any human intervention.

3.3.2   Class Diagram

The class diagram as shown in Figure 3-3 presents a set of classes and their
relationships in the e-transaction system. It is a static view of the system. The diagram
illustrates that a customer can have many accounts. Each account can have multiple
payment options and be linked to many applications. Each application may require
many financial transactions, which are linked to one of the payment options. The
business staff can review many applications. The financial staff can manage many
financial transactions. An application can lead to zero or one document for the
customer.

3.3.3   Statechart Diagram

The statechart diagram as shown in Figure 3-4 provides a dynamic view of the e-
transaction system. It consists of states, transitions, events, and activities. Its purpose is
to explore the behavior of an interface, class, or collaboration and emphasize the event-
ordered behavior of an object, which is useful in modeling reactive or real-time systems.

As explained in the following section, the statechart diagram will be useful to construct
the architecture of the Application Processing Center that follows the workflow
management design approach.

Booz Allen Hamilton Inc.                     3-4                                         September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                           3. Design of the e-Transaction System




                              e-transaction system

                                    Manage Account




                                   Browse Current/
                                   Past Applications



                                                                       3rd Party Payment Processing Service
                                     File Application




              Customer                Issue Document




                                       Approve                                 DOT Business Staff
                                       Application




                                     Reject Application



                                                                             DOT Financial Staff

                                        Initaite
                                      Transaction




                                                                     DOT Financial Management System




                              Figure 3-2. Use Case Diagram




Booz Allen Hamilton Inc.                     3-5                                           September 2004
NCHRP Project No. 20-24(19)                                             Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                3. Design of the e-Transaction System




      Customer                                     Account                                        Payment Option


                       1..1              1..*                         1..1               1..*

                                                 1..1                                                  1


                                                 0..*                                                  1

      Document                                   Application                                    Financial Transaction


                       1..1              0..1                        1..1             1..*

                                                 0..*                                                0..*



                                                 1..1                                               1..1

                                                Business Staff                                     Financial Staff




                                                Figure 3-3. Class Diagram




                 Application Submitted                  Application Approved                       Payment Approved




                                                         Payment Rejected                          Document Issued




                                                        Application Rejected




                                            Figure 3-4. Statechart Diagram




Booz Allen Hamilton Inc.                                          3-6                                                 September 2004
NCHRP Project No. 20-24(19)                           Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                         4. Architecture of the e-Transaction System


4     THE ARCHITECTURE OF THE E-TRANSACTION SYSTEM

This section presents the architecture design of the e-transaction system. It starts with
some basic architecture design considerations based on the business and system models
developed in the last section. With the understanding of the basic architecture
consideration, the section then presents an overview of the system architecture and
examines the operations that are performed within and across each component within
the architecture.

The architecture design of the e-transaction system uses two different architecture
models. The Model-View-Controller architecture is used to design the interactive part
of the system. The backend of the system, which is responsible for coordinating
different activities, is designed based on a workflow-oriented architecture.

4.1     Basic Architecture Consideration

4.1.1    Application Tiers

As described in Section 2, the J2EE platform is designed for multitier applications, and it
offers flexibility in distributing application functionality across the tiers. Given the
system requirements defined in the last section, the e-transaction system is to be
designed in a three-tier architecture:

•     User Interface Tier or the Presentation Tier—Providing graphical user interfaces to
      enable customer, DOT business staff, and DOT financial staff to perform different
      activities.
•     Application Tier—Containing all the business rules and functionality to support the
      application process. It is responsible for almost all of the application functionality. It
      handles dynamic content generation, content presentation, and user requests. This
      tier is integrated with the database tier using a JDBC connection.
•     Database or Enterprise Information System Tier—Hosting the database for the
      system and connecting to other enterprise information systems.

4.1.2    Distributed Architecture

The e-transaction system is designed to be a distributed system that operates across a
network. Each tier of the system can reside on different machines or servers. This makes
the system more modular, maintainable, and reusable because there is less dependency
among individual components. This will also make the system more scalable because all
of its components are designed from the ground up to run in a different address space.

Based on these basic considerations, Figure 4-1 presents the distribution architecture of
the e-transaction system. The software shown in the diagram, such as Tomcat and

Booz Allen Hamilton Inc.                        4-1                                          September 2004
NCHRP Project No. 20-24(19)                                            Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                          4. Architecture of the e-Transaction System


MySQL, are used to develop the prototype, and they are used in the diagram for
purposes of illustration. Section 7 describes in detail the prototype.


                                                                        DOT
                               DOT                                    Application                        DOT
                             Desktop                                   Servers                           Data
                            Workstations                                                                Servers


                                   GUI




                                                                                                           Data




                                                                      Tomcat 5.x
                     Internet
         DOT       Exlplorer 6.0
          Full     Web Browser                             File System
        Function                                            Interface e        DOT
         -ality                          HTML
                     Windows                                                 Application
                    Workstation
                                         Pages                                Services

  DOT                                             TCP/IP                                     TCP/IP      MySQL4.0.x
                                                   HTTP      Static                         SQL*Net   Database Services
                                                             HTML
                     Netscape                                Pages                  JDBC
         DOT       Navigator 4.78                              &
          Full     Web Browser                                Java
        Function                          Java               Server
         -ality
                     Windows             Server              Pages
                                                                                Reporting
                    Workstation          Pages
                                                                                 Engines


                     User Interface Tier                      Application Tier                            Data Tier


                    Figure 4-1. Distribution Architecture of the e-Transaction System



4.2     Architecture Overview

With an understanding of the basic architecture considerations, this subsection presents
an overview of the system architecture for the e-transaction application as shown in
Figure 4-2. The system is divided into two units: a Web site that serves as frontend to
the users and an Application Processing Center on the backend. The Web site follows
the Model-View-Controller architecture. The Application Process Center (APC) follows
a process workflow architecture.

Section 4.3 describes the architecture design for the frontend Web site. Section 4.4
describes the architecture design for the backend Application Processing Center.




Booz Allen Hamilton Inc.                                        4-2                                               September 2004
NCHRP Project No. 20-24(19)                                      Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                    4. Architecture of the e-Transaction System


                                   DOT Financial Staff




                                                                                               State DOT
                                    e-transaction                 Application                     FMS
                                       system                     Processing
                                      Web Site                      Center
                                                                 e
                                    (Frond End)                   (Back End)                   3rd Party
               Customer                                                                        Payment
                                                                                           Processing Service

                                                    e-transaction system




                                  DOT Business Staff




                           Figure 4-2. Architecture of the e-Transaction System


4.3   Application Web Site Architecture

As described early, the application Web site handles user interactions. The Web site
presents the application’s data to the user in response to the user’s requests. The Web
site’s primary responsibilities include handling user requests, retrieving and displaying
application data to a user’s browser, and allowing users to file, review, and process the
application.

The Model-View-Controller architecture is used to design the application Web site. At
the highest level, the application divides into three logical categories of layers: layers
that deal with presentation aspects of the application, those that deal with the business
rules and data, and those that accept and interpret user requests and control the
business objects to fulfill these requests.

The main idea behind design patterns is to extract the high-level interactions between
objects and reuse their behaviors from application to application. Design patterns help
shape the way a problem is parsed, which leads to helping break up the problem into
objects and modules. The Model-View-Controller pattern is surprisingly simple, yet
incredibly useful.

Given the high-level system architecture, the next step of the design process is to
subdivide the application into objects or components and assign these components to
layers. While most components are consigned to one layer or another, some serve to
connect the layers and need to span layers, and they must be designed accordingly.

Booz Allen Hamilton Inc.                                   4-3                                             September 2004
NCHRP Project No. 20-24(19)                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                     4. Architecture of the e-Transaction System



4.3.1   Functional Modules

One of the critical steps in the design process is to partition the application into
modules and objects that address the different functional requirements. According to
the functional requirements identified in Section 3, the application can be divided into
several modules as follows:

•   A control module to create and maintain user account information, which includes a
    user identifier, billing, and contact information. This information is maintained in a
    database.

•   A sign-on module to handle the user’s log-in process and security, such as verifying
    a user identifier and password.

•   A customer module that manages a user’s application process and maintains
    account records for a customer.

•   An application review module that manages the application review process
    conducted by the DOT business staff.

•   A financial review module that manages the financial transaction process
    conducted by the DOT financial staff.

•   A messaging module that enables the system to send and receive asynchronous
    messages containing application status.

Figure 4-3 shows how these modules in the sample application Web site relate to each
other.




Booz Allen Hamilton Inc.                    4-4                                          September 2004
NCHRP Project No. 20-24(19)                                      Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                    4. Architecture of the e-Transaction System




                                             e-transaction
                                              home page
                                                                                Sign on


                                                                                              user database


              Users            Interface               Control



                                                                               Customer


                                                                                              account database



                                                                               Application
                                                                                Review
                                           Messaging
                                                                                             application database



                                                                                Financial
                                                                                 Review
                                            Queue
                                                                                             financial transaction
                                                                                                  database


                      Figure 4-3. Functional Modules of the e-Transaction System


After the application is partitioned into functional modules, the next step is to identify
units of business logic, data, and presentation logic and model them as software objects.
This starts with identifying the options at the highest level, then working down.

In the design of the Web site application, it is first partitioned into model-view-
controller layers. Figure 4-4 shows how the e-transaction system is divided roughly into
these layers. It is important to note that there are no clear boundaries between model,
view, and controller because application functions typically operate across these layers.

The next few sections examine the operations that are performed within and across each
Model-View-Controller architecture section and their design issues.




Booz Allen Hamilton Inc.                                   4-5                                             September 2004
NCHRP Project No. 20-24(19)                                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                      4. Architecture of the e-Transaction System




                                                       Browser Client
                     View                                                                     Controller


                                                                                       Filter Applicatio
                                                                                            Status
                      Format Page to
                         Display


                                                                                     Map Application to
                                                                                       User Roles


                    Determine Page to
                         Display
                                                                                     Invoke Command to
                                                                                      Handle Application




                                                        Coordinate
                                                         activities
                     Model



                                                                         Peform
                                       Retrieve Data
                                                                        Operations




         Figure 4-4. Model-View-Controller Architecture for the e-Transaction System


4.3.2   View Layer

The e-transaction system is designed to use the J2EE platform technologies for handling
user views. The software prototype developed for this project uses JSP pages for
presentations in which the presentation data changes rather than the structure of the
presentation. JSPs are an excellent technology for creating views for Web applications.
The prototype also uses servlets for graphics and other binary data representations.
XML technology is also applied to transform the data.

Some key issues have been taken into account when designing the view layer:

•   View components should focus on presentation and be separated from business and
    control logic. The business logic often deals with business rules. The control logic
    focuses on process flow controls. This makes it easier to reuse the presentation logic
    portion of the JSP page.



Booz Allen Hamilton Inc.                                     4-6                                           September 2004
NCHRP Project No. 20-24(19)                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                       4. Architecture of the e-Transaction System


•   To have a common look and feel and keep page layouts similar within the system,
    all view pages for the prototype have the same structure: a banner across the top, a
    navigation menu just below the banner, and a footer at the bottom. Figure 4-5 is an
    example of page layout for the prototype.



                                                                                     Banner


                                                                                     Menu




                                                                                     Content




                                                                                     Footer



               Figure 4-5. An Example of Page Layout for the e-Transaction System


•   The prototype developed to illustrate the conceptual design also includes several
    features designed to improve accessibility for users with disabilities. For example,
    the images on the site contain “alt tags,” which aid users who listen to the content of
    the site by using a screen reader, rather than reading the site. “Sticky keys” are
    provided on all navigation buttons. These allow a user to navigate the prototype
    using only the keyboard.


4.3.3   Model Layer

The model layer of the e-transaction system contains the components that handle
business logic: Session Facade, Business Object, and Data Access Object. They extract
and formulate the data required to handle a client request.

Some key issues need to be taken into account when designing the model layer:


Booz Allen Hamilton Inc.                      4-7                                             September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                        4. Architecture of the e-Transaction System


•     Code needs to be developed as components or modular to promote reuse. Modular
      components are designed to be independent from other components so that they are
      loosely coupled with other components. As a result, changes to components have
      little or no impact on other components. It is also preferred to design modular
      components to perform only a single function. Single function components can be
      easily reused.

•     It is best if the system’s business objects are not tightly coupled to a specific data
      persistence mechanism. The e-transaction system could use business data stored in
      several databases. Each type of databases may have its own Application
      Programming Interface (API). Therefore, changing the underlying data store or
      database requires changing the data access logic in the business objects. A data
      access object can be used to encapsulate data access mechanism details so that these
      details are kept separate from business logic. This increases the capability to manage
      data access for portability.

4.3.4    Controller Layer

The controller section of the e-transaction system architecture controls the flow of the
application and serves as the glue between the model and view. It executes business
logic in the model in response to user requests and helps select the next view for
display. The controller decouples data presentation from business data and logic.

Two controllers can be implemented in the e-transaction system, and they are described
as following:

•     A front controller can be implemented to control the log-in requests from different
      users. The front controller, using the data in the request, extracts the type of user
      and converts it to the appropriate type of event object. It then passes the event to the
      modal layer. The model layer then checks the information with the database and
      selects the appropriate view to display on the Web tier.

•     Another controller can be implemented to control the flow of the application filed by
      the customer during the application reviewing and financial transaction processes.
      The controller receives the data from users as the result of the application filing and
      processing and then passes it to the model layers. The model layer checks the
      information with the business logic and assigns the application to the appropriate
      parties to handle the subsequent actions.

4.4     Process Workflow Architecture

One of the J2EE architecture approaches is the Process Workflow Architecture. In
contrast to the Model-View-Controller architecture, workflow architecture is more
suitable for applications that focus on process control and have fewer interactive

Booz Allen Hamilton Inc.                       4-8                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                               4. Architecture of the e-Transaction System


features. The focus is to enable different processing steps in the workflow to
communicate with each other.

4.4.1   Overview of the Application Process Center Workflow

The APC as shown in Figure 4-2 in the e-transaction system can be designed in a
workflow architecture. The APC processes customer applications and manages the
financial transactions. Processing starts in this backend of the system when a customer’s
application is received from the Web site.

The APC can be designed with four modules: the application process coordinator,
application reviewer, financial processor, and financial administrator modules. Figure
4-6 shows the modules of the APC and their relationships to each other.




                                                                                      Em ail


                                                   Custom er

                                                <<application>>
                                                 e-transaction
                                                    web site




                                          Application Process Center


                                                                  <<application>>
                                                                Process Coordinator
                              <<application>>
                                Application
                                 Reviewer                           <<application>
                                                                      Custom er
                                                                      Relations




                              <<application>>                     <<application>>
                                 Finance                             Finance
                               Administrator                        Processor




                  Figure 4-6. Application Process Center Workflow Architecture

•   The Application Process Coordinator module receives the application and verifies
    the customer’s credit status. It acts as the processing coordinator or workflow
    manager and maintains a global view of the entire application processing flow.
    When it receives an application from the Web site, it can assign the application an
    identifier and store it in the database. It communicates with the Financial

Booz Allen Hamilton Inc.                              4-9                                          September 2004
NCHRP Project No. 20-24(19)                   Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                 4. Architecture of the e-Transaction System


    Administrator module if the payment type selected by the customer requires instant
    processing.

•   The Application Process Coordinator module passes the application to the
    Application Reviewer module or the Financial Processor module depending on the
    application status.

•   A Customer Relation submodule can be put to the Application Process Coordinator
    module to notify the customer the status of the application at different stages.

•   The Financial Administrator module handles the financial request and interacts with
    external services. It also passes the results of the financial transaction back to the
    Application Process Coordinator module.

•   The Application Processing module updates its application records based on the
    information from the other three modules. This process continues until the
    application is approved and the document is issued.

4.4.2   Implementation Considerations

The APC is process-oriented, its process driven by the receipt of an application from the
Web site. It can be developed using a number of J2EE technologies, including Java
Message Service (JMS) API, message-driven enterprise beans, JavaMail API, and XML.
The following are implementation considerations for developing the APC.

•   The APC needs to separate the implementation of process control from business
    logic. A process manager is responsible for the entire workflow process. The process
    manager knows the sequence of steps and the rules for following these steps. Each
    activity handles its portion of the business logic.

•   Messages need to be sent asynchronously using the JMS API between workflow
    activities. It is preferred that messages be encoded in XML, making it easy for
    different application to communicate.

•   The JavaMail API can be used to send e-mail notifying customers of application
    status and issuance of the document.

•   Each activity in the APC corresponds to a named JMS destination. This named
    destination is the endpoint that maps to a step in the workflow. Components of the
    system can send messages to and receive messages from these named destinations.

•   To remove any tight-coupling restrictions between activities, a message-driven bean
    can be implemented, which enables asynchronous process control messaging. It
    receives and handles the incoming message request, passes it to the particular
    destination, and passes the message contents to its related work activity.




Booz Allen Hamilton Inc.                   4-10                                      September 2004
NCHRP Project No. 20-24(19)                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                           5. Integration with Enterprise Portals


5     INTEGRATION WITH ENTERPRISE PORTALS

5.1    Enterprise Portal Concept

An enterprise portal is a Web-based application that commonly provides
personalization, single sign-on, and content aggregation from different sources, and it
hosts the presentation layer of the information system. A portal may have sophisticated
personalization features to provide customized content to users. Portal pages may have
different sets of portlets creating content for different users. One of the key advantages
of portals is that they allow integrating a wide range of applications for a number of
different audiences including customers, employees, supply chain partners, executive
decision-makers, and the general public.

The following is a list of features that are commonly seen and applicable in state DOT
enterprise portals.

Aggregation of Content—The capability to tie different content fragments into one
consistent and interoperating view.

Customized Views and Content—Customization commonly refers to having different
views based on the role of the person in the organization. It also provides the capability
for individual users to customize their views to suit their individual needs.

Unified Security Model—This provides not only single sign-on but also an enterprise-
wide security policy based on role.

Self-Service—This is a recent trend in portals, particularly those for external customers.
It has been focused toward users being able to provide self-service. The idea is that it
should be easy for a user to provide and access sufficient information to conduct
transactions with minimal or no support from other people.

Workflow and Collaboration—Workflow supports the user’s ability to seamlessly
move through a set of tasks across multiple data sources and applications.
Collaboration is also provided in many portals to develop communities of interest so
that people can share common expertise and insight on a particular set of topics and
data.

Figure 5-1 illustrates an overview of an enterprise portal.




Booz Allen Hamilton Inc.                    5-1                                           September 2004
NCHRP Project No. 20-24(19)                                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                           5. Integration with Enterprise Portals




                                               Portal Clients/Customers
                                                          Mobile
                                                           Mobile                      Other
                                                                                        Other
                                Browsers
                                 Browsers                 Devices
                                                           Devices                    Systems
                                                                                       Systems




                                                    Enterprise Portal

                                              Content
                                               Content               Messaging / /
                                                                      Messaging
                                            Management
                                             Management              Collaboration
                                                                      Collaboration

                                                                       Content
                                                                        Content
                                              Security
                                               Security              Presentation
                                                                      Presentation

                                                                      Enterprise
                                                                       Enterprise
                                             Workflow
                                             Workflow                   Search
                                                                         Search

                                                       Database
                                                        Database
                                                      Integration
                                                       Integration




                                        Sources of Information and Applications
                                                                                             Web
                                                                                             Web
                           Documents
                            Documents       Applications
                                             Applications          Databases
                                                                    Databases              Services
                                                                                            Services




                           Figure 5-1. An Overview of an Enterprise Portal


5.2   Integration at the Presentation Tier

The role of the presentation tier is to provide a unified view to segmented business
processes. Enterprise portals are more varied than e-commerce sites but still have
common characteristics. Access to information is customized so logging into the portal
is the first step. Once the user is authenticated, the presentation layer provides
dynamically generated content. In many portal examples, the interface is composed of a
series of items framed in distinct regions. The complexity of items ranges from simple
objects (e.g., URLs and images) to applets (e.g., calendars and calculators) to
component-based applications (e.g., query and visualization tools).

Figure 5-2 presents an example of a page layout for an enterprise portal that provides a
high-level roadmap to a variety of performance indicators. Many DOT portal pages are
currently using this structure such as

Booz Allen Hamilton Inc.                                    5-2                                           September 2004
NCHRP Project No. 20-24(19)                             Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                 5. Integration with Enterprise Portals


•   http://www.accessindiana.com
•   http://www.accesskansas.com




                                                 Banner


                     Login         Application    Application     Application    Application
                                       1              2                3              4

                                   Application    Application     Application    Application
                                       5              6                7              8
                 Personalized
                   Options
                    Menu
                                    Search          Primary Contents


                   News and
                    Industry
                  Information
                                             Navigation/Links to Other Sites



                  Figure 5-2. An Example of Page Layout for an Enterprise Portal


The e-transaction system can be integrated to a DOT enterprise portal following a
structure similar to that depicted Figure 5-2 at the presentation tier. Figure 5-3 presents
an enterprise portal interface to the e-transaction system from the prototype. The portal
page provides the contents as the following:

•   Links to static HTML reports
•   Links to business intelligence tools for ad hoc querying and analysis
•   Links to different enterprise applications and systems
•   Third-party news feeds for industry-specific information
•   Content management features for publishing and sharing documents.

To ensure a consistent and reliable framework for combining arbitrary elements in a
unified DOT enterprise portal application, each component application, such as the e-
transaction system, needs to be designed as a portlet, which is a pluggable Web
component managed by a portlet container as shown in Figure 5-4. The portlet provides
dynamic content as part of an aggregated user interface.




Booz Allen Hamilton Inc.                          5-3                                           September 2004
NCHRP Project No. 20-24(19)                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                  5. Integration with Enterprise Portals




              Figure 5-3. An Enterprise Portal Interface to the e-transaction System




                                Portlet
                                 Portlet            Portlet
                                                     Portlet              Portlet
                                                                           Portlet
                              Interface
                               Interface          Interface
                                                   Interface            Interface
                                                                         Interface




                                Portlet
                                 Portlet            Portlet
                                                     Portlet              Portlet
                                                                           Portlet
                              Interface
                               Interface          Interface
                                                   Interface            Interface
                                                                         Interface

                                             Application Server




                                                Enterprise
                                           Integration Services




                     Figure 5-4. Application of Portlets in an Enterprise Portal




Booz Allen Hamilton Inc.                           5-4                                           September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                            5. Integration with Enterprise Portals


5.3   Integration at the Application Tier

In many ways the application server tier is the brain of an enterprise portal. It is here
that server-side processing of servlets occurs; business rules are executed; and data
from multiple data sources is integrated.

The e-transaction system can be integrated with an enterprise portal in the following
areas at the application tier:

Integration of data from multiple sources—Depending on specific situations within
individual agencies, the e-transaction system could possibly operate across multiple
databases such as a permit database and a finance database. The e-transaction system
should leverage the data integration capability, e.g., the XML, Web services, that is
already developed within the portal to facilitate its data integration.

Workflow management—In a DOT environment, the business process of applying for a
permit could depend on the integration of multiple applications for reviewing the
application, checking the credit status, processing the payment, etc. Programs running
in the application server can bridge these systems by managing the workflow between
them and ensuring that the data produced by one system is properly formatted and
streamed to the next application in the overall process. Application servers provide
many of the messaging and transaction processing services required to ensure that
these business processes are treated as atomic units. As a result, it prevents incomplete
transactions.

Application of business rules—As described in Section 3, the e-transaction system
operates on a set of business rules, policies, and procedures that dictate how business is
done with a DOT. Some of these rules (e.g., the financial transaction) need to support
large numbers of applications. Rather than maintaining these rules in the e-transaction
system, the portal can separate them from the execution model of the application and
use a rule-processing engine to serve multiple applications.

Content management—The e-transaction system is currently designed for three types
of users: external customers, DOT business staff, and DOT financial staff. These roles
should be merged with the roles and responsibilities that have already been defined in
the enterprise portal. This will ensure a consistent content management style across
multiple applications with the portal for each of these roles.

Security and user administration—The user log-in and authentication in the e-
transaction system can be integrated with the enterprise single sign-on service. This
minimizes the need for users to log in to individual applications. As a result, the portal
controls access to content, portlets, and customization feature. These features are
controlled with conventional users, groups, and access control lists within the portal
engine.

Booz Allen Hamilton Inc.                     5-5                                           September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                   5. Integration with Enterprise Portals


5.4     Integration at the Data Service Tier

The third tier in the integration of the e-transaction system with an enterprise portal is
the enterprise information services or data services layer. It is here that the e-transaction
system meets the rest of an organization’s information infrastructure:

•     Relational databases
•     ERP system
•     CRM systems
•     Documentation management system
•     E-mail systems
•     Legacy applications.

      Figure 5-5 presents the approaches that can be used to integrate the e-transaction
      system with different enterprise information components.




              Figure 5-5. Approaches of Enterprise Information System Integration

* This figure was downloaded from the Sun Microsystems’s J2EE Web site.


•     Data integration using the JDBC API (for relational databases) or Connector
      architecture (for nonrelational databases)
•     Asynchronous, message-based, loosely-coupled integration using the JMS and J2EE
      Connector architecture
•     Synchronous, tightly-coupled integration using the Connector architecture

Booz Allen Hamilton Inc.                            5-6                                           September 2004
NCHRP Project No. 20-24(19)                     Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                         5. Integration with Enterprise Portals


•   Legacy connectivity using the Connector architecture.

The J2EE Connector architecture provides a standard architecture for integrating J2EE
applications with existing EISs and applications. The Connector architecture enables
adapters for external EISs to be plugged into the J2EE application server. Enterprise
applications can then be developed using these adapters to support and manage secure,
transactional, and scalable integration with EISs.




Booz Allen Hamilton Inc.                  5-7                                           September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                              5. Integration with Enterprise Portals




                              This Page Is Intentionally Left Blank




Booz Allen Hamilton Inc.                       5-8                                           September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                           6. Financial Transactions


6     FINANCIAL TRANSACTIONS

6.1     Overview of the Current Financial Transactions

An increasingly critical piece of e-business is the ability to pay for goods and services
using Internet-based applications. According to the survey conducted in this NCHRP
project on current state DOT e-business, it is found that the financial transaction is one
of the most challenging issues that senior DOT managers are facing in the design and
development of their e-businesses. The following explains what makes the financial
transaction a complex issue:

•     Financial transactions are required to strictly follow agency or state’s related
      regulations, processes, and procedures.
•     The financial transaction is viewed as an enterprise issue. It often involves the
      agency’s financial management system or other enterprise resource planning
      systems.
•     The architecture and technology for processing financial transactions are complex,
      and they change frequently to adopt new standards and innovations. The cost is also
      not trivial to most e-business projects.
•     Security is a serious concern. Agencies need to ensure their customers that their
      private information will be protected during the transaction process. At the same
      time, they also want to protect their online business from fraud and other criminals.

The first step in designing a robust capability in support of financial transactions is to
have a good understanding of the payment types customers often use. Our study shows
the following major payment types commonly used in many state DOT’s e-businesses:

•     Checks—This is still a common and traditional payment method at present.
      Financial transaction processes in many state DOTs still involve manual steps. It
      provides a mechanism by enabling customers to use their existing checking accounts
      to transfer funds to the agency. A secure infrastructure ensures that confidential
      information is not compromised in transit.

•     Debit account—Customers with good reputations and credit history usually
      establish a debit account with a state DOT. Charges are accrued on the account
      every time a transaction is performed. A bill is then sent to the customers at regular
      intervals. In other cases, these accounts are linked to the customer’s credit cards. If
      their balances exceed a certain amount, the credit cards will be automatically
      charged.

•     Credit cards—It is still the dominant online payment type, credit cards are popular
      because of their ubiquity and the familiarity customers have in using them in a
      variety of settings.

Booz Allen Hamilton Inc.                       6-1                                           September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                         6. Financial Transactions


•   Online payment—It enables any individual or business with an e-mail address to
    securely, easily, and quickly send and receive payments online. A representative
    example is PayPal. It builds on the existing financial infrastructure of bank accounts
    and credit cards and uses the advanced proprietary fraud prevention systems to
    create a safe, global, real-time payment solution.

•   Internet banking—Some e-businesses enable customers to transfer funds from their
    bank accounts to pay bills. Major banks usually facilitate online bill payments;
    customers can log on and pay bills at their convenience.

•   Electronic funds transfer (EFT)—EFT is a system of transferring money from one
    bank account directly to another without any paper money changing hands. It
    provides a means of transferring funds from customers to agencies.




Table 6-1 presents an overview of these payment methods including their usages at
present and in the future. It also highlights their key features as explained below:

Instant Processing—The dominant payment method and financial transaction process
in the future should offer convenience to customers, who can pay for their products or
services and receive immediate feedback on the status of their payment. The system
should be able to address the payment needs of the bulk of their customers and offer
them valuable features such as electronic receipts, recurring billing options, and more.

Manual Steps Required—It is inevitable that at some time manual processes will be
involved in financial transactions to comply with regulations and procedures. A
successful financial transaction approach will depend on how the level of human
involvement can be minimized while allowing no compromise in regulations and
procedures.

Relying on DOT or State’s FMS—The financial management system (FMS), as a critical
component in an organization’s ERP system, plays a key role in initiating and managing
financial transactions. In some cases, it sits on the critical path of the entire process and
acts as a gateway to external services.

Using the Third-Party Services—Instead of developing their own capabilities, many
states turn to third-party payment services such as the PayPal and VeriSign online
payment processing services. Equipped with advanced technology and robust anti-
fraud functions, these services have become more mature than in the past. They are
gaining confidence from organizations as well as the general public. They represent one
of the most promising approaches in managing financial transactions.




Booz Allen Hamilton Inc.                     6-2                                           September 2004
NCHRP Project No. 20-24(19)                             Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                              6. Financial Transactions




                Table 6-1. Overview of Payment Methods Used in DOT Environment

                    Frequency of Usage                                Key Features
      Payment
      Method                                                                     Relying             Using
                                           Instant         Manual Steps
                                                                                on DOT or         the Third-
                   Present     Future    Processing         Required
                                                                               State’s FMS       Party Services

      Check         3            1          No                  Yes                  Yes              No

       Debit        2            2          No                  Yes                  Yes              No
      Account
      Credit        3            3          Yes                 Yes                  Yes              No
       Card

     Online         1            3          Yes                  No                  No               Yes
    Payment

    Internet        1            2          No                  Yes                  Yes              No
    Banking

       EFT          1            2          No                  Yes                  Yes              No




6.2     Design Approach in the e-Transaction System

The major payment types and their features as presented in

Table 6-1 have been considered in and incorporated into the conceptual design of the e-
transaction system. Figure 6-1 illustrates the financial transaction use cases designed for
the e-transaction system.

•     The design does not intend to have the e-transaction system to complete all financial
      transactions within the system itself. It is impossible to do that because the financial
      transaction has become an enterprise issue, and no single system can handled it
      alone. Instead, the design relies on three external actors to execute and manage the
      financial transaction. They are the Finance Staff, Agency’s Financial Management
      System, and the Third-Party Service. The e-transaction system becomes merely a
      tool to receive the payment request and pass it to other parties via integration with
      work flow management, interface to FMS, and Web service connection to online
      payment services. This approach takes into account the current operating approach
      in state DOTs and also incorporates the industry best practice trend.




Booz Allen Hamilton Inc.                          6-3                                           September 2004
NCHRP Project No. 20-24(19)                                Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                 6. Financial Transactions


•   Finance Staff—The Financial Staff is one of the three actors. We envision that the
    financial processor is an authorized staff in a state DOT who supports the processing
    of the financial payment for the application filed by the external customers. Given
    the fact that certain financial transactions will still need manual review and
    facilitation, it is expected that the role of a financial staff will exist for the time being.
•   Agency’s Financial Management System —The FMS in a DOT is a critical piece in
    support financial transaction. It is the repository of the agency’s financial
    regulations, business rules, and procedures. It maintains customer accounts and
    often serves as a gateway to external parties such as credit card companies. It is
    expected that the FMS will continue playing such a role in the near future.
•    Third-Party Service—This represents the online payment services such as the
    PayPal and direct credit card processing. These third-party services, which
    sometimes are called Instant Processing, will enable customers to pay for their
    products or services and receive immediate feedback on the status of their payment.

The rest of this section on Financial Transactions will focus on credit card processing
and third-party services using the PayPal as an example. They will represent a
substantial amount of payments to be processed by state DOTs’ e-businesses over the
Internet.




                                   Financial Transaction
                                 in E-Transaction System



                                       File Application



                                                                        3rd Party Payment Processing Service


                                           Approve
                                           Application




                                                                                DOT Financial Staff
                                             Initaite
              Customer                     Transaction




                                                                         DOT Financial Management System




          Figure 6-1. Use Cases of Financial Transactions in the e-Transaction System


Booz Allen Hamilton Inc.                             6-4                                                 September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                  6. Financial Transactions




6.3     Credit Card Processing Architecture

In a typical credit card payment scenario, the transaction flow can be divided into two
major phases or steps: authorization and settlement. Authorization verifies that the
card is active and that the customer has sufficient credit available to make the
transaction. Settlement involves transferring money from the customer’s account to the
organization’s account.

6.3.1 Authorization

Figure 6-2 illustrates the process of credit authorization that is initiated from the e-
transaction system.




                                                                                                       $




        Customer           e-transaction system     Gateway                   Processor               Bank




                                    Figure 6-2. Credit Authorization Process


1. Customer decides to make a payment at the e-transaction site, proceeds to check out and
   inputs credit card information.
2. The e-transaction system (the application layer) receives customer information and sends
   transaction information to a payment processing service.
3. The payment processing service acting as a gateway routes information to a processor.
4. The processor receives the information, validates the credit card number, and sends the
   information to the issuing bank of the customer’s credit card.
5. The issuing bank sends the transaction result (authorization or decline) to the processor.
6. The processor routes the transaction result to the payment processing service.
7. The payment processing service passes the result information to the e-transaction system.
8. The e-transaction system accepts or rejects the transaction and issues the document (i.e., the
   permit) to the customers, if necessary.


6.3.2

Booz Allen Hamilton Inc.                              6-5                                           September 2004
NCHRP Project No. 20-24(19)                                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                           6. Financial Transactions


        Settlement

Figure 6-3 illustrates the process of credit settlement once the authorization process is
completed.

                                                                                                Acquiring Bank

                                                                                                         $
                                                $

                                                                $

                                        Organization's Accounts Receivable




             e-transaction system                   Gateway                                  Processor




                                                                                                         $




                                                    Customer                                     Issuing Bank




                                    Figure 6-3. Credit Settlement Process


1. Once the authorization is completed, the e-transaction system sends a request to the
   payment gateway to settle the transaction.
2. The payment gateway sends the transaction to be settled to the processor.
3. The processor sends the settlement details to the issuing bank of the customer’s credit card.
4. At the same time, the process also sends the settlement details to the organization’s
   acquiring bank.
5. The issuing bank includes the charges on the customer’s credit card statement.
6. The acquiring bank also deposits the appropriate funds into the organization’s accounts
    receivable.




Booz Allen Hamilton Inc.                                       6-6                                               September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                6. Financial Transactions


6.3.3   Implementation Approaches

State DOTs can have several approaches to implement the credit card processing service
as described early in their e-businesses. Three representative methods are introduced as
following:

Using the state’s financial system as a gateway—Based on the survey from this
NCHRP project, several states are in the process of implementing a statewide financial
management system. The role of such a system is to standardize the financial
transaction processes within its agencies in the state and also to act as a gateway to send
or receive payments. As shown in Figure 6-4, in this case, the e-transaction system
needs to connect its Financial Transaction model in the APC to the state’s financial
management system.


                               e-transaction system




         Customer

                                  <<application>>
                                                                     state's
                                     Finance
                                                                      FMS
                                   Administrator


                                                                                           Gateway

            Figure 6-4. Credit Card Processing—Using the State’s FMS as a Gateway


Incorporating the third-party’s software component—As shown in Figure 6-5, this
approach will require that a software component be downloaded from the third party
and incorporated into the e-transaction system. It allows the agency to process
payments through the e-transaction Web site. The download usually comes with a
software development kit for simple API integration. In most cases, the software comes
combined with Secure Socket Layer (SSL) certificate that allows customers to send
information online with the assurance that they are really doing business with the state
DOT and that the information they send such as credit card numbers is protected from
interception or alteration over the Web.




Booz Allen Hamilton Inc.                            6-7                                           September 2004
NCHRP Project No. 20-24(19)                                      Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                       6. Financial Transactions



                                    e-transaction system




                                                                                                        Gateway of
                                                                                                         3rd Party
                                                                                                      Payment Service
          Customer
                                       <<application>>     3rd Party
                                          Finance          Software                TCP/IP
                                        Administrator                               SSL




          Figure 6-5. Credit Card Processing—Incorporating the Third-Party Software


Using the Third-Party’s Hosted Service—As shown in Figure 6-6, this approach is
useful for the e-business that requires a simple solution to process its payments. Instead
of controlling the processing at the Web site of the e-transaction, it uses a hosted order
form service that allows a customer to securely input credit card information. To use
such a service, the e-transaction system needs only add a small piece of HTML code that
will link a customer from its Web site to the order forms hosted by the third party.


                           e-transaction system                                         3rd Party Service



                                                                                                    Gateway of
                                                                           Hosted Order Form         3rd Party
                                                                                Service           Payment Service
          Customer

                              <<application>>
                                 Finance                   TCP/IP
                               Administrator                SSL




             Figure 6-6. Credit Card Processing—Using the Third-Party Host Service



6.4   PayPal Processing Architecture

PayPal is currently a global leader in online payment solutions. It enables any
individual or business with an e-mail address to securely, easily, and quickly send and
receive payments online. PayPal’s service builds on the existing financial infrastructure
of bank accounts and credit cards and uses the world’s most advanced proprietary
fraud prevention systems to create a safe, global, real-time payment solution.

This subsection introduces two popular payment processing methods from PayPal, the
Buy Now button, and the Web Service, and illustrates how they can be integrated with
the e-transaction system. The developer’s center at the PayPal Web sites provides many


Booz Allen Hamilton Inc.                                   6-8                                                  September 2004
NCHRP Project No. 20-24(19)                                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                          6. Financial Transactions


examples of coding that can be readily applied to the integration.

6.4.1   Overview of the PayPal Payment Process
The payment mechanism is simple enough. Newcomers to PayPal provide details of a
credit card or bank account. These are verified with a nominal transaction. Thereafter, a
buyer can e-mail a payment directly to a seller. This is immediately debited from the
buyer’s credit card or bank account, and a credit is made to the seller’s PayPal account.
Money in a PayPal account can be withdrawn by check or transferred to a bank account.
Individuals and small traders can receive credit-card payments without obtaining a
merchant account. PayPal’s cut comes from charging recipients between 2.2 percent and
3.4 percent, depending on the country, and levying fees for currency conversions.

To use the PayPal service, an organization needs to first create a business account that
links to the organization’s bank account.

6.4.2 Using PayPal Buy Now Button

The Buy Now button is one of the Web site payment methods provided by the PayPal. It
is a simple way to add e-commerce functionality to an organization’s Web site. By
placing the button anyway, it makes it convenient for customers to pay securely by
credit card on the Web site. Currently, PayPal no longer requires the customers to create
a PayPal account. This means the purchase process is more streamlined, resulting in an
increase in completed sales and higher customer satisfaction. Another benefit is that
buyers do not have to disclose banking or credit card information to merchants

Figure 4-6-7 presents an overview of the payment flow between the e-transaction
system Web site and the PayPal Web site using the Buy Now button.


               Click                 PayPal cookie                                           Logged in
                                                            Login in to PayPal
                                                              payment page
                at e-transaction


                                                                                                     Payment
                                                                                                    Confirmation



                   Back to                                       Payment
                e-transaction      User clicks "Continue"        Receipt               Payment completed
                                    to go back to the e-
                                        transaction




                                                                    e-transaction Web site           PayPal Web site


              Figure 6-7. Overview of Payment Flow Using PayPal Buy Now Button


Booz Allen Hamilton Inc.                                      6-9                                                      September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                         6. Financial Transactions


To set up and use the Buy Now button, the developer needs to log in to the agency’s
PayPal account and fill in relevant information. The PayPal will generate customized
HTML code that is to be pasted to the e-transaction system’s Web site to create the Buy
Now button. When a customer clicks the Buy Now button, he or she will be taken to a
secure PayPal payment page to complete the purchase.

The PayPal’s Web site provides instructions and examples of code to help developers
implement the button.

6.4.3 Using PayPal Instant Payment Notification

PayPal’s Instant Payment Notification (IPN) allows organizations to integrate the
PayPal payments with the Web site’s backend operations, enabling organizations to get
immediate notification and authentication of the PayPal payments they are received.

Figure 6-8 illustrates how the PayPal’s IPN can be integrated with the e-transaction
system’s backend. The steps shown in the figure are explained as follows:

1. The organization first needs to activate the IPN feature in its business account and enter the
   URL at which the application server will receive the notification.
2. When a customer makes a payment, PayPal will post a notification to the server at a
   specified URL. Included in this notification is the customer’s payment information (e.g.,
   customer name, amount) as well as a piece of encrypted code.
3. When the application server receives a notification, it will confirm it by constructing an
   HTTP POST including the encrypted code, back to a secure PayPal URL.
4. PayPal will authenticate the transaction by checking the encrypted string. PayPal will send
   confirmation of its validity back to the application server.
5. The Financial Administrator in the application server will perform various checks on the
   transaction details.
6. Once the Financial Administrator completes all checks, it will communicate with the Process
   Coordinator with the IPN data. The Process Coordinator will then update the database and
   proceed to subsequent activities.




Booz Allen Hamilton Inc.                       6-10                                        September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                           6. Financial Transactions




                  e-transaction system


                      <<application>>
                    Process Coordinator
                                                a state DOT

                       <<application>
                         Customer                                  1
                         Relations



                              6

                                            2

                       <<application>>
                          Finance           3                                   $
                        Administrator
                                                                                          $
                                            4
                                                                              Customer Payment
                                        5
                                                              PayPal




              Figure 6-8. Integrating with the PayPal Instant Payment Notification


6.4.4   Using PayPal Web Service

Most PayPal merchants currently use the PayPal Web site to manage their PayPal
transactions. PayPal now extends this flexibility with the introduction of PayPal Web
services. Using an API, merchants can now use Web services technology to create
applications that work directly and automatically with PayPal. PayPal API calls can
automate certain PayPal functions that normally would require a person to manually
enter information. This allows merchants greater flexibility and control when using
PayPal for payment transactions.

The e-transaction system can integrate PayPal Web services to enhance its financial
transaction capabilities as follows:

•   Withdraw funds from customers’ accounts with their prior permission
•   Refund payments to customers
•   Search or obtain details of a particular transaction.

Because the PayPal Web service API takes advantage of available open standards, such
as SOAP and WSDL, it becomes a easy task to integrate the Web service functions with
the organization’s own transaction framework. Figure 6-9 illustrates the architecture of
integrating the Web service with the e-transaction system’s Financial Administrator
module.




Booz Allen Hamilton Inc.                        6-11                                             September 2004
NCHRP Project No. 20-24(19)                            Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                             6. Financial Transactions




                                         WSDL+XSD




               e-transaction system
                                                                        Server-side PayPal APIs

                    <<application>>        SOAP                   PayPal              Native PayPal
                       Finance                                  API Gateway           Business Logic
                     Administrator
                                          over HTTPS




                  Figure 6-9. Architecture of Integrating with PayPal Web Service




Booz Allen Hamilton Inc.                            6-12                                           September 2004
NCHRP Project No. 20-24(19)                          Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                   7. The Prototype


7     THE PROTOTYPE

This section introduces the software prototype that is developed to illustrate the
conceptual design of the e-transaction system. It provides an overview of the software
and describes the open source tools that are used to develop the software. It also
includes instructions on how to install the prototype as well as the recommendations on
how to expand and use the prototype.

7.1     Prototype Overview

As a part of the conceptual design, a prototype of the e-transaction system was
developed using the J2EE technologies. This prototype follows the generic customer-
oriented transaction process as introduced in the prior section but uses the DOT permit
application process as an example.

The purpose of the prototype is to:

1. Illustrate the approach and architecture of J2EE technologies
2. Present a working architecture to a common e-business process
3.     Illustrate and implement the key design considerations as presented in the prior
      sections
4. Provide a code framework that state DOTs can use to develop a production system
   or pilot test new concepts and functions.

For the purpose of illustration, separate user ids are created for the three types of users
as follows. The passwords of these three user ids are “password”.

•     The use id “permitrequestor” refers to an external person or company who are
      required to file an application, i.e., an oversize vehicle permit, in order to do
      business with a state DOT.
•     The use id “permitprocessor” refers to the DOT business staff that is responsible for
      reviewing, approving, and rejecting the application from the customer.
•     The user id “finprocessor” refers to an authorized staff in a state DOT who manages
      the financial transaction, i.e., processing of the payment, for the application filed by
      the external customers.


Figure 7-1 presents an overview of the prototype tier architecture as well as the
software used to run the prototype. State DOTs can contact NCHRP to obtain a
software installation CD that includes all open source tools, prototype codes, and
installation instructions.

Booz Allen Hamilton Inc.                       7-1                                          September 2004
NCHRP Project No. 20-24(19)                                       Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                                7. The Prototype




                                                         Tomcat 5.x
        Internet
      Exlplorer 6.0
      Web Browser                             File System
                                               Interface            DOT
                       HTML
        Windows                                                   Application
       Workstation
                       Pages                                       Services
                                                                                                        Data

                                   TCP/IP                                           TCP/IP
                                    HTTP        Static                             SQL*Net
                                                                   e
                                                HTML
        Netscape                                Pages                   JDBC
      Navigator 4.78                              &                                                MySQL4.0.x
      Web Browser                                Java
                        Java                    Server
                                                                                                Database Services
         Windows       Server                   Pages
                                                                       Reporting
        Workstation    Pages
                                                                       Engines


        User Interface Tier                       Application Tier                                  Data Tier

                           Figure 7-1. Overview of the e-Transaction Prototype


7.2     Open Source Tools

This prototype is developed exclusively using the state-of-art J2EE technology and open
source tools (Java, Tomcat, Ant, MySQL). It can be installed on any computer platform.
Table 7-1 lists all the open sources that are used to develop and operate the prototype.
The installation CD includes these software products. Users can also visit their web site
to download most recent releases.

                            Table 7-1. Open Source Tools Used in Prototype

              Software                      Version                        Role                     Web Site
Java 2 SDK Standard Edition
                                      1.4.2                   Platform                   http://java.sun.com/j2ee/1.4
(J2SE)
Java 2 SDK Enterprise Edition
                                      1.4                     Platform                   http://java.sun.com/j2ee/1.4
(J2EE)
                                                              Application
Tomcat                                5.0.25                                             http://jakarta.apache.org/tomcat
                                                              Server

MySql                                 4.0.20                  Database Server            http://www.mysql.com

                                                              Development
Struts J2EE Framework                 1.0                                                http://struts.apache.org
                                                              Framework
                                                              Java-based build
Ant                                   1.6.2                   tool
                                                                                         http://ant.apache.org




Booz Allen Hamilton Inc.                                    7-2                                                September 2004
NCHRP Project No. 20-24(19)                         Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                  7. The Prototype


7.3     Installing the Prototype

Once users obtain the installation CD from the NCHRP, they can follow the instructions
to install the prototype.
1. Download and install Tomcat 5.0.25
2. Download and install MySql 4.0
3. Create the tables in the MySQL database using the scripts provided in the
   installation package and populate the tables with data for the prototype. Create a
   default user with full access to the database.
4. Copy the MySQL JDBC connector JAR file “mysql-connector-java-3.0.14-production-
   bin.jar” to /tomcat5.x/common/lib folder.
5. Deploy the prototype application in tomcat by copying the DOT.WAR file provided
   in the installation package into the tomcat deploy folder.

Instructions for downloading and installing Tomcat and MySql can be found at their
web sites as listed in Table 7-1.

7.4     Using the Prototype

This prototype along with the conceptual design aims to provide state DOTs with a best
practice solution to an emerging critical technology that many state DOTs will need.
The e-transaction process addressed by the conceptual design is common in many state
DOT’s e-businesses. However, the J2EE technology architecture can also be applied to
other business areas. The following is a list of recommendation on how state DOTs can
leverage this conceptual design and the software prototype.

•     Expand the conceptual design to make it as a one-stop portal for all types of
      permits processed in a state DOTs.

      Generally, the processes of applying for different permit are very similar. They all
      need to involve application review and financial transactions. It will save state DOTs
      a lot of resources if all permit applications can be handled and processed through a
      same system. The prototype is already designed to handle all types of permits.
      However, the business logics for different types of permits will need to be
      implemented to the prototype.

•     Integrate the conceptual design to an existing state DOT enterprise portal

      State DOTs are moving toward enterprise portal architecture that serves as a
      gateway to all their applications and also leverage resources and capacities across
      them. State DOTs can follow what are described in Section 5 to integrate the
      prototype to an enterprise portal.


Booz Allen Hamilton Inc.                      7-3                                          September 2004
NCHRP Project No. 20-24(19)                        Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                 7. The Prototype


•     Plug the conceptual design to other e-businesses

      The e-transaction process described in this document is adaptable and scalable. This
      enables the conceptual design to be plugged into different e-business applications
      that involve transactions with external customers such as purchasing a state map or
      brochure.

In addition to these recommendations, the subsequent section introduces each
prototype screen and explains how each of them can be expanded to perform additional
activities.

7.5     Screens Shots

This section presents a list of major screen shots from the prototype. For readers who do
not have access to the prototype, these screens will provide them with a visual
understanding of the scope and functions of the prototype.

Each screen shot is accompanied by a paragraph of description, a list of tools used, and
thoughts on how to expand the screens to perform additional activities. These
descriptions are also imbedded in the prototype. Users can click the “Screen
Information” tab to see these descriptions for each screen.




Booz Allen Hamilton Inc.                     7-4                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                          7. The Prototype




 Screen Name:                 DOT Enterprise Portal Access Screen

 Screen Shot:




 Description:                 This screen is an illustration of how the prototype can be accessed via an
                              enterprise portal page. It also serves to demonstrate the layout of a typical
                              enterprise portal page. It is to demonstrate how the prototype can be
                              implemented within an enterprise portal architecture. Currently this screen is
                              designed as one portlet among a DOT enterprise portal. The screen layout
                              illustrates the framework of a typical DOT enterprise portal. Users can first
                              come to the DOT enterprise portal and then start running the prototype

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    Following the same portal technical approach, state DOTs can also add
 Suggestion:                  other applications as different portlets under the same enterprise
                              architecture. However, it is highly recommended that state DOTs need to
                              develop their portlet integration plan first. The portlet integration plan
                              typically outlines the overall components that are needed to successfully
                              deploy the enterprise portal, which can include hardware, software, portlets
                              overview, requirements, database schemas, and administrative information.




Booz Allen Hamilton Inc.                              7-5                                          September 2004
NCHRP Project No. 20-24(19)                                  Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                           7. The Prototype




 Screen Name:                 e-Transaction Login Screen

 Screen Shot:




 Description:                 This screen is for users to login into the e-Transaction prototype. Separate
                              user names are created for three types of users that are supported by this
                              prototype:

                              “permitrequestor” (for permit applicant)

                              “permitprocessor” (for state DOT business staff)

                              “finprocessor” (for state DOT financial staff)

                              The passwords of these three user ids are “password”

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    Different roles have been defined to support the system. The Administrator
 Suggestion:                  of the system will need to create different types of users to perform under
                              different roles. These roles are: Permit Requestor, Permit Processor, and
                              Financial Processor.




Booz Allen Hamilton Inc.                               7-6                                          September 2004
NCHRP Project No. 20-24(19)                                  Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                           7. The Prototype




 Screen Name:                 Permit Inbox Screen

 Screen Shot:




 Description:                 This screen is designed for the permit applicant to view his or her current
                              and past permits and their status. Users can review their permits filed in the
                              past. They can also open and print an approved permit. For the rejected
                              permits, users can open them and then modify and resubmit them to the
                              DOT. Users can also start a new permit application from this screen. Users
                              will get an e-mail notification every time a new item is added to this inbox. is
                              an illustration of how the prototype can be accessed via an enterprise portal
                              page. It also serves to demonstrate the layout of a typical enterprise portal
                              page.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    It can be expanded to do a search on permits, sorting on different fields,
 Suggestion:                  Move Approved and Rejected permits to different page




Booz Allen Hamilton Inc.                               7-7                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                          7. The Prototype




 Screen Name:                 Permit Application Filing Screen

 Screen Shot:




 Description:                 This screen is for the permit applicant to file a new permit application. Some
                              fields on the screen are automatically populated according to the information
                              from the applicant’s profile. Once the user selects a permit type, the bottom
                              part of the screen will automatically show its pertinent fields. After the user
                              fills all mandatory data fields and selects a payment type, he will proceed to
                              the Payment Method Information screen. The prototype will generate
                              warning messages if information of any mandatory data field is missing.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    This screen is designed as a universal architecture to apply for all types of
 Suggestion:                  permits. State DOTs can modify the list of permit types and add and refine
                              the pertinent fields for each permit type. Some of these changes will involve
                              adding new fields to the database.

                              If the customer selects the “PayPal” payment method, the screen can be
                              expanded to directly connect to the PayPal web site using either the Buy
                              Now function or the web service. Section 6 provides details.




Booz Allen Hamilton Inc.                              7-8                                          September 2004
NCHRP Project No. 20-24(19)                                 Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                          7. The Prototype




 Screen Name:                 Payment Method Screen – Credit Card

 Screen Shot:




 Description:                 This screen is for the permit applicant to enter the relevant information for
                              the credit card payment method. The applicant will enter its credit card
                              number and expiration date. Once the information is submitted, the
                              application is sent to the Permit Processing Inbox of the DOT’s application
                              reviewer. At the same time it is also added to the applicant’s Inbox with the
                              pending status. An e-mail notification is also generated and sent to the
                              applicant’ e-mail address.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    All the sensitive and personal information is gathered through secured layer
 Suggestion:                  (SSL).




Booz Allen Hamilton Inc.                              7-9                                          September 2004
NCHRP Project No. 20-24(19)                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                       7. The Prototype




 Screen Name:                 Payment Method Screen – Check

 Screen Shot:




 Description:                 This screen is for the permit applicant to enter the relevant information for
                              the check payment method. Once the information is submitted, the
                              application is sent to the Permit Processing Inbox of the DOT’s application
                              reviewer. At the same time, it is also added to the applicant’s Inbox with the
                              pending status. An e-mail notification is also generated and sent to the
                              applicant’ e-mail address.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    All the sensitive and personal information is gathered through secured layer
 Suggestion:                  (SSL).




Booz Allen Hamilton Inc.                             7-10                                       September 2004
NCHRP Project No. 20-24(19)                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                       7. The Prototype




 Screen Name:                 Payment Method Screen – Debit Account

 Screen Shot:




 Description:                 This screen is for the permit applicant to enter the relevant information for
                              the debit account method. The applicant will enter the relevant information
                              about its debit account at the state DOT. Once the information is submitted,
                              the application is sent to the Permit Processing Inbox of the DOT’s
                              application reviewer. At the same time it is also added to the applicant’s
                              Inbox with the pending status. An e-mail notification is also generated and
                              sent to the applicant’ e-mail address.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    All the sensitive and personal information is gathered through secured layer
 Suggestion:                  (SSL).




Booz Allen Hamilton Inc.                             7-11                                       September 2004
NCHRP Project No. 20-24(19)                              Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                       7. The Prototype




 Screen Name:                 My Profile Screen

 Screen Shot:




 Description:                 This screen is for the permit applicant to review and edit its profile
                              information. Most of applicants are recurring customers and often apply for
                              similar permits. By having a profile online, the applicant will save much time
                              by not entering the same information every time. This function will also help
                              state DOTs keep track of the applicants and their permits.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    This screen can be expanded to add additional fields that state DOTs want
 Suggestion:                  to capture about the customer.




Booz Allen Hamilton Inc.                             7-12                                       September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                        7. The Prototype




 Screen Name:                 Permit Processing Inbox Screen

 Screen Shot:




 Description:                 This screen lists all current permits pending review. It is designed for the
                              state DOT’s staff that is responsible for reviewing, processing, and
                              approving permit applications. The permits residing in this inbox are either
                              new application just filed by the applicants or those that are returned with the
                              completed financial transactions. By clicking a particular application, the
                              state DOT staff will proceed to the Permit Application Review screen.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    This screen can be expanded to do a search on permits and sort on different
 Suggestion:                  fields.




Booz Allen Hamilton Inc.                              7-13                                       September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                        7. The Prototype




 Screen Name:                 Permit Application Review Screen

 Screen Shot:




 Description:                 This screen lets the state DOT staff review the details of the permit
                              application in the permit processing inbox. As a result, the staff will either
                              reject the application or approve it for financial transaction or issue the
                              permit. The “comment” field is for the staff to record his or her review
                              comments. If the staff rejects the application or approves it for issuing the
                              permit, the application will be sent to the applicant’s inbox with an automatic
                              e-mail notification. If the staff approves the application for financial
                              transaction, the system will either initiate the automatic financial transaction
                              process or send the application to the Permit Financial Transaction Inbox
                              depending on the selected payment type.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    This screen can be expanded to incorporate business rules and logic that
 Suggestion:                  are linked to each type of permit. This function will help make some steps in
                              the review process become automatic and improve review quality and
                              efficiency.




Booz Allen Hamilton Inc.                              7-14                                       September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                        7. The Prototype




 Screen Name:                 Permit Financial Transaction Inbox Screen

 Screen Shot:




 Description:                 This screen lists all current permits pending financial transactions except
                              those with the PayPal payment method. It is designed for the state DOT’s
                              staff who are responsible for processing the financial transactions for permit
                              applications. The permits residing in this inbox are the applications that are
                              reviewed and approved by the state DOT staff with respect to their
                              application contents. By clicking a particular application, the state DOT staff
                              will proceed to the Permit Financial Transaction Processing screen.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    This screen can be expanded to do a search on permits and sort on different
 Suggestion:                  fields.




Booz Allen Hamilton Inc.                              7-15                                       September 2004
NCHRP Project No. 20-24(19)                               Task 3 “Conceptual Design for an e-Transaction System”
State DOTs and e-Business                                                                        7. The Prototype




 Screen Name:                 Permit Financial Transaction Processing Screen

 Screen Shot:




 Description:                 This screen lists the details of the permit application with respect to its
                              selected payment methods, i.e., credit card, debit account, and checks. As
                              a result, the staff will either reject or approve the application based on the
                              outcome from the financial transaction. The application will then be sent
                              back to the Permit Processing Inbox.

 Technology:                  Java, JSP, Struts, MySql, Tomcat

 Expansion                    The system is expected to use this screen to interface with the state
 Suggestion:                  DOT’s financial management system or the third-party payment
                              processing service in order to complete the financial transactions. An
                              alternative is to design and implement this screen within the DOT’s
                              financial management system, which can be one of the portlets under the
                              enterprise portal architecture as shown in the Login screen.




Booz Allen Hamilton Inc.                              7-16                                       September 2004

				
DOCUMENT INFO