Realizzazione con tecnologia ICE di una applicazione distribuita per il monitoraggio remoto di risorse mediante dispositivi mobili

(1)

Realizzazione con tecnologia ICE di

una applicazione distribuita per il

monitoraggio remoto di risorse

mediante dispositivi mobili

FACOLTA

FACOLTA’’ DI INGEGNERIADI INGEGNERIA

CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA

CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA TESI DI LAUREA

Relatori: Prof. Marco Avvenuti Ing. Alessio Vecchio Ing. Stefano di Sandro

(2)

2

Alberto Della Santina 5 Marzo 2007

E di una applicazione distribuita

sorse mediante disposit

ivi mobili

Presentazione: Ulis s.r.l.

z

Servizi dedicati al mondo del mobile

Î

SMS, MMS, Instant Messaging

Î

Mobile marketing

Î

Piattaforme di content delivery

(3)

ivi mobili

Presentazione: stato dell’arte

z

Tecnologie esistenti in azienda frammentate:

Î

Middleware attuale e iterazioni server-to-server:

ICE

Bus software (Spread toolkit)

Web Services (HTTP-XML, Soap)

z

Scopo di questa tesi:

Î

aumentare know-how in ICE

Î

con riferimento ad ICE-Embedded

z

Valutazione risposta tecnologica in vista di:

Î

Unificare la piattaforma dei servizi in azienda

Î

Beneficiare di sistema ad oggetti distribuiti da mobile

Î

Convenienza come costo in fase di utilizzo

Uniformità Funzionalità Efficienza

(4)

4

ivi mobili

ICE

z

ICE as Internet Communication Engine

z

Una piattaforma middleware sviluppata dalla ZeroC Inc. con

licenza GPL, nel 2003 e periodicamente aggiornato a nuove

versioni

z

Tecnologia adottata da:

Î

Skype

Î

HP/DreamWorks

Î

Boeing/SAIC

(5)

ivi mobili

Requisiti funzionali del progetto

Progettazione di un’applicazione client-server, sfruttando

ICE-E per la parte del mobile.

Monitor di risorse:

Risorsa Trigger Start connec_tion Info #1 Info #2 Info #N Stop request

(6)

6

ivi mobili

Problemi da risolvere

z

Comunicazione verso il mobile per mantenere il

funzionamento asincrono

Î

PUSHING per attivazione del client

Î

Apertura socket su client (non so come indirizzare il

dispositivo se non con numero di telefono).

z

Soluzione:

Avvio dell’applicazione sul mobile con un sistema di trigger

basato sul PUSH via SMS

Comunicazione bidirezionale sullo stesso canale

È sempre il client che apre un socket verso il server

(7)

ivi mobili

Sviluppo del software - interfaccia

Slice

module Demo {

interface CallbackReceiver {

void callback(int num); };

interface CallbackSender {

void addClient(Ice::Identity ident, int res); void shutdown();

};

(8)

8

ivi mobili

Sviluppo del software - IceGrid

z

application.xml

</adapter>

<property name="Callback.Server.PublishedEndpoints" value="tcp -h dellas.dyndns.org - p15000"/> </server> </node> </application> </icegrid> z

config.grid

Ice.Default.Locator=DemoIceGrid/Locator:tcp -p 12000

(9)

ivi mobili

Meccanismo di PUSH

Come viene implementato:

z

SMS binario in cui viene specificata la porta nell’UDH

Destination port: 03E8 (hexadecimal) = 1000 Destination phone number

(10)

1 0

ivi mobili

Struttura finale applicazione

z

Client installato su telefono compatibile J2ME

z

Location Service

z

Server

z

DBMonitor

z

awakeSMS

(11)

ivi mobili

Applicazione finale

6

1

3

2

4

7

5

(12)

1 2

ivi mobili

(13)

ivi mobili

Analisi frames

z

Analisi frames

Una volta instaurata la connessione:

z FRAME Callback : 153 bytes z FRAME Reply (ACK) : 91 bytes

(14)

1 4

ivi mobili

Confronto con applicazione SOAP

Semplice applicazione SOAP

SOAP Request (Size – 702 bytes)

POST /soap/servlet/rpcrouter HTTP/1.1 User-Agent: kSOAP/1.0

SOAPAction: urn:xmethods-Temperature#getTemp Host: localhost:8080

Content-Type: text/xml; charset=utf-8 Content-Length: 510 <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encod ing/">

<getTemp xmlns="urn:xmethods-Temperature" id="o0" SOAP-ENC:root="1"> <zipcode xmlns="" xsi:type="xsd:string">27713</zipcode> </getTemp> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Weather/Temperature service (www.xmethods.com) Internet Internet HTTP/SOAP _HTTP/SOAP

SOAP Response (Size – 833 bytes) HTTP/1.0 200 OK

Date: Sun, 28 Apr 2002 01:33:01 GMT Status: 200

Content-Type: text/xml; charset=utf-8

Servlet-Engine: Lutris Enhydra Application Server/3.5.2 (JSP 1.1; Servlet 2.2; Java 1.3.0; Linux 2.4.7-10smp x86; java.vendor=IBM Corporation) Content-Length: 465 Set-Cookie: JSESSIONID=PLIQ2gjA8M2RJ-9PzKmRRua-;Path=/soap Server: Enhydra-MultiServer/3.5.2 <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getTempResponse xmlns:ns1="urn:xmethods-Temperature" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/"> <return xsi:type="xsd:float">63.0</return> </ns1:getTempResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Request: 702 bytes!!! Response: 833 bytes!!!

“A Performance Analysis of Web Services on Wireless PDAs”

Vinay Bansal and Angela Dalton Duke University Computer Science

(15)

ivi mobili

ICE e CORBA: due middleware a confronto

z

Che cosa è un middleware:

Î

Piattaforma orientata agli oggetti adatta all'uso in ambienti

eterogenei, sia per linguaggio che per sistema operativo

scelto

Î

Strumento per lo sviluppo di applicazioni distribuite

z

ICE e CORBA sono entrambi dei middleware

z

Vantaggi offerti da ICE

Î

Un’azienda (ZeroC) che fornisce continuamente supporto di

tipo free e commerciale

(16)

1 6

ivi mobili

ICE

Un nuovo approccio per il middleware

z

basato sulle potenzialità di Corba

z

superando le sue debolezze in quanto a:

Î

facilità d’uso

Î

scalabilità

Î

performance

(17)

ivi mobili

CORBA e DCOM

Principali limiti di CORBA e DCOM:

1.

DCOM è una soluzione proprietaria

2.

DCOM non può gestire grandi quantità di oggetti (> di

10^5)

3.

CORBA soffre di una scarsa interoperabilità tra le sue

differenti implementazioni vendor-specific

4.

CORBA soffre di mancanza di supporto ufficiale, se non

(18)

1 8

ivi mobili

ICE

z

Vantaggi di ICE

Î

No “Design by Committee”

Î

Slice

Î

C++ Mapping

Î

Ice Protocol

Î Security Î AMD & AMI

Î …

Michi Henning (ZeroC Chief Scientist)

z “Advanced CORBA Programming with C++”,

Addison Wesley Longman

z “The Rise and Fall of CORBA” - ACM

(19)

ivi mobili

Risultati positivi

z

Il trasferimento di know-how ICE esistente verso le implementazioni

embedded (ICE-E) si è rivelato vantaggioso in termini di curva di

apprendimento

z

I vincoli di eterogeneità tecnologica, imposta dagli ambienti operativi

esistenti sono stati sufficientemente superati grazie alla disponibilità

di implementazioni ICE in un sottoinsieme significativo di linguaggi e

piattaforme

(20)

2 0

ivi mobili

Risultati negativi

z

Rilevato qualche problema nella costruzione degli ambienti di

run-time a partire dalla distribuzione del sorgente, dovuto alle politiche di

rilascio di tipo "open source", volutamente anticipanti le versioni

stabili e supportate commercialmente.

z