4.1 Requirement Analysis
4.1.1 Functionality
The system will provide following services:
a. Automation of referral-consolidation.
b. Looking up service for personal vaccination records.
c. Looking up service for information about vaccines of medical institutions.
4.1.2 Operation
The system should be based on exist systems in hospitals, clinic and health bureaus.
Furthermore, the system needs Internet access when transferring data to the central database, and through Internet, legacy systems can cooperate and the users can get access to the central system.
4.1.3 Scalability and Capacity
The system should be large-scale to maintain vaccination records for everyone in the country and provide nationwide vaccination services.
4.1.4 Integration
We should use technologies that can integrate heterogeneous and autonomous systems to automate the interoperation between them to simplify the operation related to vaccination.
4.1.5 Security
A unique username and password are required to get access to the system, and for different group of account, they have different limits of authority. Furthermore, all data transfer need to be encrypted, and all communications have to be over a secured connection.
4.2 Related Works
In [5], they define reference architecture for distributed database management systems from system and schema viewpoints and show how various FDBS architectures can be developed and then define a methodology for developing one of the popular architectures of an FDBS.
We refer to the bottom-up development process proposed in [5] to design our OVS system.
It is mentioned in [6] that XML (Extensible Markup Language) has become the standard for data and document interchange between distributed systems. [6] focuses particularly on searches through legacy databases and on the changes you can make to your legacy systems to effectively exploit XML. SkyQuery [7] and Autonomous Data Integration Middleware (ADIM) [8] are two researches that use Web Services to design architecture for data distribution and integration in distributed heterogeneous database systems.
SkyQuery is a prototype of an evolving federation of geographically separate astronomy databases on the Internet. It has a web interface that allows astronomers to query spatial data stored in the databases participating in the federation. In particular, SkyQuery evaluates a probabilistic federated spatial join query called the cross match query. The SkyQuery architecture is based on the wrapper mediator architecture, which is common in federated database systems. It consists of three components (1) the Clients, (2) the Portal and (3) the SkyNodes. The Portal is the mediator and the SkyNodes contain the wrappers around databases. These three components coordinate with each other to perform two tasks: allowing databases to join the federation, and evaluating cross match queries. It adopts Web Services as the main communication and encapsulation interface both for the query processor and data sources wrappers.
In ADIM, the data schema integration is achieved by XML based global schema which is used by QPE (Query Execution Processor) and QMP (Query Mapping Processor) in the client and server components to translate and exchange metadata between data sources. The heterogeneity of access interfaces and protocols provided by each distributed paradigm is resolved by adopting Web Service as the communication model for uniformity of communication protocol in HTTP, message exchange in SOAP for service request and response, and service definition and description in WSDL. They also develop the SOAP
and have implemented a prototype of ADIM in the distributed environment. They are working on the two-phase-commit service and distributed scheduler to extend ADIM to allow database update operations.
About the security issues, it is mentioned in [9] that SSL [17], which operates between the HTTP and TCP network layers, is the most popular tool that provides a secure channel between a client and a Web server. Even though SSL is the de facto standard for transport layer security, its high overhead and poor scalability are two major problems in designing secure large-scale network servers. Therefore, improving the performance of SSL-enabled network servers is critical for designing scalable and high-performance data centers. [10] used the Netscape Enterprise Server and Apache Web server, and it was shown that the session reuse is critical for improving the performance of Web servers. And [9] examined the impact of SSL offering and SSL-session-aware distribution in cluster-based network servers and proposed a back-end forwarding scheme to achieve a good load balance among server nodes.
NICTIZ is the standardization authority for data exchange in healthcare for the Netherlands.
[11] discusses the issues, lessons learned and pitfalls in applying web services to a large, complex, real-life environment. The experience of Dr. Marc de Graauw in implementing Web Services for healthcare gives us guidelines when designing our system.
4.3 Web Services
The World Wide Web Consortium provides a definition to Web Services: "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL).
Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [12]"
4.3.1 Core Specifications of Web Services
Web services specifications compose together to provide interoperable protocols for Security, Reliable Messaging, and Transactions in loosely coupled systems. The specifications build on top of the core XML and SOAP standards.
4.3.1.1 XML
The Extensible Markup Language (XML) [13] is a general-purpose markup language. It is classified as an extensible language because it allows its users to define their own tags. Its primary purpose is to facilitate the sharing of data across different information systems, particularly via the Internet
4.3.1.2 SOAP
Simple Object Access Protocol (SOAP) [14] is a protocol for the exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols like HTTP and SMTP.
4.3.1.3 WSDL
WSDL [15] stands for Web Services Description Language. For our purposes, we can say that a WSDL file is an XML document that describes a set of SOAP messages and how the messages are exchanged. In other words, WSDL is to SOAP what IDL is to CORBA or COM.
Since WSDL is XML, it is readable and editable but in most cases, it is generated and consumed by software.
4.3.1.4 UDDI
The Universal Description, Discovery, and Integration (UDDI) [16] specification defines a SOAP-based Web service for locating WSDL-formatted protocol descriptions of Web services.
UDDI provides a foundation for developers and administrators to readily share information about internal Web services across the enterprise and public Web services across the Internet
4.3.2 Basic Operation
There are probably as many definitions of XML Web Service as there are companies building them, but almost all definitions have these things in common:
• XML Web Services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is SOAP.
• XML Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a WSDL document.
• XML Web services are registered so that potential users can find them easily. This is done with UDDI.
Figure 9 Standard XML Web Service
4.4 Secure Socket Layer
4.4.1 Overview
Secure Sockets Layer (SSL) is the most widely used protocol for implementing cryptography over a distributed communication protocol such as HTTP. This is achieved by using symmetric key cryptography for data encryption between the client and server, and asymmetric key cryptography (or public/private key cryptography) to authenticate the identities of communicating parties as well as to encrypt the shared encryption key that is used during establishing SSL session. This means that the data being sent is encrypted by one side – transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.
Another important aspect of the SSL protocol is Authentication. This means that during the initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a "Certificate", as proof the site is who and what it claims to be.
4.4.2 Securing Web Services with SSL
Since that the message exchanged in OVS will not go through intermediates except the central system, and all local systems and the central system are trustworthy, we only need to ensure the security between local system and central system to meet the secure requirement of OVS.
Moreover the communication between local and central is using SOAP over HTTP, hence HTTP over is used in OVS system.
To securing Web Services with SSL, we need to apply the required features of SSL on the web servers which the web services run on. First, we have to generate certificates and keystores, and then set a port which HTTPS should use. After that, we have to modify the WSDL description of the Web Service with the HTTPS URL, so that the service consumer can use the accurate protocol of HTTPS to communicate with the web services.