wordt
NIET
uitgeleend
Institute for Mathematics and Computing Science
M.Sc. Final Research Project
System Wide Database Notification Service
Samvel Petrosyan
April 2007
J
This thesis is submitted to the Department of Computer Science at Rijksuni- versiteit of Groningen in partial fulfillment of the requirements for the degree of Master of Science in Software and System Engineering.
Contact Information
Author: Samvel Petrosya.n
E-mail: s.petrosyan©student.rug.nl
Supervisors:
Dr. Paris Avgeriou
Department of Mathematics and Computing Science Software Engineering and Architecture (SEARCH) Group University of Groningen
Email: paris©cs.rug.nl Richard Storm
Head of Software development dep.
ChipSoft BV.
Email: richard©chipsoft .nl
Abstract
There is an increasing amount of data in databases that is shared among many client computers. Some of this data may be relatively static. However, certain types of data may be changing frequently. Client applications may be interested in changes that are made to these data. Notifications of such changes allow a client to be made aware of changes that are made by another client application in a timely fashion. In this paper, I describe my work on exploring, designing, implementing and integrating of a notification mechanism in the CS-ECIS application developed at the company ChipSoft. To achieve this goal is the publish/subscribe technol- ogy, which is emerging as an appropriate comxnunicatioii paradigm for large-scale distributed systems, used. In the designed architecture. each client application defines and advertises change events to the notification service. The clients can subscribe to events of interest, and can refine their subscriptions through attribute-
filter expressions. A notification is sent whenever a database change, detected by the notification service, matches some active subscriptions.
Contents
Notation and Abbreviations vii
Acknowledgments ix
1 Introduction
i
1.1 The Company 1
1.2 CS-ECIS Application 1
1.3 Problem Definition 2
1.4 Purpose 3
1.5 Background 4
2 Performance of Existing System
52.1 Introduction 5
2.2 Test Environment 5
2.3 Test Description 5
2.4 Data Analysis 6
2.5 Estimation 10
3 Architecture of CS-ECIS 12
3.1 Common Object Model 12
3.2 Software Architecture 13
3.2.1 ObjectLogics 16
3.2.2 Data Objects 16
3.2.3 Data Fields 17
3.2.4 Data Field
.
173.2.5 Collections 18
3.2.6 Scope 19
3.2.7 Filter 20
3.3 Key Drivers 20
3.4 Industrial Relevance of the Project 22
4 Background Theory and Problem analysis
234.1 Base Technologies for the Notification Facility 23
4.1.1 Passive Databases 23
4.1.2 Active Databases 24
4.1.3 Publish/Subscribe Mechanism with Message Brokers . . . . 25
4.1.4 Comparison of Active, Passive Databases and External Mes-
sage Brokers 26
4.2 Waiting and Non-Waiting Applications 27
4.3 Push and Poll Notifications 28
4.4 Reliability and Correctness 29
4.4.1 Reliability of Notifications 29
4.4.2 Consistency and Invalidation 30
4.5 Notification Propagation 33
4.6 Types of Notifications 34
4.7 Duplicate Notifications 34
4.8 Wanted and Unwanted Notifications 34
5 Requirements
366 Design and Implementation
426.1 Design Decisions and Related Design Patterns 42
6.1.1 DCOM 42
6.1.2 Topic and Content Based Publishing/Subscription 43
6.1.3 Tightly and Loosely Coupled Events 44
11
6.1.4 Strategy Design Pattern
.
476.2 Architecture of Notification Service 47
6.2.1 Logical View 49
6.2.2 Dynamic View 51
6.2.3 Development View 56
6.2.4 Deployment View 58
6.3 Notification and Content-based Filter Model 59
6.4 Lightweight Evaluation of the Architecture 60
6.4.1 Scenario Based Evaluation 60
6.4.2 Prototype Evaluation 62
6.5 Implementation Issues 65
6.5.1 Development Environment 65
6.5.2 Integration into CS-ECIS 65
7 Discussion
678 Related Work 69
9 Future Work
7110 Conclusions 72
11 Appendix 73
11.1 Screenshot of ECIS client with integrated notification facility . . . 73
11.2 Definitions of the Interfaces 73
Bibliography 77
111
List of Figures
1.1 Database configuration of CS-ECIS
.
21.2 Client views become out of sync 3
Query trace
Query trace (Continued)
Number of queries of the clients Architecture of CS-ECIS
Layered architecture of CS-ECIS Class Diagram
ICS..ObjectLogic ICS..Objeds ICSVelden ICS..Veld
19 3.9 Relations between ICS.Veld,
and ICS..Object 3.10 ICS...Sco-pe
3.11 ICSFilterExpression .
4.1 Data inconsistency due to a concurrency issue 4.2 Data invalidation mechanism
6.1 CS-ECIS client and the DCOM notification service 6.2 Tightly Coupled Events (TCE) pattern
iv 2.1
2.2 2.3
3.1 3.2 3.3 3.4 3.5 3.6 3.7
8 9 10
3.8 ICS.Collection
ICS...ObjectLogic, ICS...Collection
19 20 20
31 33
43 45
6.3 Loosely Coupled Events (LCE) pattern
.
466.4 Applied strategy pattern 47
6.5 Architecture of the notification service 49
6.6 Logicalview 51
6.7 Flow of calls in the system 53
6.8 Sequence diagram of communication between the clients and the
notification service 55
6.9 Development view 56
6.10 Dependencies between modules . . . 58
6.11 Deployment view 59
11.1 Screenshot of CS-ECIS client 73
v
List of Tables
2.1 Pattern of queries issued by a client 7
2.2 Top 10 clients 10
2.3 Estimated and worst case values of number of queries 11
4.1 Comparison of the active/passive databases and external message
brokers 27
5.1 The requirements 37
5.2 Use case scenario 1 38
5.3 Use case scenario 2 39
5.4 Use case scenario 3 40
5.5 Use case scenario 4 41
6.1 Scenarios 61
6.2 Cost of the impact of scenarios 62
6.3 Impact of scenarios 62
6.4 Performance test results 63
6.5 Efficiency test results 64
6.6 Security test observations . . . 65
vi
Notation and Abbreviations
API Application Programming Interface ASP Active Server Pages
BL Business Logic
COM Common Object Model
CS-ECIS Electronic Care Information System CQ Continuous Queries
DBMS Database Management System DCOM Distributed COM
DLL Dynamic Loadable Library
DTC Diagnosis Treatment Combination ECA Event-Condition-Action
EPR Electronic Patient Record GUI Graphic User Interface
GUID Globally Unique Identification HR Hardware Requirement
ID Identification number
vii
JS Java Script
LAN Local Area Network
LAZR Landelijke Ambulante Zorg LCE Loosely Coupled Events MS Microsoft Co.
OK Operatie Kainer (Operation Room) OLTP Online Transaction Processing OOP Object Oriented Programming PDA Personal Digital Assistant RPC Remote Procedure Call
SAAM Software Architecture Analysis Method SFR Software Functional Requirement
SMTP Simple Mail Transfer Protocol SNFR Software Nonfunctional Requirement SQL Structured Query Language
TCE Tightly Coupled Events TLB Type Library
TPC Transaction Processing Performance Council VCL Visual Component Library
YB Visual Basic
WML Wireless Markup Language XML Extensible Markup Language
viii
Acknowledgments
I would like to express my heartfelt thanks to my supervisor at ChipSoft, Richard Storm. His thoughtful support and guidance throughout the duration of this project truly helped make this one of the most useful learning experience ofmy study. I would like to thank all of colleagues at ChipSoft forso selflessly giving of their time to help me to understand the architecture and the working of CS-ECIS.
I would like also thank my supervisor at RuG, Paris Avgeriou for reviewing and giving helpful hints for improvement of this document.
ix
Chapter 1
Introduction
1.1 The Company
ChipSoft is a software house that has been specialized in computerization in health care and from the outset it is focused exclusively on supplying the health care sec- tor. In 1986, ChipSoft began developing software products for medical specialists and various hospital departments. In 1994, ChipSoft introduced its first hospital information system. In 2001, ChipSoft launched the first integrated Windows- based care information system: the Electronic Care Information System (CS- ECIS). ChipSoft is a successful, innovative, flexible and dynamic company with a contemporary vision of computerization in health care. On the basis of a thorough understanding of the developments within the health care sector, ChipSoft provides accurate ICT solutions. The Windows-based CS-ECIS offers a seamless solution for the increasing need for flexible and deployable functionality and transmural communication facilities. Although the products of ChipSoft are already used in six European countries, ChipSoft is still a purely Dutch software house.
1.2 CS-ECIS Application
The CS-ECIS application is based on various care processes and divided into a few concepts, such as: inpatients, outpatients, order communication, EPR (Electronic Patient Record) generation, invoicing and procedure administration. In a single system, patient records, planning schedules, patient flow organization, medication and administrative transactions are processed and made readily comprehensible.
The CS-ECIS is an evolving system and has the foundations for future expansions.
These expansions can lead the application beyond the traditional boundaries be- tween medical and management information. The building blocks of the CS-ECIS are individual functions, which can be assembled as components in a configure-it- yourself user interface, based on the user's specific work processes. On the basis of their function profile, users can consult or register various data.
Figure 1.1 depicts the conventional CS-ESIC database configuration, wherein the users access information stored in the database. The application is divided into the following three tiers: the graphic user interface, the application business logic and the database drivers. The application and the database interact in a client/server relationship, where the application is the client and the database is
1
2 1.3 Problem Definition
the server. Application business logic establishes a connection to the database using the database driver. The application business layer uses the API provided by the database driver abstraction layer. This allows the application to have more than one database driver in a transparent for the application manner.
a a a
User I User 2 User N
GUI GUI GUI
BL BL BL
Div Div Div
GUI-Gogifluc1.1wIuitl.c.
SL -nsu Logic
Database
Figure 1.1: Database configuration of CS-ECIS
Data retrieved from the database displayed to the user in grids and other GUI elements. In order to keep data in the application up-to-date (i.e. sync with the database), the client applications poll the database once in two minutes (or once in 30 seconds dependent on functionality) and refresh stale collections of data. Because of this, the ability of CS-ECIS to display critical and timely data is restricted by the substantial amount of time delay between these data refresh cycles.
1.3 Problem Definition
The CS-ECIS enterprise system is a complicated database system which is extend- ing rapidly with respect to functionalities and function groups of the system. The system based on three-tier client server architecture. The several hundred clients working with shared data in the database, hold passive data such as views, records etc. Each client has own view on the current state of shared data. If the state of shared data in question is changed, the data will not be able to notify the clients about this change. That means that the client views become out of sync with the database and the users get inconsistent views. This requires continuous fetching data (i.e. polling) out of the database server to refresh data collections. The above described situation is depicted in figure 1.2.
3 1.4 Purpose
Ctat1 Cieit2 Cht3
Figure 1.2: Client views become out of sync
The clients refresh their data collections once in /t period of time. If the client 1 changes a record in the database, depending on the polling time-frame/frequency, other clients (in this case client 2 and client 3) become temporarily inconsistent with the database. These clients have to wait maximum Lt period of time to get the changed data.
However, the main problem is that the system constantly deals with big number of growing new users (physiotherapists, nurses etc.). Because of this, constantly polling the database has created capacity and performance problems. The de- creasing performance has become a bottleneck of the system. At the present, some complex database forms/screens in the system are refreshing once every 30 seconds, regardless the data has changed or not. This results in heavy load on the network and on the database. Simple operations (e.g. making an appoint- ment, receiving a reception etc) take much longer than acceptable. In order to improve the performance of the system, ChipSoft desires to develop a system and methods for automatically notifying users upon the occurrence of selected events (e.g. changed data in the database). In addition, it would be desirable for such notification system to be able to handle different types of events and to present notifications to the users in different ways.
1.4 Purpose
Currently, the users of CS-ECIS are working with views that often contain out of date data. Beside this, the increasing number of users causes high database and network load. This all makes difficult to efficiently perform work in hospitals and care centers. ChipSoft desires to improve the usability of CS-ECIS and reduce the current load of the system by introducing a database change detection and user notification facility, so that the system can handle the increasing capacity of users and decrease likelihood of stale data. The purpose of this project is to help Chip-
I View up-to-
View oil de Xt -daarrethcde
4 1.5 Background
Soft to find the roots causing low performance of the system, analyze them, design an appropriate database change detection and notification mechanism, implement it and integrate it into CS-ECIS environment.
1.5 Background
Many computer applications utilize a database to store, retrieve and manipulate information. Such systems have a wide range of usage in health care information systems. For example, a hospital department might use a database to store in- formation about their patients, appointments with doctors, occupation of surgery rooms, etc. The database store is a collection of data structures organized in a disciplined fashion that makes stored information of interest quickly accessible.
The retrieval and display of this information is essential in modern information systems. To achieve this goal CS-ECIS provides access to information on the database that enables users to enter, organize and select data in the database.
In the last few years, closely controlled environments have evolved into large scale collaboration spaces that are both highly distributed and dynamic. This evolu- tion has led to new requirements (e.g. displaying timely and critical data, etc), as well as to new application domains for distributed information systems. Exam- ples arise in health care information systems, business process (workflow) control, network management, etc. These areas share the same basic requirement of track- ing changes at a collection of information sources in order to detect situations of interest. The information system must identify relevant changes and notify them to users or client applications, without requiring them to know a priori where and when to look for data. The challenge of this project is to provide CS-ECIS the necessary mechanisms and strategies for a scalable, reliable and secure notification service to meet the new requirements.
P.
Chapter 2
Performance of Existing System
2.1 Introduction
One of the goals of this project is to reduce the load on the network and on the database server to an acceptable level by reducing the refresh queries to minimum.
In order to find the roots of the performance bottleneck in the system, a perfor- mance test is performed. There can be a few sources that can cause a performance bottleneck in the system. One of them is the refresh queries. The ECIS client application consists of several screens which must be always kept up-to-date with the database. Each of these screens regularly issues one or more refresh queries to the database. The number of the refresh queries depends on the number of opened screens in the ECIS client at the moment. The aim of this test is to make
an estimation about the frequency and the quantity of these refresh-queries in the system. Further, it has to be examined if these queries cause a bottleneck in the system.
2.2 Test Environment
The test is performed on the production database at the hospital of SFG (Sint Franciscus Gasthuis in Rotterdam). MS SQL 7.0 on a dual processor server as the production database, and ECIS 4.8 as client application are used during the test.
2.3 Test Description
During the performance test, the queries generated by 251 online clients has been traced and logged. There are two types of online clients: active clients and passive clients. An active client is referred to the client which user was active working on the database. A passive client is referred to the client that was idle during the test and has only issued refresh queries. During 6 minutes were all the queries fired by 251 active/passive clients captured and stored in the database. The logged queries consist of a few comment lines and a native SQL query. The comment
lines provide debug information about the query, such as the logic from which the query is originated, the action during which the query is fired, the scope and
5
6 2.4 Data Analysis
the filter of the query, etc. In order to estimate the performance of the database server is the reference TPC-C benchmark used. TPC Benchmark C is an on- line transaction processing (OLTP) benchmark. TPC-C is an industry standard benchmark for measuring the performance and scalability of OLTP systems. It tests a broad cross-section of database functionality including inquiry, update, and queued mini-batch transactions. Many IT professionals consider TPC-C to be a valid indicator of "real-world" OLTP system performance. The benchmarks of Compaq servers (we take an average Compaq server as a reference point) have shown that a four processor database server scores an average of 100000 tpmC (transactions per minute of type C). It means that a dual processor system would be limited by approximately 833 transactions/sec. In order to avoid the bottleneck, the number of transaction in the ECIS system should be below this limit. The ECIS clients are programmed to use automatic transactions which means that one transaction comprised from one query. So the number of queries is equal to the number of transactions in the system. Further in this section, all calculations applied to queries are the same for transactions.
2.4 Data Analysis
Working with the ECIS client requires from the user to keep number of screens open simultaneously. One of the opened screens, that is active at the moment, fires "normal" queries to retrieve data from the database. Other screens, at the background, fire refresh-queries in order to refresh data and keep data collections up-to-date with the database. It is very difficult task to distinguish the "normal"
queries from the refresh-queries among all logged queries. It took a lot of time from me to dig these refresh-queries out and make an estimation.
During 6 minutes, there were total 65584 queries logged in the database. If we assume that the queries are uniform distributed over the total time of the test then we get an average query-rate of:
65584 queries/6 mm = 182 queries/ sec (2.1) This is not so much for an advanced database server such as MS-SQL. However, this estimation of the average query-rate may not represent the reality. The query- rate depends on several variables (such as the type and a number of open screens in ECIS, how long a screen was open, the way of behaving of the user, the time when the test is taken, etc.) that have sporadic behavior. However, the analysis of the logged queries revealed many patterns of SQL queries which have regular basis and it seems that they are generated by the refresh timers of passive ECIS clients. An example of such query is shown below:
* Generated by ChipSoft Base 4.7.0.27
*
* ADO Version : 2.7
* Logic csAgendaService2.cS_AfspraakMutatieLogic
* Action : CreateView(Scope, Filter)
* Trigger : NeedsLast
* ScopeOrder : SubagendalD,Mutatiedatum,Mutatietijd
* ScopeFilter : (<SubagendalD> — 'S00034' EN <Mutatiedatum> — 05—10—2005 EN
<Mutatietijd> >— 01—01—0002 15:27:09)
* Filter : Altijd Waar
7 2.4 Data Analysis
sp_executesql N'
SELECT TOP 20 A. [AFSPRAAKNR] ,A.[DATUM],A. [TIJD] ,A. [CONSULTNR] ,A. [AGENDA] ,A. [SUBAGENDA], A. [PATIENTNR] ,A. [AFSPTYPE] ,A. [COMBINR] ,A. [INVOERDAT] ,A. [DOORWIE],
A. [TEBNIJN] ,A. [OMSCHR] ,A. [CODE] ,A. [DUUR] ,A. [DIAGNOSE] ,A. [CONSTYPE], A. [NIEUWDECL] ,A.[ONTBRREDEN] ,A. [KLIN?OLI] ,A. [AANVRAGER] •A. [UITVOERDEB.], A. [MOBILITEIT] ,A. [VOLDAAN] ,A. [VERPLREDEN] ,A. [LOKATIE] ,A. [AUTODAT], A. [FAKTDAT] ,A. [LAZRDAT] ,A. [FAXTSTATtJS] ,A. [LAZRSTATUS] ,A. [EPB] ,A. [MUTDAT], A. [MUTTIJD] ,A. [MUTWIE] ,A. [MUTTYPE] ,A. [M1O] ,A. [EPISODE] ,A. [LISTCDDES], A. [AANKOMST] ,A. [OPROEP] ,A. [VERTREK] , A. [STATUS] , A. [GROEPSNR] ,A.[HERHAALNR]
FROM [dbo]. [AGENDA_MUTATIE] AS A
WHERE ((A. [SUBAGENDA] • CSV1 AND A. [MUTDAT] — CSV2 AND A. [MUTTIJD] >= CSV3)
AND A. [DATUM] — CSV4) ORDHE BY A. [SIJBAGENDA] DESC ,A. [MUTDAT] DESC ,A. [MUTTIJD] DESC ,A.[AFSPRAAKNR] DESC,
A. [MUTTYPE] DESC OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)
',
N'CSVl nvarchar(6) ,OSV2 datetime,OSV3 nvarchar(11) ,OSV4 datetime', CSV1'S00034',0SV2'20051005',0SV3'15:27:09:91' ,0SV4'20051005'Finding in the log all instances of this query revealed that the query is issued once each 30 seconds. It is shown in the table 2.1.
Database Id Hostname Duration Start Time Reads Writes CPU
8 N26293 0 15:29:55 4 0 0
8 N26293 0 15:31:09 4 0 0
8 N26293 0 15:31:24 4 0 0
8 N26293 0 15:31:54 4 0 0
8 N26293 0 15:32:24 4 0 0
8 N26293 0 15:32:54 4 0 0
8 N26293 0 15:33:24 4 0 0
8 N26293 0 15:33:54 4 0 0
8 N26293 0 15:34:24 4 0 0
8 N26293 0 15:34:54 4 0 0
Table 2.1: Pattern of queries issued by a client
The above described query is a small query that requires 4 reads from the database server. It seems that the database can easily handle these kind of refresh- queries because of the null duration of the queries. Among these small refresh- queries, I found huge blocks of refresh-queries. For instance, the following block of refresh-queries consists of 70 refresh-queries. The snipped block is shown be- low. The refresh cycle takes place once in 2 minutes (the second block begins at
15:34:23:023).
8
Figure 2.1: Query trace
2.4 Data Analysis
1*:
r createVi... 116466
r CreateVi.-. 116466
/
CreateVi. -. 116466ft CreateVi... 116466 / CreateVi.. - 116466 ft Createvi.. - 116466 ft CreateVi... 116466 /t CreateVi - - 116466
/ CreateVj .- 116466
/ CreateVj. .- 116466
426 30 0
426 0 426 0 426 0 426 0 426 0 426 0 426 0 426 0
2005—10—05 15:31:22 77U 2005—10—OS IS:31:23.083
2005—10—05 15:31:23. 300 2005—10—05 15:31:23.300 2005—10-05 15:31:23.317 2005-10-05 15:31:23.350 2005—10—05 15:31:23.363 2005—10—05 15:31:23.380 2005—10—05 15:31:23.397 2005—10—05 1S:31:23.397
574 2
91 7 5 37 8 4 3 73
0 0 0 0 0 0 0
u 0 0 0 0 0 0
/ CreateVi . 116466 426 0 2005—10—05 15:31:23.410 8 0 0 / Createvi. -. 116466
/t CreateVj.. . 116466
426 0 426 0
2005—10—05 15:31:23.427 2005—10—05 16:31:23.443
4 3
0 0
9 0
/t CreateVi. 116466 426 0 2005—10—05 15:31:23.460 85 0 0
ft CreateVi... 116466 ft CreateVj.. 116466
426 0 426 0
2005—10—05 15:31:23.473 2005—10—05 15:31:23.473
7 5
•0 .0
0 .0
f CreateVi... 116466
/ CreateVi... 116466
426 0 426 0
2005—10—05 15:31:23.503 2005—10—os 15:31:23.503
3 73
.0 0
0 0
ft CreateVi... 116466 426 0 2005—10—05 15:31:23.520 7 0 0
/ Createvj. 116466
ft CreateVj . 116466 / Createvi. .. 116466 / Createvi. . 116466
I CreateVL.. 116466
ft CreateVj.. 116466
/ CreateVj.. 116465
426 0 426 0 426 0
.
426+0 426 0 426 0 426 0
20051005 15:31:23.537 2005—10—05 15:31:23.550 2005—10—05 15:31:23.567
.
2005—10—05 15:31:23.567
—r—-—
2005—10—05 15:31:23.583
2005—10—05 15:31:23.600 2005—10—05 15:31:23.613
.
3 91 28 4 3 22
° 0 0 0
.
0 0 0
•o 0
—--.0 0
.
0 0 0
ft CreateVi.. 116466
ft CreateVi. 116466
/t CreateVi... 116466
426 0 426 0 426 0
2005—10—05 15:31:23.630 2005—10—05 15:31:23.647 2005—10—05 15:31:23.660
7 6 73
0 0 0
•0 0 0
ft Createvj.. 116466
I CreateVi. 116466
426 0 426 16
2005—10—05 15:31:23.677 2005-10—05 15:31:23.693
7 4
0 0
0 15
9
Figure 2.2: Query trace (Continued)
2.4 Data Analysis
From picture above we can see that these queries require much more reads from the database server and some of them took pretty much time and CPU resources to execute. It is clear that too much of this kind of queries can easily cause a bottleneck in the system.
In order to get a complete picture of what is going on in the system, I made a histogram where the number of fired queries by the clients is shown. The histogram is depicted in the figure 2.3.
-n
ft ft ft
ft ft
ft
ft
f
ft
CreateVi.. .
Createvi.- - Createvi.. . CreateVi.- - Createvi.-.
CreateVi.- - Createvi...
Createvi. - -
Createvi...
116466 116466 116466 116466 116466 116466 116466 116466 116466
426 426 426 426 426 426 426 426 426
0 0 0 0 0 0 0 30 0
2005—10—05 2005—10—OS 2005—10—05 2005—10—OS 2005—10—05 2005—10-05 2005—10—OS 2005—10—05 2005—10—05
15:31:24.210 15:31:24.223 15:31:24.240 15:31:24.253 15:31:24.270 15:31:24.287 15:31:24.300 15:34:23.023 15:34:23.117
37 7 4 3 7 S 5
573 2
0 0 0 0 0 0
•0 0
0 0 0 0 0 0 0 16 0 ft
ft
ft
ft ft
rft ft
ft ft
f
f ft
ft
ft
/
Createvi...
CreateVi...
CreateVi...
Createvi...
CreateVi...
createVi. ..
CreateVL ..
CreateVi..
CreateVi. .
CreateVi. .
CreateVi..
CreateVi. . .
CreateVi...
CreateVi...
CreateVi...
CreateVi...
116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466 116466
426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426
0 0 0 0
0
0 -
:0
0
0 0 .0
0 0 0 0 0
2005—10-05 2005—10—05 2005—10—OS 2005—10—05 2005—10—OS 2005—19-05 2005—10—05 2005—10—05 2005—10—OS 2005—10-Os 2005—10—05 2005—10—05 2005—10—OS 2005—10—05 2005—10—05 2005—10—05
15:34:23.320 -
15:34:23.337
15:34:23.350 15:34:23.380 15:34:23.443 15:34:23.460 15:34:23.477 15: 34:23.490 15:34:23.523 15:34:23.523 15:34:23.553 15:34:23.553 15:34:23.570 15:34:23.587 15:34:23.600 15:34:23.617
91 7 S
37 8 4
3 73 8 4
3 85 7 5
•3 73
0
-
- •0
•0
9 0
0
•0
0 0 0 0 0 0 0
0 0 0 0 0
•
0 0
•0
0 0 0
•0
•0 0 ft
ft ft
createvi. - .
CreateVi...
CreateVi...
116466 116466 116466
426 426 426
0 0 0
2005—10-05 2005—10—05 2005—10—05
15:34:23.630 15:34:23.647 15:34:23.663
7
•4 3
0 0 0
0
•0
0 f CreateVi... 116466 426 0 2005—10—05 15:34:23.680 91 0 0
ft
ft CreateVi...
CreateVi...
116466 116466
426 426
•0 0
2005—10—05 2005—10—OS
15:34:23.680 15:34:23.693
28
4 0 0
0 0
10
Figure 2.3: Number of queries of the clients
2.5 Estimation
SPID (Security Process ID)
119 89 434
167 305 267 250 288 157
#Queries 9734 5963 3655 2963 1523 1374 1309 1271 1116
The queries, that have been fired by these clients, are studied but unfortu- nately no regular patterns were found among them. That means that there were no refresh-queries queries, or blocks of refresh-queries were too long and it was impossible to recognize them.
2.5 Estimation
Many patterns of refresh-queries have been found in the sql-trace. If we assume that all 250 users have three simultaneous open screens then each screen would generate in average 60 queries/mm (arithmetic average of all blocks of refresh- query patterns that are found in the trace). In the table 2.3, the estimated and
:
6O61 61 11 81 90101113121 134l44l551691761861621522423224o24825172812923o1313321 334346361 3723e7401425439 SPID of the cb.ns
From the histogram we can see that about 30% (22000 queries) from all queries belongs to 4 clients. In the table 2.2, the top 10 clients with the number of fired queries are shown.
Table 2.2: Top 10 clients
11 2.5 Estimation
the worst case values of the number of queries are shown.
Estimated average value Worst case value
Number of users 250 500
Open screens 3 6
Query /min (per user) 60 120
Query / sec (all users) 750 6000
Table 2.3: Estimated and worst case values of number of queries
The above calculations show that the estimated value of the number of all queries remains under the limit of an average SQL server (833 transactions/see).
However, when the number of users and the number of open screens increases, the number of queries increases too and in worst case we get three times more queries than an average SQL server can handle. It is clear that in worst case the refresh queries can cause performance problems.
This research shows that the database queries generated by the GUI widgets of CS-ECIS can be the source of the network and the database heavy load. They can cause a bottleneck in the system. By introducing a system wide notification facility, CS-ECIS application will be able to heavily relay on cached data and will be able to decrease the number of refresh-queries sending to the database. This way, the performance of the system can be increased and the usability of CS-ECIS application improved.
Chapter 3
Architecture of CS-ECIS
The CS-ECIS application has component based architecture and entirely based on the Common Object Model (COM) technology of Microsoft. It makes heavy use of COM-objects. In order to understand the rationale behind CS-ECIS architecture, it is important to know the basic concepts of COM. In the following section I revise the basic principles of the COM technology.
3.1 Common Object Model
The Microsoft Component Object Model (COM) is a platform-independent, dis- tributed, object-oriented system for creating binary software components that can interact. COM is a framework for developing and supporting program component objects. It provides the underlying services of interface negotiation, life cycle man- agement (determining when an object can be removed from a system), licensing, and event services (putting one object into service as the result of an event that has happened to another object). On the one hand, the COM is a specification for writing reusable software that runs in component-based systems. On the other hand, COM can be thought of as a sophisticated infrastructure that allows clients and objects to commmicate across process and host computer boundaries. COM is a model based on binary reuse. This means that software (components) adhering to COM can be reused without any dependencies on source code. From developer's point of view, using a COM-object is exactly like using a local object; however the COM infrastructure is a bit more complex. COM was built from the ground up to be object-oriented. It is based on clients, classes and objects. Classes are defined in binary files called servers. These servers make it possible for clients to create and connect to objects whose code lives in a separate binary file. For example, in CS-ECIS application each module that resides on GUI tier and each service that resides on business logic tier are COM servers. At the run-time, the application creates these servers and connects to them in order to use the services offered by these servers. After a client connects to an object, it simply invokes methods as in any other OOP environment. COM fully supports the object-oriented concepts of encapsulation and polymorphism as means to achieve code reuse. Moreover, it is completely language independent and virtually any programming language can be used to create COM powered components and application. That means that scripting languages such as VB, JS, ASP, etc. are able to use COM objects.
12
13 3.2 Software Architecture
These languages lack of compile time interface binding that COM objects require.
However, COM provides so-called interface late binding technique. Late binding is all about asking an object what methods it supports instead of what interfaces.
Whereas early binding passes a GUID of the interface it is interested in to COM object, late binding presents the object with a method name in the form of a wide- character string. If, after interpreting the string, the object supports a method by that name, it returns with a number representing that method. This number is referred to as a dispatch ID or DISPID. After the client has this number, it can call the method by invoking the number.
3.2 Software Architecture
Figure 3.1 depicts the global architecture of the CS-ECIS client.
GUI Framework
caM o
. .
V
\•
cCMOS4sc* \I
,
\ /\
4! \
CIpSefEs 5/
CaMa /
I
Figure 3.1: Architecture of CS-ECIS
The application consists of services, modules and a GUI framework. As I explained earlier, each module is a COM object that implements the desired func- tionality. The services are also COM objects and they take care of providing data to modules. The modules get desired data from services and show it in grids and other GUI controls. The framework hosts and manages the windows, exposed by modules that contain these GUI controls. Communication between these COM ob- jects goes only via defined interfaces that the COM objects expose. The figure 3.2 shows how the framework and COM servers from different layers connect to each other via defined interfaces. For example, the framework connects to the modules from the business layer via ICSOK and ICS.Agenda interfaces. The modules, in their turn, connect to the services from de the data layer via ICS_OKLogic and ICSAgendaLogic interfaces.
14 3.2 Software Architecture
cS-ECIS UI
___tics
4ea da
Figure 3.2: Layered architecture of CS-ECIS
Every COM object in the application belongs to the corresponding tier de- pendent on provided functionality. The COM objects that belong to the data tier of the application (i.e. services) are data-object factories for the COM object that belong to the business tier. For example, in order to display a table filled with OK data-objects, first, the "raw" data is retrieved from the database then it is processed by CSOKLogic. The CSOKLogic converts the "raw" data to a typed collection and corresponding sub-collections of OK data-objects. These data-objects are processed against business rules which are defined in CS.DK object in the business tier and then, they are displayed on the screen. The data layer of CS-ECIS consists of several interfaces. The cooperation between these interfaces ensures that the presentation layer operates on data which are validated by the application defined business rules. The descriptions of the most relevant interfaces of CS-ECIS are provided in the following sections. The simplified logical view of the related classes is shown in the figure 3.3.
_PIcatuon Bisiness Layer
-
Datibass
Figure 3.3: Class Diagram
::tnp_base::T iwC S_Collection::l,rp base::TflçCS ObiscI 4 DreckSurn 6 '0 6 ID Widen ii iecdog 6 Vekjen
1+ Count 14torn 4 Cb1ectLogc [4 Scope 6 SpawnFdrtabln 6 Veiden
6
4Cc * Ono( 6 ::oare 6i.tuCulecterr 6 1:ua!uFe- 7 c'oateFrnrr0.trrecLcqcr 6. _a.,ii9: 7D.tr.( 6 DeietePoa(I 6 De.rroy 6 ri 'S.' 14iu*ni( 14->rmi 6 6 inec,,cuI 6.. 14'.3 6 Set Marerl 6 6 inn, base tinn,C5 Velden +.t.<:iD..rr.(:Dcn.ldLr +!c(L!)!rk Vrkl'strrThc •idCodeV CI 7 ;tlcaer.tVeOt + PeIdCC lot inIntZrln:trrra 4 NIdLI.t:e It' 3 MrtFiae'o..s let 7 0€_IdOm 3 SldCorrtrrflber iv 91 [4 trJt.rr. orvelth Ft.., 6 etdM'ye 6-ccl 146 4 0€_ti*rt cIVo'd 6'1014k nN flet h oWetd. 4 Lt<oI- 3 ijr<rrOieetin( 4 Delete:i 4 3Vole 14,Otherrto( 14:wftt + PaiseVnlrterrE,rtrt 4 t-'u:seVeldenEorotrrttI 4 4Getraurn •c'J: •14klVerptcnftI 4B seC4rtecp +DaMGtjecS 1+[4 canceR..) 6 1.'*u.e•cli 6 1.€arø:3 6 :+n,_i.3 6 411*1 6 a'PrnpVatje1 6 CoD Vett 1+,laler( 4 I C0€CCtL oqt 3t. 6 let cecc '1(lnre?al,t 4 ...toerc'Statn 6 nt Voider 6 .La. 6 itetreletiF 7 SetF'topVflu,1F 6SetPMnt,tiI 7 ::Iwp b...::tfl,€S B...Obj.ct 14 Cooittnir 4 Ditntf [4 0Typ.intn
N
6 tçec1Ontchrqung 4 TaOb.ct 14 MdtiotthcatonlI 6 Cream 6 Dt1roi 6Enooti 6Erroofnt(I <en 144*iOtOt 6 Gettwmelntocou • (Mt Uaetlarr.1 14 o.trm4armro' 6H.n 6 0u+inme'4uce 6 R.rmc.Notcfl,n( 7 Ri:..<Ii-' 6MdRe 14toni ba.e::TItvCS Otrter.tloqt 1+ CacheControt 4 Catlectoncbsu 4 ID Veiden 14I ntetn.toqcRieRts 4 Iertjetonoqc 4 LoctrMode 4 logiccache 6 LocMd. 1+ Loq,cRethts 4 lbpctLogicFvents 4 l14nctNaam 14 Vetd.n 4 Mi 4 MiD mob tMdVektI.. tc 14 CoetiteCe rplo. 11:1 tn 4 Coeate' no.1.4tctnnt 6 u ratu I4. 6 C,:1 . 7-n- WDemteII 6 D.St,CascaSrgVekten( WDegmout 6 *t 6 .' Otup toot 3UtDF 6 .' Obecti.ore nteact 6 S.tAIt'laroele3
7.,
6 Ipew it 'drtab4I 4awn 4ttawncttetttnmt icier Ft ::Inbat:IC S_ Scop. 6 BoundCotjnt 14 etternalScopeBound 6 tntuntScop.V.kt.n 6 Scopettdt 6 ScopeLow 6 ScopeVetderr 3 AddScopeBoundnI •AddScopeValje(F 4CatAJScopes 14! 14— 1.<t',r j'3 re! —.1c:n 14 r_mateSt <DO: 6 Dnsrrr:,iI 6-. 6 ::In bne::IinpCS Veld •+ AlowEnpwahre 1+ CanBelMleted CanOØnn 1+CokrnnNann •Decirretett 14 D.fautV.tue • Ditty 't DiwJtutOme '+ DiwtWatue 4 Haslookup • Lenrfl 14 ttaanm I' Ob,ectoqc 14 Va. 14 vecTyp. 7 Adctookup(3 6M&toflcnonl.sttiiI 6 Createlt 6 CmcameF-cniDbp: tI_no:c: 4 DeteteNothcaonLrklI 6 Dentin_i 6 DoCatcadrqDetete33 6--. 14et-:-'tmni.et 6 Get C.,iurrr:Fiane: 6 (MIlrec:-tt:eniI 4'4)rlt3I 6 Get DrtpCIjtatnei — 6 (14tflisolauVatrici 6 Gel Hilt [4 c_ornt roVer 6 jetengrer 4<et lootijitl 4Gettoni 14 1'et'jrintVri4 of 7'et .'q.j 6 (letReadt4r'rt 6 Get 3cfNaan4I 6 jet Rciamjnirtj+r 61.et<'or 6 let&ldl,.p.n 6 HookMfletlI 7::.,. 6 s.t CohjrrnN.neII 4 Set DuwSsttamel.I 6 S.t_Hin* 6 Set tnteonVeht(3 6 Set LenØe(3 6 SMNan* 6 Set ture(3 6 Set VaetI 6 Set VeElype)i
16 3.2 Software Architecture
3.2.1
ObjectLogics
ObjectLogic is the base class of all logics in the business layer. ObjectLogic resides on the data layer and provides data-objects to the higher layers of the application.
Single data-objects are provided by means of an unique key (ID), and collections of data-objects by means of a scope and/or a filter. The ObjectLogic takes care of that the objects can be read, erased or written to the database. Before objects are written to the database, ObjectLogic validates these objects against the business rules defined in logics such as CSOKLogic, etc. Usually, an ObjectLogic maps objects to one table in the database. But it can also map objects to zero or several tables. The ObjectLogics know which fields the table contains and which fields are ID fields. The interface that exposes these functionalities is ICS.ObjectLogic.
It is shown in the following diagram.
r
:be_T LB::lCS_ObectLog.c F idt
'dCrject,
F4 CreateEnCoe:
CreateS
reF
rateVie'.M Deletet
WGei e1
WGSccpe t WGei_.i
ReIe(...) II aiEdab
Figure 3.4: ICSObjectLogic 3.2.2
Data Objects
Every data object in CS-ECIS has ICSObjed interface. A data object is usually mapped to a record in a database table. It contains some fields, but in contrast to ObjectLogics, these fields really contain the values of the fields of the record which represents the object. All data objects have an unique key (ID). The data objects are created, read, stored and removed by ObjectLogics. ICS.Object interface is shown in the following diagram.
-
17 3.2 Software Architecture
<ritere>'
ICS_Otect fi Cance(
± GetE c1ab(
iJGGetD0
±C ObettS
• G_ear
± Pol(.
Rete.
VaateI + Vd ti Ex
Figure 3.5: ICS_Objects 3.2.3
Data Fields
ICS..Velden is a simple interface. As shown in the following diagram, the interface contains nothing else but a collection of the type of ICS_Veld.
cc,itere>>
IC S_Velden I1 - =
J Get_
Figure 3.6: ICSVelden 3.2.4
Data Field
ICSVeId interface represents a field from a database table and it has a large number of properties. It contains the value of a field of a database table. The ICSVe1d can be readonly. In this case the value of the field cannot be changed.
Otherwise, if the value changes, the original value of the field is kept. It makes possible to be able to undo the change. The fields are lazy updateable. When a change occurs, the modified fields become marked as dirty and ObjectLogic generates an update query only for these dirty fields. This ensures that the data transferred to the database is minimal. It keeps network and database load low.
The following diagram depicts the ICSVe1d interface.
k
18 3.2 Software Architecture
ICS_Vdd
MNotitcahonLw,k(
DeleteNotiicatxrnLrk(
Get Oo'a'w
Get_ ec,ier, + Get_rtv + GetO isp4 imet + Get_t LW8vVak4e
+ Get_'rt(
LJ Get nternVdd Lenote GeL LOOJJp.
GeL Naarv Fi Get_Ongui&V ue
Get_Pcturei
Ei Ge:
I Set_VakeL
Figure 3.7: ICS...Veld 3.2.5 Collections
ICS.Collection is a collection of data objects. The collections can be obtained from the ObjectLogics, but also from an already existing collection. The collection is in the first place composed by means of criteria which are given by means ofscope and/or filter. If no criterion is given, the collection will contain all objects of the database table. There can be also empty collections. If a collection is created then the objects of the same type can be added to the collection, removed or updated.
To get a data object from the collection, the ID of the data object can be used.
If the ID is unknown, the collection can be iterated in order to find the desired object. One of the important properties of collections is that the number of data objects that the collection contains is unknown. It is not always clear how many objects the collection contains and it entirely depends on the implementation of the collection interface. The following diagram depicts the ICSCollection interface.
19
Figure 3.8: ICS_Collection
3.2 Software Architecture
The relation between ObjectLogic, Filed, Collection and Data Objects is shown in the figure 3.9.
3.2.6 Scope
Scope specifies the sorting criteria of data in collections. It is possible to define low and high bounds to which the certain fields of the objects must satisfy. The scope can be only created on indexed database fields. It can be created from Ob-
<<mtere>
IC S_Collection
--
De4ete( }
f bect
C_veien et_temi
;e:_scope
_SoperibL .-oc b- ei
• di
Figure 3.9: Relations between ICSVe1d, ICS.ObjectLogic, ICS..CoUection and ICS_Object
20 3.3 Key Drivers
jectLogic or from data object collections and it exposes the interface ICS..B cape.
The ICSScope interface is shown in the following diagram.
"itere'
ICS_Scope
±1 'ddScope8ound.
MdScopeie( )
• ClewAlScooes
Figure 3.10: ICSScope
3.2.7
Filter
A filter, also called Filterexpressie, has no sorting criteria. In contrast to scope, it gives much more freedom. Several filters on different fields can be combined with operators such as "larger than", "smaller than", "contains", etc. It is also possible to create sub-filters and combine these in a tree structure. This way, every desired selection from the database can be realized. The fields which are used in a filter do not need to have an index in the database. However, the filters are slower than scopes. Just like scopes, filters can be created from ObjectLogics or from collections. The exposed interface of filters is ICS...FilterExpression. The following diagram depicts the ICS..FilterExpression interface.
<<itere>,.
ICS_F dte,€ ,eson
t
/erfl
ten1 Set_EressonTy
Figure 3.11: ICS_Fi/tcrE.rpn.ssion
3.3 Key Drivers
The architecture of CS-ECIS is designed around many functional and quality re- quirements. All these requirements have been influencing the architecture during the design process. Some of these requirements or combination of them have higher priority than others. They are standing high on the top-priority list of the requirements. These requirements can be identified as architectural drivers that are key-drivers of the design. These key-drivers are:
Extendibility and Adaptability
The architecture is highly extendible. By implementing new modules and services, it can be easy extended with new functionalities. Because of the layered design and modularity of the system, it can be easy adapted to
21 3.3 Key Drivers
changes in requirements as required by evolving business needs and industry standards. For example, the hospital has deployed a new database back-end and ECIS has to be adapted in order to use it.
Modifiability
Most of the entities in the software communicate with each other through well defined interfaces (contracts). This interface based design ensures that when a modification occurs in an entity, it remains local and will not propagate behind its interface. Every other entity in the system will remain unaffected by the modification. This makes the whole architecture less sensitive to local modifications.
• Usability
In order to improve the usability for the majority of CS-ECIS customers, ChipSoft has the overall appearance of the application changed from the standard way. These changes have affected the menu structure, the toolbar User Interface, etc. and finally the overall window layout. While ChipSoft has own GUI style-guides for the target platform, they take care of familiarity of users to this interface and provide predictable and consistent GUI. More than 100 proprietary custom GUI design components ensure high flexibility, high robustness, high customizability, and high learnability of ECIS GUI concepts and features.
Achieving these requirements in CS-ECIS is supported by architectural pat- terns and architectural decisions. These are:
• Layered design
The architecture of ECIS is divided into three layers, stacked on top of each other. These layers are: presentation, business and data. Each layer focuses on one functional problem. Each layer uses the layer immediately below it and provides services to the layer above it. The layered design facilitates the reuse of system components, e.g. the services reuse the data-layer below of them. It also facilitates the modularity of the system by minimizing the coupling between layers, i.e. a layer knows little about other layers behind the exposed interface.
• Modularity
The entire functionality of ECIS is spitted up and assigned to different mod- ules. Each module is developed independently and design decisions are, taken in different modules, do not interference. Modularity of ECIS makes the complexity of the entire system manageable, enables parallel and inde- pendent development process and ensures easy integration.
• Reuse of components
One of primary goals of the designed architecture is making reuse of the parts of the system. The COM based architecture makes it possible to be able to reuse the different parts of the application. For example, the modules can reuse services that belong to other modules. The reuse gives huge advantage during development process. It decreases the development effort and results
in shorter development time.
