Sistemi Informatici s.r.l.

Pag. 1/20 _______________________________________________________________________________________________________________________

Medisoft Sistemi Informatici s.r.l. - v.G.Ciaralli,84 - 00156 Roma - tel.06-4103654 fax 06-41220693 - P.I. 08441191007 - REA:1094428

Recapiti on-line: Commerciale 348-3822534 Sig. F. Magnolia – Assistenza Tecnica e Software 348-3332752 Sig. G. La Terza http://www.medisoft.it - e-mail: info@medisoft.it

The EUPHORIC Web Application and Data Recovery System

Creation of a web service for data “consumption”

Activities implemented in GRANT AGREEMENT ISS/CE NR.2003134 THE EC-CONTRACT

Working group: Giampaolo LA TERZA, Emanuele MALLIA.

Release 3.1 – Dec 2008

Pag. 2/20

Medisoft

OVERVIEW

1. INTRODUCTION ....................................................................................................... 3

2. OBJECTIVE ................................................................................................................ 4

3. THEORY OF USED STANDARDS ........................................................................... 5

3.1 SOAP.................................................................................................................................... 5

3.2 WDSL .................................................................................................................................. 5

3.3 WEB SERVICE.................................................................................................................... 5

3.4 WHY WEB SERVICE CHOICE.......................................................................................... 6

4. THE EUPHORIC WEB APPLICATION OPERATION ........................................ 7

4.1 WEBSERVICE CORE – CODE EXAMPLE ...................................................................... 8

4.2 PROS AND CONS ............................................................................................................ 15

5. ALTERNATIVES EVALUATION ......................................................................... 16

6. FUTURE USE AND ENVIRONMENTS FOR UTILIZING APPLICATION.... 17

7. AVAILABLE WEB SERVICES .............................................................................. 18

8. SUMMARY ................................................................................................................. 19

9. BIBLIOGRAPHY ...................................................................................................... 20

Pag. 3/20

Medisoft

1. INTRODUCTION

In this document will be presented the study of a system enable to make available data from database to remote

sites for different proposes that may be consulting, creation of a local cache, but also update data to the source.

That data stream may be in both direction server-client and client-server.

To realize the core architecture will be used known and standardized protocols.

In the bibliography section will be reported the official references where take information about individual

formats or protocols listed in the document.

The choice of using standard formats has three benefits:

the first one is related to usability of the final product. This means that the "service given" may be used in any

operating system, application platform or program language used to develop client components.

Second is flexibility. The architecture can be easily implemented for new requirements, readapted for future

uses or new projects.

Third is the project economic impact. Standardized formats and protocols, used on widespread operating

systems and platforms can dramatically decreases the overall cost of the project.

Nowadays several organizations and consortiums such as ISO (International Organization for Standardization),

W3C (World Wide Web Consortium), IETF (Internet Engineering Task Force) approve and publish universally

recognized standards that are binding for whoever decides to carry on a project implying an exchange of

information with external entities

Pag. 4/20

Medisoft

2. OBJECTIVE

The objective of this study was to create a system that enable every client to collect their data, process them and

send them to a server with repository function without applying a double conversion format.

Primarily we wanted to prevent that the export operations - sending - and import data required the assistance of

the operator.

The repository server provides the single entry point for accessing global data from the project, both for the

analyzers that use them for processing statistics and server involved in the presentation on the web.

The "data collection" from clients participating in the project is arbitrary: predetermined (scheduled) or each

time that a client enters or editing a new record.

Pag. 5/20

Medisoft

3. THEORY OF USED STANDARDS

3.1 SOAP

SOAP (originally Simple Object Access Protocol lately also Service Oriented Architecture Protocol) is a

protocol for exchanging XML-based messages over computer networks, normally using HTTP. SOAP forms

the foundation layer of the Web services stack, providing a basic messaging framework that more abstract

layers can build on. The original acronym was dropped with Version 1.2 of the standard, which became a

W3C Recommendation on June 24, 2003, as it was considered to be misleading.

There are several different types of messaging patterns in SOAP, but by far the most common is the Remote

Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another

node (the server), and the server immediately sends a response message to the client. SOAP is the successor

of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from

elsewhere, probably from WDDX.

Originally designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998 with backing

from Microsoft (where Atkinson and Al-Ghosein worked at the time) as an object-access protocol, the

SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web

Consortium

3.2 WSDL

WSDL is an XML format for describing network services as a set of endpoints operating on messages

containing either document-oriented or procedure-oriented information. The operations and messages are

described abstractly, and then bound to a concrete network protocol and message format to define an

endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to

allow description of endpoints and their messages regardless of what message formats or network protocols

are used to communicate, however, the only bindings described in this document describe how to use WSDL

in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

3.3 WEB SERVICE

The main reason for the creation and the purpose of the Web Service is the “uncouplement” that the standard

interface facing by the Web Service makes possible between the customer system and the Web Service

itself: modifications these applications can be put into effect in a “transparent” way through the interface

between the two systems; such flexibility allows the creation of complex software systems constituted by

disengaged elements and it concurs to a strongly reuse of code and of the applications already developed.

The service Web has moreover had consents as, like transport’ s protocol, they can use HTTP “over” TCP

on port 80; such port is, normally, one of the few (or the only one) left “opened” by the firewall systems to

the traffic of income and of the outflow from the outside towards the business systems and that because on

such port the HTTP web browser traffic passes: this allows uses the Web Service use without modifications

on the configurations of emergency of the company (an aspect that if on one side it is positive, on the other

hand it raises worries concerning the emergency).

One of the reasons that has favoured the adoption and proliferation of the Web Service is the lack, before the

development of SOAP, of the interfaces easily functional for the use of the practical qualities distributed in

net: EDI, RPC, and other types of API (Application Programming Interface) were and they still remain less

known and by easily use that the architecture of the Web Service.

Pag. 6/20

Medisoft

3.4 WHY WEB SERVICE CHOICE

The reason for using Web Service is the "uncoupling" that the standard interface exposed from the Web

Service makes possible between the system user and the same Web Service: modifications to one or to the

other applications can be executed in a "transparent" way by interfacing the two systems.

In this way automatic procedures for the recovery of data are executed without involving an operator in the

procedure of data extrapolation and data sending.

Pag. 7/20

Medisoft

4. THE EUPHORIC WEB APPLICATION OPERATION

1. The Web Application EUPHORIC (WAE) request data to the Web Service of the Country participant.

2. The Web Service interrogated transmit to the WAE the data combines to you in format XML.

3. The WAE process the data and saves them in its database

This procedure of data acquisition will come carried out in automatic way.

When web user visit Euphoric web site, WAE will show data on it database.

Pag. 8/20

Medisoft

4.1 WEBSERVICE CORE – CODE EXAMPLE

Below is shown a portion of the code for the implementation of the WebService.

The first part provides information about the number of records in the database.

From reading the code shows that you can apply a search criteria (filter) seeking.

Creating a WebService

vb.net Imports System.Web.Services

Imports System.Web.Services.Protocols

Imports System.ComponentModel

<System.Web.Services.WebService(Description:="EUPHORIC Web Application Data Recovery

System - WebService", Name:="EUPHORIC-WS", Namespace:="http://www.euphoric-

project.eu/")> _

<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _

<ToolboxItem(False)> _

Public Class EuphoricData

Inherits System.Web.Services.WebService

<WebMethod(Description:="Returns the number of records in the database",

EnableSession:=False)> _

Public Function GetRecordNumber(ByVal Filter As String) As System.Xml.XmlElement

Dim recordNumber As Integer = 0

'--- Code for access to database ---------------------

.

.

.

.

.

. the result of procedure retrieve

. the recordNumber variable

'-----------------------------------------------------

'------------------------------------------------

'--- Code that returns the result ---

'--- XML standard format (W3C) ---

'------------------------------------------------

Dim xmlDoc As New System.Xml.XmlDocument

Dim xmlRoot As System.Xml.XmlElement

xmlRoot = xmlDoc.CreateElement("EDataRoot")

Dim xmlRecordNumber As System.Xml.XmlElement 'Number of records

'--- Number of records ---

xmlRecordNumber = xmlDoc.CreateElement("RecordNumber")

xmlRecordNumber.InnerText = recordNumber.ToString

xmlRoot.AppendChild(xmlRecordNumber)

Return xmlRoot

End Function

End Class

Fig. 1

Pag. 9/20

Medisoft

c# using System;

using System.Data;

using System.Web;

using System.Collections;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.ComponentModel;

namespace Euphoric

{

[WebService(Description="EUPHORIC Web Application Data Recovery System -

WebService", Name="EUPHORIC-WS", Namespace = "http://www.euphoric-project.eu/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[ToolboxItem(false)]

public class EuphoricData : System.Web.Services.WebService

{

[WebMethod]

public System.Xml.XmlElement GetRecordNumber(string Filter)

{

int recordNumber = 0;

//--- Code for access to database ---------------------

.

.

.

.

.

. the result of procedure retrieve

. the recordNumber variable

//-----------------------------------------------------

//------------------------------------------------

//--- Code that returns the result ---

//--- XML standard format (W3C) ---

//------------------------------------------------

System.Xml.XmlDocument xmlDoc = new System.Xml.XmlDocument();

System.Xml.XmlElement xmlRoot = default(System.Xml.XmlElement);

xmlRoot = xmlDoc.CreateElement("EDataRoot");

System.Xml.XmlElement xmlRecordNumber = default(System.Xml.XmlElement);

//Number of records

//--- Number of records ---

xmlRecordNumber = xmlDoc.CreateElement("RecordNumber");

xmlRecordNumber.InnerText = Convert.ToString(recordNumber);

xmlRoot.AppendChild(xmlRecordNumber);

return xmlRoot;

}

}

} Fig. 2

Pag. 10/20

Medisoft

Being test before deploy (debug mode)

Fig. 3

Fig. 4

Pag. 11/20

Medisoft

First method – GetRecordNumber - returns the result in XML format

Fig. 5

We have not implemented an XML Schema for defining elements and attributes of XML document, otherwise

you could create the schema like the one below.

<?xml version="1.0"?>

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

targetNamespace="http://www.euphoric-project.eu/"

xmlns="http://www.euphoric-project.eu/" elementFormDefault="qualified">

<xs:element name="EDataRoot">

<xs:complexType>

<xs:all>

<xs:element name="RecordNumber" type="xs:integer" />

</xs:all>

</xs:complexType>

</xs:element>

</xs:schema>

Fig. 6

Pag. 12/20

Medisoft

Fig. 7

Fig. 8

Pag. 13/20

Medisoft

Second method – GetRecordData - returns the result in XML format

Fig. 9

Issue

Fig. 10

Pag. 14/20

Medisoft

After deploy on the internet website you can "consume" the WebService from anywhere on the network by any

client in several languages (vb c#, vb.net, c++, perl, php, asp classic, java, javascript …) operating in various

platforms (Windows, Unix, Linux, MacOS, Sun Solaris …).

Here are the screenshots that show the use of a simple client for take the data,

how contact the WebService and the result of its "consumption" seen in a datagrid (Fig. 13).

Fig. 11

http://euphoric.medisoft.it/EUPHORIC-WS/euphoric.asmx - this is the URL for the service

Fig. 12

euphoric.disco – this is the discovery document for the service

Pag. 15/20

Medisoft

Fig. 13

The test client program can be downloaded from here:

http://euphoric.medisoft.it/EUPHORIC-WS/Client/EuphoricDataClient.exe

4.2 PROS AND CONS

pro

Extremely flexible and adaptable to different types of data or database.

It can be enjoyed from different programming languages (c#, vb.net, c++, perl, php, asp classic, java,

javascript …) on different operating systems (Windows, Unix, Linux, MacOS, Sun Solaris …)

Working with a disconnected database, using standard protocols HTTP as application protocol and TCP

as internet transport, does not require any special firewall configurations.

This means that clients and servers may be located in any geographic network

Can be made secure by using HTTPS protocol.

cons With a large amount of data can be slow and becomes strongly dependent on the network bandwidth.

It is not meant to replace a classic direct connection to a database, is done to provide data in a platform

independent data exchange (cross platform).

Pag. 16/20

Medisoft

5. EVALUATION OF ALTERNATIVES

There are other ways to provide data in a client-server infrastructure and each of them certainly valid and

reliable.

Now look at some of these at glance:

Direct access to a database

Direct access to a database is a good system to be implemented in an intranet. Not recommended in a

distributed internet / intranet or internet reality.

This because the data must reside in a protected area with a perimetral firewall that requires a

configuration that does not allow a malicious access to data and database structure.

Then create an uncoupling layer between the code for data manipulation and the data, results complex

and expensive.

Furthermore, the transmission of credentials for access to the database should not be in clear-mode, not

all database engines implements a system for encrypted access.

Although the WAE core uses direct access to the database, this happens in an intranet area, where the

data is protected by a firewall, and packets of data between the WebService core and the database are not

transported through an external network (internet) .

What is "exposed" is the results of the database enquiry, which use the HTTP protocol as transport and,

as mentioned above, can be made safe implementing HTTPS protocol.

Data transmission multicast mode

The multicast technology allows you to send data packets to multiple recipients simultaneously.

Although is very efficient, it requires hardware that can support multicast protocol or clients configured

to accept the IP multicast transmission.

In a clients distribution like intranet / internet, even routers must support forwarding of multicast

datagrams.

This means that the total cost of project is greater and the multicast is a valid choice in real-time

applications (for example IPTV or applications that use the RTP protocols).

Some components are common to both technologies, just seen that the system of publishing data via Web

Service.

For example, the transport-level datalink (LAN, Routers, Ethernet Switches) is always required and from it

depends much of the system of data transmission.

Same goes for the hardware data-store.

Pag. 17/20

Medisoft

6. FUTURE USE AND ENVIRONMENTS FOR UTILIZING APPLICATION

The flexibility of the architecture has been highlighted in the introduction, being one of the main aspects

supporting the choice of such a solution

Till now we have talked about the system able to "expose data”, thinking about data like text or numbers.

It is possible to think of other types of data that represent an object, such as an image.

Using the format MIME Base64 encoding is possible to transmit images that will recode by the client to be

used in their native format.

Analyzing the operation of a RPC protocols where the client sends to the server a command that will initiate a

remote procedure (localized on the server), this opens up new windows where we can already imagine the use.

Applications that use RPC over http already exist.

Regarding the use of different databases, changes to be made are those concerning the access code to the

database, the selection and formatting code of data to be made available.

In a modular system at multiple levels such operations have a relatively low impact on the amount of changes.

We can then say that the areas of use are not only those listed in the examples provided in this document, but

such an architecture can be imagined adapted to environments currently managed with classic client-server

procedures often requiring firewall configurations or creation of VPN as a solution to access data in a new way,

rethought and replanned, considering recent technologies

Pag. 18/20

Medisoft

7. AVAILABLE WEB SERVICES

Nowadays there are several public access WebServices: Google for example has made available its search

engine allowing the search through an HTTP GET and returns the result in xml format through a Web Service.

This technique has been implemented through the interface "Search" in various web sites of CNESPS -

Epidemiology, Surveillance and Health Promotion ( www.iss.it/esps/ ) creating core customizable by the

webmaster.

Through some experimental activity, we have involved two projects already present in ISS - National Institute

of Health ( www.iss.it ) which implement the architecture of the WAE:

The Project CUORE and Epimail project- mailing list of Epicentro.

Epimail Epimail is a system that allows users who wish to receive a weekly email

containing the information published on Epicentro ( www.epicentro.iss.it ).

Registration is on the web site of the Epicentro CNESPS - ISS.

Initially the system was designed to make the operation of the distribution of email from the site to the

SMTP server of ISS.

The increase of subscribers and the exchange of mail server have done that the system loses its initial

efficiency.

It was then thought to creating a stand alone system multithreading to increase efficiency and control of

transmission, but at the same time disconnected from the data.

The problem of the recovery of subscribers in real time has been exceeded due to the use of a specially

created WebService to allow access to data in "disconnected" mode.

Il Progetto CUORE Inside the project CUORE is present a business analysis of data sent by the doctors involved in the

project that is performed by an outside company from ISS.

This society takes data relating to doctors involved in the project and then through a Web Service

properly implemented in order to align data in their database with data in line in the website of project

CUORE.

Pag. 19/20

Medisoft

8. SUMMARY

The architecture presented in this document has been applied to a portion of pilot data (see 4.1 - Fig.13)

currently published at the address listed at the end of point 4.19

The examples in paragraph 7 – AVIABLE WEB SERVER - Epimail and Project CUORE,

represent two other practical aspects of WebService with the same architecture of WAE, but today they are no

longer at an experimental stage. Their implementation has become final and the two WebServices are currently

working.

Possibility of transmitting data are very interesting, but the WebServices are not limited to this.

It is possible to transmit documents of various kinds.

For example, using the protocol for the MIME encoding, you can send PDF files, Word or images.

Till now has been described a unidirectional data stream (from server to client), but in reality the stream may be

bidirectional (server-client, client-server) and then is not only receive data we can also store data in the remote

system.

Data are serialized in Xml format so it is possible apply a XML format (xsd) for validate data before make it

definitive or available.

Again, the implementation of safety standards does not provide solutions particularly complicated due to the

HTTP protocol used for transport.

Pag. 20/20

Medisoft

9. BIBLIOGRPHY

WebServices, XML, XML Schema, XSD W3C – World Wide Web Consortium – www.w3.org

Protocols SMTP: RFC 821, RFC 822

MIME:RFC 2045 – 2049

IETF - Internet Engineering Task Force - www.ietf.org

To know more about networking protocols see:

Internetworking with TCP/IP – Douglas E. Comer

This report was produced by a contractor for Health & Consumer Protection Directorate General and represents the views of thecontractor or author. These views have not been adopted or in any way approved by the Commission and do not necessarilyrepresent the view of the Commission or the Directorate General for Health and Consumer Protection. The EuropeanCommission does not guarantee the accuracy of the data included in this study, nor does it accept responsibility for any use madethereof.