E-Appointment Service - Development Report - Ver 1.0

e-Appointment Service

Development Report

Elsa Estevez

Vincent Douwe

Tomasz Janowski

type

date

version

location

Technical Report

14 April 2009

1.0

www.egov.iist.unu.edu/outputs

UNU-IIST Center for Electronic Governance www.egov.iist.unu.edu

Copyright © 2009, UNU-IIST Center for Electronic Governanc

UNU-IIST Center for Electronic Governance

Identity: An International Center of

Excellence on research and practice

in Electronic Governance, part of

United Nations University - Interna-

tional Institute for Software Tech-

nology, located in Macao, China.

Activities: Applied and policy research,

capacity building, and various forms of

development – strategy development,

software development, institutional

development and development of com-

munities of practice.

Mission: To support govern-

ments in developing countries

in strategic use of technology

to transform the working of

public organizations and their

relationships with citizens,

businesses, civil society, and

with one another.

SUMMARY

UNU-IIST CENTER FOR ELECTRONIC GOVERNANCE | www.egov.iist.unu.edu

i

SUMMARY

This document describes the development of the e-

Appointment Service, part of the software infrastructure

for Electronic Government, enabling government cus-

tomers to make appointments for public services. The

system enables government agencies to define the loca-

tions and working hours for serving their customers. It

also allows citizens to make appointments, as well modi-

fy or cancel previous appointments. In addition, the

system notifies citizens about confirmed appointments.

The document first presents the scope of the Macao

Data Exchange Gateway Project and an introduction to

the e-Appointment Service. Next, it specifies in detail

the software requirements, conceptual and use case

models, followed by design, implementation and dep-

loyment diagrams. A glossary of terms and some imple-

mentation artifacts, such as XML Schemas, configuration

files, Application Programming Interfaces and the main

Java classes of the Appointment System are included in

the appendices.

This work was partly funded by Macao Foundation un-

der the e-Macao Program (www.emacao.gov.mo).

TABLE OF CONTENTS


ii

TABLE OF CONTENTS

Summary .................................................................................................................................................................................... i

Table of Contents ...................................................................................................................................................................... ii

List of Tables ............................................................................................................................................................................. iii

List of Figures ........................................................................................................................................................................... iv

List of Requirements ................................................................................................................................................................. v

Abbreviations ........................................................................................................................................................................... vi

Revisions .................................................................................................................................................................................. vi

1. Introduction .......................................................................................................................................................................... 1

2. Background ........................................................................................................................................................................... 2

2.1. Motivation ..................................................................................................................................................................... 2 2.2. Concepts ........................................................................................................................................................................ 3 2.3. Process ........................................................................................................................................................................... 4 2.4. Implementation Approach ............................................................................................................................................ 5 2.5. Challenges...................................................................................................................................................................... 7 2.6. Case Studies ................................................................................................................................................................... 7

3. Requirements ...................................................................................................................................................................... 14

3.1. Functional Requirements............................................................................................................................................. 14 3.2. Non-Functional Requirements ..................................................................................................................................... 21

4. Modeling ............................................................................................................................................................................. 24

4.1. Conceptual Model ....................................................................................................................................................... 24 4.2. Use Case Model ........................................................................................................................................................... 25

5. Design .................................................................................................................................................................................. 30

5.1. Architecture – Static View ........................................................................................................................................... 30 5.2. Architecture – Dynamic View ...................................................................................................................................... 31 5.3. Detailed Structural Design Diagrams ........................................................................................................................... 32 5.4. Detailed Behavioural Design Diagrams ........................................................................................................................ 38

6. Implementation ................................................................................................................................................................... 43

6.1. Overview ...................................................................................................................................................................... 43 6.2. Technologies ................................................................................................................................................................ 45 6.3. Improvements ............................................................................................................................................................. 46

7. Deployment ......................................................................................................................................................................... 48

8. Conclusions ......................................................................................................................................................................... 49

References............................................................................................................................................................................... 50

Appendices .............................................................................................................................................................................. 51

A. Glossary .......................................................................................................................................................................... 51 B. XML Schemas .................................................................................................................................................................. 53 C. Configuration File ........................................................................................................................................................... 59 D. Application Programming Interfaces .............................................................................................................................. 64 E. Java Classes ..................................................................................................................................................................... 72

LIST OF TABLES


iii

LIST OF TABLES

Table 1: Examples of Public Services Requiring Appointment................................................................................................... 2 Table 2: Main Tasks of the e-Appointment Business Process ................................................................................................... 4 Table 3: Implementation Approach for Main Tasks of the e-Appointment Business Process ................................................... 5 Table 4: e-Appointment Functions ............................................................................................................................................ 6 Table 5: Greece DDYEP e-Appointment Service - Performance Indicators ............................................................................... 8 Table 6: Top-Level Use Cases .................................................................................................................................................. 25 Table 7: Use Cases – Manage e-Appointment Service ............................................................................................................ 26 Table 8: Use Cases – Manage Supported Services .................................................................................................................. 27 Table 9: Use Cases – Request Appointments .......................................................................................................................... 28 Table 10: Use Cases – Use Software Infrastructure ................................................................................................................. 28 Table 11: Use Cases versus Functional Requirements............................................................................................................. 29 Table 12: Technologies Used by e-Appointment Service ........................................................................................................ 45

LIST OF FIGURES


iv

LIST OF FIGURES

Figure 1: Appointment Negotiation Process ............................................................................................................................. 7 Figure 2: Singapore – ICA e-Appointment Service ..................................................................................................................... 9 Figure 3: Singapore – ICA e-Appointment Service – Authenticating Applicants...................................................................... 10 Figure 4: Singapore – ICA e-Appointment Service – Retrieving an Appointment.................................................................... 10 Figure 5: Singapore – ICA e-Appointment Service – Appointment Receipt ............................................................................. 11 Figure 6: Singapore – LRWD e-Appointment Service – Terms and Conditions ........................................................................ 11 Figure 7: Singapore – LRWD e-Appointment Service – Negotiating Time ............................................................................... 12 Figure 8: Singapore – LRWD e-Appointment Service – Providing Personal Data .................................................................... 13 Figure 9: Singapore – LRWD e-Appointment Service – Retrieving an Appointment ............................................................... 13 Figure 10: Conceptual Model .................................................................................................................................................. 24 Figure 11: Top Level Use Case Diagram ................................................................................................................................... 25 Figure 12: Use Case Diagram – Manage e-Appointment Service ............................................................................................ 25 Figure 13: Use Case Diagram – Manage Supported Services .................................................................................................. 26 Figure 14: Use Case Diagram – Request Appointments .......................................................................................................... 27 Figure 15: Use Case Diagram – Use Software Infrastructure .................................................................................................. 28 Figure 16: Architecture – Static View ...................................................................................................................................... 30 Figure 17: Architecture – Dynamic View for Making an Appointment .................................................................................... 31 Figure 18: Design Class Diagram – e-Appointment Common Web Pages ............................................................................... 33 Figure 19: Design Class Diagram – e-Appointment Portal Web Pages .................................................................................... 33 Figure 20: Design Class Diagram – e-Appointment Agency Web Pages .................................................................................. 34 Figure 21: Design Class Diagram – Service .............................................................................................................................. 36 Figure 22: Design Class Diagram – Util .................................................................................................................................... 36 Figure 23: Design Class Diagram – Communication ................................................................................................................ 36 Figure 24: Design Class Diagram – Database ........................................................................................................................... 37 Figure 25: Sequence Diagram for Adding an Agency............................................................................................................... 38 Figure 26: Sequence Diagram for Deleting an Agency ............................................................................................................ 39 Figure 27: Sequence Diagram for Making an Appointment – Steps 1 and 2 ........................................................................... 40 Figure 28: Sequence Diagram for Making an Appointment – Steps 3 and 4 ........................................................................... 41 Figure 29: Implementation Diagram ....................................................................................................................................... 43 Figure 30: Deployment Diagram – A Possible Scenario ........................................................................................................... 48

LIST OF REQUIREMENTS


v

LIST OF REQUIREMENTS

Requirement 1: Administering Agencies ................................................................................................................................. 14 Requirement 2: Administering Services List ............................................................................................................................ 15 Requirement 3: Managing Public Holidays .............................................................................................................................. 15 Requirement 4: Managing Services Data ................................................................................................................................ 16 Requirement 5: Managing Centers ......................................................................................................................................... 16 Requirement 6: Managing Non-Working Days ........................................................................................................................ 17 Requirement 7: Managing Working Hours .............................................................................................................................. 17 Requirement 8: Viewing Appointments .................................................................................................................................. 18 Requirement 9: Exporting Appointments................................................................................................................................ 18 Requirement 10: Making Appointment .................................................................................................................................. 19 Requirement 11: Cancelling Appointment .............................................................................................................................. 19 Requirement 12: Modifying Appointment .............................................................................................................................. 20 Requirement 13: Notifying Applicant ...................................................................................................................................... 20 Requirement 14: Reminding Applicant ................................................................................................................................... 21 Requirement 15: Exchanging Appointment-related Information ............................................................................................ 21 Requirement 16: Authenticating users ................................................................................................................................... 22 Requirement 17: Ensuring Confidentiality .............................................................................................................................. 22 Requirement 18: Ensuring Generality ..................................................................................................................................... 23 Requirement 19: Ensuring Interoperability ............................................................................................................................. 23

ABBREVIATIONS AND REVISIONS


vi

ABBREVIATIONS

EPS Electronic Public Services

IAS Social Welfare Institute

ID Macao Sports Development Board

IPIM Macao Trade and Investment Promotion Institute

SAFP Public Administration and Civil Services Bureau

SI4EG Software Infrastructure for Electronic Government

SS Health Bureau

UML Unified Modeling Language

UNU United Nations University

UNU-IIST UNU International Institute for Software Technology

UNU-IIST-EGOV Center for Electronic Governance at UNU-IIST

XML eXtensible Markup Language

XSL eXtensible Stylesheet Language

XSLT XSL Transformations

REVISIONS

DATE RESPONSIBLE SCOPE VERSION

24/01/2009 Elsa Estevez First version 0.96

09/02/2009 Vincent Douwe Second draft version 0.97

20/02/2009 Elsa Estevez Second draft version revised 0.98

14/04/2009 Tomasz Janowski Final version 1.0

SECTION 1 – INTRODUCTION


1

1. INTRODUCTION

The provision of Electronic Public Services (EPS) in terms

of number, maturity and accessibility is central for mea-

suring the progress of Electronic Government develop-

ment. However, the rapid provision of mature EPS can-

not be achieved following a case-by-case approach, as it

requires the availability of pre-existing components,

tools and artifacts that can be used for rapid develop-

ment, deployment and reliable delivery. These compo-

nents, tools and artifacts constitute the so-called Soft-

ware Infrastructure for Electronic Government. Such

infrastructure includes design-time artifacts – like ready-

to-customize domain models, guidelines and implemen-

tation frameworks that can be used for accelerating EPS

development; as well as run-time components and ser-

vices supporting or realizing common software functio-

nality required for the efficient and reliable delivery of

services – like submission of citizen data through elec-

tronic forms, notifications to applicants, and message

exchange between software applications. The availabili-

ty of such infrastructure is one of the major facilitators

for scaling up, rapidly and efficiently, the provision of

EPS.

In addition to the motivation explained above, main

benefits that can be gained by delivering such infrastruc-

ture for Electronic Government include: providing stan-

dardized services to all agencies based on common

technical standards; reducing the costs of developing

EPS by individual agencies; promoting the adoption of

standards across government; establishing a platform

for collaboration between agencies and between public

and private sector on EPS and infrastructure develop-

ment; facilitating the creation of cross-agency EPS; and

enabling the integration of applications built with differ-

ent technologies.

Based on the motivation and prospective benefits of

providing software infrastructure, the Software Infra-

structure for Electronic Government Project was defined

by the UNU-IIST Center for Electronic Governance to be

executed as part of the e-Macao Program during 2007.

The Message Exchange Gateway (Gateway), a major

infrastructure service, was delivered by this project. The

Gateway enables asynchronous exchange of messages

among registered members (e.g. software applications

or human users) through dynamically created and sub-

scribed channels. It comprises a core framework sup-

porting plain exchange of messages, and various exten-

sions providing enhanced functionality - such as mes-

sage logging, validation, transformation, encryp-

tion/decryption, mediation, and resource discovery,

enabled on the platform.

In 2008, the Macao Data Exchange Gateway Project was

carried out by UNU-IIST Center for Electronic Gover-

nance. The project aim was to develop a unified mes-

sage infrastructure based on the UNU’s Extensible Mes-

sage Gateway and DSC’s e-DocX Service – Unified Macao

Government Message Gateway. This integration leve-

rages the strengths of the two solutions to support inte-

gration of back-office applications, e-document ex-

change and multi-channel service delivery. A meeting

was held between SAFP, DSC and UNU-IIST representa-

tives to discuss the integration of the Extensible Mes-

sage Gateway and e-DocX Service. Consequently, it was

concluded that it would be simpler for government

agencies to use both tools independently of the other,

based on specific needs. Subsequently, the objectives of

the Macao Data Exchange Gateway Project were revised

producing the following:

o1) In order to facilitate the use of the Messaging Ga-

teway by Macao Government Agencies, UNU will

provide APIs to invoke the Message Gateway ser-

vices by software applications running on the IT

platforms most commonly used by Macao Gov-

ernment.

o2) The encryption-decryption extension of the Mes-

saging Gateway will be re-implemented using the

certificates provided by Macao Post Office.

o3) In order to facilitate the testing of the Messaging

Gateway by SAFP, UNU will submit the Message

Gateway Quality Assurance report.

o4) To develop a pilot e-service enabling the manage-

ment of customer queues by government agencies.

To achieve the former two objectives, a new release of

the Gateway was delivered including new APIs and en-

hanced services. To fulfill the third objective, the Extens-

ible Messaging Gateway – Quality Assurance Report [29]

was delivered to SAFP. To achieve the last objective, two

services were developed – Queuing and Appointment.

This report constitutes the development report for the

e-Appointment Service.

The rest of this document is structured as follows. Sec-

tion 2 introduces some concepts and motivation for pro-

viding an appointment service. Section 3 defines the

functional and non-functional requirements for the ser-

vice. Section 4 describes the domain concepts and the

required functionality, depicted by the Conceptual and

Use Case models, respectively. Section 5 presents the

architecture and detailed design of the service. Section 6

and 7 introduce implementation details and possible

deployment scenarios. Some conclusions are drawn in

Section 8. Finally, a set of appendices include the XML

schemas, configuration files, application programming

interfaces, and the main Java classes of the e-

Appointment Service.

SECTION 2 – BACKGROUND


2

2. BACKGROUND

The aim of this section is to provide background infor-

mation related to the e-appointment service in order to

get a better understanding of its scope. The section is

structured as follows. Section 2.1 (Motivation) presents

the need for providing an appointment service as part of

the software infrastructure for Electronic Government,

by presenting concrete public services delivered by the

Government of Macao SAR requiring appointments as

part of their business processes. Section 2.2 (Concepts)

introduces definitions related to the service. Section 2.3

(Business Process) explains the different stages for deli-

vering the service. Section 2.4 (Implementation Ap-

proach) discusses an approach for implementing each of

the steps of the service business process. Section 2.5

(Challenges) outlines some of the challenges for imple-

menting and delivering the service. Finally, Section 2.6

(Case Studies) illustrates some examples of e-

Appointment services.

2.1. MOTIVATION

The delivery of some public services requires the appli-

cant to visit a government agency or a centre providing

specialized public services. For example, a business

owner visits a government agency to sign the establish-

ment of a new company; a patient visits a hospital to

receive medical assistance. Likewise, it may also require

a civil servant to visit the applicants’ facilities – for ex-

ample, an official inspecting the sanitary conditions of a

new establishment. These visits involve skillful or pro-

fessional civil servants, like government officials or med-

ical doctors, usually part of the scarce human resources

in government.

In order to deliver such services more efficiently - mak-

ing better use of scarce government resources and

avoid applicants queuing; some kind of agreement is

required to schedule such visits. These agreements are

managed through appointments.

Examples of public services delivered by the Govern-

ment of Macao SAR requiring appointments were ex-

tracted from the survey carried out as part of the e-

Macao Project (Phase I), documented in The State of

Electronic Government in Macao, Volume 2 Agencies

report [4]. These examples are depicted in Table 1 and

explained as follows:

1) Health Bureau (SS) provides Out-patient Medical

Assistance service. Once the patient is referred to a

specialist, a consultation is booked with the special-

ist for the patient to receive adequate treatment.

After paying the visit to the specialist, new ap-

pointments may be required for follow-up consul-

tations, as well as appointments for follow-up clini-

cal analysis.

2) Social Welfare Institute (IAS) provides the Financial

Assistance to Individuals service. Applicants need to

book an appointment to visit the social welfare

center to apply for the service. In addition, after

the application is complete and the computer

records are created for the applicant, a government

official visits the applicant to inspect his/her life

conditions in order to complete the assessment of

the applicant’s financial status.

Table 1: Examples of Public Services Requiring Appointment

AGENCY SERVICE

APPOINTMENT REQUIREMENT

SS Out-patient Medical Assistance

An appointment with a specialist is booked

IAS Financial Assistance to Individuals

Applicant books an appointment to visit the social welfare center.

Government official visits the applicant to inspect his/her life conditions

IPIM One-stop Investor Service

An appointment is done with IPIM notary for signing the company establishment

ID Sport Medical Services

Appointments with physiotherapy are booked for the patient



3

3) Macao Trade and Investment Promotion Institute

(IPIM) provides One-Stop Investor service. Once the

submission of all the necessary documentation by

the applicant is completed, the applicant makes an

appointment with IPIM notary to sign the company

establishment.

4) Macao Sports Development Board (ID) provides

Sport Medical services. After the patient is re-

ceived and registered at the center, consultation is

carried out and a prescription is issued to the pa-

tient. The patientmakes payment and an appoint-

ment is booked for the applicant to visit the physio-

therapy.

As illustrated, appointments are included as part of the

business processes of various public services. Therefore,

instead of developing individual solutions for each of

these services, providing an e-Appointment service as

part of the software infrastructure for Electronic Gov-

ernment would facilitate the rapid development and

efficient provision of such services.

2.2. CONCEPTS

An appointment is an arrangement for a meeting, as

defined by the Merrian-Webster Dictionary [2]. Our pro-

posed definition is presented below.

Definition 1: Appointment

An appointment is an arrangement between parties

for interacting at a certain time and place for a specific

purpose.

For example, a citizen and the local government who

agree to have a meeting in a given place for the citizen

to be examined before issuing a driving license.

Since we are focusing on appointments which are in-

volved in the delivery of public services, the appoint-

ment itself can be treated as a service. Consequently, it

can be transformed into an e-service. In order to trans-

form the appointment service into an e-service, the

interactions between parties - for making the arrange-

ment, should be supported through ICT. In this way, the

concept of e-Appointment emerges.

Klischewski defines e-Appointment as an Internet-

mediated agreement between two or more parties as

social subjects (person or institution) to interact at a

certain time and place for a certain purpose, such as a

business meeting or medical treatment [3]. The follow-

ing definition of e-Appointment is proposed.

Definition 2: e-Appointment

e-Appointment is a service providing an agreement

between a service consumer and the service provider

for interacting at a certain future time and place

(physical or virtual) for a specific purpose. The agree-

ment is achieved through a series of ICT-supported

interactions.

Main differences can be highlighted between the last

definition and the one provided by Klischewski, such as:

1) e-Appointment is a service – all service-related

concepts can be applied, like service consumer and

provider, business process supporting the delivery

of the service, the interactions for providing the

service, benefit delivered by the service, etc.;

2) the concrete benefit delivered by the service is an

agreement;

3) the agreement involves two parties – service con-

sumer and service provider;

4) the agreement is about interacting in the future

(i.e. the interaction will take place on a future date

and time;

5) the future interaction may take place in a physical

place – like a hospital; or in a virtual place – like an

e-forum;

6) the agreement pursues a specific purpose. Since

parties know in advance the purpose of the meet-

ing, they are able to fulfill the pre-defined require-

ments for the future interaction. For example, an

agreement for clinical analysis, requiring the pa-

tient not to eat during a given time before the

analysis takes place;

7) the agreement is achieved through a series of inte-

ractions; and

8) the agreement is not restricted to be done through

the Internet; it is achieved through interactions

supported by ICT.

Finally, Klischewski [3] differentiates between the ap-

pointment and the booking services. He emphasizes that

appointments involve agreements between social actors

– like persons or institutions; while bookings involve

physical resources, like booking a venue, or booking a

seat for a government press conference.



4

2.3. PROCESS

In order to better understand the requirements for de-

veloping an e-Appointment service, Klischewski [3] iden-

tifies three main phases as part of the process for deli-

vering the service – Pre-appointment Activities, Ap-

pointment Negotiation, and Post-Appointment activi-

ties; and provides concrete examples for the interac-

tions taking place during these phases.

Aiming at defining the underlying business process for

providing e-Appointment services, we follow the three

main stages identified by Klischewski. However, we re-

name the activities as Pre-Application, Application and

Post-Application phases, in order to avoid any confusion

that could be raised by using the Post-Appointment

name to refer to the actions that could take place after

the agreement itself (appointment) and not after the

date on which the appointment was agreed. In addition,

we enrich the model by defining tasks that the two par-

ties – service provider and service consumer can ex-

ecute during these phases. The process is depicted in

Table 2 and explained below.

The Pre-Application phase comprises all the tasks that

the parties can execute before negotiation of the

agreement takes place. For instance, during this phase,

the service provider shall announce the e-appointment

service in support of a public service (S); define the loca-

tions (places) and working hours (times) where the inte-

ractions regarding S can take place; and register some

performance measures related to S, like number of cus-

tomers that can be served at a time; mean time for serv-

ing a customer; and how many minutes in advance the

service provider would like to remind the applicant

about the agreed interaction (reminder notification)

time. At the same time, the service consumer can search

for the required service (S); find the e-appointment ser-

vice supporting the delivery of S; and find information

about S, like the application form, eligibility criteria,

required supporting documents, delivery channels, deli-

very centers, etc.

Table 2: Main Tasks of the e-Appointment Business Process

ACTIVITY SERVICE PROVIDER – TASKS SERVICE CONSUMER – TASKS

Pre-

application

P1 Announce the e-Appointment service in

support of a public service (called S)

S1 Search for the required service (S)

P2 Define places for S-related interactions S2 Find e-Appointment for S

P3 Define times for S-related interactions S3 Find S-related information, like:

- application form,

- supporting documents,

- delivery channels,

- delivery centers,

- …

P4 Register performance measures for S, like:

- number of consumers served at a time;

- mean time for serving each consumer;

- notification period of time.

Application P5 Negotiate place for S-related interaction S4 Negotiate place for S-related interaction

P6 Negotiate time for S-related interaction S5 Negotiate time for S-related interaction

P7 Provide pre-defined requirements for at-

tending the agreed interaction

S6 Receive pre-defined requirements for at-

tending the agreed interaction

S7 Notify the service provider about special

conditions

Post-

application

P8 Notify consumer about the agreement S8 Fulfill the requirements for attending the

agreement

P9 Ensure resources are available for provid-

ing S on the agreed places and at the

agreed time

S9 Cancel existing agreement

S10 Modify existing agreement

P10 Remind consumer about the agreement S11 Be present at the place at the agreed time



5

The Application phase involves those interactions be-

tween the parties that enable them to set the agree-

ment. For instance, both parties need to negotiate the

place and time for the interaction. In addition, the ser-

vice provider shall provide information about the re-

quirements that the consumer needs to fulfill before the

meeting; while the service consumer shall receive such

information. In addition, the service consumer can noti-

fy the service provider about special conditions he/she

would like before an interaction is agreed upon.

The Post-application phase comprises all possible ac-

tions that the parties can execute after the agreement is

established. For example, the service provider notifies

the consumer about the confirmed agreement; assures

all the required resources will be available for the inte-

raction; and remind the service consumer some time in

advance that the interaction will take place. The service

consumer fulfills the requirements before at-tending the

interaction and is available at the time and place agreed.

In addition, the service consumer can modify or cancel

an existing agreement.

The following section discusses implementation ap-

proaches for each phase.

2.4. IMPLEMENTATION APPROACH

Based on the business process tasks defined in the pre-

vious section, an implementation approach for each of

them is depicted in Table 3 and explained as follows.

Some tasks could be provided by available services of-

fered by the government portal since they involve pub-

lishing information on the portal and facilitating access

to an e-service through the portal. For instance, P1 -

Announce the e-Appointment service in support of

another public service (called S); P7 - Provide pre-

defined requirements for attending the agreed interac-

tion; S1 – Search for the required service (S); S2 – Find e-

Appointment for S; and S3 – Find S-related information.

Task P9 - Assure resources are available for providing S

at the agreed places at the agreed time; should be ex-

ecuted according to organizational procedures.

Some of the tasks executed by the service consumer are

out of the scope of public administrations since they are

consumer’s responsibility, like: S6 - Receive pre-defined

requirements for attending the agreed interaction; S8 -

Fulfill the requirements for attending the agreement;

and S11 - Be present at the place and time agreed.

Table 3: Implementation Approach for Main Tasks of the e-Appointment Business Process

ACTIVITY SERVICE PROVIDER – TASKS SERVICE CONSUMER – TASKS

Pre-

application

P1 Service of the government portal S1 Search service of the government portal

P2 e-Appointment function S2 Search service of the government portal

P3 e-Appointment function S3 Search service of the government portal

P4 e-Appointment function

Application P5 e-Appointment function S4 e-Appointment function and optionally

Authentication service

P6 e-Appointment function S5 e-Appointment function and optionally

Authentication service

P7 e-Appointment function and/or search

services of the government portal

S6 Out of scope

S7 e-Appointment function

Post-

application

P8 e-Appointment function and Notification

service

S8 Out of scope

P9 Organizational procedures S9 e-Appointment function

S10 e-Appointment function

P10 e-Appointment function and Notification

service

S11 Out of scope



6

Table 4: e-Appointment Functions

ACTIVITY FUNCTIONS

Pre-

application

P2 Define places for S-related interaction

P3 Define times for S-related interaction

P4 Define performance measures for S

Application P5 – S4 Negotiate place for S-related interaction

P6 – S5 Negotiate time for S-related interaction

P7 Notify the service provider about special conditions

Post-application P8 Notify consumer about agreement

P10 Remind consumer about agreement

S9 Cancel existing agreement

S10 Modify existing agreement

All other tasks should be provided by the e-appointment

service, like P2 - Define places for S-related interactions;

P3 - Define times for S-related interactions; P4 - Register

performance measures for S; P5 and S4 – Negotiate

place for S-related interaction; P6 and S5 – Negotiate

time for S-related interaction; P7 - Provide pre-defined

requirements for attending the agreed interaction; P8 –

Notify the consumer about the agreement; P10 – Re-

mind the consumer about the agreement; S7 – Notify

the provider about special conditions; S9 – Cancel the

agreement; and S10 – Modify the agreement. In addi-

tion, P8 and P10 – Notify and Remind the consumer

about the agreement, may involve the notification ser-

vice of the software infrastructure. In addition, if the

service requires authenticating the applicant, tasks S4

and S5 – Negotiate place and time for S-related interac-

tion, can be supported by the Authentication service of

the software infrastructure.

In summary, Table 4 presents the list of tasks that shall

be considered as functionality offered by the e-

Appointment service. The tasks include defining places,

times and performance measures for S-related interac-

tion; negotiate place and time for the interaction; notify

the service producer about special conditions; notify

and remind the service consumer about the agreement;

and cancel and modify an existing agreement.

Except for the appointment negotiation tasks (P5-S4 and

P6-S5), all other functions involved in the e-

Appointment service are simple tasks to be automated,

since they involve updating information in a database.

For the appointment negotiation tasks, Klischewski [3]

differentiates two possible approaches for negotiating

the agreement:

1) Consultation hour - the provider informs the avail-

able dates and times; the consumer selects and

submits his/her choice, the provider and optionally,

the consumer confirms the agreement.

2) One-on-one appointment - the consumer submits

his/her choices and/or restrictions, the provider

presents the available choices matching the con-

sumer’s preferences, the consumer selects and

submits his/her choice, and the provider confirms

the agreement.

The first approach minimizes the number of interactions

required to reach an agreement and is the most com-

monly used. Therefore, the one adopted in this work.

However, we present a more refined version explained

as follows. We introduce the idea that there might be

several locations where the interaction can take place,

and each of them may have different working hours.

Consequently, the consumer, first selects the location,

and second, selects the date and time. In summary, the

agreement negotiation can be executed according to the

following sequence: 1) service provider informs availa-

ble places; 2) service consumer selects place; 3) service

provider informs available times; 4) service consumer

selects time; 5) service provider confirms place and

time; and 6) service consumer confirms place and time.

The sequence is illustrated in Figure 1.



7

Figure 1: Appointment Negotiation Process

2.5. CHALLENGES

As Klischewski has pointed out [3], there are no scientif-

ic publications about e-Appointment mainly due to the

rather simple implementation problem when consider-

ing the appointment for one single service. However,

while attempting to generalize the appointment service

and conceiving it as an infrastructure service, various

challenges arise. Some of them are presented below.

C1) Communication Infrastructure – the e-Appointment

service, part of the software infrastructure, should

be accessible through the government portal.

However, the service needs to provide information

about the confirmed agreements to several gov-

ernment agencies responsible for delivering servic-

es using the e-Appointment solution. A secure

communication infrastructure is needed to ex-

change appointment-related information between

the government portal and agencies providing ser-

vices.

C2) Standardized Data – each government agency pro-

viding services using the e-Appointment solution

may have its own computerized records about the

available places and times in which the interactions

can take place. Standardized data shall be available

for the e-Appointment solution to be able to re-

trieve them.

C3) Back-Office Heterogeneity – each government

agency providing services using the e-Appointment

solution may have its own software applications

supporting the back-office processes. The e-

Appointment shall be able to communicate the

agreements made with different IT platforms on

which these software applications are deployed.

C4) Multi-Channel Delivery – as any other service, a

multi-channel delivery approach may be adopted

for e-Appointment; meaning that service consum-

ers should be able to make appointments through

various channels, like portal, phone, SMS, counter,

call centre, fax, etc. If a multi-channel delivery ap-

proach is implemented, the e-Appointment solu-

tion shall be able to fit within the existing ap-

proach.

C5) Service Parameterization – since each service using

the e-Appointment may have its own performance

measures; the e-Appointment solution shall pro-

vide a mechanism to easily configure parameters

for each service.

C6) Infrastructure Integration – if a software infrastruc-

ture providing common functionality – like authen-

tication and notification services; is deployed, the

e-Appointment solution shall be able to integrate

and interact with the infrastructure components

and services.

2.6. CASE STUDIES

Experiences of e-Appointment services from Greece and

Singapore were analyzed. The findings are presented in

Section 2.6.1. The next sections present in details each

of the case studies analyzed.

2.6.1. FINDINGS

1) The experience from Greece, although is not an e-

Appointment infrastructure service since it only

sup-ports services provided by one government

agency, explains clearly the benefits achieved by

implementing an e-Appointment solution. The case

study presents concrete performance indicators

and measurements demonstrating the improve-

ments achieved in efficiency.

2) Two experiences from Singapore were analyzed – i)

provided by the Ministry of Home Affairs and ii)

provided by the Ministry of Manpower. Both solu-

tions are different; showing the lack of a common

e-Appointment service, part of software infrastruc-

ture for Electronic Government.

3) The Singapore experience from the Ministry of

Home Affairs shows an e-Appointment service sup-

porting various services delivered to different reci-

pients – like citizens, permanent residents and

tourists- all provided by the same government

agency. The service does not provide a standar-

dized mechanism for authenticating applicants;

uses different data for each service.



8

4) A good design feature implemented in the solution

provided by the Ministry of Home Affairs of Singa-

pore is the user interface. For example, it made

good use of colors to highlight different options –

like holidays, available and non-available dates for

appointments.

5) Two special features implemented in the solution

provided by the Ministry of Home Affairs of Singa-

pore include: 1) issuing of a receipt after confirming

the appointment for some services; the applicant is

required to bring the receipt to the appointment;

2) managing different validation rules for each ser-

vice; for example, the time in advance for changing

an appointment.

6) The Singapore experience from the Ministry of

Manpower shows a very simple and friendly ser-

vice, although it seems very unreliable – no exhaus-

tive validations are executed and while submitting

the results of a questionnaire about the service, an

error was obtained informing that the database

was not available.

2.6.2. GREECE – E-APPOINTMENT SERVICE IN HEALTH

AREA

The National Organization for Medicines (EOF) [5] of

Greece is a public entity under the Ministry of Health

and Solidarity responsible for ensuring the public health

and safety regarding specific products, like medicines for

human and veterinary use, feeding stuffs and food addi-

tives, food supplements, medical devices, and cosmet-

ics, among others. Within EOP, the Validation of Appli-

cations and Marketing Authorization Division (DDYEP) is

responsible for validating all applications submitted to

EOF, for issuing all EOF licensing decisions concerning

approval, renewal, modification and withdraw of mar-

keting authorizations, and for storing and maintaining all

EOF records.

DDYEP has deployed an e-Appointment system [5]

through which pharmaceutical companies can arrange

scheduled appointments. Some of the driving forces

creating the need for the e-Appointment solution in-

clude: i) to provide a solution to the increasing pressure

on resource utilization; ii) to be more customer-focused;

iii) to seek out and make use of available technologies;

iv) to better utilize the time of personnel and stakehold-

ers; and v) to secure transparency and equity.

Strategic and operational objectives were defined for

the e-Appointment service. The strategic objectives

include: i) to increase process transparency by directly

involving the consumers (pharmaceutical companies) in

the formulation of the visit schedule; ii) to ensure fair

treatment to all pharmaceutical companies; iii) to pro-

vide services based on the consumers’ needs rather

than on the division capabilities; iv) to create an envi-

ronment of common purpose and cooperation between

DDYEP and the pharmaceutical companies; v) to develop

a standardized process which can be monitored, meas-

ured, analyzed, and continuously improved; and vi) to

build capacity among pharmaceutical companies and

staff for future development comprising e-services. The

operational objectives comprise: i) to increase effective-

ness by controlling the amount of time for serving each

company; ii) to eliminate idle time between companies

visits; iii) to control the differences between the time

spent with each company, for ensuring all receive the

services they require; and iv) to ensure effective long

term scheduling for staff activities.

Table 5: Greece DDYEP e-Appointment Service - Performance Indicators

KEY PROCESS INDICATOR BEFORE AFTER IMPROVEMENT

Number of appointments 8063 9024 12%

Number of appointments served per staff 1675 2112 26%

Number of calls for arranging appointment 1-5 0 100%

Number of visits for arranging appointment 1-3 1-2 50%

Variance between appointment desired and scheduled 50% 20% 60%

Employee time spent in arranging appointments 20% 0 100%

Statistics available to pharmaceutical companies – number of appoint-

ments scheduled, held, missed, per category, for a given time, etc not known recorded 100%

Statistics available to DDYEP – number of appointments scheduled,

held, missed, repeated, per category, per assessor, per a given time, etc not known

recorded

analyzed 100%



9

Some of the lessons learnt after deploying the solution

include: 1) the increased transparency for scheduling

visits has proactively addressed pharmaceutical compa-

nies’ grievances, and has helped in cultivating spirit of

common purpose; 2) a systematic analysis of statistics

enables to improve efficiency in managing the workload

and making better use of limited resources; and 3) anal-

ysis of the statistics of visit schedules enables better

staffing decisions, and hence provides better services to

companies.

Results about the improvements gained with the dep-

loyed solution are presented in Table 5. The results

show how the total number of appointments served

increased by 12%; the number of appointments served

by each staff increased by 26%; the number of calls for

arranging appointments dropped to zero; while the

number of visits for the same purpose also decreased by

50%. The latter two results help to reduce the time

spent by employees in arranging appointments to zero.

The differences between the appointments desired and

scheduled improved by 60%. Finally, statistics are avail-

able for the pharmaceutical companies and for DDYEP.

2.6.3. SINGAPORE - E-APPOINTMENT SERVICE IN

MINISTRY OF HOME AFFAIRS

The Immigration and Checkpoints Authority (ICA) [7] of

Singapore is a government agency under the Ministry of

Home Affairs. ICA is responsible for the security of Sin-

gapore’s borders including the entry of undesirable per-

sons and cargo through land, air and sea checkpoints.

ICA is also responsible for issuing ID cards and passports

to Singapore citizens, and various immigration permits

and visas for tourists.

ICA has deployed an e-Appointment system [5] through

which citizens, permanent residents and visitors can

arrange an appointment to receive various services. For

example, i) citizens can arrange appointments for col-

lecting Identity Card (IC) and passport, and for modifying

an existing appointment (Citizenship Registration); ii)

permanent residents can arrange appointments for ap-

plying for Permanent Residence (PR), for renewing or

transferring the Re-Entry Permit (REP) or Certificate of

Identity (CI), and for completing Permanent Residence

formalities; iii) visitors can arrange appointments for

completing visit pass and Secure Trade Partnership (STP)

formalities, and for changing an existing appointment

(e-XTEND). Figure 2 shows the different types of servic-

es which are supported by the e-Appointment service.

Figure 2: Singapore – ICA e-Appointment Service



10

Four main features of the solution include:

1) Different data is used to authenticate the service

consumer depending on the service. For instance, if

a citizen would like to change a previous appoint-

ment (Citizenship Registration), he/she needs to

provide the application ID; for collecting the IC (Col-

lection of IC), he/she needs to provide the number

of the National Registration Identity Card (NRIC)

and the NRIC date of issue; while for collecting the

passport (Collection of Passport), he/she needs to

provide the NRIC and the File reference numbers.

Figure 3 shows these examples.

2) Colors are used for indicating to the service con-

sumer the status of the available times. For in-

stance, when a citizen would like to change an ap-

pointment, a calendar is shown on the screen, as

the one presented in Figure 4. The current appli-

cant’s appointment is highlighted in orange (Thurs-

day 31); the available dates are shown in green

(like Friday 18), non-working days are indicated in

pink (like Sunday 20), while days on which all ap-

pointments are booked are shown in grey (like

Thursday 24).

3) Validation rules are defined for each service. For

instance, for collecting ICs, appointments can be

changed at least two days before the appointment

date and the appointment can be changed only

twice; while for applying for permanent residence

the appointment can be changed at least one day

before the scheduled date.

4) A receipt, like the one presented in Figure 5, is is-

sued for some of the services. The applicant is re-

quired to carry this acknowledgment when attend-

ing the appointment, and scan it in the Self Service

Ticketing Kiosk for the queue ticket.

Figure 3: Singapore – ICA e-Appointment Service –

Authenticating Applicants

Figure 4: Singapore – ICA e-Appointment Service – Retrieving an Appointment



11

Figure 5: Singapore – ICA e-Appointment Service – Appointment Receipt

2.6.4. SINGAPORE - E-APPOINTMENT SERVICE IN MINIS-

TRY OF MANPOWER

The Labour Relations and Workplace Division (LRWD) [9]

is a government unit under the Ministry of Manpower of

the Government of Singapore. LRWD is responsible for

promoting and maintaining industrial peace and stability

in Singapore by providing a legal framework to balance

the interests of employers and employees.

LRWD provides an e-Appointment service [10]. The ser-

vice allows a person to book an appointment through

the Internet to consult the Division Advisory Officers on

the Employment Act. Therefore, the e-Appointment

solution only supports one service.

Main features of the solution include:

1) The first mandatory page for accessing the e-

Appointment service is related to terms and condi-

tions of the use of the service (Figure 6.) Consum-

ers must accept the conditions to access the ser-

vice.

2) The service enables the applicant to make a new

appointment, view, cancel or re-schedule an exist-

ing appointment.

3) The applicant is not authenticated when accessing

the service.

4) A demo online – provided as a pdf file; is available

for explaining the process for obtaining the ap-

pointment to the applicant.

Figure 6: Singapore – LRWD e-Appointment Service – Terms and Conditions



12

Figure 7: Singapore – LRWD e-Appointment Service – Negotiating Time

5) The process comprises three steps. The first step

presents a calendar showing the available dates

and time, and requests the applicant to select his

choice – See Figure 7. Non-working days are identi-

fied in grey (like 7-8 February), unavailable times

are shown in orange (like all times on 9 February),

and available times are indicated in blue (like all

times on 11 February). The second step requests

the applicant to fill a form indicating the type of

appointment requested – claim or enquiry about

Employment Act, and his personal data – like type

of identifier (NRIC, FIM – Foreigner Identification

Number, Passport, or Work Permit) and number,

name, mobile, and office/home phones, email ad-

dress, home address, and an explanation of the

purpose of the visit. The form is illustrated in Figure

8. Finally, the third step confirms the appointment

and allows the applicant to print a receipt.

6) Few validations are executed when making an ap-

pointment. Except controlling that all mandatory

fields are completed and that the home/office

phone is valid, no other validations are applied. It is

possible to make an appointment with entirely fake

data – only a valid phone is required.

7) To retrieve an existing appointment, the applicant

needs to inform the identification he/she used to

make the appointment and the appointment date.

In this way, the applicant must remember these da-

ta in order to modify, cancel, or view an existing

appointment. See Figure 9.

8) A survey is available for providing feedback. After

completing and submitting the form, an error mes-

sage was presented indicating that the sys-

tem/database was down.



13

Figure 8: Singapore – LRWD e-Appointment Service – Providing Personal Data

Figure 9: Singapore – LRWD e-Appointment Service – Retrieving an Appointment

SECTION 3 – REQUIREMENTS


14

3. REQUIREMENTS

This section describes the functional and non-functional

software requirements for the e-Appointment service.

Each requirement is assigned the following fields:

1) a unique identifier,

2) requirements category,

3) textual description,

4) list of glossary terms used,

5) justification for the requirement,

6) implementation priority,

7) feasibility of the requirement and

8) criteria for verifying the requirement.

The category field has two possible values: functional or

non-functional. The implementation priority has three

possible values: high, medium or low.

The following sections describe in details the functional

and non-functional requirements.

3.1. FUNCTIONAL REQUIREMENTS

The functionality that shall be provided by the e-

Appointment service is defined according to three main

user categories: i) portal administrator – person respon-

sible for the administration of the government portal; ii)

service providers – persons responsible for operating

the e-Appointment Service in each of the agencies deli-

vering services supported by e-Appointment; and iii)

service consumers – persons requesting appointments.

The requirements are explained in the following sec-

tions as follows:

1) Section 3.1.1 – Managing e-Appointment Service,

describes the functionality for the portal adminis-

trator;

2) Section 3.1.2 - Managing Supported Services,

presents the functionality for service providers; and

3) Section 3.1.3 – Requesting Appointments, intro-

duces the functionality for service consumers.

3.1.1. MANAGING E-APPOINTMENT SERVICE

As any other e-service, access to the e-Appointment

service should be offered through the one-stop govern-

ment portal. The functionality that shall be provided for

the portal administrator involves managing data about

those services for which appointments are required as

part of their business process, and the agencies provid-

ing those services. In addition, to avoid applicants book-

ing an appointment on a public holiday, data about pub-

lic holidays shall be available. The following three re-

quirements address these needs.

Requirement 1: Administering Agencies

ID F1

CATEGORY Functional

DESCRIPTION Information about agencies providing services requiring appointments as part of their delivery

process shall be available. Data about the communication structures used for exchanging informa-

tion with these agencies shall be maintained.

TERMS Agency, Communication Structures

JUSTIFICATION Allows keeping information about the agencies which are responsible for carrying out the appoint-

ments and all communication-related data enabling information exchange between the portal and

the agencies.

PRIORITY High

FEASIBILITY It can be implemented through a simple function updating data in a database.

VERIFICATION Log in as portal administrator, view agencies, add two agencies, view the updated data, remove

one agency, view the updated data, and log out.



15

Requirement 2: Administering Services List

ID F2

CATEGORY Functional

DESCRIPTION Information about the services requiring appointments as part of their delivery processes shall be

available. For each service, information about the providing agency shall also be maintained.

TERMS Service

JUSTIFICATION To make an appointment, the applicant shall specify the service for which he/she is requesting the

appointment.

PRIORITY High


VERIFICATION Log in as portal administrator, select an agency, add two new services, view the updated data, re-

move the second added service, view the updated data, and log out.

Requirement 3: Managing Public Holidays

ID F3

CATEGORY Functional

DESCRIPTION Public holidays representing non-working days for all government agencies shall be maintained. If

the government portal already maintains information about public holidays, this information

should not be duplicated. In this case, this requirement shall be interpreted as providing a function

to get this data.

TERMS Public Holiday

JUSTIFICATION A list of all non-working days for all government agencies shall be maintained to avoid applicants

booking appointments for those days.

PRIORITY High


VERIFICATION Log in as portal administrator, view holidays, add two new holidays, view the updated data, delete

one holiday, and log out.



16

3.1.2. MANAGING SUPPORTED SERVICES

Service providers (agencies) shall be able to define

which of the services provided by them require appli-

cants to make appointments (supported services),

where the services are provided (centers), days in which

appointments cannot be made (non-working days), and

hours in which appointments can take place (working

hours). In addition, service providers shall be able to

update service parameters – like number of persons

that can be served at a time (counters), mean time for

serving a person (service time), minutes in advance to

remind the applicant about the appointment (reminder

notification time). Finally, service providers shall be able

to view and export to a file the appointments done for a

particular date. The following requirements specify

these functions.

Requirement 4: Managing Services Data

ID F4

CATEGORY Functional

DESCRIPTION Information about services requiring appointments shall be available. For each service, data about

performance measures – like mean time for serving a person (service time), and minutes in ad-

vance to remind the applicant about the appointment (reminder notification time) shall be main-

tained.

TERMS Service Time, Reminder Notification Time

JUSTIFICATION Information about the service time is required for being able to show applicants the available times

for the appointments. Information about the reminder notification time is needed for sending an

appointment reminder to applicants.

PRIORITY High


VERIFICATION Log in as portal administrator, select an agency, add two new services, add its parameters, view the

updated data, update the parameters of the first added service, remove the second added service,

view the updated data, and log out.

Requirement 5: Managing Centers

ID F5

CATEGORY Functional

DESCRIPTION For each service requiring appointments, information - like name and address, about the centers in

which the appointments can take place shall be maintained. Appointments for a service can be

provided in more than one center, and one center can serve appointments for several services. For

each center and service, the number of applicants that can be served at a time shall be maintained

(Counters)

TERMS Center, Counter

JUSTIFICATION Appointments related to one service can take place in more than one place, not necessarily the

government agency. Information about these places shall be stored.

PRIORITY High


VERIFICATION Log in as agency administrator, select an agency, add one service, add two centers, view centers,

delete one center, view the updated data, and log out.



17

Requirement 6: Managing Non-Working Days

ID F6

CATEGORY Functional

DESCRIPTION Each agency shall be able to define its own non-working days in addition to the public holidays.

Non-working days are applicable to all centers serving appointments for the services provided by

the agency.

TERMS Non-working Day

JUSTIFICATION An agency should be able to define a non-working days in addition to public holidays.

PRIORITY High


VERIFICATION Log in as agency administrator, add two non-working days, view non-working days, delete one non-

working day, view the updated data, and log out. Log-in as user, try to make an appointment for

the non-working day, and log out.

Requirement 7: Managing Working Hours

ID F7

CATEGORY Functional

DESCRIPTION Each agency shall be able to define the working hours. Working hours are related to the service and

the center - different services may have different working hours, and the same service can be deli-

vered during different working hours in the centers.

TERMS Working Hour

JUSTIFICATION In order to make appointments, working hours are needed for defining the available times.

PRIORITY High


VERIFICATION Log in as agency administrator, select an agency, add one service, add one center, add two working

hours, view working hours, delete one working hour, view the updated data, and log out. Log in as

user, try to make an appointment during non-working hours, make an appointment during work-

ing-hours, and log out.



18

Requirement 8: Viewing Appointments

ID F8

CATEGORY Functional

DESCRIPTION Each agency shall be able to retrieve the appointments done for a particular date.

TERMS Appointment

JUSTIFICATION It is necessary to know in advance the appointments confirmed for a specific date in order to plan

the required resources for serving government customers.

PRIORITY High

FEASIBILITY It can be implemented through a simple function retrieving data from the database.

VERIFICATION Make appointments for one date. Log in as agency administrator, input the date for which the ap-

pointments have been made, view the appointments, and log out.

Requirement 9: Exporting Appointments

ID F9

CATEGORY Functional

DESCRIPTION Each agency shall be able to export the appointments done for a particular date.

TERMS Appointment, Export

JUSTIFICATION It is necessary to know in advance the appointments confirmed for a specific date in order to plan

the required resources for serving government customers, and to be able to export these data for

being able to process it by another software application.

PRIORITY High

FEASIBILITY It can be implemented through a simple function retrieving data from the database.

VERIFICATION Make appointments for one date. Log in as agency administrator, input the date for which the ap-

pointments have been made, export the appointments and log out.



19

2.1.3. REQUESTING APPOINTMENTS

Government customers shall be able to make appoint-

ments, cancel or modify an existing appointment, re-

ceive notifications about the appointments they con-

firmed or cancelled, and receive a reminder before the

appointment will take place. The following requirements

define these functions.

Requirement 10: Making Appointment

ID F10

CATEGORY Functional

DESCRIPTION The system shall implement a function enabling a user to make an appointment for a particular

service. The negotiation process shall be divided in steps, and in each step the user shall be allowed

to continue or return back to the previous step. The process shall be clearly explained to the user

before it starts. An estimation of the amount of time required for completing the process shall be

informed to the applicant when the process starts. The negotiation process executed by the con-

sumer includes: selecting the service for which the appointment is required; selecting the center;

selecting a suitable date and time, and confirming the choice.

TERMS Appointment

JUSTIFICATION This is the main function provided by the service.

PRIORITY High

FEASIBILITY It requires exchanging information between the government portal and the agency. Once the

agency receives the data about the appointment, the data shall be stored in the agency database.

VERIFICATION Log in as user, make an appointment, and log out. Log in as agency administrator, view appoint-

ments, and log out.

Requirement 11: Cancelling Appointment

ID F11

CATEGORY Functional

DESCRIPTION The system shall implement a function enabling a user to cancel an existing appointment. The ap-

plicant shall receive a notification about the cancelled appointment. The applicant needs to be

authenticated for cancelling an appointment.

TERMS Appointment

JUSTIFICATION Enabling the user to cancel an existing appointment allows reducing the number of applicants no

showing up and making better use of government resources – since another user can booked an

appointment for the center/date/time of the one who was cancelled.

PRIORITY High


agency receives the data about the appointment, these data shall be updated in the database (the

existing appointment shall be deleted).

VERIFICATION Log in as user, make an appointment, and log out. Log in as agency administrator, view appoint-

ments, and log out. Cancel the appointment. Log in as agency administrator, view appointments,

and log out.



20

Requirement 12: Modifying Appointment

ID F12

CATEGORY Functional

DESCRIPTION The system shall implement a function enabling a user to modify an appointment that was pre-

viously done. The service shall delete the previous appointment and add the new one. The appli-

cant shall receive a notification about the new appointment.

TERMS Appointment

JUSTIFICATION Enabling the user to modify an existing appointment allows reducing the number of applicants no

showing up and making better use of government resources – since another user can booked an

appointment for the center/date/time of the one who was changed.

PRIORITY High


agency receives the data about the appointment, these data shall be updated in the database (the

existing appointment shall be deleted and a new appointment shall be added).

VERIFICATION Make an appointment. Log in as agency administrator, view appointments, and log out. Modify the

appointment. Log in as agency administrator, view appointments, and log out.

Requirement 13: Notifying Applicant

ID F13

CATEGORY Functional

DESCRIPTION The system shall implement a function notifying the applicant every time an appointment is done,

cancelled or modified. Notifications shall be sent through e-mail and SMS.

TERMS Appointment, Notification

JUSTIFICATION It is important for the user to receive a notification that the system registered precisely the action

he/she requested (make, cancel or modify an appointment)

PRIORITY High

FEASIBILITY It requires notifying the applicant according to his/her preferred channel (e-mail or SMS).

VERIFICATION Make an appointment and receive notification. Modify the existing appointment and receive notifi-

cation. Cancel the existing appointment and receive notification.



21

Requirement 14: Reminding Applicant

ID F14

CATEGORY Functional

DESCRIPTION The system shall implement a function reminding the applicant that the appointment will take

place. The notification shall be sent some minutes in advance, those indicated by the reminder

notification time. The service provider defines the reminder notification time as part of the service

parameters.

TERMS Appointment, Reminder Notification Time

JUSTIFICATION It is important for the user to receive a notification reminding him/her about the appointment.

PRIORITY High

FEASIBILITY It requires notifying the applicant according to his/her preferred channel (e-mail or SMS).

VERIFICATION Make an appointment and receive a notification before the appointment will take place.

3.2. NON-FUNCTIONAL REQUIREMENTS

The non-functional requirements for the e-Appointment

service address four major aspects of system quality:

reliability, security, generality and interoperability. Each

of them is described as follows.

3.2.1. RELIABILITY

The e-Appointment must essure that information about

appointments confirmed and cancelled through the

government portal is received by the agencies providing

the services.

Requirement 15: Exchanging Appointment-related Information

ID NF15

CATEGORY Non-Functional

DESCRIPTION The e-Appointment service shall be able to ensure that all appointments confirmed and cancelled

through the government portal are sent to the proper agencies. An agency shall receive only ap-

pointment-related information for the services delivered by it.

TERMS Reliability

JUSTIFICATION Users (service providers and consumers) shall trust the service is reliable.

PRIORITY High

FEASIBILITY The property can be fulfilled if communications between the government portal and government

agencies are supported by reliable communication infrastructure.

VERIFICATION Log in as user; make two appointments for two different services delivered by different agencies,

and log out. Log in as one of the service providers, view the appointments done and log out. Log in

as the other service provider, view the appointments done and log out.



22

3.2.2. SECURITY

Authentication and confidentiality are the security re-

quirements defined for the e-Appointment service. Au-

thentication ensures that access to the e-Appointment

service and its data is restricted to those who can pro-

vide the appropriate proof of identity. For instance, in

order to cancel an appointment, the applicant needs to

be authenticated. Confidentiality ensures that minimum

data are requested from applicants for making ap-

pointments, and that these data are stored and ex-

changed without risks of being tampered. The following

requirements address these issues.

Requirement 16: Authenticating users

ID NF16


DESCRIPTION Users – like service consumers, service providers and portal administrator shall be authenticated

for accessing functionality and data about appointments.

TERMS Authentication

JUSTIFICATION Only authorized users can have access to information managed by the e-Appointment service.

PRIORITY High

FEASIBILITY Authentication is a common feature in software applications.

VERIFICATION Log in as user; make an appointment, and log out. Log in as portal administrator, control the avail-

able functions and log out. Log in as service provider, control the available functions, view and ex-

port appointments for a specific date, check the information is only related to services delivered by

the agency, and log out.

Requirement 17: Ensuring Confidentiality

ID NF17


DESCRIPTION Information used for authenticating applicants shall be minimal. Information stored and ex-

changed shall be protected.

TERMS Confidentiality

JUSTIFICATION The amount of personal information used by the e-Appointment service shall be minimized and

disclosure of these data must be avoided.

PRIORITY High

FEASIBILITY The property can be fulfilled if an authentication mechanism is used, access to databases is re-

stricted only to those authorized, and communications rely on a secure network.

VERIFICATION Check that the authentication mechanism is in place. Check that only the authorized functions are

available for each user type. Check policies for accessing databases.



23

3.2.3. GENERALITY

Generality tries to minimize the need for changing the

software due to restrictions introduced during the de-

sign phase. Parameterization techniques can be used for

providing a general solution enabling service consumers

to make appointments for various services delivered by

different agencies. The following requirement describes

this feature.

Requirement 18: Ensuring Generality

ID NF18


DESCRIPTION The system shall rely as much as possible on service parameters which shall enable functions to

show different behavior according to the value of the parameters. Possible parameterization in-

clude: service mean time; service reminder notification time; whether the applicant needs to be

authenticated or not for making appointments; among others.

TERMS Configuration file

JUSTIFICATION The e-Appointment service shall be able to support various services, not only one. Specific re-

quirements for each service shall be considered.

PRIORITY High

FEASIBILITY Parameterization techniques are a common feature of software applications

VERIFICATION Log in as service provider, check the service mean time for a service, and log out. Log in as service

consumer, make an appointment, and log out. Log in as service provider, modify the service mean

time for the service, and log out. Log in as service consumer, check the times for making appoint-

ments, and log out.

3.2.4. INTEROPERABILITY

The e-Appointment service shall be able to interoperate

with other software infrastructure components and

services like authentication, notification, and the Mes-

saging Gateway.

Requirement 19: Ensuring Interoperability

ID NF19


DESCRIPTION The system shall be able to interact with other software infrastructure components.

TERMS Configuration file

JUSTIFICATION The e-Appointment service shall be able to interact with other software infrastructure components,

like the government portal, authentication and notification services, and be able to exchange in-

formation through the messaging gateway.

PRIORITY High

FEASIBILITY Interoperability can be assured if open standards and open source technologies and tools are used

for software development.

VERIFICATION Check whether messages are exchanged using the messaging gateway.

SECTION 4 – MODELING


24

4. MODELING

The following two sections describe the conceptual (Sec-

tion 4.1) and use case (Section 4.2) models for the e-

Appointment service.

4.1. CONCEPTUAL MODEL

The conceptual model depicted in Figure 10 describes

the e-Appointment-related concepts and their relation-

ships. For each concept, a definition is provided in the

Glossary and an explanation follows.

An Agency delivers Services (supported services)

through Centers. One Service can be delivered at various

Centers, and several Services can be delivered in one

Center. Services are delivered at Centers every day,

except Non-working Days, which include Public Holidays.

Non-working Days are defined for each Center. Services

are delivered at Centers through Counters. A Counter

serves one consumer at a time. Each Counter may de-

fine its own Working Hours.

Appointments are requested by Service Consumers for a

given Service. An Appointment involves a Notification.

There exist different types of Notifications (Notification

Type), like those sent through SMS or e-Mail.

Three types of Users are identified: i) Service Consumer

– applicants making appointments; ii) Service Provider –

persons responsible for managing appointments at the

agencies providing supported services; and iii) Portal

Administrator – person responsible for maintaining the

Government portal.

Figure 10: Conceptual Model



25

4.2. USE CASE MODEL

The top-level use case diagram is depicted in Figure 11.

Four main groups of services are provided:

1) Manage e-Appointment Service

2) Manage Supported Services

3) Request Appointments

4) Use Software Infrastructure

The top-level use cases are listed in Table 6 and are de-

scribed in the following sections.

Figure 11: Top Level Use Case Diagram

Table 6: Top-Level Use Cases

ID DESCRIPTION

UC-1 Manage e-Appointment Service

UC-2 Manage Supported Services

UC-3 Request Appointments

UC-4 Use Software Infrastructure

4.2.1. MANAGE E-APPOINTMENT SERVICE

The functionality provided to the portal administrator is

defined by the high-level use case Manage e-

Appointment Service. This use case comprises three

uses cases: Manage Agencies, Manage Services, and

Manage Public Holidays. These uses cases are depicted

in Figure 12 and are identified in Table 7.

The Manage Agencies use case enables management of

information about the agencies delivering services

which require appointments as part of their delivery

processes. For each agency, its identifier, name and the

channel identifier used for exchanging messages

through the Messaging Gateway shall be maintained.

New agencies can be added. Information about an exist-

ing agency can be modified, or deleted if the agency no

longer deliver services requiring appointments.

Figure 12: Use Case Diagram – Manage e-Appointment

Service



26

The Manage Service List use case allows keeping infor-

mation about the services for which the service con-

sumers can request appointments. For each service, its

identifier and name are maintained, together with in-

formation about the agency that is responsible for its

delivery. New services can be added to the list, and ex-

isting services can be removed if they do not require

appointments.

Finally, the Manage Public Holidays use case enables

storing information about official holidays for all gov-

ernment agencies and centers. Each holiday has an iden-

tifier and a date. To avoid information duplication, if

information about public holidays is already available at

the government portal, the functionality provided by

this use case shall be replaced by a function able to get

the list of public holidays.

Table 7: Use Cases – Manage e-Appointment Service

ID DESCRIPTION

UC-1-1 Manage Agencies

UC-1-2 Manage Services

UC-1-3 Manage Public Holidays

4.2.2. MANAGE SUPPORTED SERVICES

The functionality offered to service providers is defined

by the high-level use case Manage Supported Services.

This use case comprises seven use cases: Manage Ser-

vices Data, Manage Centers, Manage Non-Working

Days, Manage Counters, Manage Working Hours, View

Appointments, and Export Appointments. These uses

cases are depicted in Figure 13 and are identified in

Table 8.

The Manage Services Data use case enables manage-

ment of information about those services requiring ap-

pointment which are delivered by a particular agency.

For each service, its identifier, name and its perfor-

mance measures – like service time and reminder notifi-

cation time, are stored. In addition, information about

centers used for delivering the service is also main-

tained. Information about services can be modified. An

existing service can be deleted, if the service no longer

requires appointments.

The Manage Centers use case enables management of

the identification and addresses of those places where

appointments take place. New centers can be added,

and the data of existing centers can be modified and

deleted. Each agency stores information about the cen-

ters used for delivering its services.

The Manage Non-working Days use case allows registe-

ration of dates in which appointments cannot be re-

quested.

Each center can define its own Non-working Days. New

Non-working Days can be added and existing Non-

working Days can be deleted.

The Manage Counters use case enables defining how

many applicants can be served at a time for a particular

service in a given center. This data can be updated.

The Manage Working Hours use case allows defining the

time frame in which appointments can be requested.

For each day of the week, the starting and ending times

for arranging appointments is stored. Working Hours

can be added, modified and deleted.

Figure 13: Use Case Diagram – Manage Supported Services



27

The View Appointments use case enables the service

provider to retrieve all the appointments arranged for a

given date.

Finally, the Export Appointments use case enables the

service provider to generate a file with data about all

the appointments arranged for a given date.

Table 8: Use Cases – Manage Supported Services

ID DESCRIPTION

UC-2-1 Manage Services Data

UC-2-2 Manage Centers

UC-2-3 Manage Non-Working Days

UC-2-4 Manage Counters

UC-2-5 Manage Working Hours

UC-2-6 View Appointments

UC-2-7 Export Appointments

4.2.3. REQUEST APPOINTMENTS

The functionality offered to service consumers is de-

fined by the high-level use case Request Appointment.

This use case comprises three uses cases: Make Ap-

pointment, Cancel Appointment, and Change Appoint-

ment. These uses cases are depicted in Figure 14 and

are identified in Table 9.

The Make Appointment use case enables the applicant

to arrange an appointment related to a specific service.

After selecting the service, the process follows the set of

interactions depicted in Figure 1. Once the appointment

is confirmed, a notification is sent to the applicant.

Some validation rules can be defined for avoiding appli-

cants booking many appointments. In the pilot imple-

mentation, the rule specifies that an applicant is not

allowed to book more than three appointments with a

given agency.

The Cancel Appointment use case enables the applicant

to cancel an existing appointment. After cancelling the

appointment, a notification is sent to the applicant.

The Change Appointment use case enables the applicant

to change the date and time for an existing appoint-

ment. After changing an appointment, a notification is

sent to the applicant.

The Send Reminder use case enables to send a notifica-

tion to the applicant before the appointment will take

place. For sending the reminder, the service attribute

reminderNotificationTime is used. The notifica-

tion is sent as many minutes in advance to the appoint-

ment as the value of this attribute indicates.

The Send Notification use case allows sending a notifica-

tion to the applicant. The software infrastructure notifi-

cation service could be used for this purpose.

Figure 14: Use Case Diagram – Request Appointments



28

The Notify Applicant use case sends notifications to

service consumers. This function shall invoke the notifi-

cation service provided by the software infrastructure.

In the current release, it sends notifications by e-mail

and by SMS using Clickatell [26] service.

Table 9: Use Cases – Request Appointments

ID DESCRIPTION

UC-3-1 Make Appointment

UC-3-2 Cancel Appointment

UC-3-3 Change Appointment

UC-3-4 Send Notification

UC-3-5 Send Reminder

UC-3-6 Notify Applicant

4.2.4. USE SOFTWARE INFRASTRUCTURE

The e-Appointment service can rely on three software

infrastructure components and services: Authentication,

Notification, and Messaging Gateway. These uses cases

are depicted in Figure 15 and are identified in Table 10.

The Use Authentication use case aims to integrate the e-

Appointment service and the authentication service of

the software infrastructure. However, not all services

supported by the e-Appointment service require au-

thenticating the applicant. The implementation of this

use case could be done based on an attribute defined

for the service.

The Use Notification use case aims to integrate the e-

Appointment service and the notification service of the

software infrastructure. The implementation of this use

case is merely the invocation of the software infrastruc-

ture service.

The Use Messaging Gateway use case enables to invoke

the services of the Gateway for exchanging information

between the government portal and the agencies deli-

vering the supported services. For creating the commu-

nication structures – like registering members and creat-

ing and subscribing to channels, the user interface of the

Gateway is used. For sending and receiving messages,

the e-Appointment service relies on the Gateway APIs.

Since the implementation of the first two use cases (UC-

4-1 and UC-4-2) highly depends on the software infra-

structure services, they are not implemented in the

current release.

Table 10: Use Cases – Use Software Infrastructure

ID DESCRIPTION

UC-4-1 Use Authentication

UC-4-2 Use Notification

UC-4-3 Use Messaging Gateway

Figure 15: Use Case Diagram – Use Software Infrastructure



29

4.3. USE CASES VERSUS INFORMAL REQUIREMENTS

This section relates the informal requirements pre-

sented in Section 3 to the use cases described in Section

4.2. The relation is depicted in Table 11.

Table 11: Use Cases versus Functional Requirements

USE CASE DESCRIPTION FUNCTIONAL REQUIREMENTS

UC-1-1 Manage Agencies F1

UC-1-2 Manage Services List F2

UC-1-3 Manage Public Holidays F3

UC-2-1 Manage Services Data F4

UC-2-2 Manage Centers F5

UC-2-3 Manage Non-Working Days F6

UC-2-4 Manage Counters F5

UC-2-5 Manage Working Hours F7

UC-2-6 View Appointments F8

UC-2-7 Export Appointments F9

UC-3-1 Do Appointment F10

UC-3-2 Cancel Appointment F11

UC-3-3 Change Appointment F12

UC-3-4 Send Notification F13

UC-3-5 Send Reminder F14

UC-4-1 Use Authentication F10, F11, F12

UC-4-2 Use Notification F10, F11, F12

UC-4-3 Use Messaging Gateway F10, F11, F12

SECTION 5 – DESIGN


30

5. DESIGN

This section presents the design details of the e-

Appointment System. First, the static and dynamic views

of the architecture models are presented in Sections 5.1

and 5.2 respectively. Next, detailed structural design

diagrams for the major components are provided in

Section 5.3, while detailed behavioral diagrams are pre-

sented in Section 5.4.

5.1. ARCHITECTURE – STATIC VIEW

The static view of the system is depicted in Figure 16.

The system design follows a layered architecture com-

prising the following five main packages - User In-terface – Portal , User Interface – Agency , Core Business , Entities , and Data-base . The User Interface – Portal and the

User Interface – Agency provide classes im-

plementing all the web pages offering the functionality

that is available through a browser. The web pages are

grouped in three components: a common set of pages

required at the government portal and the agencies

(Common), a set of pages with the functions offered to

the portal administrator and users (Portal ), and a set

of pages offering functions to the service providers

(Agency ). The Core Business package implements

the e-Appointment business logic; for instance, it com-

prises classes implementing methods for making, can-

celling and modifying an appointment (Service ), for

sending and receiving messages between the govern-

ment portal and the agencies providing services (Com-munication ) and for storing some parameters of the

delivery channels used for sending notifications (Util ) .

The Entities package implements the system enti-

ties, like Agency – for representing government units;

Centers – for defining the places where the appoint-

ments will take place, and Service – for defining services

requiring appointments, among others. Finally, the Da-tabase package is responsible for managing the data-

base. It implements operations required for storing,

reading, updating, and deleting an entity from the data-

base.

Figure 16: Architecture – Static View



31

5.2. ARCHITECTURE – DYNAMIC VIEW

For illustrating a dynamic view of the architecture, Fig-

ure 17 presents high-level collaborations for making an

appointment. The collaborations are divided in four

steps following the process for negotiating the appoint-

ment. The three objects on the left – depicted in green,

reside at the government portal side, while the two

objects on the right – depicted in orange, reside at the

agency providing the service for which the appointment

is requested. The collaborations for each step are ex-

plained as follows.

Figure 17: Architecture – Dynamic View for Making an Appointment



32

In Step 1, the User requests a new appointment -

1:makeAppointment . Then, the user is requested to

select the service for which the appointment is required

- 2:requestService , and the user selects the ser-

vice - 3:selectedService . A request for getting the

centers - 4:getCenters , is forwarded to the portal

business layer, who prepares the message to be sent to

the provider agency - 5:msgToSend , and sends the

message - 6:sendMessage(getCenters) . After

receiving the message at the provider agency (AgencyA),

a request is sent to the database to retrieve this infor-

mation – 7:retrieve(centers) . The information

is sent back through all the involved components until it

reaches the user – 8:centers ,

9:receiveMessage(centers) , and 10-11:centers . Finally, the user selects the center –

12:selectedCenter .

In Step 2, the user is requested to provide appointment-

related data, like preferred delivery channels for receiv-

ing notifications, and text message to be sent to the

provider agency – 13:requestApplicantData .

The applicant provides his/her data –

14:applicantData , he/she is requested to select

the appointment date – 15:requestDate ; and in-

forms his/her choice – 16:selectedDate .

In Step 3, a request for getting the working hours is sent

to the portal business layer – 17:getWorkingHours ,

which prepares the message to be sent to the provider

agency – 18:msgToSend , and sends the message –

19:sendMessage(getWorkingHours) . After

receiving the request, the core business component at

the agency forwards the request to the database –

20:retrieveWorkingHours . The information ob-

tained is sent back to the user, through all the objects

requesting it – 21:workingHours ,

22:receiveMessage(workingHours) ,

23:workingHours , 24:workingHours . Finally,

based on the working hours indicated, the user selects

the preferred time for the appointment –

25:selectedTime .

In Step 4, a web page is shown for confirming the ap-

pointment – 26:requestConfirmation , and the

user confirms – 27:confirmation . A request is sent

to the portal business layer for sending the information

about the new appointment to the provider agency –

28: NewAppointment . A message is formatted -

29:msgToSend , and is sent to the agency –

30:sendMessage(new Appointment) . Upon

reception to the message at the agency, the new ap-

pointment is stored in the database –

31:store(Appointment) .

For simplicity of the diagram, the Entities component

was not shown. However, every time an entity is han-

dled – like centers, working hours, and appointment;

either at the portal or at the agency side, by any of the

tiers – user interface, core business or database, the

data is processed through the Entities component. In

addition, the information exchange between the gov-

ernment portal and the provider agency is done through

the Messaging Gateway, although this component was

not shown for the same reason.

5.3. DETAILED STRUCTURAL DESIGN DIAGRAMS

The following sections present detailed design for the

main layers of the architecture: User Interface, Core

Business and Database.

5.3.1. USER INTERFACE LAYER

The e-Appointment user interface is implemented as

part of a web application, which is built using Apache

Wicket (Wicket) framework [11]. Wicket is a framework

enabling the rapid development of Java-based web ap-

plications.

As mentioned before, three main components imple-

ment the user interface: i) UI-Common, ii) UI-Portal , and iii) UI-Agency .

The detailed design class diagram of UI-Common is

shown in Figure 18. Four main packages are shown: i)

Wicket Component ; ii) web.template ; iii) web;

and iv) web.session .

The Wicket Component represents the develop-

ment framework used.

The component web.template comprises the follow-

ing classes:

o Template – is an abstract class defining a general

template for all web pages. For instance, the tem-

plate includes the page header and footer.

o SecureTemplate – is a base class for all web

pages requiring authentication.

o Result – a general template to display some in-

formation. It provides a simple box. Its content can

be filled and displayed.

o PendingAppointment – a general template

displaying a fixed message explaining that there are

pending appointments. It is used when a deletion

request cannot be satisfied due to this reason.

o ConfirmLink – a general template requesting a

confirmation. Every time a deletion request is sub-

mittted, this class is used for getting the user’s con-

firmation.

o DateSection – a template for displaying the

schedule of working hours for a particular date. It

shows which are the available and the unavailable

times.



33

o TimeField – a template for managing the start-

ing and ending time of working hours, showing the

hour and minutes.

The web component includes three classes: i) Appli-cation – this class is required by the Wicket frame-

work for managing all requests; ii) Login – is a con-

crete page instantiating the Template class provided

by the web.template component; it enables the user

to log in; and iii) Home Page – is a concrete page in-

stantiating SecureTemplate for implementing the

home page of the application.

The web.session contains one class –

My.session , for handling the sessions. In this release,

information about the current user is maintained.

The detailed design class diagram of UI-Portal is

shown in Figure 19. Four main packages are shown: i)

web.agency; ii) web.holidays ; iii)

web.service ; and iv) web.appointment

Figure 18: Design Class Diagram – e-Appointment Common Web Pages

Figure 19: Design Class Diagram – e-Appointment Portal Web Pages



34

The web.agency package comprises two classes for

creating or editing agencies providing services requiring

appointments (Create ) and for listing and deleting

these agencies (List ).

The web.holidays package contains two classes for

creating public holidays (Create ) and for listing and

deleting existing public holidays (List ).

Similarly, the web.service package comprises two

classes: CreateFromPortal – enables to include one

service requiring appointments; and ListFromPor-tal – allows viewing and deleting services supported by

the e-Appointment service.

The web.appointment package contains the follow-

ing classes:

o NewAppointment – implements the functions

for showing information related to the appoint-

ment process when a new appointment is re-

quested;

o Cancel – implements the functions for deleting

an appointment;

o Update – implements the functions for modifying

an appointment, which comprises deleting the ex-

isting appointment and creating a new appoint-

ment;

o AppointmentWizard – implements the negoti-

ation process for getting an appointment. It keeps

information about the current step and allows

moving to the previous and next steps;

o AppointmentPage – is used to initiate the ap-

pointment process.

One more package is depicted in Figure 19 –

web.template . The package is shown in green co-

lour, since it belongs to the e-Appointment Com-mon Web Pages package. All classes in the e-Appointment Portal Web Pages package are

subclasses of the SecureTemplate class provided by

the web-template package.

The detailed design class diagram of the UI-Agency is shown in Figure 20. Five main packages are shown: i)

web.center; ii) web.service ; iii)

web.holidays ; iv) web.workingHours ; and v)

web.appointment .

web.center package includes classes for managing

the creation of a new center (Create ) and for listing

information about existing centers (List ). In addition,

it contains one class for managing the interactions when

there is a request for deleting a center and there are

appointments that will take place at this center (Cen-terPendingAppointment ).

web.service package includes classes for managing

the creation of a new service (Create ), for listing in-

formation about existing services (List ), for keeping

the relation between the service and the centers where

appointments related to the service can take place

(Center ), and for listing information about these cen-

ters (ListCenters ).

web.holidays package includes classes for managing

the creation of a new holiday or non-working day for the

agency (CreateFromAgency ) and for listing this in-

formation (ListFromAgency ). In addition, it contains

one class for managing the interactions when there is a

request for creating a non-working day for an agency

and there are appointments that will take place at this

date (HolidayPendingAppointment ).

Figure 20: Design Class Diagram – e-Appointment Agency Web Pages



35

web.workingHours package includes classes for

managing the creation of new working hours (Create )

and for listing this information (List ). In addition, it

contains one class for managing the interactions when

there is a request for updating working hours and there

are appointments that will take place at the time that

will be changed (WorlkingHourPendingAppoint-ment ).

web.appointment package includes classes for

listing existing appointments (List ) and exporting in-

formation about existing appointments to a file (Ex-port ).

One more package is depicted in Figure 20 –

web.template . The package is shown in green co-

lour, since it belongs to the e-Appointment Com-mon Web Pages package. All classes in the e-Appointment Agency Web Pages package are

subclasses of one of the classes contained in the

web.template package, although for simplicity, these

relationships are only shown for the web.workingHours package. As illustrated in the

figure, Create and List are subclasses of Secure-Template ; while WorkingHourPendingAp-pointment is a subclass of PendingAppoint-ment . The relationships between the rest of the classes

are as follows: Create and List – from the web.center package, Create , List , Center and

ListCenters – from the web.service package, CreateFromAgency and ListFromAgency – from web.holidays package; and List and Export –

from the web.appointment package; are all sub-

classes of SecureTemplate. CenterPendin-gAppointment , ServicePendingAppointment ,

HolidayPendingAppointment , and Working-HourPendingAppointment are subclasses of Pen-dingAppointment.

5.3.2. CORE BUSINESS LAYER

The core business layer comprises three main compo-

nents: Service , Util and Communication .

The design class diagram for the Service component

is depicted in Figure 21. The component includes the

following classes:

1) ServiceFactory – acts as a factory for instan-

tiating different types of objects like concrete im-

plementation of: IAppointmentService , IA-gencyService , IWorkingHourService ,

IHolidayService , ICitizenService ,

IServiceService , and INotification-Service ;

2) AppointmentService – manages data and

functions related to appointments;

3) AgencyService – manages data and functions

related to agencies;

4) WorkingHourService – manages data and

functions related to working hours;

5) HolidayService – manages data and functions

related to holidays;

6) CitizenService – manages data and functions

related to citizens requesting appointments;

7) ServiceService – manages data and functions

related to the services requiring appointments;

8) NotificationService – manages data and

function related to notifications to applicants;

9) Host – manages the reminder notifications that

are sent to applicants before the appointment

takes place.

10) Sender – is an abstract class for sending notifica-

tions to applicants;

11) SMSSender – is a subclass of Sender responsible

for sending notifications through SMS;

12) EmailSender – is a subclass of Sender respon-

sible for sending notifications through e-mails.

13) AppointmentServiceException – manages

the exceptions raised by processing errors.

Functions of classes 2) to 8) implement the operations

defined in their interfaces. The name of the interface

defining the operations of the class starts with capital I

and is followed by the class name; for instance, Ap-pointmentService provides implementation for

the operations defined in IAppointmentService .

The design class diagram for the Util component is

depicted in Figure 22. The component includes the

ConfigurationParameter class for storing para-

meters to send notifications and other data used by the

application like the id of the member to be used or the

name of the current agency, among others. It is a com-

posite class involving SMSParameter and EmailPa-rameter classes – each of these classes defines the

parameters used to send notifications through SMS and

e-Mail, respectively.



36

Figure 21: Design Class Diagram – Service

Figure 22: Design Class Diagram – Util

Finally, the Communication component involves two

classes for receiving messages through the Messaging

Gateway: i) AgencyApplicationListener – im-

plements a listener enabling the providing agency to

receive messages; ii) PortalApplicationListen-er – implements a listener enabling the government

portal to receive messages. In addition, the

XG2GSynchron class allows synchronizing the reply

messages with the request messages for simulating

synchronous communications based on the asynchron-

ous communications provided by the Messaging Gate-

way. The XG2GSynchron implements the operations

defined by the IXG2GSynchron interface for getting

the reply messages. The design class diagram for the

Communication component is depicted in Figure 23.

Figure 23: Design Class Diagram – Communication

5.3.3. DATABASE LAYER

The design class diagram for the Database component

is shown in Figure 24. The component includes a Generic

Access Object (GenericDAO ) implementing an inter-

face (IDAO) which provides general functions for ac-

cessing the database, like – add , remove , update ,

listAll , and findById (CRUD operations) .

In addition to IDAO, there are other specific interfaces,

subclasses of DAO, like INotificationDao , IAp-pointmentDao , IServiceDao , IHolidayDao ,

IWorkingHoursDao , IAgencyDao , ICenterDao ,

ICounterDao , and ICitizenDao – for defining

specific operations for accessing notifications, appoint-

ments, services, holidays, working hours, agencies, cen-

ters, counters, and citizens, respectively. Similarly, in

addition to GenericDAO, there are other classes, all sub-

classes of GenericDAO, like: NotificationManager ,

AppointmentManager , ServiceManager , Ho-lidayManager , WorkingHoursManager , Agen-cyManager , CenterManager , CounterManager ,

CitizenManager – for managing notifications to

applicants, appointments, services, holidays, working

hours, agencies, centers, counters and citizens, respec-

tively. These classes provide implementation for the

corresponding interfaces. For instance, Notifica-tionManager implements INotificationDao .

Figure 24 depicts the general design for the database.

However, different data is stored in the portal database

and in agency databases. For instance, the portal data-

base stores information about agencies, services and

holidays; while the agency database stores information

about services, centers, counters, working hours, non-

working days, citizens, appointments, and notifications.



37

Figure 24: Design Class Diagram – Database



38

5.4. DETAILED BEHAVIOURAL DESIGN DIAGRAMS

Three detailed sequence diagrams are shown for ex-

plaining the behavior of the system. The diagrams

present the collaboration between objects for: i) adding

an agency; ii) deleting an agency, and iii) making an ap-

pointment. Each of these diagrams is presented in the

following sections.

5.4.1. ADDING AN AGENCY

The sequence diagram for adding an agency is pre-

sented in Figure 25 and is explained below.

Adding an agency is part of the use case for managing

agencies. The function is requested by the portal admin-

istrator (1:manageAgencies ). The request is

processed by the Application object, who asks the

ServiceFactory to get the interface object respon-

sible for managing agencies

(2:getAgencyService ). As a reply, the IAgen-cyService object is received

(3:IAgencyService ). Application requests this

object to get the list of all existing agencies

(4:getAllAgencies ). The IAgencyService ob-

ject forwards the request to the interface of the agency

entity for retrieving the list of agencies from the data-

base (5:getAll ). The replies -

6:reply(listOfAgencies) and

7:reply(listOfAgencies) , are sent back and

presented to the user (8:listOfAgencies ).

After viewing the list of agencies, the user decides to

add a new agency (9:addAgency ). The Applica-tion object creates a new object (10:newAgency ),

and asks the ServiceFactory to get the interface

object responsible for managing agencies

(11:getAgencyService ). Similarly, as a reply, the IAgencyService object is received

(12:IAgencyService ). Application requests

this object to create the new agency (13:create ). The

IAgencyService object forwards the request to the

interface of the agency entity to store the data in the

database (14:add ).

Figure 25: Sequence Diagram for Adding an Agency



39

5.4.2. DELETING AN AGENCY

The sequence diagram for deleting an agency is pre-

sented in Figure 25 and is explained below.

Deleting an agency is part of the use case for managing

agencies. Therefore, steps 1) to 9) are the same as those

explained for adding an agency.

After viewing the list of agencies, the user may decide to

delete an existing agency (9:deleteAgency). The Ap-plication object asks the ServiceFactory to get

the interface object responsible for managing agencies

(10:getAgencyService ). As a reply, the IAgen-cyService object is received

(11:IAgencyService ). Application requests

this object to delete the selected agency (12:delete ).

The IAgencyService object forwards the request to

the interface of the agency entity to delete the record

from the database (14:destroy ).

Figure 26: Sequence Diagram for Deleting an Agency



40

5.4.3. MAKING AN APPOINTMENT

Making an appointment involves various collaborations

among several objects. A detailed sequence diagram of

the collaborations involved in the first two steps of the

negotiation process is presented in Figure 27. The six

objects on the left of the diagram – depicted in green,

reside at the portal side, while the four objects on the

right – depicted in orange reside at the agency side.

The process starts when the user requests to make an

appointment - 1:makeAppointment . The request is

processed by Application , who gets the list of ser-

vices and requests the user to select one -

2:requestService . For simplicity, this action is

shown as a simple action in the diagram; however, it

involves requesting ServiceFactory to get the in-

terface of the object managing services (IService-Service ), ServiceFactory to provide this object,

Application requesting IServiceService to get

the list of services, and ServiceDao object getting all

services from the database. Once the list of services are

shown to the user, he/she selects one -

3:selectedService . Application requests

ServiceFactory to get the interface for the object

managing Agencies (IAgencyService ) -

4:getAgencyService , and the object is returned -

5:reply(IAgencyService) . Application requests the IAgencyService to get the list of cen-

ters where appointments for the selected service can

take place - 6:getCenters . IAgencyService

prepares the message to be sent to the agency –

7:msgToSend , and asks the member acting on behalf

of the government portal in the Messaging Gateway

(p:Member ) to send the message - 8:sendMessage .

The member acting on behalf of the agency providing

the service (ag:Member ) receives the message and

delivers it to the AgencyApplicationListener -

9:receiveMessage . Upon interpreting the message,

the AgencyApplicationListener requests the

IAgencyService to get all centers. The request is

forwarded to IAgencyDao -

11:getAll(Centers) . The reply (listOfCen-ters ) is received by IAgencyService –

12:reply(listOfServices) , who forwards it to

AgencyApplicationListener . When the list of

centers is received by this later object, it prepares the

message to be sent as reply – 14:msgtoSend , and

requests ag:Member to send the message –

15:sendMessage . The message received by

p:Member is forwarded to PortalApplication-Listener - 16:receiveMessage , who sends the

list of centers received to the IAgencyService –

17:reply(listOfCenters) . For simplicity, action

16 is shown as a single interaction but it involves colla-

boration from IXG2GSynchron for synchronizing the

request and the reply messages. IAgencyService

sends the reply to Application –

18:reply(listOfCenters) , who shows the list of

centers to the user – 19:listOfCenters . Finally,

the user selects the center – 20:selectedCenter .

Figure 27: Sequence Diagram for Making an Appointment – Steps 1 and 2



41

Step 2 of the process involves Application request-

ing the user to provide appointment-related informa-

tion, like the preferred channel for notifications and a

text message to the provider agency –

21:requestApplicantInformation , and the

user provides these data – 22:applicantData . In

addition, Application requests the appointment

date – 23:requestDate , and the user selects his/her

preferred date – 24:selectedDate .

The collaborations involved for executing the third and

fourth step of the appointment negotiation process are

shown in Figure 28. As in the previous figure, the seven

objects on the left – depicted in green, reside at the

portal side, while the four on the right – depicted in

orange, reside at the agency side.

In Step 3, after receiving the date selected by the user,

Application requests IAgencyService to get

the working hours – 1:getWorkingHours . IAgen-cyService prepares the message to be sent to the

agency – 2:msgToSend , and requests the p:Member

to send the message – 3:sendMessage . ag:Member

receives the message, and forwards it to AgencyAp-plicationListener – 4:receiveMessage , who

asks IAgencyService to get the working hours –

5:getWorkingHours . For simplicity, collaborations

between IAgencyService , IServiceService ,

IWorkingHoursService , and IWorkingHours-DAO for getting this information from the database are

not shown. Once IAgencyService has the informa-

tion about working hours, it replies to AgencyAppli-cationListener – 6:reply(workingHours) ,

who prepares the message to be sent to the portal –

7:msgToSend , and sends the message –

8:sendMessage . The member at the portal, after

receiveing the message, forwards it to PortalAppli-cationListener – 9:receiveMessage . Reply

messages are sent back to the objects requesting the

information – 10:reply(workingHours) ,

11:reply(working Hours) , and 12: wor-kingHours . Finally, based on the available hours, the

user selects their choice – 13:selectedTime .

Figure 28: Sequence Diagram for Making an Appointment – Steps 3 and 4



42

In Step 4, after receiving the time selected by the user,

Application request a confirmation of the appoint-

ment – 14:requestConfirmation , and the user

confirms – 15:confirmation . Application re-

quests ServiceFactory to get the interface object

for managing appointments

(p:IAppointmentService ) –

16:getAppointmentService , and receives the

object as reply –

17:reply(IAppointmentService) . Applica-tion requests IAppointmentService to create a

new appointment – 18:newAppointment . There-

fore, p:IAppointmentService prepares the mes-

sage to be sent to the agency – 19:msgToSend , and

requests p:Member to send the message –

20:sendMessage . ag:Member , after receiving the

message, forwards it to AgencyApplicationLis-

tener – 21:receiveMessage . AgencyApplica-tionListener requests the IAppointmentSer-vice at the agency side

(ag:IAppointmentService ) to create the new

appointment – 22:createAppointment . Further

collaborations, not shown in the diagram, take place

among ag:IAppointmentService and IAp-pointmentDao to store the record in the database.

After updating the database, AgencyApplication-Listener creates a message to confirm the registra-

tion of the appointment at the agency –

23:msgToSend , and requests ag:Member to send

the message – 24:sendMessage . After receiving the

message, p:Member forwards it to PortalAppli-cationListener . All replies are sent back through

all the objects involved, until the user is informed – 26-27-28:reply(appointmentConfirmed) .

SECTION 6 – IMPLEMENTATION


43

6. IMPLEMENTATION

The following three sections provide a general overview

of the implementation phase of the e-Appointment

service (Section 5.1), technologies used (Section 5.2),

and further customization details that could improve the

current functionality (Section 5.3).

6.1. OVERVIEW

Figure 29 presents the implemented components, the

relationships among them, and the relationships with

other software infrastructure components – depicted in

orange.

Figure 29: Implementation Diagram



44

Five packages were implemented: i) User Inter-face - Portal – implementing the user interface

for users and the portal administrator; ii) User In-terface – Agency – implementing the user inter-

face for service providers; iii) e-Appointment Core Business –implementing the business logic, iv) Ent-ities – a set of classes for manipulating the data

structure of each entity; and vi) Database – imple-

menting data persistence through the database. The

Messaging Gateway – xG2G, a software infrastructure

component used by the e-Appointment service is also

depicted. In addition, a configuration file for the e-

Appointment service is provided – e-AppointConfigurationFile .

As explained in Section 5.3, the user interface packages

include three components: UI-Common, UI-Portal

and UI-Agency . UI-Common, through the Appli-cation class, uses the IVisitor interface provided

by the Messaging Gateway to restart a member – either

a member acting on behalf of the portal, or a member

acting on behalf of a providing agency. It also uses the

Util component to access the configuration file. UI-Portal uses IXG2GSynchron , an interface provided

by the Communication component to synchronize

requests and replies between the portal and the agen-

cies. All three– UI-Common, UI-Portal , and UI-Agency ; use the interfaces of the core business layer

provided by the Service component. These inferfaces

include: IAgencyService , IAppointmentSer-vice , IHolidayService , INotificationSer-vice , and IServiceService .

The CoreBusiness package includes three compo-

nents: i) Service , ii) Communication , and iii)

Util . As explained above, the Service component

provides the interfaces required by the user interface

layer. In addition, it uses the interfaces provided by the

Database component – IDAO and all its sub-classes,

and the IMember interface provided by the Messaging

Gateway, as well as the component for sending notifica-

tion – Utils . The Communication component im-

plements the IXG2GSynchron interface used by UI-Portal and the ApplicationListener used by

the Messaging Gateway. In addition, it uses the Ser-vice component for processing the received messages.

The Util component uses the e-AppointmentConfigurationFile . All three

components – Service , Communication and

Util , use the Entities component for processing

the entity data structures.

The Database package implements a general interface

IDAO – used by the core business layer. IDAO is refined

by several interfaces – one for each table of the data-

base, like, IAgencyDao , IServiceDao , ICenter-Dao, IHolidayDao , IWorkingHourDao , ICiti-zenDao , INotificationDao , and IAppoint-mentDao . The classes contained in this package use the

classes of the Entities package.

The Entities package provides one class for manag-

ing every entity. The package is used by all other pack-

ages: User Interface – Portal , User Inter-face – Agency , Core Business , and Database .

The specification of e-AppointmentConfigurationFile is included in

Appendix C. The following parameters are defined in the

file:

o memberId - identification of the member acting

on behalf of the software applications deployed on

the node

o agencyName - identification of the hosting agen-

cy

o agencyDescription – full name of the hosting

agency

o channelId - identification of the channel used by

the hosting agency to communicate with the gov-

ernment portal

o type - role of the application deployed at the

node. The possible values include: portal and agen-

cy;

o numbermonth – number of months in advance

when appointment can be booked . For instance, if

the current date is 6 February 2009, it will allow to

book appointments till 6 May 2009.

o Parameters for sending notifications through e-

mails, like:

o emailserver - smtp server ,

o emailport - smtp port number,

o isemailauthenticationre-quired - flag for indicating if authenti-

cation is required for sending e-mails. The

possible values are true and false,

o sendermail - e-mail address of the

sender,

o emailsenderpassword - password

for authenticating the sender,

o istlsenabled - flag for indicating if

transport layer security (tls) is enabled;

o emailtemplate – text of the e-mail to

be sent to the applicant as a reminder of

the appointment



45

o newnotificationtemplate – text

of the e-mail to be sent to the applicant

as a confirmation of the appointment.

o updatenotificationtemplate -

text of the e-mail to be sent to the appli-

cant as a confirmation of the updated

appointment.

o cancelnotificationtemplate –

text of the e-mail template to be sent to

the applicant as a confirmation of the

cancelled appointment.

o Parameters for sending notifications through SMS,

like:

o username – name of the user holding the

account used for sending SMS

o smsuserpassword – password of the user

holding the account used for sending

SMS

o smsapiid – key enabling the user to send

SMS

o smstemplate – text of the SMS to be

sent to the applicant as a reminder of the

appointment.

Two bounds are defined in the configuration file:

1) number of appointments per citizen – in order to

avoid misusing the service., For instance, a citizen

booking most of the appointments. A bound is de-

fined to set the maximum number of appointments

a citizen can request; and

2) number of months – a bound is defined for show-

ing future days in the calendar when the user is re-

questing or updating an appointment.

6.2. TECHNOLOGIES

The guiding principle for implementing the e-

Appointment Service was to adopt open-source tech-

nologies and open-standards. Therefore, all software

components were implemented in Java [12][13]. The

database used is MySQL [14][15], and Hibernate [16][17]

is applied for the object-relational mapping. Messages

are written using eXtensible Markup Language (XML)

[18][19], and composed and decomposed using

XMLBeans [20]. The exchange of messages is supported

by the e-Macao Messaging Gateway [21]. Log4J [22] API

is used for logging messages, and JavaMail [23] for send-

ing e-mails. The development framework used for im-

plementing the web application is Apache Wicket 1.3.4

[11]. The web server used for deploying the web appli-

cation is Apache Tomcat 6 [24], and the Spring 2.5 [25]

container is used to instantiate different objects.

The set of technologies used by the e-Appointment ser-

vice is depicted in Table 12.

Table 12: Technologies Used by e-Appointment Service

Appointment Application – Technologies

LANGUAGE Java 1.6

DATABASE MySQL 5

OBJ.-REL. MAPPING Hibernate 3.2

MESSAGING xG2G 1.0 (e-Macao infrastructure)

OBJECT-XML MAPPING XMLBeans 2.3.0

LOGGING FRAMEWORK Log4j 1.2

MAIL FRAMEWORK JavaMail

WEB FRAMEWORK Apache Wicket 1.3.4

WEB SERVER Apache Tomcat 6

CONTAINER Spring 2.5



46

6.3. IMPROVEMENTS

The current release presents a prototype implementa-

tion of the e-Appointment service that could be im-

proved in different ways. Three areas of improvements

are identified and discussed in the following sections;

integration with other software infrastructure compo-

nents (Section 6.3.1), service parameterization (Section

6.3.2) and service reliability (Section 6.3.3).

6.3.1. SERVICE INTEGRATION

The proposed e-Appointment service aims to deliver a

general solution for managing appointments supporting

the delivery of public services, as part of the software

infrastructure for Electronic Government. Therefore, like

other e-services, it should be integrated with software

infrastructure components and services. In particular,

we discuss the integration with authentication and noti-

fication services, a multi-channel delivery strategy, and

the government portal database.

An authentication service is usually provided as part of

the software infrastructure for Electronic Government,

which enables users to prove their identity before ac-

cessing some public services. In order to deliver these

services following a customer-focus approach through a

one-stop contact, the user should be requested to au-

thenticate only once and gain access to different servic-

es – single sign on. Therefore, the e-Appointment ser-

vice should be integrated with the authentication ser-

vice already in place. In the current release, a web page

is used for simulating the need for authentication. The

integration of the e-Appointment service with an au-

thentication service shall discard the use of the e-

Appointment authentication page, and replace it by an

invocation to the authentication service. The Secure-Template class of the web.Template component

should be modified.

A notification service which enables notification of ap-

plicants through various channels can also be part of the

software infrastructure for Electronic Government. If

so, notifications should be sent by this infrastructure

service and not by the e-Appointment service. The inte-

gration of the e-Appointment service with a notification

service will require introducing changes to the following

classes in the Service component: i) Sender – for

invoking the infrastructure notification service instead of

sending the notifications itself; and ii) Host – likewise,

for sending the reminder notifications. In addition, the

current release uses the services of Clickatell for sending

SMS notifications. In the future, the interface with Click-

atell [26] should be replaced by the interface to the

telecommunication company chosen by the govern-

ment.

A multi-channel delivery approach for delivering public

services requires providing access to a centralized data-

base containing information about citizens, like the citi-

zen’s contact details for each channel. Therefore, this

data should not be handled by the e-Appointment ser-

vice, but by some other infrastructure component.

However, the e-Appointment service can request from

the applicant which is his preferred channel for receiving

appointment-related notifications and manage this in-

formation. The integration of the e-Appointment service

with a multi-channel delivery strategy will require

changes to the data manipulated in the second step of

the appointment negotiation process. In such case, the

AppointmentWizard class of the

web.Appointment component shall be modified, as

well as the class managing persistence in the database –

CitizenDao .

The current implementation of the e-Appointment ser-

vice manages information that should be part of the

government portal database. For instance, public holi-

days. The integration of e-Appointment and government

portal databases will require replacing the function for

updating public holidays in the e-Appointment database

by a function retrieving this information from the portal

database. In addition, it will require keeping in the e-

Appointment database at the portal side, only the list of

agencies and services using e-Appointment service, and

validating that these agencies and services exist in the

corresponding tables of the portal database.

One more improvement is to automatically update the

table of services requiring appointments at the portal by

exchanging messages through the Extensible Messaging

Gateway every time a service is updated in the providing

agency.

In addition, the e-Appointment service could be inte-

grated with other software applications supporting the

delivery of services for which appointments are re-

quested. One possible scenario for such integration is

already supported by the current release through the

function exporting an XML file with information about

the appointments for a given date. Further improve-

ments could consider importing appointment-related

information from these applications for udating the

database managed by the e-Appointment service.

6.3.2. SERVICE PARAMETERIZATION

The e-Appointment service aims to provide a general

solution for making appointments for delivering various

public services. Each of these services may have its own

requirements related to applicant’s authentication, noti-

fication texts, and number of appointments required for

the service delivery, among others. A general solution

for addressing these specific service needs can be pro-

vided through parameterization. Therefore, possible

improvements related to service parameters could be

introduced in further releases. For instance, the follow-

ing service-related parameters are proposed to be in-

troduced:



47

o isAuthenticationRequired – a flag for indicating if

the appointment requires or not applicant’s au-

thentication;

o appointmentPre-requisites – each service may have

its own prerequisites for applicants attending ap-

pointments. For instance, the applicant should

present some supporting documents during the

appointment; the applicant should not eat within

certain amount of hours prior to the appointment,

in case of medical analysis; and others. Managing

these appointment pre-requisites in the e-

Appointment service will enable reminding the ap-

plicant about such prerequisites when sending the

notifications confirming and reminding the ap-

pointment.

o numberOfAppointments – a general parameter is

defined in the configuration file of the e-

Appointment service for controlling that an appli-

cant is not allowed to book more than a given

number of appointments. Since the number of ap-

pointments required for delivering a service de-

pends on the service, it would be advisable to de-

fine the number of admissible appointments for a

citizen as a service related parameter.

o monthsAheadForBookingAppointments – likewise

the previous case, a general parameter is defined

for setting the number of months ahead for arrang-

ing appointments. However, the completion time

of the business process for delivering services de-

pends on the service. Therefore, a proposed im-

provement is to define the months ahead for book-

ing appointments as a service related parameter.

o notificationTexts – each service may need to define

different texts for notifying applicants about ap-

pointments. Moreover, different texts may be re-

quired for each delivery channel. In the current re-

lease, the configuration file manages different pa-

rameters for notification texts for reminding appli-

cants through e-mail and through SMS, and for con-

firming, changing and cancelling an appointment

(same text regardless the channel used for sending

notifications). A proposed improvement is to define

notifications texts for each delivery channel, as ser-

vice-related parameters.

Finally, an improvement is proposed for providing a

function enabling service providers to update service-

related parameters.

6.3.3. SERVICE RELIABILITY

In the current release, it may happen that the member

acting on behalf of the e-Appointment service at the

agency side is not available when the application at the

government portal is trying to exchange information

with it. Therefore, an alternative mechanism shall be

provided for such cases in order to improve reliability.

Possible solutions include providing a secondary data-

base at the government portal with information up-

dated daily through batch processes, and enssuring

members are deployed on servers, among others.

SECTION 7 – DEPLOYMENT


48

7. DEPLOYMENT

There is only one deployment component – e-AppointmentService providing the functionality

for all users. Depending on the value defined for the

parameter type in the configuration file, the compo-

nent plays two roles: i) Portal – provides the functionali-

ty for the portal administrator and users requesting

appointments - e-Appointment Service (P) ;

and ii) Agency – provides the functionality for service

providers – e-Appointment Service (A) .

Figure 30 presents a possible deployment scenario for

the software components.

The node Government Portal represents the Portal

role, while all other nodes correspond to the Agency

role. In any deployment scenario, there must be only

one node playing the Portal role, and as many nodes as

required hosting the e-Appointment Service with the

Agency role – at least as many as government units

using the e-Appointment service.

The Portal Component corresponds to the govern-

ment portal application, which may or may not be dep-

loyed on the same node as e-Appointment Ser-vice (P) . While deploying the e-Appointment Service , the e-AppointmentDatabase is created

on the hosting node. The libraries of the Messaging Ga-

teway – xG2G, are required on all nodes hosting an e-

Appointment Service component. As depicted in Figure

30, Portal uses e-Appointment Service (P) ,

and the e-Appointment Service , regardless of its

role, uses the e-AppointmentDatabase and xG2G.

Figure 30: Deployment Diagram – A Possible Scenario

SECTION 8 – CONCLUSIONS


49

8. CONCLUSIONS

This report presents technical details of the e-

Appointment service development. The development

was carried out by UNU-IIST Center for Electronic Gov-

ernment during 2008 for the Government of Macao

SAR, under the Macao Data Exchange Gateway Project,

part of the e-Macao Program.

The e-Appointment service enables booking of ap-

pointments between service consumers and service

providers related to public service delivery. The pro-

posed solution presents a general approach for manag-

ing appointments supporting the delivery of services

provided by different agencies. The appointment-

related information exchanged between the govern-

ment portal and the agencies is supported by the Ex-

tensible Messaging Gateway [1]. The service can be

considered part of the software infrastructure for Elec-

tronic Government.

The e-Appointment service is built upon the following

concepts: i) appointment – an arrangement between

parties for interacting at a certain time and place for a

specific purpose; ii) appointment negotiation process –

required steps for making an appointment; iii) service –

a public service requiring appointments as part of its

delivery process; iv) center – a physical or virtual place

where appointments are held; v) public holiday – a day

on which government agencies are officially closed; vi)

non-working day – a day on which an agency is not serv-

ing customers; and vii) working hours – a period of time

in which appointments can be arranged.

The service distinguishes three types of users: i) portal

administrator – a person responsible for administering

the government portal; ii) service providers – adminis-

trators of the government units delivering services; and

iii) service consumers – persons who request appoint-

ments. Portal administrator is responsible for maintain-

ing information about the government agencies deliver-

ing services requiring appointments, services for which

appointments can be requested, and public holidays.

Service providers are responsible for managing informa-

tion about services delivered by them, centers in which

these services are delivered, non working days and

working hours. In addition, they can view and export the

arranged appointments for a given day. Service con-

sumers can make, change or cancel an appointment.

They are notified about appointments made and re-

minded about coming appointments. In the current

release, these notifications are delivered through e-mail

and SMS.

This report presented the development stages followed

for implementing the software component. It also intro-

duced some of the development artifacts produced. An

introduction to the project scope, its aim and objective

were presented in Section 1. Section 2 introduced some

background for developing an e-Appointment service.

The motivation for an e-Appointment service was pre-

sented, as well as e-Appointment-related concepts,

business process, implementation approach, challenges

for implementing and delivering the service, and case

studies. Section 3 presented functional and non-

functional requirements for the e-Appointment service.

A set of functional requirements was introduced for

specifying the functionality to be provided to the portal

administrator, service providers and consumers. Four

non-functional requirements were specified, related to:

i) reliability, ii) security, iii) generality and iv) interopera-

bility. A domain conceptual model and a use case model

were presented in Section 4. In addition, the section

introduced cross-references between the functional

requirements identified in Section 3 and the use cases

defined. The service top level and detailed design were

explained in Section 5. Static and dynamic views of the

architecture were presented, as well as design class

diagrams and sequence diagrams explaining the struc-

ture and behavior of the service, respectively. Section 6

presented implementation details including some tech-

nologies used, and possible improvements to the cur-

rent release. Section 7 illustrated a possible deployment

scenario. Finally, appendices describing glossary of

terms, configuration file, XML schemas, Application

Programming Interfaces (APIs), and main Java classes

were included.

The main contributions of the e-Appointment develop-

ment process include: i) providing a prototype solution

for managing appointments in delivering public services,

ii) presenting a general solution that can be used for

delivering any service requiring appointments, iii) illu-

strating the exploitation of the Extensible Messaging

Gateway, and iv) proposing enhancements based on the

experience gained.

This development report is complemented by the e-

Appointment User Manual [27]. Information about the

project is also available at the project website [28].

REFERENCES


50

REFERENCES

[1] Elsa Estevez, Vincent Douwe and Tomasz Janowski,

Extensible Messaging Gateway - Enhanced Services

and New APIs, Macao Data Exchange Gateway

Project, UNU-IIST-EGOV, February 2009.

[2] Merrrian-Webster Online, available at

http://www.merriam-webster.com/, visited on 25

January 2009.

[3] Ralf Klischewski, The Challenges of e-Appointment:

Process Modeling, Infrastructure, and Organiza-

tional Context, available at http://swt-

www.informatik.uni-

ham-

burg.de/publications/./files/ibim_klischewski.pdf

visited on 25 January 2009.

[4] Tomasz Janowski, Adegboyega Ojo and Elsa Estevez

(Eds), The State of Electronic Government in Ma-

cao, Volume 2 Agencies, e-Macao Project, available

at www.emacao.gov.mo, Deliverables - Survey, re-

port 2, visited on 25 January 2009.

[5] National Organization for Medicines (EOF), Ministry

of Health, Government of Greece,

http://eof1.eof.gr/eof_en/enhome.html.

[6] S. Giannakou, Providing e-Appointment System to

Pharmaceutical Companies for Licensing Applica-

tions and Guidance, Validation of Applications and

Marketing Authorization Division (DDYEP), National

Organization for Medicines (EOF), Government of

Greece, 5th

Quality Conference for Public Adminis-

tration in the EU, Paris, 20-22 October 2008, avail-

able at www.5qualiconference.eu/bib_res/364.pdf,

27 January 2009.

[7] Ministry of Home Affairs, Government of Singa-

pore, Inmigration and Checkpoints Authority (ICA),

http://ica.gov.sg.

[8] Ministry of Home Affairs, Government of Singa-

pore, E-Appointment at ICA,

https://eappointment.ica.gov.sg/ibook/index.do,

visited 26 January 2009.

[9] Ministry of Manpower, Government of Singapore,

Labour Relations and Worplace Division,

http://www.mom.gov.sg/publish/momportal/en/a

bout_us/divisions_and_statutory/labour_relations_

department.html, visited 27 January 2009.

[10] Ministry of Mapower, Government of Singapore, E-

Appointment at LRWD,

http://app.etools.mom.gov.sg/eindex.aspx, visited

27 January 2009.

[11] Apache Wicket, http://www.wicket.apache.org,

visited 3 February 2009.

[12] Herbert Schildt, Java 2 The Complete Reference,

Osborne, 5th

Edition, 2002.

[13] Sun Microsystems, The Java Tutorial, 2004,

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

[14] Sun Microsystems, MySQL, http://www.mysql.com.

[15] Paul DuBois, MySQL Cookbook, O’Reilly, November

2006.

[16] Hibernate, Relational Persistence for Java and .Net,

http://www.hibernate.org.

[17] Christian Bauer and Gavin King, Hibernate in Action

(In Action series), Hanning, August 2004.

[18] W3C, Extensible Markup Language (XML),

http://www.w3.org/XML/.

[19] Erik T. Ray, Learning XML, O’Reilly, 2001.

[20] The Apache XML Project, Apache XMLBeans,

http://xmlbeans.apache.org.

[21] Vincent Douwe, Elsa Estevez, Tomasz Janowski,

Extensible Message Gatewa - Development Report,

Software Infrastructure for e-Government Project,

UNU-IIST-EGOV, April 2008.

[22] Logging Apache Org, Logging Services (LOG4J),

http://logging.apache.org/log4j/1.2/index.html.

[23] Sun Developer Network (SDN), J2EE Java Mail,

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

[24] The Apache Software Foundation, Apache Tomcat,

http://tomcat.apache.org.

[25] The Spring Source Community,

http://www.springsource.org/.

[26] Clickatell, Any message, Anywhere, Messaging So-

lutions, http://www.clickatell.com/solutions.php.

[27] Elsa Estevez, Vincent Douwe, and Tomasz Janowski,

e-Appointment Service – User Manual, Macao Data

Exchange Gateway Project, UNU-IIST-EGOV, Febru-

ary 2009.

[28] Macao Data Exchange Gateway Project,

http://www.egov.iist.unu.edu/index.php?/cegov/p

rojects/infras-tructure.

[29] Elsa Estevez, Vincent Douwe and Tomasz Janowski,

Extensible Messaging Gateway – Quality Assurance

Report, Macao Data Exchange Gateway Project,

UNU-IIST-EGOV, September 2008.

APPENDICES


51

APPENDICES

A. GLOSSARY

ID TERM DESCRIPTION

T1 Agency An administrative division of the government providing and receiving

services.

T2 Appointment An arrangement between parties for interacting at a certain time and

place for a specific purpose.

T3 Authentication The process of determining whether a member is authentic and eligible

to access the e-Appointment service and its data. The process involves

using the authentication service provided by the software infrastructure.

T4 Center A place where appointments can take place.

T5 Communication Structures Members, Channels, and Extensions of the Messaging Gateway used for

information exchange.

T6 Configuration File File storing parameters used by some functions of the service.

T7 Counter A place, usually physical, where customers can be served.

T8 Export To generate information and store it in a file to be used by another soft-

ware application.

T9 e-Mail A delivery channel for sending notifications.

T10 Non-working Day A day in which appointments cannot be arranged.

T11 Notification Acknowledgement of a fact. The e-Appointment service shall send notifi-

cations every time an appointment is confirmed or cancelled.

T12 Notification Type A criteria for classifying notifications based on the delivery channel used

for sending notifications.

T13 Portal Administrator Person responsible for maintaining the Government Portal.

T14 Public Holiday A day in which government agencies are officially closed.

T15 Reliability The ability of a system or component to perform its required function

under stated conditions for a specified period of time (IEEE).

T16 Reminder Notification Time Time in advance from the appointment, in which a notification to the

applicant will be sent for reminding him/her about the appointment.

T17 Service The outcome produced and delivered in interaction between a service

provider and a service consumer in order to benefit the consumer or

fulfill the consumer’s needs.

T18 Service Consumer A person or entity receiving a public service.

T19 Service Provider A government unit providing services.

APPENDICES


52

T20 Service Time Service-related time that is required for serving one customer. The ap-

pointment between service provider and consumer will last at most the

service mean time.

T21 SMS A delivery channel for sending notifications – SMS is the acronym of

Short Message Service.

T22 User Any person accessing the e-Appointment service.

T23 Working Hour Time frame for arranging appointments.

APPENDICES


53

B. XML SCHEMAS

B.1. SCHEMA FOR EXCHANGED MESSAGES

XML Schema 1: Exchanged messages Schema

<schema xmlns="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://egov.iist.unu.edu/emacao/queue/messages"

elementFormDefault="qualified"

xmlns:Q1="http://egov.iist.unu.edu/emacao/queue/messages">

<complexType name="NewAppointment">

<sequence>

<element name="CustomerId" type="string" maxOccurs="1"

minOccurs="1">

</element>

<element name="CustomerName" type="string" maxOccurs="1"

minOccurs="1">

</element>

<element name="Date" type="date" maxOccurs="1"

minOccurs="1">

</element>

<element name="ServiceCode" type="string" maxOccurs="1"

minOccurs="1">

</element>

<choice maxOccurs="1" minOccurs="1">

<element name="EmailAddress" type="string"></element>

<element name="MobilePhone" type="string"></element>

</choice>

<element name="Time" type="time" maxOccurs="1"

minOccurs="0">

</element>

<element name="Error" type="Q1:ErrorType" maxOccurs="1"

minOccurs="0">

</element>

<element name="ErrorDescription" type="string" maxOccurs="1"

minOccurs="0">

</element>

<element name="Details" type="string"></element>

<element name="center" type="string" maxOccurs="1"

minOccurs="1">

</element>

</sequence>

</complexType>

<complexType name="UpdateAppointment">

APPENDICES


54

<sequence>

<element name="Service" type="string" maxOccurs="1"

minOccurs="1">

</element>

<element name="CustomerId" type="string" maxOccurs="1"

minOccurs="1">

</element>


minOccurs="1">

</element>

<element name="NewDate" type="date" maxOccurs="1"

minOccurs="1">

</element>


minOccurs="0">

</element>


minOccurs="0">

</element>

<element name="Center" type="string" maxOccurs="1"

minOccurs="1">

</element>

<element name="Time" type="time" maxOccurs="1" minOccurs="1"></element>

</sequence>

</complexType>

<complexType name="TrackAppointment">

<sequence>


minOccurs="1">

</element>


minOccurs="1">

</element>


minOccurs="0">

</element>


minOccurs="0">

</element>


minOccurs="1">

</element>

<element name="number" type="int" maxOccurs="1" minOccurs="0"></element>

</sequence>

APPENDICES


55

</complexType>

<complexType name="CancelAppointment">

<sequence>

<element name="Service" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="Date" type="date" maxOccurs="1" minOccurs="1"></element>

<element name="CustomerId" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="Error" type="Q1:ErrorType" maxOccurs="1" minOccurs="0"></element>

<element name="ErrorDescription" type="string" maxOccurs="1" minOccurs="0"></element>

</sequence>

</complexType>

<simpleType name="ErrorType">

<restriction base="string">

<enumeration value="SUCESS"></enumeration>

<enumeration value="FAILURE"></enumeration>

<enumeration value="UNKNOWN"></enumeration>

<enumeration value="NO_APPOINTMENT"></enumeration>

</restriction>

</simpleType>

<simpleType name="MessageType">

<restriction base="string">

<enumeration value="REQUEST"></enumeration>

<enumeration value="REPLY"></enumeration>

</restriction>

</simpleType>

<complexType name="QueueMessages">

<sequence>

<element name="Type" type="Q1:MessageType" maxOccurs="1"

minOccurs="1">

</element>

<choice maxOccurs="1" minOccurs="1">

<element name="newAppointment"

type="Q1:NewAppointment">

</element>

<element name="tractAppointment"

type="Q1:TrackAppointment">

</element>

<element name="cancelAppointment"

type="Q1:CancelAppointment">

</element>

<element name="updateAppointment"

type="Q1:UpdateAppointment">

APPENDICES


56

</element>

<element name="listDates" type="Q1:ListDates"></element>

<element name="listCenters" type="Q1:ListCenters"></element>

</choice>

<element name="messageId" type="long" maxOccurs="1" minOccurs="1"></element>

</sequence>

</complexType>

<element name="QueueMessage" type="Q1:QueueMessages"></element>

<complexType name="DateInterval">

<sequence>

<element name="MinDate" type="time"></element>

<element name="MaxDate" type="time"></element>

</sequence>

</complexType>

<complexType name="ListDates">

<sequence>


minOccurs="1">

</element>

<element name="MeanTime" type="int" maxOccurs="1"

minOccurs="0">

</element>

<element name="OldDate" type="date" maxOccurs="1"

minOccurs="0">

</element>

<element name="Occupied" type="Q1:DateInterval"

maxOccurs="unbounded" minOccurs="0">

</element>


minOccurs="0">

</element>


minOccurs="0">

</element>

<element name="WorkHours" type="Q1:DateInterval"

maxOccurs="unbounded" minOccurs="0">

</element>


minOccurs="1">

</element>

<element name="customerId" type="string" maxOccurs="1"

minOccurs="1">

APPENDICES


57

</element>

<element name="NewDate" type="date" maxOccurs="1" minOccurs="1"></element>

</sequence>

</complexType>

<complexType name="ListCenters">

<sequence>

<element name="service" type="string" maxOccurs="1"

minOccurs="1">

</element>

<element name="center" type="string" maxOccurs="unbounded"

minOccurs="0">

</element>

<element name="errorType" type="Q1:ErrorType" maxOccurs="1"

minOccurs="0">

</element>

<element name="errorDescription" type="string" maxOccurs="1"

minOccurs="0">

</element>

<element name="customerId" type="string" maxOccurs="1" minOccurs="0"></element>

</sequence>

</complexType>

</schema>

B.2. SCHEMA FOR EXPORTING APPOINTMENTS

XML Schema 2: Schema for Exporting Appointments

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNames-

pace="http://egov.iist.unu.edu/emacao/queue/export" xmlns:tns="http://www.example.org/export" elementFormDe-

fault="qualified" xmlns:Q1="http://egov.iist.unu.edu/emacao/queue/export">

<complexType name="Appointment">

<sequence>

<element name="ServiceCode" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="Time" type="time" maxOccurs="1" minOccurs="1"></element>

<element name="CitizenId" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="CitizenName" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="CitizenContact" type="string" maxOccurs="1" minOccurs="1"></element>

<element name="ServiceCenter" type="string" maxOccurs="1" minOccurs="1"></element>

</sequence>

</complexType>

<complexType name="ListAppointment">

<sequence>

APPENDICES


58

<element name="Date" type="date" maxOccurs="1" minOccurs="1"></element>

<element name="Appointments" type="Q1:Appointment" maxOccurs="unbounded" minOc-

curs="0"></element>

</sequence>

</complexType>

<element name="Appointments" type="Q1:ListAppointment"></element>

</schema>

APPENDICES


59

C. CONFIGURATION FILE

C.1. E-APPOINTMENT CONFIGURATION FILE

Configuration File 1: e-Appointment Configuration File

# Define the member id used by this agency

memberId= 100001

# The name of the hosting agency

agencyName=SAFP

# The description of the agency

agencyDescription= Public Administration and Civil Service Bureau

# Specifies the channel used for communication with the portal . It is only used by the agencies.

channelId= 500001

# Defines the type of deploiment. Possible values a re agency and portal

type= agency

# Define the parameters required for sending email

# Defines the smtp server

emailserver= mailhost .iist .unu .edu

# Defines the smtp port number. Default is 25

emailport= 25

# Defines the sender password. Can be blank in case no password is required

emailsenderpassword=

# Defines if authentification is required. Possible values true or false

isemailauthenticationrequired= false

# Defines the address used to send emails

senderemail= vincent@iist .unu .edu

# Specifies if the tls need to enabled to send emails . Possible values are true or false

istlsenabled= false

# Define the parameters required for sending sms us ing the clickatell sms gateway

# The user account at clickatell

smsuser= douwevincent

# The user password

APPENDICES


60

smsuserpassword=

# Defines the api key to be used

smsapiid=

# Define the number of months in advance that we ca n make an appointment. The de-fault value is 3

numbermonth= 3

# Define the number of appointment a citizen can ma ke. The default value is 2

numberappointment= 2

# Define the email template to send to the appointm ent maker to remind him about his appointment

emailtemplate= Mr./Mrs <<name>>. This message is to inform you that \

you have an appointment with <<agency>> today at <<time>>. \

We look forward to meeting you.

# Define the sms template to send to the appointmen t maker to remind him about his appointment

smstemplate= Mr./Mrs <<name>>. This message is to inform you that you \

have an appointment with <<agency>> today at <<time>>. \

We look forward to meeting you.

# Define the email template to send to the appointm ent maker to confirm the ap-pointment

newnotificationtemplate= Mr./Mrs <<name>>, this message is to inform you \ that your appointment with <<agency>> at the center <<center>> is confirmed for <<date>> at <<time>>. \

We look forward at meeting you.

# Define the email template to send to the appointm ent maker when an appointment is updated

updatenotificationtemplate= Mr./Mrs <<name>>, this message is to inform you that the date your appointment with \

<<agency>> at the center <<center>> was successfully updated. The new date is <<date>> and the time is <<time>> \

We look forward at meeting you.

# Define the email template to send to the appointm ent maker when an appointment is canceled

cancelnotificationtemplate= Mr./Mrs <<name>>, this message is to inform you that your appointment with \

<<agency>> at the center <<center>> on <<date>> at <<time>> is successfully can-celled . \

We look forward at meeting you in the future.

APPENDICES


61

C.2. SPRING CONFIGURATION FILE

Configuration File 2: Spring Configuration File

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:tx="http://www.springframework.org/schema/tx"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">



<bean id="agencyManager" class="edu.unu.iist.emacao.queuing.database.impl.AgencyManager" />

<bean id="agencyCenterManager" class="edu.unu.iist.emacao.queuing.database.impl.AgencyCenterManager"

/>

<bean id="centerDetailsManager" class="edu.unu.iist.emacao.queuing.database.impl.CenterDetailsManager"

/>

<bean id="notificationManager"

class="edu.unu.iist.emacao.queuing.database.impl.NotificationManager" />

<bean id="appointmentManager"

class="edu.unu.iist.emacao.queuing.database.impl.AppointmentManager" />

<bean id="customerManager"

class="edu.unu.iist.emacao.queuing.database.impl.CustomerManager" />

<bean id="holidayManager"

class="edu.unu.iist.emacao.queuing.database.impl.HolidayManager" />

<bean id="serviceManager"

class="edu.unu.iist.emacao.queuing.database.impl.ServiceManager" />

<bean id="servingDetailsManager"

class="edu.unu.iist.emacao.queuing.database.impl.ServingDetailsManager" />

<bean id="workingHoursManager"

class="edu.unu.iist.emacao.queuing.database.impl.WorkingHoursManager" />



<bean id="agencyService" class="edu.unu.iist.emacao.queuing.service.impl.AgencyService">

<property name="agencyDao" ref="agencyManager" />

<property name="agencyCenterDao" ref="agencyCenterManager" />

<property name="centerDetailsDao" ref="centerDetailsManager" />

<property name="serviceService" ref="serviceService" />

<property name="serviceDao" ref="serviceManager" />

</bean>

<bean id="customerService"

class="edu.unu.iist.emacao.queuing.service.impl.CustomerService">

<property name="customerDao" ref="customerManager" />

</bean>

<bean id="notificationService"

APPENDICES


62

class="edu.unu.iist.emacao.queuing.service.impl.NotificationService">

<property name="notificationDao" ref="notificationManager" />

</bean>

<bean id="appointmentService"

class="edu.unu.iist.emacao.queuing.service.impl.AppointmentService">

<property name="appointmentDao" ref="appointmentManager" />

<property name="customerDao" ref="customerManager" />


<property name="notificationDao" ref="notificationManager" />




</bean>

<bean id="holidayService" class="edu.unu.iist.emacao.queuing.service.impl.HolidayService">

<property name="holidayDao" ref="holidayManager" />

<property name="agencyDao" ref="agencyManager" />


</bean>

<bean id="workingHourService"

class="edu.unu.iist.emacao.queuing.service.impl.WorkingHourService">

<property name="workingHourDao" ref="workingHoursManager" />

</bean>



<bean id="serviceService" class="edu.unu.iist.emacao.queuing.service.impl.ServiceService">


<property name="centerDetailsDao" ref="centerDetailsManager" />


<property name="servingDetailsDao" ref="servingDetailsManager" />

</bean>

<bean id="serviceFactory" class="edu.unu.iist.emacao.queuing.service.ServiceFactory">

<property name="serviceService" ref="serviceService" />

<property name="workingHourService" ref="workingHourService" />

<property name="holidayService" ref="holidayService" />

<property name="appointmentService" ref="appointmentService" />

<property name="agencyService" ref="agencyService" />

<property name="customerService" ref="customerService" />

<property name="notificationService" ref="notificationService" />

</bean>



<bean id="entityManagerFactory"

class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">

<property name="dataSource" ref="dataSource" />

<property name="jpaVendorAdapter">

<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">

<property name="showSql" value="false" />

<property name="databasePlatform" val-

APPENDICES


63

ue="org.hibernate.dialect.MySQL5InnoDBDialect" />

<property name="generateDdl" value="true" />

</bean>

</property>

<property name="loadTimeWeaver">

<bean

class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver" />

</property>

</bean>



<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"

destroy-method="close">

<property name="driverClassName" value="com.mysql.jdbc.Driver" />

<property name="url" value="jdbc:mysql://localhost:3306/appointment" />

<property name="username" value="root" />

<property name="password" value="" />

</bean>



<tx:annotation-driven transaction-manager="txManager" />

<bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">

<property name="entityManagerFactory" ref="entityManagerFactory" />

</bean>



<bean

class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" />



<bean

class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

</beans>

APPENDICES


64

D. APPLICATION PROGRAMMING INTERFACES

D.1. IDAO INTERFACE

Interface 1: IDao

package edu.unu.iist.emacao.queuing.database;

import java.io.Serializable;

import java.util.Collection;

import javax.persistence.EntityManager;

public interface IDao<T,ID extends Serializable> {

public T findById(ID id) throws DataAccessException;

public Collection<T> findAll() throws DataAccessException;

public T create(T object) throws DataAccessException;

public void delete(T object) throws DataAccessException;

public T update(T object) throws DataAccessException;

public void setManager(EntityManager manager) throws DataAccessException;

}

D.2. IAGENCYDAO INTERFACE

Interface 2: IAgencyDao


import edu.unu.iist.emacao.queuing.entities.Agency;

public interface IAgencyDao extends IDao<Agency, Long> {

public Agency findByName(String name) throws DataAccessException;

}

D.3. IAPPOINTMENTDAO INTERFACE

Interface 3: IAppointmentDao



import java.util.Date;

import edu.unu.iist.emacao.queuing.entities.AgencyCenter;

import edu.unu.iist.emacao.queuing.entities.Appointment;

import edu.unu.iist.emacao.queuing.entities.Customer;

import edu.unu.iist.emacao.queuing.entities.Service;

APPENDICES


65

public interface IAppointmentDao extends IDao<Appointment, Long> {

public Collection<Appointment> findByDate(Date date) throws DataAccessException;

public Collection<Appointment> findByServiceDate(Customer customer, Service service,

Date date) throws DataAccessException;

public Collection<Appointment> findByServiceDate(Service service,

Date date) throws DataAccessException;

public Appointment getLastAppointment(Service s, Date d)throws DataAccessException;

public Collection<Appointment> getRunningAppointment(Date d) throws DataAccessException;

public Collection<Appointment> findByServiceCenterDate(Service s,Date date, AgencyCenter center) throws DataAc-

cessException;

// relative to pending appointment

public Collection<Appointment> getPendingAppointmentService(Service service, Date date) throws DataAccessExcep-

tion;

public Collection<Appointment> getPendingAppointmentCenter(AgencyCenter center, Date date) throws DataAcces-

sException;

public Collection<Appointment> getPendingAppointmentDate(Date date) throws DataAccessException;

public Collection<Appointment> getPendingWorkingHour(Date date, Date timeS, Date timeE) throws DataAccessEx-

ception;

}

D.4. ICOUNTERDAO INTERFACE

Interface 4: ICounterDao




import edu.unu.iist.emacao.queuing.entities.CenterDetails;


public interface ICounterDao extends IDao<CenterDetails, Long> {

public Collection<CenterDetails> findByService(Service service) throws DataAccessException;

public Collection<CenterDetails> findByCenter(AgencyCenter center) throws DataAccessException;

public CenterDetails findByServiceAndCenter(Service service, AgencyCenter center) throws DataAccessException;

}

D.5. ICITIZENDAO INTERFACE

Interface 5: ICitizenDao



public interface ICitizenDao extends IDao<Customer, Long> {

APPENDICES


66

public Customer getById(String customerId) throws DataAccessException;

}

D.6. INOTIFICATIONDAO INTERFACE

Interface 6: INotificationDao




import edu.unu.iist.emacao.queuing.entities.Notification;

public interface INotificationDao extends IDao<Notification, Long> {

public Collection<Notification> findByTime(Date timeInf, Date timeSup,boolean used) throws DataAccessException;

public Collection<Notification> getNotSentNotification(Date date) throws DataAccessException;

}

D.7. ISERVICEDAO INTERFACE

Interface 7: IServiceDao



public interface IServiceDao extends IDao<Service, Long> {

public Service findByCode(String code) throws DataAccessException;

}

D.8. IHOLIDAYDAO INTERFACE

Interface 8: IHolidayDao


import edu.unu.iist.emacao.queuing.entities.Holiday;

public interface IHolidayDao extends IDao<Holiday, Long> {

}

D.9. IWORKINGHOURSDAO INTERFACE

Interface 9: IWorkingHoursDao


APPENDICES


67

import edu.unu.iist.emacao.queuing.entities.WorkingHours;

public interface IWorkingHoursDao extends IDao<WorkingHours, Long> {

}

D.10. IAGENCYCENTERDAO INTERFACE

Interface 10: IAgencyCenterDao



public interface IAgencyCenterDao extends IDao<AgencyCenter, Long> {

}

D.11. ISYNCHRON INTERFACE

Interface 11: ISynchron

package edu.unu.iist.emacao.queuing.xg2g;

import edu.unu.iist.egov.emacao.queue.messages.QueueMessages;

public interface IXG2GSynchron {

public void addMessage(QueueMessages msg);

public QueueMessages getMessage(long id);

}

D.12. IAGENCYSERVICE INTERFACE

Interface 12: IAgencyService

package edu.unu.iist.emacao.queuing.service;




import edu.unu.iist.emacao.queuing.entities.DayOfWeek;




public interface IAgencyService {

APPENDICES


68

public Agency create(Agency agency)throws QueueServiceException;

public Agency update(Agency agency) throws QueueServiceException;

public Agency findByName(String name) throws QueueServiceException;

public void delete(Agency agency) throws QueueServiceException;

public Collection<Agency> list()throws QueueServiceException;

public Collection<Service> getServices(Agency agency)throws QueueServiceException;

public Collection<WorkingHours> getWorkingHours(AgencyCenter center, Service service)throws QueueServiceExcep-

tion;

public Collection<WorkingHours> getWorkingHours(AgencyCenter center, Service service,DayOfWeek day) throws

QueueServiceException;

public Collection<Holiday> getHolidays(Agency agency)throws QueueServiceException;

public Collection<Holiday> getHolidays(AgencyCenter center)throws QueueServiceException;

public Collection<AgencyCenter> getCenters(Agency agency)throws QueueServiceException;

public AgencyCenter getCenter(Agency agency, String address) throws QueueServiceException;

public void addHoliday(Agency agency,Holiday holiday) throws QueueServiceException;

public void addHoliday(AgencyCenter center,Holiday holiday) throws QueueServiceException;

public void deleteHoliday(Agency agency,Holiday holiday) throws QueueServiceException;

public void deleteHoliday(AgencyCenter center,Holiday holiday) throws QueueServiceException;

public void addWorkingHour(AgencyCenter center, Service service, WorkingHours workingHour) throws QueueServi-

ceException;

public void deleteWorkingHour(AgencyCenter center, Service service,WorkingHours workingHour) throws QueueSer-

viceException;

public void deleteCenter(Agency agency,AgencyCenter center) throws QueueServiceException;

public AgencyCenter addCenter(Agency agency,AgencyCenter center) throws QueueServiceException;

public Collection<AgencyCenter> getCenterServingService(Agency agency, Service service) throws QueueServiceEx-

ception;

}

D.13. IAPPOINTMENTSERVICE INTERFACE

Interface 13: IAppointmentService








import edu.unu.iist.emacao.queuing.util.WorkingHourDetails;

import edu.unu.iist.emacao.queuing.xg2g.IXG2GSynchron;

import edu.unu.iist.emacao.xg2g.core.Member;

public interface IAppointmentService {

APPENDICES


69

public int newAppointment(Appointment appointment, String center) throws QueueServiceException;

public void cancelAppointment(String customerId,Date date,Service service)throws QueueServiceException;

public int updateAppointment(String customerId,Date date,Service service, Date newDate, Date newTime)throws


public int trackAppointment(Service service) throws QueueServiceException;

public Collection<Appointment> list() throws QueueServiceException;

public Collection<Appointment> findByServiceDate(String customerId, String serviceCode,Date date) throws Queue-

ServiceException;

public Collection<Appointment> findByServiceDate(String serviceCode,Date date) throws QueueServiceException;

public Collection<Appointment> findByServiceCenterDate(String serviceCode,Date date, AgencyCenter center) throws


// CRUD method

public Appointment update(Appointment appointment) throws QueueServiceException;

public Appointment create(Appointment appointment) throws QueueServiceException;

public void delete(Appointment appointment) throws QueueServiceException;

public Appointment getLastAppointment(Service s, Date d) throws QueueServiceException;

public void setMember(Member member);

public void setXg2gSynchron(IXG2GSynchron synchron);

public Collection<Appointment> getStillRunningAppointment()throws QueueServiceException;

public Collection<WorkingHourDetails> getAvailableHours(Service service,String customer,Date newDate,Date old-

Date, String center) throws QueueServiceException;

public String[] getCenter(String serviceCode) throws QueueServiceException;

// Services related to pending appointment especially when we need to delete some data structures

public Collection<Appointment> getPendingAppointmentForWorkingHour(WorkingHours working) throws QueueSer-

viceException;

public Collection<Appointment> getPendingAppointmentForService(Service serv) throws QueueServiceException;

public Collection<Appointment> getPendingAppointmentForCenter(AgencyCenter center) throws QueueServiceEx-

ception;

public Collection<Appointment> getPendingAppointmentForDate(Date date) throws QueueServiceException;

// Method to notify citizen

public void notifyCitizen(Collection<Appointment> appointments, String message) throws QueueServiceException;

}

D.14 ICITIZENSERVICE INTERFACE

Interface 14: ICitizenService



public interface ICustomerService {

public Customer getById(String customerId) throws QueueServiceException;

}

APPENDICES


70

D.15. IHOLIDAYSERVICE INTERFACE

Interface 15: IHolidayService






public interface IHolidayService {

public Holiday getById(Long id) throws QueueServiceException;

public void delete(Holiday holiday) throws QueueServiceException;

public boolean isHoliday(Agency agency, Date date) throws QueueServiceException;

public boolean isCenterHoliday(AgencyCenter center, Date date) throws QueueServiceException;

}

D.16. INOTIFICATIONSERVICE INTERFACE

Interface 16: INotificationService




public interface INotificationService {

public void createNotification(Notification notification) throws QueueServiceException;

public void markAsSent(Notification notifcation) throws QueueServiceException;

public Collection<Notification> listReadyToBeSent() throws QueueServiceException;

public void delete(Notification notification) throws QueueServiceException;

public void update(Notification notification) throws QueueServiceException;

}

D.17. ISERVICESERVICE INTERFACE

Interface 17: IServiceService





APPENDICES


71

import edu.unu.iist.emacao.queuing.entities.CenterDetails;


public interface IServiceService {

public Service create(Service service)throws QueueServiceException;

public Service update(Service service) throws QueueServiceException;

public Service findByCode(String code) throws QueueServiceException;

public Collection<Service> list() throws QueueServiceException;

public void delete(Service service) throws QueueServiceException;

public void updateCurrentServing(Service service, int numServing) throws QueueServiceException;

public int getCurrentServing(Service service) throws QueueServiceException;

public int getCurrentServing(Service service, Date date) throws QueueServiceException;

public void modifyNumCounters(Service serv,AgencyCenter center, int counters) throws QueueServiceException;

public int getNumberCounters(Service serv,AgencyCenter center)throws QueueServiceException;

public Collection<CenterDetails> getCenterDetails(Service service) throws QueueServiceException;

}

D.18. ISERVICEDAO INTERFACE

Interface 18: IServiceDao



public interface IServiceDao extends IDao<Service, Long> {

public Service findByCode(String code) throws DataAccessException;

}

D.19. IWORKINGHOURSERVICE INTERFACE

Interface 19: IWorkingHourService



public interface IWorkingHourService {

public WorkingHours getById(Long id) throws QueueServiceException;

public void delete(WorkingHours workingHours) throws QueueServiceException;

}

APPENDICES


72

E. JAVA CLASSES

E.1. SERVICE CREATE CLASS

Class 1 : Create

package edu.unu.iist.emacao.queuing.web.service;

import org.apache.wicket.markup.html.basic.Label;

import org.apache.wicket.markup.html.form.Button;

import org.apache.wicket.markup.html.form.Form;

import org.apache.wicket.markup.html.form.TextField;

import org.apache.wicket.markup.html.panel.FeedbackPanel;

import org.apache.wicket.model.PropertyModel;

import org.apache.wicket.model.ResourceModel;


import edu.unu.iist.emacao.queuing.service.QueueServiceException;

import edu.unu.iist.emacao.queuing.web.template.SecureTemplate;

public class Create extends SecureTemplate {

private Service service;

public Create() {

this(new Service());

}

protected Service getService() {

return service;

}

protected void setService(Service service) {

this.service = service;

}

public Create(Service service) {

this.service = service;

MyForm form = new MyForm("form");

TextField codeText = new TextField("code", new PropertyModel(service,

"code"));

codeText.setRequired(true);

TextField nameText = new TextField("name", new PropertyModel(service,

"name"));

TextField ackDelayText = new TextField("ackDelay", new PropertyModel(

service, "ackDelay"));

ackDelayText.setRequired(true);

APPENDICES


73

nameText.setRequired(true);

TextField meanSerText = new TextField("meanServiceTime",

new PropertyModel(service, "meanServiceTime"));

meanSerText.setRequired(true);

Button button=new Button("button");

if(service.getId()==null){

add(new Label("header", new ResourceModel("service.header_create")));

button.setModel(new ResourceModel("service.create"));

}else{

add(new Label("header", new ResourceModel("service.header_edit")));

button.setModel(new ResourceModel("service.edit"));

}

form.add(codeText);

form.add(nameText);

form.add(ackDelayText);

form.add(meanSerText);

form.add(new Label("agency", new PropertyModel(getAgency(),"name")));

form.add(button);

add(form);

add(new FeedbackPanel("feedback"));

}

@SuppressWarnings("serial")

class MyForm extends Form {

public MyForm(String id) {

super(id);

}

@Override

protected void onSubmit() {

Service service = getService();

service.setAgency(getAgency());

try {

if(service.getId()==null)

getServiceFactory().getServiceService().create(service);

else

getServiceFactory().getServiceService().update(service);

setResponsePage(edu.unu.iist.emacao.queuing.web.service.List.class);

} catch (QueueServiceException e) {

error(e.getMessage());

}

}

APPENDICES


74

}

@Override

public String getPageTitle() {

return "Appointment System - Create a service";

}

}

E.2. AGENCY LIST CLASS

Class 2: List

package edu.unu.iist.emacao.queuing.web.agencies;


import org.apache.wicket.markup.html.link.Link;


import org.apache.wicket.markup.repeater.Item;

import org.apache.wicket.markup.repeater.data.DataView;

import org.apache.wicket.markup.repeater.data.IDataProvider;

import org.apache.wicket.markup.repeater.data.ListDataProvider;



import edu.unu.iist.emacao.queuing.web.template.ConfirmLink;


public class List extends SecureTemplate {

java.util.List<Agency> listAgencies;

public List() {

add(new NewAgency("newAgency"));

listAgencies = getData();

refreshList(false);


}

private void refreshList(boolean test) {

IDataProvider provider = new ListDataProvider(listAgencies);

DataView agenciesData = new AgencyDataView("loops", provider);

if (test)

remove("loops");

add(agenciesData);

APPENDICES


75

}

private java.util.List<Agency> getData() {

java.util.List<Agency> result = null;

try {

result = (java.util.List<Agency>) getServiceFactory()

.getAgencyService().list();

} catch (Exception e) {

e.printStackTrace();


}

return result;

}

private void edit(Agency agency) {

Create create = new Create(agency);

setResponsePage(create);

}

private void delete(Agency agency) {

try {

getServiceFactory().getAgencyService().delete(agency);

setResponsePage(List.class);



}

}

private void services(Agency agency) {

edu.unu.iist.emacao.queuing.web.service.List servList = new

edu.unu.iist.emacao.queuing.web.service.List(

agency);

setResponsePage(servList);

}

@Override


return "Appointment System - List of agencies";

}

private final class AgencyDataView extends DataView {

private static final long serialVersionUID = 2202514093282421239L;

private AgencyDataView(String id, IDataProvider dataProvider) {

APPENDICES


76

super(id, dataProvider);

}

@Override

protected void populateItem(Item item) {

final Agency ag = (Agency) item.getModelObject();

item.add(new Label("name", ag.getName()));

item.add(new Label("description", ag.getDescription()));

item.add(new Label("channelId", ag.getChannelId()));

item.add(new ServicesAction("services", ag));

item.add(new EditAction("edit", ag));

item.add(new DeleteAction("delete", ag));

}

}

private final class NewAgency extends Link {


private NewAgency(String id) {

super(id);

}

@Override

public void onClick() {

setResponsePage(edu.unu.iist.emacao.queuing.web.agencies.Create.class);

}

}

private final class ServicesAction extends Link {

private static final long serialVersionUID = -3877244923013587852L;

private final Agency ag;

private ServicesAction(String id, Agency ag) {

super(id);

this.ag = ag;

}

@Override


services(ag);

}

}

APPENDICES


77

private final class EditAction extends Link {



private EditAction(String id, Agency ag) {

super(id);

this.ag = ag;

}

@Override


edit(ag);

}

}

private final class DeleteAction extends ConfirmLink {

private static final long serialVersionUID = -8992796734551382870L;


private DeleteAction(String id, Agency ag) {

super(id);

this.ag = ag;

}

@Override


delete(ag);

}

}

}

E.3. AGENCY CREATE CLASS

Class 3: Create

package edu.unu.iist.emacao.queuing.web.agencies;


import org.apache.wicket.markup.html.form.Button;

import org.apache.wicket.markup.html.form.Form;

import org.apache.wicket.markup.html.form.TextField;


import org.apache.wicket.model.PropertyModel;

import org.apache.wicket.model.ResourceModel;

import org.apache.wicket.validation.validator.PatternValidator;

APPENDICES


78




public class Create extends SecureTemplate {

public Create() {

this(new Agency());

}

public Create(Agency agenc) {

agency = agenc;

MyForm form = new MyForm("form1");

TextField nameText = new TextField("name", new PropertyModel(this,

"agency.name"));

nameText.setRequired(true);

TextField descriptionText = new TextField("description",

new PropertyModel(this, "agency.description"));

descriptionText.setRequired(true);

TextField channelIdText = new TextField("channelId", new PropertyModel(

this, "agency.channelId"));

channelIdText.setRequired(true);

channelIdText.add(new PatternValidator("[0-9]+"));

Button button = new Button("button");

if (getAgency().getId() == null) {

add(new Label("header", new ResourceModel("agency.header_create")));

button.setModel(new ResourceModel("agency.create"));

} else {

add(new Label("header", new ResourceModel("agency.header_edit")));

button.setModel(new ResourceModel("agency.edit"));

}

form.add(nameText);

form.add(descriptionText);

form.add(button);

form.add(channelIdText);

add(form);


}

private Agency agency;

protected Agency getAgency() {

return agency;

}

APPENDICES


79

protected void setAgency(Agency agency) {

this.agency = agency;

}

@SuppressWarnings("serial")

class MyForm extends Form {

public MyForm(String id) {

super(id);

}

@Override

public void onSubmit() {

try {

if (getAgency().getId() == null)

getServiceFactory().getAgencyService().create(getAgency());

else

getServiceFactory().getAgencyService().update(getAgency());

setResponsePage(List.class);




}

}

}

@Override


return "Appointment System - Create new agency";

}

}

E.4. CONFIGURATIONPARAMETERS CLASS

Class 4: ConfigurationParameter

package edu.unu.iist.emacao.queuing.util;

import java.io.FileInputStream;

import java.net.URL;

import java.util.Properties;

public class ConfigurationParameter {

private static final String memberId;

APPENDICES


80

private static final String type;

private static final SMSParameter smsParameter;

private static final EmailParameter emailParameter;

private static final String CONFIG_FILE="/config/config.properties";

private static final String emailTemplate;

private static final String smsTemplate;

private static final String agencyName;

private static final String agencyDescription;

private static final String channelId;

private static final String createNotificationTemplate;

private static final String updateNotificationTemplate;

private static final String cancelNotificationTemplate;

private static final int numMonth;

private static final int numAppointment;

static {

try {

URL url=ConfigurationParameter.class.getResource(CONFIG_FILE);

FileInputStream f=new FileInputStream(url.getPath());

Properties prop=new Properties();

prop.load(f);

memberId = prop.getProperty("memberId");

type=prop.getProperty("type");

smsParameter = new SMSParameter();

smsParameter.setUser(prop.getProperty("smsuser"));

smsParameter.setPassword(prop.getProperty("smsuserpassword"));

smsParameter.setApiId(prop.getProperty("smsapiid"));

emailParameter = new EmailParameter();

emailParame-

ter.setAuthentificationRequired(prop.getProperty("isemailauthenticationrequired"));

emailParameter.setEmailPort(prop.getProperty("emailport"));

emailParameter.setEmailServer(prop.getProperty("emailserver"));

emailParameter.setSenderEmail(prop.getProperty("senderemail"));

emailParameter.setSenderPassword(prop.getProperty("emailsenderpassword"));

emailParameter.setTLSEnabled(prop.getProperty("istlsenabled"));

emailTemplate=prop.getProperty("emailtemplate");

smsTemplate=prop.getProperty("smstemplate");

agencyName=prop.getProperty("agencyName");

agencyDescription=prop.getProperty("agencyDescription");

channelId=prop.getProperty("channelId");

createNotificationTemplate=prop.getProperty("newnotificationtemplate");

updateNotificationTemplate=prop.getProperty("updatenotificationtemplate");

cancelNotificationTemplate=prop.getProperty("cancelnotificationtemplate");

numMonth=Integer.parseInt(prop.getProperty("numbermonth"));

numAppointment=Integer.parseInt(prop.getProperty("numberappointment"));

} catch (Throwable e) {

APPENDICES


81


throw new ExceptionInInitializerError("Unable to initialize the configuration parameters");

}

}

public static String getMemberId() {

return memberId;

}

public static SMSParameter getSmsParameter() {

return smsParameter;

}

public static EmailParameter getEmailParameter() {

return emailParameter;

}

public static String getType() {

return type;

}

public static String getEmailTemplate(){

return emailTemplate;

}

public static String getSMSTemplate(){

return smsTemplate;

}

public static String getAgencyName() {

return agencyName;

}

public static String getAgencyDescription() {

return agencyDescription;

}

public static String getChannelId() {

return channelId;

}

public static String getSmsTemplate() {

return smsTemplate;

}

APPENDICES


82

public static int getNumMonth() {

return numMonth;

}

public static String getCreateNotificationTemplate() {

return createNotificationTemplate;

}

public static String getUpdateNotificationTemplate() {

return updateNotificationTemplate;

}

public static String getCancelNotificationTemplate() {

return cancelNotificationTemplate;

}

public static int getNumAppointment() {

return numAppointment;

}

}

E.5. SERVICEFACTORY CLASS

Class 5: ServiceFactory


public class ServiceFactory {

private IAgencyService agencyService;

private IAppointmentService appointmentService;

private IHolidayService holidayService;

private IServiceService serviceService;

private IWorkingHourService workingHourService;

private ICustomerService customerService;

private INotificationService notificationService;

public IAgencyService getAgencyService() {

return agencyService;

}

public void setAgencyService(IAgencyService agencyService) {

this.agencyService = agencyService;

}

public IAppointmentService getAppointmentService() {

return appointmentService;

}

APPENDICES


83

public void setAppointmentService(IAppointmentService appointmentService) {

this.appointmentService = appointmentService;

}

public IHolidayService getHolidayService() {

return holidayService;

}

public void setHolidayService(IHolidayService holidayService) {

this.holidayService = holidayService;

}

public IServiceService getServiceService() {

return serviceService;

}

public void setServiceService(IServiceService serviceService) {

this.serviceService = serviceService;

}

public IWorkingHourService getWorkingHourService() {

return workingHourService;

}

public void setWorkingHourService(IWorkingHourService workingHourService) {

this.workingHourService = workingHourService;

}

public ICustomerService getCustomerService() {

return customerService;

}

public void setCustomerService(ICustomerService customerService) {

this.customerService = customerService;

}

public INotificationService getNotificationService() {

return notificationService;

}

public void setNotificationService(INotificationService notificationService) {

this.notificationService = notificationService;

}

}

APPENDICES


84

E.6. GENERICDAO CLASS

Class 6: GenericDao

package edu.unu.iist.emacao.queuing.database.impl;

import java.io.Serializable;

import java.lang.reflect.ParameterizedType;


import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

import edu.unu.iist.emacao.queuing.database.DataAccessException;

import edu.unu.iist.emacao.queuing.database.IDao;

public class GenericDao<T, ID extends Serializable> implements IDao<T, ID> {

private Class<T> entityClass;

@PersistenceContext

private EntityManager manager;

@SuppressWarnings("unchecked")

public GenericDao() {

entityClass = (Class<T>) ((ParameterizedType) getClass()

.getGenericSuperclass()).getActualTypeArguments()[0];

}

public Class<T> getEntityClass() {

return entityClass;

}

protected EntityManager getManager() throws DataAccessException{

if(manager==null)

throw new DataAccessException("The entity manager has not yet been set");

return manager;

}

public void setManager(EntityManager manager) {

this.manager = manager;

}

APPENDICES


85

@Override

public T create(T object) throws DataAccessException {

getManager().persist(object);

return object;

}

@Override

public void delete(T object) throws DataAccessException {

//object=findById(id)

getManager().remove(object);

}

@SuppressWarnings("unchecked")

@Override

public Collection<T> findAll() throws DataAccessException {

Collection<T> result=getManager().createQuery(" select u from "+entityClass.getName()+"

u").getResultList();

return result;

}

@Override

public T findById(ID id) throws DataAccessException {

T result=(T)getManager().find(entityClass, id);

return result;

}

@Override

public T update(T object) throws DataAccessException {

object=getManager().merge(object);

return object;

}

}

E.7. APPLICATION CLASS

Class 7: Application

package edu.unu.iist.emacao.queuing.web;

import java.util.HashMap;

import java.util.Map;

import javax.servlet.ServletContext;

APPENDICES


86

import org.apache.wicket.Page;

import org.apache.wicket.Request;

import org.apache.wicket.Response;

import org.apache.wicket.Session;

import org.apache.wicket.protocol.http.WebApplication;

import org.apache.wicket.util.lang.PackageName;

import org.springframework.context.ApplicationContext;

import org.springframework.web.context.support.WebApplicationContextUtils;


import edu.unu.iist.emacao.queuing.entities.User;


import edu.unu.iist.emacao.queuing.service.ServiceFactory;

import edu.unu.iist.emacao.queuing.util.ConfigurationParameter;

import edu.unu.iist.emacao.queuing.util.Host;

import edu.unu.iist.emacao.queuing.web.agencies.Create;

import edu.unu.iist.emacao.queuing.web.session.MySession;

import edu.unu.iist.emacao.queuing.xg2g.AgencyApplicationListener;

import edu.unu.iist.emacao.queuing.xg2g.IXG2GSynchron;

import edu.unu.iist.emacao.queuing.xg2g.PortalApplicationListener;

import edu.unu.iist.emacao.queuing.xg2g.XG2GSynchron;

import edu.unu.iist.emacao.xg2g.core.Anon;


public class Application extends WebApplication {

private ServiceFactory serviceFactory;

private Member member;

private Map<String, User> users;

public Application() {

}

@Override

public Class<? extends Page> getHomePage() {

return Login.class;

}

@Override

public Session newSession(Request request, Response response) {

MySession session = new MySession(request);

return session;

APPENDICES


87

}

public ServiceFactory getServiceFactory() {

return serviceFactory;

}

@Override

protected void init() {

super.init();

ServletContext servletContext = getServletContext();

ApplicationContext applicationContext = WebApplicationContextUtils

.getRequiredWebApplicationContext(servletContext);

serviceFactory = (ServiceFactory) applicationContext

.getBean("serviceFactory");

mount("/pages", PackageName.forPackage(Login.class.getPackage()));

mount("/agency", PackageName.forPackage(Create.class.getPackage()));

mount(

"/app",

PackageName

.forPackage(edu.unu.iist.emacao.queuing.web.appointment.NewAppointment.class

.getPackage()));

mount(

"/holi",

PackageName

.forPackage(edu.unu.iist.emacao.queuing.web.holidays.Create.class

.getPackage()));

mount(

"/service",

PackageName

.forPackage(edu.unu.iist.emacao.queuing.web.service.Create.class

.getPackage()));

mount(

"/work",

PackageName

.forPackage(edu.unu.iist.emacao.queuing.web.workinghours.Create.class

.getPackage()));

mountBookmarkablePage("/pages/Home", HomePage.class);

users=new HashMap<String, User>();

if ("portal".equalsIgnoreCase(ConfigurationParameter.getType())) {

APPENDICES


88

PortalApplicationListener pListener = new PortalApplicationListener();

Anon anon = new Anon();

IXG2GSynchron synchron = new XG2GSynchron();

pListener.setXg2gSynchron(synchron);

serviceFactory.getAppointmentService().setXg2gSynchron(synchron);

member = anon.getMember(ConfigurationParameter.getMemberId(),

pListener);

users.put("portal", new User("portal", "portal", "portal",0));

users.put("user", new User("user","user","user",2));

} else {

AgencyApplicationListener aListener = new AgencyApplicationListener();

Anon anon = new Anon();

member = anon.getMember(ConfigurationParameter.getMemberId(),

aListener);

aListener.setMember(member);

aListener.setServiceFactory(serviceFactory);

users.put("agency", new User("agency","agency","agency",1));

}

if (member != null) {

serviceFactory.getAppointmentService().setMember(member);

long time = 30000L;

Host h = new Host(time);

h.setServiceFactory(serviceFactory);

h.start();

}

// Create the hosting if it does not already exists in the database

// Now we need to decide what to do if the member and the agency are not specificy

String name = ConfigurationParameter.getAgencyName();

if (name != null) {

try {

Agency ag = getServiceFactory().getAgencyService().findByName(name);

if(ag==null){

ag=new Agency();

ag.setName(name);

ag.setDescription(ConfigurationParameter.getAgencyDescription());

ag.setChannelId(ConfigurationParameter.getChannelId());

getServiceFactory().getAgencyService().create(ag);

}



APPENDICES


89

}

}

}

public Map<String, User> getUsers() {

return users;

}

}

E.8. AGENCYAPPLICATIONLISTENER CLASS

Class 8: AgencyApplicationListener


import java.text.SimpleDateFormat;

import java.util.ArrayList;

import java.util.Calendar;





import javax.persistence.NoResultException;

import org.apache.xmlbeans.XmlException;

import edu.unu.iist.egov.emacao.queue.messages.CancelAppointment;

import edu.unu.iist.egov.emacao.queue.messages.DateInterval;

import edu.unu.iist.egov.emacao.queue.messages.ErrorType;

import edu.unu.iist.egov.emacao.queue.messages.ListCenters;

import edu.unu.iist.egov.emacao.queue.messages.ListDates;

import edu.unu.iist.egov.emacao.queue.messages.MessageType;

import edu.unu.iist.egov.emacao.queue.messages.NewAppointment;


import edu.unu.iist.egov.emacao.queue.messages.UpdateAppointment;

import edu.unu.iist.emacao.gateway.xmlUtil.UserMessage;




import edu.unu.iist.emacao.queuing.entities.DayOfWeek;


import edu.unu.iist.emacao.queuing.entities.NotificationType;


APPENDICES


90



import edu.unu.iist.emacao.queuing.service.ServiceFactory;

import edu.unu.iist.emacao.queuing.util.ConfigurationParameter;

import edu.unu.iist.emacao.queuing.util.Util;

import edu.unu.iist.emacao.xg2g.core.ApplicationListener;


import edu.unu.iist.emacao.xg2g.core.Message;

public class AgencyApplicationListener implements ApplicationListener {

private ServiceFactory serviceFactory;

private Member member;

final static int CREATE = 0;

final static int UPDATE = 1;

final static int CANCEL = 2;

@Override

public void recChExtensionReply(String message) {

}

@Override

public void recConfigureChExtensionReply(String message) {

}

@Override

public void recCreateChannelReply(String message) {

}

@Override

public void recDestroyChannelReply(String message) {

}

@Override

public void recForwardReply(String message) {

}

@Override

public void recGetMemberReply(String message) {

APPENDICES


91

}

@Override

public void recManageReply(String message) {

}

@Override

public void recMemberUnsubscribe(String message) {

}

@Override

public void recReceiveMessageReply(String message) {

}

@Override

public void recRegisterReply(String message) {

}

@Override

public void recSendMessageReply(String message) {

}

@Override

public void recSubscribeChannelReply(String message) {

}

@Override

public void recUnRegisterReply(String message) {

}

@Override

public void recUnsubscribeChannelReply(String message) {

}

@Override

public void receiveMessage(String message) {

// This is the only method we need to implement

APPENDICES


92

// We get the message content

// we get the type of message

// do the required processing

// send back the message to the sender

try {

Message msg = new Message(message);

UserMessage uMsg = UserMessage.Factory.parse(msg

.getUserDefinedMessage());

QueueMessages qMsg = QueueMessages.Factory.parse(uMsg.getContent()

.toString());

String reply = null;

if (qMsg.isSetCancelAppointment()) {

// Get the parameter

CancelAppointment cMsg = qMsg.getCancelAppointment();

String serviceId = cMsg.getService();

String customerId = cMsg.getCustomerId();

Date appointmentDate = cMsg.getDate().getTime();

reply = cancelAppointment(serviceId, customerId,

appointmentDate, qMsg);

} else if (qMsg.isSetNewAppointment()) {

NewAppointment nMsg = qMsg.getNewAppointment();

String serviceCode = nMsg.getServiceCode();

String customerId = nMsg.getCustomerId();

String customerName = nMsg.getCustomerName();

Date aDate = nMsg.getDate().getTime();

Date startTime = nMsg.getTime().getTime();

String emailAddress = nMsg.getEmailAddress();

String phoneNumber = nMsg.getMobilePhone();

String center = nMsg.getCenter();

String details = nMsg.getDetails();

reply = newAppointment(serviceCode, customerId, customerName,

aDate, emailAddress, phoneNumber, startTime, center,

details, qMsg);

} else if (qMsg.isSetUpdateAppointment()) {

UpdateAppointment upMsg = qMsg.getUpdateAppointment();

String serviceId = upMsg.getService();

String customerId = upMsg.getCustomerId();

Date oldDate = upMsg.getDate().getTime();

Date newDate = upMsg.getNewDate().getTime();

Date newTime = upMsg.getTime().getTime();

reply = updateAppointment(serviceId, customerId, oldDate,

newDate, newTime, qMsg);

} else if (qMsg.isSetListDates()) {

ListDates lMsg = qMsg.getListDates();

String serviceCode = lMsg.getService();

APPENDICES


93

String center = lMsg.getCenter();

Date oldDate = (lMsg.getOldDate() == null) ? null : lMsg

.getOldDate().getTime();

Date newDate = lMsg.getNewDate().getTime();

String customerId = lMsg.getCustomerId();

reply = listDates(serviceCode, oldDate, newDate, center,

customerId, qMsg);

} else if (qMsg.isSetListCenters()) {

ListCenters centers = qMsg.getListCenters();

String service = centers.getService();

reply = listCenters(service, qMsg);

} else {

// TODO Give a value to reply here

// reply=??

}

uMsg = UserMessage.Factory.newInstance();

QueueMessages m = QueueMessages.Factory.parse(reply);

uMsg.setContent(m);

msg.setUserDefinedMessage(uMsg.toString());

String chId = msg.getChannelId();

msg.setMessageDate(new Date());

String ids = msg.getSenderId();

msg.setSenderId(msg.getReceiverId());

msg.setReceiverId(ids);

msg.setMessageStep(msg.getMessageStep() + 1);

sendMessage(chId, m.toString());

} catch (XmlException e) {


}

}

private String listCenters(String service, QueueMessages msg) {

msg.setType(MessageType.REPLY);

ListCenters c = msg.getListCenters();

try {

Service s = null;

try {

s = serviceFactory.getServiceService().findByCode(service);

} catch (NoResultException e) {

c.setErrorType(ErrorType.FAILURE);

c.setErrorDescription("Unknown service " + service);

}

if (s != null) {

APPENDICES


94

Collection<AgencyCenter> listc = serviceFactory

.getAgencyService().getCenters(s.getAgency());

if ((listc != null) && (listc.size() != 0)) {

Collection<String> val = new ArrayList<String>();

for (AgencyCenter ce : listc) {

if (serviceFactory.getServiceService()

.getNumberCounters(s, ce) > 0)

val.add(ce.getAddress());

}

String[] values = null;

if (val.size() != 0) {

values = new String[val.size()];

val.toArray(values);

}

c.setCenterArray(values);

}

}


c.setErrorType(ErrorType.FAILURE);

c.setErrorDescription(e.getMessage());

}

return msg.toString();

}

private String listDates(String serviceCode, Date oldDate, Date newDate,

String center, String customerid, QueueMessages msg) {

ListDates ld = msg.getListDates();


try {

Service s = serviceFactory.getServiceService().findByCode(

serviceCode);

ld.setMeanTime(s.getMeanServiceTime());

Calendar cal = Calendar.getInstance();

cal.setTime(newDate);

int day = cal.get(Calendar.DAY_OF_WEEK);

DayOfWeek d = Util.getDayFromInt(day);

Collection<WorkingHours> listW = null;

AgencyCenter cent = null;

if (center == null) {

Collection<Appointment> aps = serviceFactory

.getAppointmentService().findByServiceDate(customerid,

serviceCode, oldDate);

if ((aps != null) && (aps.size() != 0)) {

APPENDICES


95

center = aps.iterator().next().getCenter().getAddress();

cent = serviceFactory.getAgencyService().getCenter(

s.getAgency(), center);

}

} else {

cent = serviceFactory.getAgencyService().getCenter(


}

if (cent == null) {

ld.setError(ErrorType.FAILURE);

ld.setErrorDescription("No appointment defined for customer "

+ customerid + " for "

+ (new SimpleDateFormat("dd/MM/yyyy").format(oldDate)));


} else {

if (serviceFactory.getHolidayService().isCenterHoliday(cent,

newDate)) {

ld.setError(ErrorType.FAILURE);

ld.setErrorDescription((new SimpleDateFormat("dd/MM/yyyy"))

.format(newDate)

+ " is not a working date for "

+ center);


}

listW = serviceFactory.getAgencyService().getWorkingHours(cent,

s, d);

}

int numCounters = serviceFactory.getServiceService()

.getNumberCounters(s, cent);

if ((listW != null) && (listW.size() != 0)) {

DateInterval[] listD = null;

if (Util.today(newDate)) {

listW = getWHours(listW, s.getMeanServiceTime());

}

listD = new DateInterval[listW.size()];

int i = 0;

for (WorkingHours dt : listW) {

listD[i] = getDateInterval(dt.getStartTime(), dt

.getEndTime());

i++;

}

APPENDICES


96

ld.setWorkHoursArray(listD);

}

// check only the services for the specified center

Collection<Appointment> listBusy = serviceFactory

.getAppointmentService().findByServiceCenterDate(

serviceCode, newDate, cent);

if ((listBusy != null) && (listBusy.size() != 0)) {

Collection<DateInterval> listD = new ArrayList<DateInterval>();

for (Appointment ap : listBusy) {

if (isFull(ap, listBusy, numCounters)) {

if (!alreadyConsidered(ap, listD))

listD.add(getDateInterval(ap.getStartTime(), ap

.getEndTime()));

}

}

DateInterval[] val = new DateInterval[listD.size()];

listD.toArray(val);

ld.setOccupiedArray(val);

}

ld.setError(ErrorType.SUCESS);


ld.setError(ErrorType.UNKNOWN);

ld.setErrorDescription(e.getMessage());


}


}

private Collection<WorkingHours> getWHours(Collection<WorkingHours> listW,

int meanTime) {

Collection<WorkingHours> list = new ArrayList<WorkingHours>();

for (WorkingHours h : listW)

if (!Util.isBetween(h, meanTime))

list.add(h);

return list;

}

private boolean alreadyConsidered(Appointment ap,

Collection<DateInterval> listD) {

for (DateInterval inter : listD) {

if (ap.getStartTime().equals(inter.getMinDate().getTime())

APPENDICES


97

&& ap.getEndTime().equals(inter.getMaxDate().getTime()))

return true;

}

return false;

}

private boolean isFull(Appointment ap, Collection<Appointment> listBusy,

int numCounters) {

int val = 0;

for (Appointment p : listBusy)

if (ap.getStartTime().equals(p.getStartTime())

&& (ap.getEndTime().equals(p.getEndTime())))

val++;

return val >= numCounters;

}

private DateInterval getDateInterval(Date dateMin, Date dateMax) {

DateInterval result = DateInterval.Factory.newInstance();

result.setMinDate(calendarFromDate(dateMin));

result.setMaxDate(calendarFromDate(dateMax));

return result;

}

private Calendar calendarFromDate(Date d) {

Calendar c1 = Calendar.getInstance();

c1.setTime(d);

return c1;

}

protected String updateAppointment(String serviceCode, String customerId,

Date oldDate, Date newDate, Date newTime, QueueMessages msg) {

UpdateAppointment u = msg.getUpdateAppointment();


try {


serviceCode);

Collection<Appointment> ap = serviceFactory.getAppointmentService()

.findByServiceDate(customerId, serviceCode, oldDate);

if (ap != null && ap.size() != 0) {

for (Appointment aps : ap) {

if (aps != null) {

aps.setDate(newDate);

aps.setStartTime(newTime);

Calendar c = Calendar.getInstance();

c.setTime(newTime);

APPENDICES


98

c.add(Calendar.MINUTE, s.getMeanServiceTime());

aps.setEndTime(c.getTime());

serviceFactory.getAppointmentService().update(aps);

Notification f = aps.getNotification();

if (f != null) {

Notification ns = createNotification(aps, null, -1);

f.setMessage(ns.getMessage());

f.setTime(ns.getTime());

f.setDate(ns.getDate());

serviceFactory.getNotificationService().update(f);

}

Notification ns = createNotification(aps, new Date(),

UPDATE);

serviceFactory.getNotificationService()

.createNotification(ns);

u.setError(ErrorType.SUCESS);

}

}

} else {

u.setError(ErrorType.FAILURE);

u

.setErrorDescription(String

.format(

"No appointment

defined for the citizen %s at the date of %s",

customerId, (new

SimpleDateFormat(

"dd/MM/yyyy").format(oldDate))));

}

// Generate the reply here


u.setError(ErrorType.UNKNOWN);

u.setErrorDescription(e.getMessage());


}


}

protected String newAppointment(String serviceCode, String customerId,

String customerName, Date date, String emailAddress,

String phoneNumber, Date startTime, String center, String details,

QueueMessages msg) {


NewAppointment n = msg.getNewAppointment();

APPENDICES


99

try {


serviceCode);

AgencyCenter ac = serviceFactory.getAgencyService().getCenter(


if (serviceFactory.getHolidayService().isCenterHoliday(ac, date)) {

n.setError(ErrorType.FAILURE);

n

.setErrorDescription("You can not have an appointment on

holiday");

} else {

Appointment ap = new Appointment();// getAppointment(s, date);

Customer c = serviceFactory.getCustomerService().getById(

customerId);

if (c == null) {

c = new Customer();

c.setName(customerName);

c.setCustomerId(customerId);

c.setEmail(emailAddress);

c.setMobile(phoneNumber);

}

ap.setCustomer(c);

ap.setDate(date);

ap.setDetails(details);

ap.setService(s);

Calendar t = Calendar.getInstance();

t.setTime(startTime);

t.add(Calendar.MINUTE, s.getMeanServiceTime());

ap.setStartTime(startTime);

ap.setEndTime(t.getTime());

ap.setCenter(ac);

ap = serviceFactory.getAppointmentService().create(ap);

// Create the notification here

Notification ns = createNotification(ap, null, -1);

// ap.setNotification(ns);

ns.setAppointement(ap);

serviceFactory.getNotificationService().createNotification(ns);

ap.setNotification(ns);

getServiceFactory().getAppointmentService().update(ap);

n.setError(ErrorType.SUCESS);

// Add another notification

APPENDICES


100

Notification nss = createNotification(ap, new Date(), CREATE);

serviceFactory.getNotificationService().createNotification(nss);

}


n.setError(ErrorType.UNKNOWN);

n.setErrorDescription(e.getMessage());


}


}

private Notification createNotification(Appointment ap, Date date, int type) {

Notification notification = new Notification();

notification.setEmail(ap.getCustomer().getEmail());

notification.setNumber(ap.getCustomer().getMobile());

notification.setDate(ap.getDate());

notification

.setType((ap.getCustomer().getEmail() == null) ? NotificationType.SMS

: NotificationType.EMAIL);

String template;

Map<String, String> props = new HashMap<String, String>();

Calendar cal = Calendar.getInstance();

switch (type) {

case CREATE:

template = ConfigurationParameter.getCreateNotificationTemplate();

props.put("<<date>>", new SimpleDateFormat("MM/dd/yyyy")

.format(date));

break;

case UPDATE:

template = ConfigurationParameter.getUpdateNotificationTemplate();


break;

case CANCEL:

template = ConfigurationParameter.getCancelNotificationTemplate();


break;

default:

template = (ap.getCustomer().getEmail() == null) ? ConfigurationParameter

.getSMSTemplate()

: ConfigurationParameter.getEmailTemplate();


}

if (date != null) {

cal.add(Calendar.MINUTE, 5);

notification.setDate(date);

APPENDICES


101

notification.setTime(cal.getTime());

// template = ConfigurationParameter.getNotificationTemplate();

} else {

cal.setTime(ap.getStartTime());

cal.add(Calendar.MINUTE, -ap.getService().getAckDelay());

notification.setTime(cal.getTime());

}

props.put("<<name>>", ap.getCustomer().getName());

props.put("<<time>>", new SimpleDateFormat("H:mm").format(ap

.getStartTime()));

props.put("<<delay>>", "" + ap.getService().getAckDelay());

props.put("<<agency>>", ap.getService().getAgency().getName());

props.put("<<center>>", ap.getCenter().getAddress());

notification.setMessage(Util.format(template, props));

return notification;

}

protected String cancelAppointment(String serviceCode, String customerId,

Date appointmentDate, QueueMessages msg) {

CancelAppointment c = msg.getCancelAppointment();


try {

Collection<Appointment> ap = serviceFactory

.getAppointmentService()

.findByServiceDate(customerId, serviceCode, appointmentDate);

if ((ap != null) && (ap.size() != 0)) {

for (Appointment aps : ap) {

serviceFactory.getAppointmentService().delete(aps);

Notification ns = createNotification(aps, new Date(),

CANCEL);

serviceFactory.getNotificationService().createNotification(

ns);

}

c.setError(ErrorType.SUCESS);

} else {

c.setError(ErrorType.FAILURE);

c

.setErrorDescription(String

.format(

"No appointment

APPENDICES


102

defined for citizen %s at the date of %s",

customerId, (new

SimpleDateFormat(

"dd/MM/yyyy"))

.format(appointmentDate)));

}


c.setError(ErrorType.UNKNOWN);

c.setErrorDescription(e.getMessage());


}


}

private void sendMessage(String chId, String msg) {

if (member != null) {

String msgs = member.formatMessage(chId, msg, null);

member.sendMessage(chId, msgs);

}

}

public ServiceFactory getServiceFactory() {

return serviceFactory;

}

public void setServiceFactory(ServiceFactory serviceFactory) {

this.serviceFactory = serviceFactory;

}

public Member getMember() {

return member;

}

public void setMember(Member member) {

this.member = member;

}

}

APPENDICES


103

E.9. XG2GSYNCHRON CLASS

Class 9: XG2GSynchron





public class XG2GSynchron implements IXG2GSynchron {

private Map<Long, QueueMessages> listMessage;

public XG2GSynchron(){

listMessage=new HashMap<Long, QueueMessages>();

}

@Override

public void addMessage(QueueMessages msg) {

if(msg!=null){

listMessage.put(msg.getMessageId(), msg);

}

}

@Override

public QueueMessages getMessage(long id) {

QueueMessages msg=null;

while(msg==null){

msg=listMessage.get(id);

try {

Thread.sleep(1000);

} catch (InterruptedException e) {

// TODO log this message


}

}

return msg;

}

}

APPENDICES


104

E.10. PORTALAPPLICATIONLISTENER CLASS

Class 10: PortalApplicationListener


import org.apache.xmlbeans.XmlException;


import edu.unu.iist.emacao.gateway.xmlUtil.UserMessage;

import edu.unu.iist.emacao.xg2g.core.ApplicationListener;

import edu.unu.iist.emacao.xg2g.core.Message;

public class PortalApplicationListener implements ApplicationListener{

private IXG2GSynchron xg2gSynchron;

public PortalApplicationListener(){

}

@Override

public void recChExtensionReply(String message) {

}

@Override

public void recConfigureChExtensionReply(String message) {

}

@Override

public void recCreateChannelReply(String message) {

}

@Override

public void recDestroyChannelReply(String message) {

}

@Override

public void recForwardReply(String message) {

}

@Override

APPENDICES


105

public void recGetMemberReply(String message) {

}

@Override

public void recManageReply(String message) {

}

@Override

public void recMemberUnsubscribe(String message) {

}

@Override

public void recReceiveMessageReply(String message) {

}

@Override

public void recRegisterReply(String message) {

}

@Override

public void recSendMessageReply(String message) {

}

@Override

public void recSubscribeChannelReply(String message) {

}

@Override

public void recUnRegisterReply(String message) {

}

@Override

public void recUnsubscribeChannelReply(String message) {

}

@Override

APPENDICES


106

public void receiveMessage(String message) {

// We need to implement this method in order to enable the portal to

// receive messages. The simple idea is to extract the content and put it in a queue

try {

QueueMessages msg=null;

Message m=new Message(message);

UserMessage uMsg = UserMessage.Factory.parse(m.getUserDefinedMessage());

msg = QueueMessages.Factory.parse(uMsg.getContent()

.toString());

xg2gSynchron.addMessage(msg);

} catch (XmlException e) {


}

}

public IXG2GSynchron getXg2gSynchron() {

return xg2gSynchron;

}

public void setXg2gSynchron(IXG2GSynchron xg2gSynchron) {

this.xg2gSynchron = xg2gSynchron;

}

}

UNU-IIST Center for Electronic Governance

E-Appointment Service - Development Report - Ver 1.0

Documents

Transcript of E-Appointment Service - Development Report - Ver 1.0