Università degli Studi di Roma La Sapienza. Facoltà di Ingegneria

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università degli Studi di Roma La Sapienza. Facoltà di Ingegneria"

Transcript

1 Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Tesi di Laurea In Ingegneria Informatica PROGETTO, REALIZZAZIONE, SPERIMENTAZIONE E TUNING DI UN ORCHESTRATORE DI WEB SERVICE Relatore: Ing. Massimo Mecella Laureando: Adriano Bernardini (matr ) Anno Accademico 2003/2004

2 1

3 Ai miei genitori. 2

4 3

5 SOMMARIO INTRODUZIONE INTEGRAZIONE E COOPERAZIONE DI SISTEMI INFORMATIVI DISTRIBUITI I SISTEMI INFORMATIVI COOPERATIVI APPLICAZIONE DEL PARADIGMA CIS SCENARIO METODOLOGICO E TECNOLOGICO DI SUPPORTO AL CIS LA PROPOSTA ATTUALE PER I CIS: I WEB SERVICE ARCHITETTURA PER WEB SERVICE Web Service Description Language Web Service Transition Language The Simple Object Access Protocol Universal Description, Discovery and Integration FRAMEWORK ATTUALI PER LA COMPOSIZIONE DI WEB SERVICE IL PARADIGMA DEL SERVICE-ORIENTED COMPUTING Inter-Organizational workflow EBXML (Electronic Business using extensible Markup Language) Piattaforme e modelli di orchestrazione Web Service Componentization Web Service discovery and automatic composition UN FRAMEWORK PER ORCHESTRAZIONE DI WEB SERVICE MODELLO CONCETTUALE DEI WEB SERVICE Diagrammi UML per la rappresentazione di Web Service MODELLO PER ORCHESTRAZIONE DINAMICA LINKING DI WEB SERVICE Compatibilità e sostituibilità di Web Service TECNOLOGIE PER ORCHESTRAZIONE DI WEB SERVICE DISEGNO DEL FRAMEWORK PARIDE STANDARD EMERGENTI PER IL DISEGNO DI PROCESSI DI BUSINESS COOPERATIVI I primi lavori Business Process Execution Language for Web Service Web Service Choreography Interface Business Process Management Language Considerazioni conclusive sulle tecnologie proposte STRUTTURA GENERALE DI UN BPEL PROCESS I partner di un BPEL Process

6 3.3.2 Message correlation Variabili nel BPEL Process Gestione delle eccezioni Attività primitive Le attività strutturate Conclusioni PROGETTO E SPERIMENTAZIONE DEL PROTOTIPO DI PARIDE PROGETTAZIONE DEI COMPONENTI DEL PROTOTIPO Architettura del prototipo PROPOSTA DI RIUSO: COLLAXA Architettura del Collaxa BPEL Server Realizzazione ed istanziamento di un processo BPEL con Collaxa DISEGNO DEL PROGETTO SPERIMENTAZIONE DELL ORCHESTRATORE DISTRIBUITO PARIDE Ambiente di esecuzione e obiettivi della fase di test Risultati e considerazioni INGEGNERIZZAZIONE ED AMPLIAMENTO DEL PROTOTIPO PARIDE COMPATIBILITÀ E SOSTITUZIONE DI WEB SERVICE Motore di compatibilità: riuso dell XMLEngine Realizzazione del modulo di compatibilità DELEGA DI RESPONSABILITÀ DI UN PROCESSO Ampliamento del Distributed Orchestration per la gestione della Delegation METODOLOGIA PER IL DISEGNO E LA REALIZZAZIONE DI UN PROCESSO COOPERATIVO DISTRIBUITO PROGETTAZIONE DEL PROCESSO COOPERATIVO DISTRIBUITO TRADUZIONE DELL ORCHESTRATION NET IN BPEL DEPLOY DEL PROCESSO COOPERATIVO DISTRIBUITO CONCLUSIONI BIBLIOGRAFIA

7 INTRODUZIONE Con l affermarsi di Internet e dell Information and Communication Technology (ICT), la comunicazione e lo scambio di risorse tra sistemi diversi che collaborano per il raggiungimento di un obiettivo comune, è un esigenza sempre più diffusa in particolare nel mondo dell ebusiness e dell egovernment. In questo contesto si inserisce PARIDE (Process based framework for Orchestration of dinamyc E-service), un approccio metodologico con lo scopo di definire e delineare un framework per l integrazione di sistemi distribuiti eterogenei basato sui processi/servizi. Gli elementi fondamentali che lo caratterizzano sono la definizione di un modello concettuale e di un architettura di riferimento per la cooperazione tra i vari sistemi in rete basata sull orchestrazione di WS, cioè coordinazione e composizione di servizi offerti on-line. Alla luce di quanto esposto la realizzazione e lo sviluppo di PARIDE si sono concretizzati inizialmente attraverso una precedente tesi [rif. 56] che ha raffinato il modello concettuale, e ha progettato ed iniziato la realizzazione di un un prototipo in grado di eseguire orchestrazione peer-topeer di WS. La capacità di comporre e coordinare Web Service in modo distribuito deriva dalle esigenze d implementare processi cooperativi direttamente applicabili al mondo dell ebusiness e dell egovernment; in particolare in quest ultimo scenario applicativo le procedure da automatizzare sono spesso frammentate in tanti workflow controllati da diverse organizzazioni per motivi burocratici o economico/amministrativi. Attualmente in commercio sono presenti diversi orchestrator capaci di interoperare con i WS, ma nessuno per ora supporta l esecuzione distribuita di un processo cooperativo. Per questo la precedente tesi si è proposta di contribuire allo sviluppo di PARIDE estendendo un orchestrator commerciale per risolvere i problemi di distribuzione delle responsabilità legati all egovernment. Eseguire cooperazione richiede al sistema di essere capace di riflettere sia i cambiamenti decisi per il miglioramento delle sue prestazioni, sia i cambiamenti delle pratiche organizzative, perciò le caratteristiche di dinamicità e flessibilità sono fondamentali in un contesto come quello a cui PARIDE intende rivolgersi. Quindi attraverso un analisi più approfondita dei processi che il sistema dovrebbe automatizzare, la presente tesi si è proposta di completare il il progetto e la realizzazione del precedente prototipo, al fine di produrre una versione ingegnerizzata capace di supportare una tipologia più ampia di processi distribuiti, e la sostituzione dinamica di servizi compatibili durante l esecuzione di un processo cooperativo che li veda coinvolti. L ingegnerizzazione si è concentrata 6

8 inizialmente sulla revisione del prototipo del precedente lavoro al fine di renderlo stabile, fino ad arrivare ad una fase di sperimentazione tesa a valutare il dazio da pagare in termini di prestazioni di un processo distribuito rispetto ad uno centralizzato. Dai risultati dei test ci si attendeva, infatti, un calo delle performance dovuto alla scelta di rendere dinamica la distribuzione di un processo cooperativo, ovvero la possibilità di scegliere a tempo di esecuzione l organizzazione destinataria del passaggio di responsabilità dell istanza in fase di processamento che, se da un lato permette al sistema di guadagnare in flessibilità, di contro, rende necessaria l aggiunta di nuovi livelli applicativi per la sua gestione che rallentano inevitabilmente l esecuzione del processo. Nel mondo dell ebusiness e dell egovernment spesso sono presenti processi in cui siano previsti dei sottoworkflow da eseguire in parallelo su organizzazioni differenti; il semplice pasaggio di responsabilità non poteva essere applicato a questo tipo di processi, quindi è stato necessario prevedere un ulteriore meccanismo di distribuzione, quale la delega di responsabilità, sia a livello metodologico che a livello progettuale, al fine di permettere, unitamente al passaggio di responsabilità, l automatizzazione di qualsiasi procedura organizzativa/amministrativa. Infine per realizzare un prototipo che sia completamente flessibile e dinamico, è stato necessario progettare ed implementare il Compatibility Manager, sulla base di un algoritmo presentato in [rif.57]; tale componente del prototipo è incaricato della sostituzione dinamica di Web Service compatibili durante l esecuzione di un processo; infatti in una realtà sempre aperta all ingresso di nuovi soggetti, la concorrenza che può nascere tra servizi alternativi che sono in grado di inserirsi in qualunque momento nell ambito di un processo cooperativo esistente, è il motore del miglioramento continuo. La tesi sarà suddivisa in sei capitoli strutturati nel seguente modo: Capitolo 1: dopo un introduzione al paradigma dei CIS e alle realtà di applicazione, viene presentata una panoramica delle metodologie e tecnologie proposte. In particolare ci sarà una approfondita descrizione della soluzione basata su Web Service, e si esploreranno le tecnologie e gli standard fondamentali che ci permettono di interoperare con loro. Capitolo 2: illustrerà il paradigma del Service-Oriented Computing per eseguire composizione di Web Service, e una panoramica dei principali sviluppi che la sua applicazione ha prodotto. Infine viene descritto il framework PARIDE come un primo approccio esaustivo ai problemi legati al SOC e viene fornita la descrizione del suo modello concettuale. 7

9 Capitolo 3: darà una descrizione dell architettura di PARIDE e una panoramica delle tecnologie e delle proposte più attuali e mature in ambito di coordinamento di Web Service, soffermandoci sullo standard BPEL4WS. Capitolo 4: si dedicherà alla riprogettazione del prototipo, con una sostanziale modifica del modulo di compatibilità ed un ampliamento di quello relativo all orchestrazione distribuita, sottolineando di volta in volta con cura le scelte progettuali e le motivazioni che le hanno determinate; in ultima istanza, presenteremo i risultati della sperimentazione dell applicazione attraverso un analisi delle prestazioni del sistema durante l esecuzione distribuita di un processo rispetto a quella centralizzata. Capitolo 5: descrive in dettaglio la realizzazione e implementazione dei moduli del prototipo riproggettati nel precedente capitolo. Capitolo 6: darà la definizione di metodi e tecniche per lo sviluppo di un processo cooperativo distribuito, nel quale siano anche previste ramificazioni di sottoprocessi paralleli. Saranno infine discusse le conclusioni tratte sulla base del lavoro proposto e verranno indicate le future direzioni di ricerca basate sull approfondimento e lo sviluppo delle tematiche presentate. 8

10 1 INTEGRAZIONE E COOPERAZIONE DI SISTEMI INFORMATIVI DISTRIBUITI In questo capitolo parleremo di ebusiness ed egovernment, applicazioni dell ICT (Information and Communication Technology) alle realtà rispettivamente del mercato economico e della pubblica amministrazione, come principali scenari applicativi del nostro progetto, e parleremo del CIS (Cooperative Information System) come l area di ricerca a cui la presente tesi intende dare il suo contributo. Per completezza si darà una breve descrizione delle proposte già presenti, delle idee positive a cui il progetto ha aderito, dei problemi che ha tentato di superare e quelli che tutt ora restano irrisolti. Infine identificando nei Web Service la proposta attuale ai problemi dei CIS, verrà fornita una panoramica delle tecnologie e degli standard più diffusi al momento. 1.1 I Sistemi Informativi Cooperativi La comunicazione e lo scambio di risorse tra sistemi diversi che collaborano per il raggiungimento di un obiettivo comune, è un esigenza diffusa in molti ambiti reali. Vari esempi si trovano nella produzione industriale, dove ogni azienda ha necessità di collaborare con altri partner offrendo e richiedendo servizi al fine di soddisfare le richieste del mercato, oppure nell ambito dell amministrazione pubblica e nel servizio sanitario nazionale in cui vari uffici o dipartimenti devono scambiarsi dati sui cittadini per poter offrire un servizio efficiente. Quanto descritto è lo scenario in cui s inserisce la definizione del Cooperative Information System (CIS), ossia, un Sistema Informativo su larga scala che interconnette sistemi di differenti organizzazioni autonome, geograficamente distribuite e che cooperano e condividono risorse (dati e/o servizi) per il raggiungimento di un obiettivo comune. I CIS pongono alla base della loro funzionalità la natura collaborativa delle interazioni tra i diversi sistemi informativi che li costituiscono. Tale collaborazione, presuppone la capacità di scambiare informazioni e di mettere le proprie funzionalità e risorse al servizio degli altri sistemi. Supportare la cooperazione richiede al sistema di essere capace di riflettere sia i cambiamenti decisi per il miglioramento delle sue prestazioni sia i continui cambiamenti delle pratiche organizzative. 9

11 Il problema diventa quindi quello di costruire sistemi informativi che siano in grado di condividere gli obiettivi dell ambiente comune in cui sono immersi (altri sistemi informativi, agenti umani, ) quando l ambiente stesso è soggetto a continue evoluzioni. Un sistema informativo cooperativo non è più considerabile come una semplice collezione di basi di dati, applicazioni e interfacce, ma piuttosto diventa un architettura che assicura la consistenza fra una varietà di sistemi automatizzati, gruppi di fruitori di servizi e obiettivi di organizzazioni che evolvono nel tempo. Sono quindi la dinamicità e la duttilità, insieme al presupposto d interoperabilità, le chiavi per il successo di un sistema informatico cooperativo. Riassumendo il concetto dei CIS è definito come segue [rif.1]: un vasto numero di sistemi cooperanti, distribuiti su una vasta e complessa rete di comunicazione, che lavorano insieme cooperativamente, richiedendo e condividendo informazioni, vincoli e obiettivi.. Per lo sviluppo di sistemi informativi cooperativi, si possono distinguere quattro principali approcci: Data Integration: integrazione dei dati e dei loro schemi concettuali, con particolare attenzione alla qualità dei dati trattati [rif.2] Sistemi e metodologie agent-based: studio di sistemi ad agenti intelligenti e mobili [rif.3] Business Process Coordination: sistemi per il coordinamento di processi [rif.4] Service-based System: sistemi service-oriented [rif.5] È su questi ultimi due aspetti che intendiamo concentrarci, definendo innanzi tutto i concetti fondamentali ad essi legati. Definiamo allora in modo rigoroso il Business Process come [rif.1]: un unità di lavoro persistente avviata da un evento di business come una richiesta di pagamento, una fattura o una richiesta di trasferimento fondi. Il processo è guidato da regole di business che avviano task e sotto-processi, la cui esecuzione è assegnata a risorse, rappresentate da organizzazioni in grado di giocare uno specifico ruolo all interno del processo stesso 10

12 Trattasi quindi dell astrazione di un complesso processo cooperativo che coinvolge più organizzazioni che cooperano tra loro offrendo dei servizi e condividendo risorse per il raggiungimento di un obiettivo comune. Inizialmente i processi informativi che sono stati oggetto di automazione, ovvero di sviluppo di procedure e applicazioni informatiche, erano ristretti a quelli relativi al flusso di attività all interno di una singola organizzazione tra i livelli operativo, organizzativo e gestionale, e prima ancora alla sequenza di attività relative al solo piano operativo. In seguito con un mercato sempre più esigente e con l avvento di Internet e delle tecnologie dell ICT, che hanno cancellato le difficoltà di comunicazione imposte dai limiti geografici, i processi di business si sono estesi alla cooperazione inter-organizzazioni. La tecnologia quindi può essere usata per (semi)automatizzare macro-processi che coinvolgono più imprese/organizzazioni attraverso applicazioni cooperative. Ma come può avvenire ciò senza richiedere cambiamenti radicali alle realtà organizzative interessate? Utilizzando i Service-based System [rif.5]: è un Sistema Informativo che si interfaccia alla realtà esterna offrendo dei servizi e nascondendo la loro realizzazione Il fatto di avere organizzazioni loosely-coupled, permette di apportare cambiamenti interni alla organizzazione mantenendo invariata l interfaccia dei servizi offerti, senza impattare quindi sul macroprocesso in cui sono coinvolte. Inoltre se a seguito di una fase di re-engeneering dei processi interni alla organizzazione sono disponibili nuovi servizi, il macro-processo può essere modificato ottenendo un globale e più sostanziale miglioramento, in sostanza un radicale re-engeneering del processo cooperativo[rif.6]. Quello che i CIS mettono a disposizione è un paradigma di cooperazione aperta basato sui processi/servizi, in cui nessun soggetto è indispensabile, perché tutti sono rilevanti in uguale misura, ma possono essere, in qualche modo, sostituiti. La capacità di gestire il cambiamento, di cui si è parlato, deve potersi intendere anche in questo senso, perché cambiare può voler dire non solo modificare i propri obiettivi, ma anche modificare i propri partner, sceglierne di migliori o semplicemente sceglierne di diversi se quelli abituali sono indisponibili, senza che questo vada ad inficiare in alcun modo il macro-processo in esecuzione. È questa realtà più dinamica a consentire il processo di miglioramento continuo, perché stimola la competizione e permette l ingresso nel 11

13 mercato di soggetti sempre nuovi, quando questi siano in grado di offrire un servizio migliore rispetto ad altri, a tutto vantaggio dei clienti di tali servizi. 1.2 Applicazione del paradigma CIS Il paradigma CIS trova la sua più naturale e concreta applicazione nelle realtà del mercato economico-commerciale e della pubblica amministrazione; in particolare la prima punta sull ebusiness, mentre la seconda sull egovernment, entrambe sempre più all attenzione dei ricercatori del CIS grazie allo sviluppo di tecnologie di rete ed al sempre maggiore affermarsi di Internet. L ebusiness è l applicazione dell ICT per condividere informazioni, erogare servizi fra diversi soggetti legati da relazioni commerciali ed economiche, per ottenere prodotti/servizi più complessi e con un maggior valore aggiunto, spinti da un mercato sempre più esigente e dall obiettivo finale della massimizzazione dei profitti. Anche le medio-piccole imprese hanno fatto proprie le soluzioni offerte dall ebusiness per poter sopravvivere in una realtà commerciale che le vedeva sfavorite rispetto ad organizzazioni di grandi dimensioni, per rispondere soprattutto a domande del mercato che da sole non avrebbero potuto soddisfare. Le modalità con cui le organizzazioni si sono interfacciate al mondo esterno nell ebusiness sono state le seguenti (vedi fig 1.1): Business to Consumer (B2C): in questa prima fase le organizzazioni hanno sfruttato il web per creare dei magazzini virtuali che facilitassero l acquisto di beni e di servizi da parte dei consumatori. Questo ha permesso un taglio netto dei costi di distribuzione nella Value Chain [rif.7], con conseguente abbassamento dei prezzi di vendita dei prodotti/servizi e l instaurazione di un rapporto diretto produttore/utente finale. Business to Business (B2B): in questa seconda fase le interazioni commerciali si sono estese alle imprese, per le quali si sono utilizzati applicazioni scritte ad hoc per l automazione di un particolare processo di business tra due organizzazioni, tipicamente quello di fornitura. e-community: il terzo passo è stato quello di estendere la collaborazione tra le imprese di una stessa area di business via Internet, per i principali processi di core business, 12

14 come quelli di gestione degli ordini, di gestione dei magazzini, i customer services fino anche alla realizzazione fisica dei prodotti. Trading Partner Network (TPN): nella quarta si è introdotta l interazione automatizzata (e trasparente) non solo tra partner di una stessa e-community, ma anche tra partner di aree di business differenti. Figura 1-1 Nella realtà italiana, una considerevole percentuale di tali soggetti è aggregata nella forma di distretti, cioè di raggruppamenti geografici d imprese (spesso piccole e medie) che contribuiscono, attraverso una catena di fornitura comune, alla produzione di beni/prodotti. Quindi per le aziende inserite all interno dei distretti, il paradigma dell ebusiness si concretizza nella possibilità di costruire un nuovo sistema di relazioni tra fornitori, produttori e canali di distribuzione, non più basato solamente sulla dislocazione geografica e/o su relazioni personali, ma sull utilizzo strategico dell ICT, permettendo in ultima analisi la creazione di Distretti Virtuali. L esperienza nel mondo delle imprese commerciali ha indotto a pensare di poter applicare il paradigma dei CIS al piano previsto per la pubblica amministrazione in cui tutti gli uffici amministrativi possano interagire come partner di una stessa e-community aperta anche ad altri soggetti non necessariamente istituzionali. Tale piano è indicato con il termine di egovernment cioè l utilizzo delle moderne tecnologie ICT nel processo di ammodernamento delle amministrazioni del Paese finalizzate al compimento delle seguenti categorie di azioni [rif.8,9]: 1. le azioni di informatizzazione dirette a migliorare l efficienza operativa interna delle singole amministrazioni; 13

15 2. le azioni dirette ad informatizzare l erogazione dei servizi ai cittadini e alle imprese che spesso implicano una integrazione tra i servizi di diverse amministrazioni; 3. le azioni dirette a consentire l accesso telematico degli utilizzatori finali ai servizi della pubblica amministrazione e alle sue informazioni. Il Piano di Azione per l egovernment, presentato nel corso dell anno 2000 [rif.8], si propone di coinvolgere tutte le amministrazioni sia centrali che locali e tutte le istituzioni del Paese: le regioni, le province, i comuni, le scuole, gli ospedali, le ASL, i centri per l impiego, le camere di commercio, ecc.; in pratica ogni ente od organizzazione cui siano delegate funzioni di servizio pubblico alle persone o alle imprese. L infrastruttura tecnologica abilitante tale piano è rappresentata dalla Rete Unitaria per la Pubblica Amministrazione (RUPA), uno tra i risultati più importanti conseguiti dall AIPA, l Autorità per l Informatica nella Pubblica Amministrazione [rif.10]. L'obiettivo della Rete Unitaria [rif.11,12] consiste nel garantire a qualunque utente della rete, purché autorizzato e in condizioni di sicurezza, di poter accedere ai dati e alle procedure residenti nei sistemi informativi automatizzati della propria e delle altre amministrazioni, indipendentemente dalle reti attraversate e dalle tecnologie adottate dai singoli sistemi informativi. Il piano propone una nuova visione dei servizi al cittadino, per cui questo ultimo: a) non dovrà più sapere come lo Stato è organizzato o a quale amministrazione si deve rivolgere per uno specifico servizio; b) potrà richiedere servizi esclusivamente in base alle proprie esigenze indipendentemente da ogni vincolo di competenza amministrativa, territoriale o di residenza; c) non dovrà più fornire all amministrazione cui si rivolge alcuna informazione che lo riguarda e che sia già in possesso di una altra amministrazione dello Stato. Per la realizzazione di questa visione è necessario che tutte le Amministrazioni e gli Enti siano dotati di sistemi informativi in grado di erogare servizi direttamente ai sistemi informatici delle altre amministrazioni. Inoltre è necessario che la rete globale sia una rete tra pari, senza gerarchie che riflettano sovrastrutture istituzionali od organizzative: deve essere solo il ruolo che l amministrazione gioca nel confronti del cittadino a fare la differenza tra i soggetti coinvolti nella cooperazione; sono le amministrazioni locali, in accordo con il decentramento amministrativo, ad assumere il ruolo di sportello per l accesso ai servizi pubblici, cioè di front-office, mentre le 14

16 amministrazioni centrali, ma anche alcune locali come ad esempio le anagrafi, svolgono un ruolo di back-office. Il ruolo delle amministrazioni di front-office è chiave nella realizzazione del modello che impone di pensare per processi : sono queste amministrazioni ad offrire al cittadino il servizio/processo, che si realizza attraverso la cooperazione e l integrazione dei servizi delle amministrazioni di back-office, ma che proprio per questo può essere rimodellato ed adattato sulle esigenze del cliente senza che questo se ne accorga e senza che il sistema complessivo debba mutare radicalmente. Dunque due mondi estremamente diversi, quello dell ebusiness e quello dell egovernment presentano in realtà problematiche simili che possono essere risolte con strumenti analoghi: ulteriori conferme arrivano dalle riflessioni che è necessario fare su un altro aspetto. Si è parlato prima del processo di miglioramento continuo di un macro-processo, perseguibile attraverso la scelta, momento per momento, del partner migliore per le proprie transazioni: questo tipo di scelta non sarebbe propriamente possibile nell ambito della Pubblica Amministrazione, dove i soggetti con i quali interagire sono definiti, in linea di principio, dalla legge. In realtà, il pensare l Amministrazione come una e-community e progettare la cooperazione incentrandola sui processi/servizi, offre a ciascuna organizzazione la possibilità di scegliere il servizio migliore, dal punto di vista di esigenze, ad esempio, di qualità o tempestività, purché sia compatibile con le specifiche del processo che l organizzazione esegue. Pensiamo ad esempio alla necessità di recuperare i dati anagrafici di un cittadino da parte di un ente: quest ultimo potrebbe scegliere, a tempo di esecuzione, come organizzazione servente quella che garantisca il miglior grado di aggiornamento possibile per quei dati; nulla vieta che una successiva richiesta sia soddisfatta da un altra organizzazione, e così via. Quindi il processo di miglioramento continuo può realizzarsi anche in questo scenario, perché i progressi nella qualità dei servizi offerti da ciascuna organizzazione, che deve ritenersi in concorrenza con le altre, si riflettono inevitabilmente sulla qualità del servizio complessivo offerto al cittadino/cliente. 15

17 1.3 Scenario Metodologico e Tecnologico di supporto al CIS Le soluzioni prima metodologiche e poi tecnologiche nello sviluppo dei sistemi informativi comunicativi (CIS) hanno puntato soprattutto a risolvere i problemi legati all integrazione a livello di logica applicativa dei prodotti/servizi offerti dalle organizzazioni, in quanto i problemi tecnologici legati all automazione dei processi di business riguardano la comunicazione e la collaborazione tra applicazioni distribuite. Non bisogna dimenticare, infatti, che proprio a livello di logica applicativa ciascuna organizzazione può rivendicare la propria unicità, può far valere le differenze che la portano a livelli di eccellenza, o meno, nel confronto con i propri concorrenti. Integrare sistemi diversi non vuol dire annullarne le individualità, e uniformare indiscriminatamente i processi di business di ognuno, ma sfruttarne appieno le potenzialità per il raggiungimento di un obiettivo comune, per la realizzazione, coordinata e collaborativa, delle best practices rispetto al mercato di interesse. Il primo approccio metodologico all integrazione venne sostanzialmente incentrato sulla comunicazione punto-punto tra le applicazioni interessate alla collaborazione e allo scambio di informazioni, secondo il paradigma client/server. Il limite di tale approccio divenne presto evidente nel momento in cui il numero dei soggetti coinvolti nel processo aumentava; infatti per ogni coppia di applicazioni che vogliano interagire tra loro risulta necessario programmare due interfacce distinte, quindi N applicazioni interagenti comportano l implementazione di N(N-1)/2 interfacce. Applicazione A A-C A-D A-B Applicazione B B-A B-D B-C C-A C-B Applicazione C C-D D-A D-C D-B Applicazione D Figura 1.2 Comunicazione punto-punto 16

18 È immediato concludere che la complessità del sistema risulta ben presto inaccettabile al crescere del numero di soggetti interessati a cooperare, in particolar modo dal punto di vista della manutenzione e della scalabilità. La soluzione che ha permesso di diminuire tale complessità architetturale prevede invece che le applicazioni interagiscano per mezzo di uno strato intermedio di software, detto middleware, che funge da vera e propria interfaccia universale per tutte le applicazioni che vi si appoggiano. La presenza di questa piattaforma comune di interazione consente di ridurre drasticamente il numero di interfacce che è necessario sviluppare e mantenere: per N applicazioni interagenti sono sufficienti solo 2N interfacce, e per ogni applicazione nuova o cambiata è sufficiente operare su solo 2 interfacce distinte. Applicazione A Interfaccia di A Applicazione B Interfaccia di B MIDDLEWARE Interfaccia di C Interfaccia di D Applicazione C Applicazione D Figura Middleware Negli anni l architettura di riferimento per l implementazione delle piattaforme di middleware è cambiata e si è notevolmente evoluta, venendo incontro alle sempre crescenti necessità di riduzione della complessità e ampliamento della gamma di servizi da mettere a disposizione. Le principali architetture middleware che si sono affermate sul mercato sono le seguenti: RPCs (Remote Procedure Calls): permette che l invio di una richiesta da un client verso un server avvenga come se fosse una normale chiamata locale di procedura. L interazione è bloccante, cioè il processo client viene sospeso finché la procedura chiamata non termina. MOM (Message Oriented Middleware): consente a client e server di comunicare scambiandosi generici messaggi attraverso code gestite in modo non bloccante. 17

19 Client e Server possono quindi essere operativi in tempi differenti, garantendo quindi un grande disaccoppiamento ed indipendenza. Distributed Objects: permette ad oggetti remoti di comunicare scambiandosi messaggi. I componenti essenziali di tale architettura sono un ORB (Object Request Broker) che trasferisce le richieste e le risposte tra oggetto client ed un oggetto server, ed un repository per la descrizione di tutti gli oggetti disponibili, utilizzato dall ORB per trovarli sulla rete. Database Oriented: permette l accesso a più basi di dati remote e gestite da differenti DBMS (DataBase Management System) relazionali in modo trasparente. Le piattaforme tecnologiche che sono state create per implementare middleware sono in parte o completamente la sintesi delle architetture esposte, in quanto ne riprendono le caratteristiche salienti. Tra quelle più note annoveriamo: JAVA RMI: permette l invocazione remota di metodo tra oggetti Java, i quali sono resi disponibili attraverso un RMI-Registry, secondo l architettura middleware delle Remote Procedure Call descritta sopra. CORBA: è una specifica che fornisce dei meccanismi che permettono l interoperabilità tra sistemi eterogenei mediante l astrazione di oggetto remoto; in particolare ciascun oggetto CORBA è definito dalla sua interfaccia espressa con il linguaggio dichiarativo IDL (Interface Definition Language) ed identificato da un riferimento IOR (Interoperable Object Reference) che mantiene le informazioni di indirizzamento dell oggetto; tali informazioni sono gestite dall Object Adapter e dall ORB (Object Request Broker)..NET: è un architettura che permette l interoperabilità tra componenti software, che possono essere implementati in qualsiasi linguaggio di programmazione e sono definiti attraverso le loro interfacce ciascuna delle quali ha un proprio identificativo (IID); tali interfacce sono generate in maniera dichiarativa attraverso il linguaggio MIDL (Middleware Interface Definition Language). J2EE: è un architettura di riferimento per lo sviluppo di applicazioni distribuite a tre livelli, definisce tecnologie ed API interoperabili tra loro (EJB, JSP, Servlet, 18

20 JDBC, JMS, JNDI, ), inoltre fornisce un ambiente di esecuzione omogeneo (Container) per le tecnologie incluse nello standard. I middleware sopra descritti sono comunque rimasti elusivi di fronte al problema principale nell industria che è quello di integrare applicazioni informatiche sviluppate in maniera indipendente: infatti, ciò ha portato ad una situazione in cui esiste un altissimo numero di tecnologie eterogenee reperibili sul mercato, e per questo difficilmente interoperabili. La più grande debolezza delle soluzioni offerte dalle architetture CORBA e DCOM per esempio, è che sono pensate per far comunicare sistemi distribuiti secondo il paradigma Server to Server, e quindi poco flessibili e duttili verso una struttura di tipo Client/Server. Inoltre prese singolarmente, CORBA è una specifica, di cui quindi ne esistono diverse implementazioni non omogenee tra loro, e per di più, è legata ad un linguaggio di programmazione Java (come J2EE), mentre DCOM, anche se potenzialmente multi-piattaforma, in realtà è un middleware proprietario. Come già previsto dal Pennine Group nel 1999 [rif.13] lo sviluppo di nuove architetture basate sulla programmazione ad oggetti ed a componenti non avrebbe garantito progressi e quindi non avrebbe avuto futuro nel campo del software. Piuttosto essi vedevano un futuro in cui gli sviluppatori avrebbero cambiato radicalmente modo di concepire il software: non più software come semplice applicazione, ma piuttosto come un servizio che implementa alcune funzionalità richieste dall utente. Tale visione è un contributo vitale al corrente modo di pensare circa lo sviluppo e la distribuzione del software che si sta affermando in parte con l iniziativa dei Web Service. 1.4 La proposta attuale per i CIS: i Web Service I Web Service sono applicazioni distribuite che espongono le funzionalità di servizi di business attraverso protocolli standard su Internet. Essi sono potenzialmente il mezzo per risolvere le problematiche inerenti i sistemi informativi cooperativi; infatti posseggono le caratteristiche di interoperabilità, incapsulamento ed accessibilità. L interoperabilità dei WS è soprattutto garantita dalle scelte sulla modalità di comunicazione: infatti i WS dialogano attraverso messaggi testuali basati sullo standard XML (extensible Markup Language), e viaggiano in Internet sfruttando i protocolli standard di rete (HTTP, MIME, ecc ). 19

21 Per questo i WS possono essere visti come un salto rivoluzionario e non semplicemente un evoluzione nell ambito dei CIS. Di recente molte tecnologie sono state classificate come Web Service Based, anche se in realtà non lo sono totalmente (CORBA, CGI Scripting, J2EE). La differenza sostanziale sta nella standardizzazione, ovvero nella scelta di usare XML in quanto linguaggio non proprietario e accettato ormai dalle maggiori firme tecnologiche. Infatti XML vanta le proprietà di essere: Indipendente dalla visualizzazione. Strutturato: sia sintassi che semantica possono essere validate. Può rappresentare dati: i dati provenienti da più sorgenti possono essere mappati su documenti XML che ne descrivono lo schema, ed integrati in un unico documento (ad es. integrazione di basi di dati). Versatile: componenti basati su tecnologie diverse possono comunicare tra loro attraverso protocolli ASCII descritti in XML. I WS sono quindi l implementazione di funzionalità offerte all esterno tramite Internet che permettono agli utenti di accedere a dei servizi e raggiungere degli obiettivi senza conoscere come in realtà tutto ciò è realizzato a livello di logica applicativa. Per questo i WS godono delle seguenti caratteristiche, tra cui alcune già citate [rif.14] : XML based: XML è usato per rappresentare i dati, per supportare le tecnologie per il trasporto dei dati stessi, ed è utilizzato anche per descrivere come poter interoperare con i WS. Loosely coupled (debolmente accoppiato): un utente di un WS non è vincolato direttamente ad esso; l interfaccia del WS può cambiare nel tempo senza compromettere l abilità del cliente di interagire con esso. Al contrario un sistema strettamente accoppiato implica che le logiche del client e del server siano molto vincolate l una all altra, cioè i cambiamenti effettuati ad una interfaccia implicano che anche l altra sia aggiornata. Quindi adottare un architettura loosely coupled genera sistemi software più flessibili e versatili, e permette di integrare tra loro sistemi differenti in maniera agevole. Incapsulamento: l implementazione della logica applicativa dei WS è trasparente all esterno. Ciò permette ai WS di poter essere implementati in qualsiasi linguaggio 20

22 di programmazione e di essere anche indipendenti dalla piattaforma di utilizzo in quanto sono esposti all esterno attraverso interfacce che permettono l accesso al servizio. Interazione bloccante o non bloccante: la sincronizzazione è riferita alla tipologia di binding del client all esecuzione del servizio. In una invocazione sincrona il client si blocca ed aspetta che il WS completi la sua elaborazione prima di continuare. Nelle operazioni asincrone al contrario, il cliente può invocare un servizio e procedere poi all esecuzione di altre operazioni ed, in un momento successivo, richiedere il risultato prodotto dall invocazione di quel servizio. La capacità di essere sia bloccante che non bloccante è una delle chiavi alla base dei sistemi loosely-coupled. Supporta RPC: i WS permettono ai client di invocare procedure, funzioni e metodi su oggetti remoti usando protocolli XML-based. Le procedure remote indicano i parametri di input e di output che i WS devono supportare. Lo sviluppo a componenti attraverso l Enterprise JavaBeans e.net Components ha visto crescere il suo ruolo all interno delle architetture software; entrambe le tecnologie sono distribuite ed accessibili attraverso meccanismi di RPC. Un WS supporta RPC attraverso i servizi che fornisce in modo equivalente ai tradizionali componenti o traducendo le invocazioni entranti in invocazioni ai componenti EJB o.net. In questo modo integra tecnologie all avanguardia e largamente diffuse, favorendo così il suo successo a la sua utilizzazione. Supporta scambio di documenti: la scelta dei WS di usare messaggi formattati in XML per comunicare ha favorito la capacità di scambiare non solo semplici dati, ma anche complessi documenti; infatti XML permette di rappresentare sia informazioni semplici quali, indirizzi, nomi, ecc.., sia libri interi e documenti complessi. Questa possibilità dei WS di supportare lo scambio trasparente di documenti gli conferisce una marcia in più nel mondo dell integrazione di business. Per tutti questi motivi i WS possono essere definiti come i componenti più flessibili e pervasivi del momento, oltre che per la loro facilità di componibilità e riusabilità. 21

23 1.5 Architettura per Web Service Con il termine Service Oriented Architecture (SOA) si definisce un architettura per la gestione delle interazioni con i WS, rappresentata in fig. 1-2, all'interno della quale si possono distinguere tre attori fondamentali: Description Language Publish() Service Provider Describe() Orchestration Language Service Broker Repository Unpublish(), Update() Discovery and Publish Language Discover() Invoke() Service Requestor Figura SOA Service Provider: entità che realizza e mette a disposizione un servizio. Tramite l'operazione di publish il servizio viene 'pubblicizzato ', cioè le caratteristiche del servizio realizzato vengono memorizzate all'interno di un repository accessibile pubblicamente. Il Service Provider rimane quindi in attesa che un cliente (utente umano e/o applicazione) richieda tale servizio. Service Broker: si occupa della gestione del repository, permettendo ai clienti di ricercare un servizio (operazione di discover) sulla base delle caratteristiche con il quale è stato definito e memorizzato (operazione di publish) dal provider. Permette inoltre la modifica (operazione di update) e anche l eliminazione di servizi già pubblicati (operazione di unpublish). Il Service Broker può seguire politiche di controllo degli accessi sulle interrogazioni, tali da limitare la visibilità sui servizi inseriti. Service Requestor: è il potenziale cliente in cerca di un servizio. A tale scopo, tramite la primitiva di discover, interagisce con il Service Broker per ottenere informazioni sul servizio più adatto ai propri obiettivi. Una volta individuato, si collega al Service 22

24 Provider corrispondente (operazione di invoke) ed inizia a fruire del particolare servizio (operazione di use). Oltre a queste figure fondamentali un framework di web service prevede un set di operazioni base da cui non è possibile prescindere: describe, publish, unpublish, discover and invoke. Il ruolo del Service Broker rappresenta il fulcro fondamentale dell intera architettura e nello stesso tempo la componente più innovativa. La sfida principale raccolta dai Web Service è quella di consentire l evoluzione dei sistemi object-oriented verso sistemi di servizi, in cui sia possibile la cosiddetta just-in-time integration, ossia la capacità per le applicazioni di interagire tra loro scoprendosi a tempo di esecuzione. Nel disegnare un processo cooperativo, dovrebbe essere necessario, dunque, preoccuparsi solamente di individuare quali sono le funzionalità di cui il processo ha bisogno per essere eseguito. A tempo di esecuzione, il gestore del processo cooperativo, assumendo il ruolo di Service Requestor, ricercherà presso il Service Broker il Web Service più opportuno per l implementazione del task corrente individuando anche le modalità di interazione con esso. Effettuato il passo di find, in base ad esempio a criteri di qualità, si passerà alla fase di bind con il conseguente scambio di dati, che consentirà l avanzamento nell esecuzione del processo cooperativo. Ogni scambio di messaggi avviene utilizzando un mezzo di trasporto comune. Essendo quindi l infrastruttura di comunicazione un parametro dell'architettura, si definisce [rif.16] una architettura per Web-Service, un istanza di una SOA in cui il mezzo di comunicazione considerato è il Web Nel recente periodo, diverse sono state le iniziative da parte dei maggiori vendor IT per realizzare un infrastruttura tecnologica per la creazione, invocazione e composizione di Web Service. Le soluzioni proposte possono ricondursi a quattro classi di obiettivi che rispecchiano altrettante problematiche legate alla tecnologia dei Web Service: linguaggi di descrizione delle interfacce e del comportamento di un servizio rivolto sia a chi realizza e pubblica il servizio, sia a chi lo cerca e utilizza; componenti per la memorizzazione e il reperimento di servizi, interrogabili secondo diversi criteri; 23

25 linguaggi di specifica per la conversazione tra diversi servizi; linguaggi di specifica di composizione di servizi a valore aggiunto partendo da servizi di base. Gli obiettivi fondamentali nelle scelte delle tecnologie impiegate per sviluppare WS sono l interoperabilità, la neutralità e la leggerezza. Ciò che assicura queste proprietà e che le distingue dalle precedenti tecnologie sono l impiego di XML e del protocollo SOAP (Service Oriented Access Protocol), che col tempo sono diventate anche degli standard, in quanto universalmente accettate da tutte le principali compagnie di software del mondo come mezzi più idonei per raggiungere gli obiettivi prefissati dal CIS. Di conseguenza le scelte tecnologiche sono ricadute su XML per strutturare i messaggi, SOAP per trasferirli, WSDL per descrivere le interfacce statiche dei WS, WSTL per descriverne il comportamento, cioè le possibili conversazioni in cui un WS è coinvolto, ed infine UDDI per rendere i WS accessibili attraverso un repository. 24

26 1.5.1 Web Service Description Language WSDL è un linguaggio nato per descrivere le capacità di un Web Service, in particolare la sua interfaccia statica : proposto da IBM e Microsoft, mette insieme le caratteristiche migliori del Network Accessibile Services Language (NASSL) di IBM e il SOAP Contract Language di Microsoft. Il linguaggio è basato su XML ed è parte integrante del progetto UDDI che descriveremo in seguito. Le specifiche della versione 1.1 [rif.17] lo definiscono come grammatica XML per descrivere servizi di rete come collezione di endpoint capaci di scambiarsi messaggi :come ci si aspetterebbe da uno standard, WSDL separa la definizione astratta degli endpoint dalla loro implementazione completa. La definizione di un servizio si basa su sette elementi fondamentali: Types, un contenitore per la definizione dei tipi di dato, in particolare dati strutturati (riconducibili all interno dei diagrammi UML ai <<type>> class); Message, la definizione astratta e tipizzata dei dati scambiati come parametri dei messaggi stessi (riconducibili all interno dei diagrammi UML ai <<message>> class); Operation, una descrizione astratta delle azioni supportate dal servizio; in particolare è possibile descrivere quattro tipologie di operazioni identificabili dal tipo di messaggi scambiati; Port Type, un insieme astratto di operazioni supportato da uno o più endpoint; Binding, il protocollo concreto utilizzato per la comunicazione e la specifica del formato dei dati di un particolare Port Type; Port, un singolo endpoint definito dalla combinazione di un indirizzo di rete (URL location) e di un indirizzo per il binding (SOAP binding); Service, una collezione di endpoint correlati tra loro, cioè interoperanti (riconducibili all interno dei diagrammi UML ai <<Web Service>> class). 25

27 Tale linguaggio permette di distinguere tre tipi di operazioni [rif.6] : Request/Response: operazione con messaggio in input ed output (entrambi non vuoti) e la cui richiesta è bloccante per il client; One Way: operazione con il solo messaggio in input (non vuoto) e quindi non bloccante per il client Notification: operazione con il solo messaggio in output (non vuoto), quale risultato di un operazione interna del WS. Message e Port Type forniscono una definizione astratta dei dati che saranno scambiati dal servizio e delle operazioni che questo è in grado di compiere su di essi: da questo punto di vista WSDL può essere assimilato all Interface Definition Language (IDL) di CORBA, anch esso specializzato nella descrizione delle interfacce di programmazione. Proprio questa analogia, o forse qualcosa di più dal momento che esistono tool automatici per la traduzione dell IDL in WSDL, ci permette di riflettere sul fatto che WSDL manca di costrutti in grado di descrivere gli aspetti comportamentali di un Web Service, ossia ad esempio in che ordine accetta gli input e in quale fornisce gli output, aspetto che lo stesso IDL non risolve. Perché la descrizione di un Web Service sia più completa, è necessario che venga descritta la sequenza corretta dello scambio di messaggi che il servizio è in grado di supportare. Per tale proposito si rimanda al paragrafo successivo in cui si darà la specifica del WSTL, linguaggio con il quale si propone di colmare tale lacuna. Riportiamo nella figura 1-3 la struttura di WSDL. 26

28 HTTP Client Mail Client Service Port (HTTP) Port (SMTP) Port Type HTTP SMTP 1..N 1 Binding Operation 1..2 Message SOAP SMTP 1 Type HTTP. Figura Struttura WSDL Web Service Transition Language Come detto in precedenza il WSDL non risolve il problema di come un servizio possa specificare, per lo scambio di messaggi, le sequenze valide supportate; il WSTL si propone come una soluzione per la definizione, attraverso schemi XML, di tali sequenze valide (con il termine sequenza valida si intende una sequenza di transizioni, testualmente legal, legali, basate sullo scambio di messaggi). WSTL [rif.6] è il merge di altri due linguaggi proposti per raggiungere lo stesso scopo. Il primo, WSCL, adotta un approccio ereditato dal dominio degli agenti software, basato su protocolli di interazione intesi come conversation policy, e lo estende scegliendo XML come contenuto dei messaggi scambiati. Ogni specifica WSCL descrive un solo tipo di conversation dal punto di vista di uno solo dei due partecipanti, cioè quello per cui si sta scrivendo la specifica, dal momento che il 27

29 punto di vista dell altro interlocutore è facilmente deducibile. Il secondo, XLANG, si propone di individuare e specificare, anch esso tramite un documento XML, le caratteristiche di conversazione di un servizio. In realtà il proposito di XLANG era maggiormente ambizioso e puntava a gettare le basi per poter definire aspetti di composizione di servizi trascurati da WSCL. In seguito alla comparsa di altri linguaggi per la definizione di conversation tra Web Service, WSTL ha mire meno ambiziose ed in realtà è un semplice linguaggio capace di rappresentare la macchina a stati finiti associata ad un WS, in un linguaggio XML-based. In dettaglio un documento WSTL è costituito dai seguenti elementi: Una conversation: equivalente dell ASF( automa a stati finiti), consiste in una o più transizioni; Transition: rappresenta una singola transizione caratterizzata da uno stato sorgente, uno stato destinazione; ogni singola transizione può essere di tipo sincrono o asincrono; Input message: rappresentano il messaggio in input ad una transizione; Output message: rappresentano il messaggio in output ad una transizione. Gli stati sono codificati con dei numeri ed i messaggi sono quelli definiti all interno del documento WSDL relativo al WS d interesse (vedi esempio seguente). Prendendo l esempio il servizio del Rilascio del Porto d Armi, nelle seguenti tabelle si intende dare la sua definizione attraverso l interfaccia statica in WSDL e il comportamento in WSTL. <?xml version="1.0"?> -<definitions name="rilascioportoarmi" targetnamespace="http://agenzia21.org/rilascioportoarmi" xmlns:tns="http://agenzia21.org/rilascioportoarmi" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns="http://schemas.xmlsoap.org/wsdl/"> - <types> - <schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace="http://agenzia21.org/rilascioportoarmi" xmlns="http://www.w3.org/2001/xmlschema"> - <element name="rilascioportoarmirequest"> - <complextype> - <sequence> <element name="nome" type="string" /> <element name="cognome" type="string" /> <element name="datadinascita_ggmmaaaa" type="int" /> <element name="codicefiscale" type="string" /> <element name="statocivile" type="string" /> <element name="figli" type="boolean" /> - <element name="residenza"> - <complextype> - <sequence> <element name="via" type="string" /> <element name="numerocivico" type="int" /> 28

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3,

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, Emergency healthcare process automation using workflow technology and web services M. Poulymenopoulou, F. Malamateniou, G. Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, 195 207 Processo

Dettagli

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

e.toscana Compliance visione d insieme

e.toscana Compliance visione d insieme Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Composizione e Coreografia di Web Services

Composizione e Coreografia di Web Services Composizione e Coreografia di Web Services Giusy Di Lorenzo Composizione Lo scopo della composizione è quello di comporre servizi esistenti al fine di definire un nuovo servizio a valore aggiunto Richiesta

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE Flavia Marzano marzano@cibernet.it 10/05/2004 ARPA Club Forum PA 2004 Contenuti Cenni normativi Sistema di gestione documentale:

Dettagli

Architettura del sistema

Architettura del sistema 18/06/15 I N D I C E 1 INTRODUZIONE... 2 2 DEFINIZIONE DEGLI OBIETTIVI... 2 3 PROGETTO DI MASSIMA... 3 3.1 REQUISITI DELLA SOLUZIONE... 4 4 LA SOLUZIONE... 4 4.1 IL NUCLEO CENTRALE... 5 4.1.1 La gestione

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

SERVER E VIRTUALIZZAZIONE. Windows Server 2012. Guida alle edizioni

SERVER E VIRTUALIZZAZIONE. Windows Server 2012. Guida alle edizioni SERVER E VIRTUALIZZAZIONE Windows Server 2012 Guida alle edizioni 1 1 Informazioni sul copyright 2012 Microsoft Corporation. Tutti i diritti sono riservati. Il presente documento viene fornito così come

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

OGGETTO DELLA FORNITURA...4

OGGETTO DELLA FORNITURA...4 Gara d appalto per la fornitura di licenze software e servizi per la realizzazione del progetto di Identity and Access Management in Cassa Depositi e Prestiti S.p.A. CAPITOLATO TECNICO Indice 1 GENERALITÀ...3

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Sfrutta appieno le potenzialità del software SAP in modo semplice e rapido

Sfrutta appieno le potenzialità del software SAP in modo semplice e rapido Starter Package è una versione realizzata su misura per le Piccole Imprese, che garantisce una implementazione più rapida ad un prezzo ridotto. E ideale per le aziende che cercano ben più di un semplice

Dettagli

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Basi di dati Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Anno Accademico 2008/2009 Introduzione alle basi di dati Docente Pierangelo

Dettagli

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo tesi di laurea Analisi e sperimentazione della piattaforma Web Service Notification Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo Correlatore Ing. Christiancarmine Esposito candidato

Dettagli

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE

SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE SPCOOP E I PROGETTI DI COOPERAZIONE INTERREGIONALE EGIDIO PICERNO POTENZA 9 LUGLIO 2010 Interoperabiltà è la capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Introduzione ad Architetture Orientate ai Servizi e Web Service

Introduzione ad Architetture Orientate ai Servizi e Web Service Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ad Architetture Orientate ai Servizi e Web Service Corso di Sistemi Distribuiti Stefano Iannucci iannucci@ing.uniroma2.it Anno

Dettagli

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org 1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org Prefazione. Da Hello World a Hello World Wide Web. Hello World è la prima frase stampata a video dal primo programma di esempio scritto

Dettagli

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet

Una piattaforma per la negoziazione di servizi business to business attraverso la rete Internet Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale della Logistica e della Produzione Una piattaforma per la negoziazione di servizi business to

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Tecnologie e sistemi per la business integration. www.xdatanet.com

Tecnologie e sistemi per la business integration. www.xdatanet.com Tecnologie e sistemi per la business integration www.xdatanet.com X DataNet, X costruttori DataNet, costruttori di softwaredi software Costruiamo Costruiamo soluzioni tecnologiche soluzioni tecnologiche

Dettagli

Sme.UP Web Application

Sme.UP Web Application Sme.UP Web Application Web Application Web.UP Una interfaccia web per i vostri dati gestionali Il modulo applicativo Web.UP fornisce al progettista di siti Internet una serie di potenti strumenti per l'integrazione

Dettagli

IL SISTEMA INFORMATIVO AZIENDALE

IL SISTEMA INFORMATIVO AZIENDALE IL SISTEMA INFORMATIVO AZIENDALE CL. 5ATP - A.S. 2006/2007 L azienda e i suoi elementi PERSONE AZIENDA BENI ECONOMICI ORGANIZZAZIONE L azienda è un insieme di beni organizzati e coordinati dall imprenditore

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

CONSIP SpA. Gara per l affidamento dei servizi di supporto strategico a Consip nel campo dell Information & Communication Technology (ICT)

CONSIP SpA. Gara per l affidamento dei servizi di supporto strategico a Consip nel campo dell Information & Communication Technology (ICT) CONSIP S.p.A. Allegato 6 Capitolato tecnico Capitolato relativo all affidamento dei servizi di supporto strategico a Consip nel campo dell Information & Communication Technology (ICT) Capitolato Tecnico

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

Modelli per la descrizione di protocolli

Modelli per la descrizione di protocolli POLITECNICO DI MILANO Corso di Laurea in Ingegneria Informatica Modelli per la descrizione di protocolli asincroni basati sull usouso di servizi Web Relatore: Prof. Stefano Ceri Correlatori: Ing. Marco

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration COSA FACCIAMO SEMPLIFICHIAMO I PROCESSI DEL TUO BUSINESS CON SOLUZIONI SU MISURA EXTRA supporta lo sviluppo

Dettagli

ATS CONSORZIO ARTEMIDE. Consorzio Artemide. Finanzia e Servizi Srl. Innovazione Qualità e Servizi S.r.l. Servizi Avanzati Srl. DAISY-NET S. c. a r. l.

ATS CONSORZIO ARTEMIDE. Consorzio Artemide. Finanzia e Servizi Srl. Innovazione Qualità e Servizi S.r.l. Servizi Avanzati Srl. DAISY-NET S. c. a r. l. Aiuti a Sostegno dei Partenariati Regionali per l Innovazione Modello 14B Presentazione conclusiva del progetto Allegato n. 21 Consorzio Artemide Finanzia e Servizi Srl Innovazione Qualità e Servizi S.r.l.

Dettagli

Alfresco ECM. La gestione documentale on-demand

Alfresco ECM. La gestione documentale on-demand Alfresco ECM La gestione documentale on-demand Alfresco 3.2 La gestione documentale on-demand Oltre alla possibilità di agire sull efficienza dei processi, riducendone i costi, è oggi universalmente conosciuto

Dettagli

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE Università degli studi di Ferrara Facoltà di scienze MM.FF.NN. Corso di Laurea Specialistica in Informatica Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Dettagli

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Servizi di connessione Prodotti a supporto del business Per sfruttare al meglio una rete di ricarica per veicoli

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Il progetto di ricerca Ellade

Il progetto di ricerca Ellade Il progetto di ricerca Ellade Ellade ELectronic Live ADaptive Learning Gruppo di lavoro Università degli Studi della Calabria, Dipartimento di Matematica Università degli Studi Mediterranea di Reggio Calabria,

Dettagli

Relazione introduttiva Febbraio 2006

Relazione introduttiva Febbraio 2006 Amministrazione Provincia di Rieti Febbraio 2006 1 Progetto Sistema Informativo Territoriale Amministrazione Provincia di Rieti Premessa L aumento della qualità e quantità dei servizi che ha caratterizzato

Dettagli

Costruire il futuro il valore delle scelte tecnologiche

Costruire il futuro il valore delle scelte tecnologiche Franco Lenzi Costruire il futuro il valore delle scelte tecnologiche 7 e 8 maggio 2010, Venezia, Hotel Hilton Molino Stucky 1 La strategia tecnologica Gli obiettivi espressi dalle scelta di strategia e

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

NUMERO 1O l esperienza migliora il business

NUMERO 1O l esperienza migliora il business NUMERO 1O l esperienza migliora il business Dal 1986 al vostro fianco NUMERO 1O, a più di vent anni dalla sua nascita, rappresenta il polo di riferimento nell esperienza informatica legata al business.

Dettagli

Processi e Miglioramento IL PROCESSO AZIENDALE IL PROCESSO AZIENDALE 07/10/2013

Processi e Miglioramento IL PROCESSO AZIENDALE IL PROCESSO AZIENDALE 07/10/2013 Processi e Miglioramento - La gestione per processi - Il miglioramento - Le metodologie del miglioramento 1 L organizzazione di successo è quella vicina al cliente, cioè in grado di fornire elevate prestazioni

Dettagli

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Allegato n. 2 al Capitolato speciale d appalto. ENTE PUBBLICO ECONOMICO STRUMENTALE DELLA REGIONE CALABRIA POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Procedura aperta sotto

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

METODO_ SOLUZIONI_ DIALOGO_ MANAGEMENT_ COMPETENZE_ ASSISTENZA_ SERVIZI_ MISSION_ TECNOLOGIE_

METODO_ SOLUZIONI_ DIALOGO_ MANAGEMENT_ COMPETENZE_ ASSISTENZA_ SERVIZI_ MISSION_ TECNOLOGIE_ DIALOGO_ METODO_ SOLUZIONI_ COMPETENZE_ MISSION_ TECNOLOGIE_ ASSISTENZA_ MANAGEMENT_ SERVIZI_ GEWIN La combinazione di professionalità e know how tecnologico per la gestione aziendale_ L efficienza per

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO DIREZIONE EMITTENTE CONTROLLO DELLE COPIE Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile

Dettagli

Sviluppo di applicazioni Internet: l'uso integrato di XML e Java

Sviluppo di applicazioni Internet: l'uso integrato di XML e Java UNIVERSITA' DEGLI STUDI DI MODENA E REGGIO EMILIA Facoltà di Ingegneria - Sede di Modena Corso di Laurea in Ingegneria Infomatica Sviluppo di applicazioni Internet: l'uso integrato di XML e Java realizzata

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Sistemi informativi secondo prospettive combinate

Sistemi informativi secondo prospettive combinate Sistemi informativi secondo prospettive combinate direz acquisti direz produz. direz vendite processo acquisti produzione vendite INTEGRAZIONE TRA PROSPETTIVE Informazioni e attività sono condivise da

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA. Sviluppare e Integrare. basate sul CLOUD ROMA 11-12 NOVEMBRE 2010 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

LA TECHNOLOGY TRANSFER PRESENTA. Sviluppare e Integrare. basate sul CLOUD ROMA 11-12 NOVEMBRE 2010 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA GERHARD BAYER Sviluppare e Integrare le Business Applications basate sul CLOUD ROMA 11-12 NOVEMBRE 2010 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket.

Portale regionale della Salute. Servizi di prenotazione prestazione e pagamento ticket. Portale regionale della Salute Servizi di prenotazione prestazione e pagamento ticket. Specifiche di integrazione dei servizi di cooperazione applicativa e dei web services. Versione 1.10 16 Ottobre 2013

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi

PRIVACY E SICUREZZA http://www.moviwork.com http://www.moviwork.com de.co dsign&communication di Celestina Sgroi PRIVACY E SICUREZZA LA PRIVACY DI QUESTO SITO In questa pagina si descrivono le modalità di gestione del sito in riferimento al trattamento dei dati personali degli utenti che lo consultano. Tale politica

Dettagli

Gestione centralizzata delle anagrafiche in uno scenario complesso con SAP NetWeaver MDM

Gestione centralizzata delle anagrafiche in uno scenario complesso con SAP NetWeaver MDM UNIVERSITÀ DI PISA Facoltà di Ingegneria Laurea Specialistica in Ingegneria Informatica per la Gestione d Azienda Tesi di Laurea Sessione di Laurea del 18/12/2008 Gestione centralizzata delle anagrafiche

Dettagli

Processi BPEL. Obiettivi

Processi BPEL. Obiettivi Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Processi BPEL Corso di Sistemi Distribuiti Stefano Iannucci Anno accademico 2009/10 Email: sd@chmod.it Obiettivi Esercitazione pratica su:

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari

Il DBMS Oracle. Express Edition. Donatella Gubiani e Angelo Montanari Gubiani & Montanari Il DBMS Oracle 1 Il DBMS Oracle Express Edition Donatella Gubiani e Angelo Montanari Il DBMS Oracle Il DBMS Oracle Oracle 10g Express Edition Il DBMS Oracle (nelle sue versioni più

Dettagli

Da 40 anni al servizio delle aziende

Da 40 anni al servizio delle aziende Da 40 anni al servizio delle aziende GESCA GROUP Gesca azienda nata nel 1972 come centro servizi specializzato nell elaborazione della contabilità aziendale fa della lunga esperienza nel campo dell Information

Dettagli

Protocolli e architetture per WIS

Protocolli e architetture per WIS Protocolli e architetture per WIS Web Information Systems (WIS) Un Web Information System (WIS) usa le tecnologie Web per permettere la fruizione di informazioni e servizi Le architetture moderne dei WIS

Dettagli

"L impatto dell Information Technology sulle aziende del terziario in Italia"

L impatto dell Information Technology sulle aziende del terziario in Italia "L impatto dell Information Technology sulle aziende del terziario in Italia" Sintesi per la stampa Ricerca promossa da Microsoft e Confcommercio realizzata da NetConsulting Roma, 18 Marzo 2003 Aziende

Dettagli

PROFILO AZIENDALE NET STUDIO 2015

PROFILO AZIENDALE NET STUDIO 2015 PROFILO AZIENDALE NET STUDIO 2015 NET STUDIO 2015 Net Studio è un azienda che ha sede in Toscana ma opera in tutta Italia e in altri paesi Europei per realizzare attività di Consulenza, System Integration,

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Prodotto Release <1.0> Gennaio 2015

Prodotto <ADAM DASHBOARD> Release <1.0> Gennaio 2015 Prodotto Release Gennaio 2015 Il presente documento e' stato redatto in coerenza con il Codice Etico e i Principi Generali del Controllo Interno Sommario Sommario... 2 Introduzione...

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I

REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I GENNAIO 2005 eprocurement pubblico Clausola di esclusione della responsabilità Commissione europea Original document

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea AUTENTICAZIONE PER APPLICAZIONI WEB Relatore

Dettagli

Programmazione Web. Introduzione

Programmazione Web. Introduzione Programmazione Web Introduzione 2014/2015 1 Un'applicazione Web (I) 2014/2015 Programmazione Web - Introduzione 2 Un'applicazione Web (II) 2014/2015 Programmazione Web - Introduzione 3 Un'applicazione

Dettagli