Code Architects S.r.l. SWOP Semantic Web-service Oriented Platform B2SO201

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Code Architects S.r.l. SWOP Semantic Web-service Oriented Platform B2SO201"

Transcript

1 UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO IL LAVORO E L INNOVAZIONE Modello M14 Allegati RTA POR PUGLIA Asse I Linea 1.1 Azione Bando Aiuti agli Investimenti in Ricerca per le PMI BENEFICIARIO Code Architects S.r.l. TITOLO DEL PROGETTO SWOP Semantic Web-service Oriented Platform CODICE DEL PROGETTO B2SO201 RAPPORTO TECNICO ATTIVITA : A Analizzare le modalità di evoluzione dell'architettura della piattaforma D Analisi dei requisiti architetturali e delle specifiche tecniche delle nuove componenti di sistema della piattaforma.

2 Indice dei contenuti 1. SERVICE ORIENTED ARCHITECTURE Introduzione alle architetture SOA Service Oriented Analysis and Design Service Oriented Archictecture Maturity Model Roadmap Service Oriented Integration Enterprise Service Bus CODE ARCHITECTS SOLUTION ENTERPRISE PLATFORM SEMANTIC WEB SERVICE ORIENTED PLATFORM Sviluppo di Semantic Web Services Discovery e Selection di Semantic Web Services Componenti del Framework SWOP Architettura del Framework SWOP Pag. 2 di 55

3 1. Service Oriented Architecture 1.1 Introduzione alle architetture SOA Un architettura SOA (Service Oriented Architecture) è un architettura software che definisce una modalità di descrivere i componenti (servizi) con caratteristiche ben specifiche orientate al riutilizzo e all'integrazione. SOA è costituito da principi, linee guida, best practices architetturali indipendenti da qualsiasi tecnologia e definisce una serie di proprietà che i servizi devono soddisfare per essere realmente riusabili e facilmente integrabili in ambiente eterogeneo. I servizi devono quindi: - Essere ricercabili e recuperabili dinamicamente; - Essere autocontenuti e modulari; - Essere loosely coupled; - Essere componibili, ovvero orchestrabili in processi di business ampi che rompano le tradizionali pile applicative verticali (silos); - Definire delle interfacce esplicite e indipendenti dall'implementazione; - Devono avere un'interfaccia distribuita e devono essere accessibili in maniera trasparente rispetto all'allocazione. Per ottenere questi requisiti, le applicazioni SOA definiscono dei ruoli: Service Consumer: l'entità che richiede il servizio; può essere un modulo di un'applicazione o un altro servizio. Service Provider: l'entità che fornisce il servizio e che ne espone l'interfaccia. Service Contract: definisce il formato per la richiesta di un servizio e della relativa risposta. Service Registry: direttorio in rete dei servizi consultabili. Pag. 3 di 55

4 Service Registry Service Contract Service Consumer invocation Service Provider Figura 1 Ruoli SOA Poichè i servizi devono essere ricercabili e recuperabili dinamicamente, il Service Contract deve essere pubblicato su un Service Registry dal Service Provider. Il Service Consumer deve richiedere al Service Registry il Contract relativo al servizio richiesto, che utilizzerà per eseguire il servizio tramite un protocollo di trasporto. Attraverso l adozione di servizi con tali caratteristiche è possibile raggiungere un allineamento orientato ai processi del business e dell IT, consentendo adattamenti più veloci ai svariati cambiamenti dei processi di business. Inoltre, SOA consente l integrazione di applicazioni preesistenti, esponendo le loro funzionalità come servizi e migliorando il valore del patrimonio software esistente e evitando la ridondanza nelle infrastrutture software. Per produrre tali benefici e per supportare il paradigma service-oriented, SOA aggiunge ulteriori livelli alla convenzionale architettura alla base dell integrazione delle applicazioni e dell orchestrazione dei servizi rendendo i sistemi di base trasparenti per gli analisti del business. Pag. 4 di 55

5 Figura 2 Layer SOA Pag. 5 di 55

6 Al livello più basso dell architettura SOA sono presenti i sistemi operazionali e le applicazioni esistenti (ERP, CRM, Applicazioni Legacy). Il Component Layer è basato su tecnologie a container e componenti. Il Service Layer fornisce i servizi ai livelli superiori basandosi sui componenti e attori degli stati sottostanti. Il livello successivo (Businee Process and Orchestartion Layer) è lo strato che compone i servizi per implementare gli use-case e i processi di business. Infine il Presentation Layer è il livello che permette gli utenti di interfacciarsi con il processo sviluppato. L Integration Architecture è l infrastruttura che permette l accesso e al composizione dei servizi fornendo meccanismi di integrazione. A questo livello sono definiti gli ESB (Enterpriss Service Bus) che gestiscono per ogni servizio i ruoli definiti(service Consumer, Service Contract, Service Provider, Service Registry). Per la gestione e il controllo di tale infrastruttura vengono utilizzati specifici tools quali QoS, Security, Management e Monitoring. 1.2 Service Oriented Analysis and Design L architettura SOA, ponendosi come obiettivo lo sviluppo di applicazioni sulla base di servizi, comporta un impatto notevole sul processo di sviluppo delle applicazioni poiché fa uso di nuove metodologie che coprono i diversi aspetti di tale processo. Dal punto di vista dell analisi e del design esistono diverse pratiche a cui ci si riferisce spesso con il termine Service Oriented Analysis and Design (SOAD). SOAD è un approccio alla modellazione e allo sviluppo dei servizi basato sul paradigma service-oriented, basandosi su metodologie preesistenti come OOAD e BPM. Esistono diversi tipi di approcci: Top- Down, Bottom-Up e Meet- In-The-Middle. L approccio Top-Down prevede due fasi: - Fase di analisi: a partire dai processi di business, si identifica un elenco di servizi candidati e un modello preliminare di composizione degli stessi. Pag. 6 di 55

7 Per l individuazione dell insieme dei servizi candidati si possono utilizzare due modalità: task-centrica e entity-centrica. La prima considera ogni organizzazione come un insieme di operazioni composte in una logica di workflow. Avendo quindi la descrizione dei porcessi si può procedere all identificazione dei servizi candidati. La seconda modalità è la modellazione delle entità primarie dell organizzazione. A partire dagli oggetti manipolati si possono astrarre le funzionalità che agiscono su tali oggetti. Queste funzionalità, opportunamente raccolte in contesti, possono essere dei candidati ad essere servizi. I servizi entità-centrici sono più difficili da modellare rispetto a quelli task-centrici ma sono più facili da riusare, in quanto sono meno legati al processo nativo. È possibile inoltre identificare altre due tipologie di servizi quali servizi applicativi infrastrutturali (come integrazione con servizi legacy) e i servizi che modellano processi componendo altri servizi. - Fase di design: realizzazione delle interfacce dei servizi (Service Contract). L appropriato passo iniziale di questa attività consiste nella creazione delle interfacce di quei servizi maggiormente riusabili. Infatti, l esatta definizione delle interfacce di questi servizi è utile alla definizione degli altri servizi. Una volta definite tutte le interfacce per ogni singolo servizio il risultato sarà un insieme di Service-Contract espressi in maniera coerente con la tecnologia implementativa scelta. La metodologia Top-Down è maggiormente utilizzata nel caso in cui si deve realizzare un sistema a servizi forma scratch. Nei casi in cui si deve integrare SOA con applicazioni già sviluppate in precedenza, l identificazione dei servizi verrà effettuata con una metodologia Meet-In-The-Middle. Questo tipo di approccio fa uso di SOMA (Service-Oriented Modeling and Architecture) che suddivide il processo di sviluppo di un sistema software verticalmente presupponendo la presenza di problematiche di integrazione con software pre-sviluppato di cui si vuole mantenere il funzionamento. SOMA prevede tre fasi: - Identification: identificazione dei possibili servizi candidati; - Specification: scelta dei servizi e specifica per ognuno di essi dei componenti enterprise che li compongono qualora dovessero essere riutilizzati; Pag. 7 di 55

8 - Realization: realizzazione dei servizi. La fase di identificazione dei servizi avviene mediante tre tecniche complementari: Domain Decomposition: viene effettuata un analisi Top- Down identificando i requisiti di business che i servizi dovranno soddisfare; Existing Asset Analysis: identificazione dei componenti attualmente esistenti che potrebbero concorrere alla creazione di un servizio; Goal-Service Modeling: analisi dei risultati delle due analisi precedenti verificando che i servizi individuati soddisfino gli obiettivi di business. Una volta identificati i processi di business da realizzare si verifica la disponibilità delle applicazioni e dei componenti nell'architettura esistente per procedere alla realizzazione dei servizi. L approccio Bottom-Up prevede inizialmente la definizione dei componenti con la conseguente realizzazione dei servizi. Quest ultimo metodo può sembrare molto pratico ma difetta del grado di astrazione necessario per la definizione di servizi realmente riusabili e non è quindi consigliabile rispetto agli altri. 1.3 Service Oriented Archictecture Maturity Model Gli aspetti visti finora riguardano la parte architettura di SOA e le metodologie SOAD ma riveste notevole importanza anche l aspetto organizzativo e culturale in quanto è necessario comprendere il valore di maturità di un azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA. La valutazione del grado di maturità tecnologica di un'azienda comporta il confronto con un maturity model consentendo quindi di giudicare l aderenza al paradigma architetturale SOA. Il maturity model attualmente in uso è il SOA Maturity Model. Tale modello si basa sul CMMI (Capability Maturity Model Integration). Per valutare la qualità di un processo, il CMMI ha definito tre attributi qualitativi fondamentali: - Capability: insieme dei risultati che un processo consente di conseguire. Esprime le potenzialità del processo e permette di effettuare stime attendibili sulla possibilità di raggiungere i risultati di un progetto, sia per il committente che per il produttore; Pag. 8 di 55

9 - Performance: misura dei risultati effettivi ottenuti nell'applicazione del processo (Valutazione a consuntivo o indice dei risultati raggiunti); - Maturity: misura dell'efficacia del processo e dell estensione e precisione con cui le fasi e le attività dello stesso sono esplicitamente definite, gestite, misurate e controllate. Rappresenta una valutazione del livello di padronanza e controllo del processo da parte dell'organizzazione inclusa anche la capacità dell'organizzazione di migliorarlo, ottimizzarlo in risposta ad eventuali necessità. Il CMMI per misurare l'efficacia del processo prevede, oltre al modello e ai suoi attributi, anche la definizione dei relativi livelli. Il Capability Level indica il livello di istituzionalizzazione del processo ovvero la capacità dell'azienda di eseguire, controllare, e migliorare le performance di un processo. Sono definiti sei strati di capability. Figura 3 CMMI - Capability Levels Pag. 9 di 55

10 Il Maturity Level è una misura dell'estensione e dell'efficacia dell'intero processo aziendale. Sono definiti cinque strati di maturità, ognuno con livelli di difficoltà e richieste diverse. 1 -Initial Process unpredictable, poorly controlled, and reactive 2- Managed Process characterized for projects and is often reactive 3 -Defined Process characterized for the organization and is proactive 4 -Quantitatively Managed Process measured and controlled 5 -Optimizing Focus on continuous process improvement Figura 4 CMMI - Maturity Levels Come in CMMI, anche in SOA-MM sono definiti diversi livelli di maturità crescente, stavolta legati a come e quanto profondamente un'impresa ha adottato l'approccio SOA al suo interno. La piramide riportata in SOA-MM paragona i cinque livelli del CMMI ai cinque analoghi livelli del SOA Maturity Model: 1. Functionality, in cui vengono introdotte le tecnologie SOA; 2. Cost Effectiveness, in vengono definiti degli standard per la gestione (governance) delle tecnologie SOA; 3. Responsiveness, in cui l obiettivo è il livello di soddisfazione dei processi di business raggiunto attraverso il SOA; 4. Transformation, o livello dei servizi di business "misurati"; 5. Optimization, o livello dei servizi di business ottimizzati. Pag. 10 di 55

11 Benefits Figura 5 Livelli del SOA Maturity Model Oltre alla figura piramidale vengono fornite due tabelle. La prima (Tabella 1) mette in relazione i livelli di maturità del modello con i più evidenti benefici in termini di business (prime-businessbenefits), la diffusione in azienda (scope), i fattori critici tecnologici e organizzativi, e gli standard di riferimento. La seconda (Tabella 2) specifica gli obiettivi (key-goals) e le principali pratiche (keypractices). Pag. 11 di 55

12 MATURITY PRIME BUSINESS SCOPE CRITICAL TECHNOLOGY CRITICAL PEOPLE & STANDARD LEVEL BENEFITS SUCCESS FACTORS ORGANIZATIONAL SUCCESS FACTORS 5 Optimized Business Business optimization Business unit or enterprise, Event driven automation for optimization Continuous improvement culture Services react and respond Cross-enterprise CEO sponsorship automatically 4 Measured Business Business transformation Business unit or enterprise Business Activity Monitoring, On-going business process evaluation and response Services from reactive to Cross-enterprise Event Stream Processing, CFO sponsorship real-time, Meet Event-driven dashboards business and alerts performance metrics 3 a Business responsiveness Business processes across Reuse, Ease of modification, IT Partnership with Business WS-BPEL Business Services change business processes quickly and effectively business unit or enterprise Availability, Business process rules, Event-driven processes, Partnership across Organizations SOA Life-cycle Composite applications Governance Executive commitment Event-driven design skills Business Unit Manager Sponsorship b Business responsiveness Services available to External services enablement, RosettaNet ebxml Collaborative Services collaboration with business processes and external partners, Cross-enterprise Cross-enterprise security, Translation of crossenterprise protocols, WS-Trust trading partners Long-running transactions 2 Architected Services IT cost reduction and control Multiple integrated Support for heterogeneity and distributed systems, Architecture group provides leadership UDDI WS-Reliable applications Reliable Messaging, SOA Competency Center Messaging Mediation, CIO Sponsorship WS-Policy Ease of Deployment, WS-Addressing Database integration, XQuery Versioning, WS-Security Internal security, SAML Performance management 1 Initial Services New functionality R&D experimentation Standards, Legacy Integration Developers learn service development skills XML XSLT, Pilot projects, Developer Sponsorship WSDL Web site, Portal, SOAP Custom Java integrations,.net Small number of services Tabella 1 Descrizione dei livelli del Maturity Model Pag. 12 di 55

13 5 4 3 a 2 1 MATURITY LEVEL Optimized Business Services Measured Business Services b Business Services Collaborative Services Architected Services Initial Services KEY GOALS KEY PRACTICES 1. Provide enterprise-wide leadership for 1. Implement self-correcting business business and SOA governance. processes. 2. Prove returns from SOA-supported continuous improvement. 1. Institute transformation from reactive to 1. Collect and analyze business processoriented real-time business processes. real-time performance metrics. 2. Define and meet business-oriented 2. Implement ongoing business process performance metrics. evaluation and re-engineering. 1. Create ongoing partnership between 1. Specify policies for use of SOA in creation business and technology organizations for or modification of business processes. SOA governance. 2. Take advantage of event-oriented and 2. Support full business processes via SOA. mediation functionality of SOA 3. Prove returns from reuse of services and technologies, especially with regards to responsiveness to change. enhancing/extending business processes. 1. Create ongoing partnership between 1. Specify policies for use of SOA in business and technology organizations for collaboration with business and trading SOA governance. partners. 2. Extend SOA business processes to external 2. Implement cross-enterprise security. organizations. 3. Prove returns from use of services for collaboration. 1. Institutionalize use of SOA. 1. Specify technology standards for SOA. 2. Put in place architecture leadership for 2. Integrate SOA into organization-wide SOA. development process. 3. Prove returns from use of standard 3. Provide organization-wide SOA training and technology. competency center. 4. Use incremental integration. 1. Learn SOA technology in R&D and pilot 1. Create services definitions projects. 2. Integrate SOA into project development 2. Apply SOA technology to immediate methodology. organizational needs. 3. Quantity costs, time, and business benefits 3. Define initial ROI measurements for SOA of pilot projects. projects and apply to initial projects. Tabella 2 Key goals e practices dei vari livelli del Maturity Model Il primo livello, Initial Services, è quello più semplice ed è limitato ad esportare come servizi alcune funzionalità (XML, XSLT, SOAP e WSDL). Al secondo livello, Architected Services, si analizzano gli standard di seconda generazione (UDDI, BPEL4WS, WS-Security) e si individuano le tecnologie e prodotti da utilizzare e le linee guida da seguire. Pag. 13 di 55

14 Al terzo livello, Business Services/Collaborative Services, l'implementazione delle SOA esce dall'ambito IT per coinvolgere anche le linee di business. È il primo passo verso l'"allineamento" tra IT e business. Al quarto livello, Measured Business Services, si ha ormai un architettura SOA ben delineata con strumenti di Business Activity Monitoring e di Event Stream Processing che permettono di collezionare i dati di business, valutare il ROI del progetto e identificare eventuali punti da migliorare. Nel quinto livello, Measured Business Services, l'architettura SOA è ormai consolidata. L azienda e l IT condividono la mission aziendale. L'obiettivo finale è quindi l'ottimizzazione dei processi e servizi di business. Un altro maturity model utilizzato è Il Service Integration Maturity Model (SIMM). Tale modello si focalizza principalmente sulla maturità dal punto di vista dell'applicazione dei principi Service Oriented alle problematiche d'integrazione. Figura 6 I livelli del SIMM Pag. 14 di 55

15 In questo modello i livelli previsti sono 7: 1. Silo (Data Integration): vengono utilizzate soluzioni di integrazione ad-hoc. A questo livello l'architettura non è aperta al cambiamento; 2. Integrato (Application Integration): l'organizzazione si muove verso una forma di EAI (Enterprise Architecture Integration), cioè si cerca una forma di integrazione architetturale ottenuta con connessioni proprietarie e punti di integrazione; 3. Componentizzato (Functional Integration): le parti critiche delle applicazioni vengono fattorizzate o wrappate in componenti. L'integrazione tra i componenti avviene tramite le interfacce definite cercando di esporre le funzionalità in maniera modulare; 4. Servizi semplici (Process Integration): utilizzo ridotto di SOA definendo alcuni servizi ad uso interno o anche esterno; 5. Servizi composti (supply-chain integration): si definisce un eco-sistema di servizi, che possono essere esposti a tutta la supply-chain; 6. Servizi virtualizzati (Virtual Infrastructure): si crea un'infrastruttura virtualizzata per le applicazioni, che a questo livello sono composte di servizi, componenti e flussi; 7. Servizi dinamicamente riconfigurabili (Eco-system Integration): l'architettura è riconfigurabile e i servizi possono essere composti dinamicamente. E' chiaro che in questo caso la misura del livello di maturità è la capacità di integrazione e gli obiettivi sono il massimo dinamismo e la massima adattabilità a fronte del cambiamento e della necessità. E' implicito in questo modello il fatto che SOA è considerato il paradigma architetturale più promettente per raggiungere questi obiettivi. 1.4 Roadmap Stabilità la maturita di un azienda nella sua implementazione di un'architettura SOA-oriented tramite un maturity model, è possibile definire i passi da intraprendere per l evoluzione. Pag. 15 di 55

16 Questi passi devono essere definiti poi formalmente in una Roadmap che ci permetta di "traghettare" l'organizzazione verso il nostro obiettivo: la completa adozione dei principi di SOA a livello architetturale e organizzativo. Figura 7 Roadmap Pag. 16 di 55

17 Una Roadmap consiste essenzialmente di cinque livelli: 1. Initial Services; 2. Architected Services; 3. Business Services; 4. Measured Business Services; 5. Optimized Business Services. Level 1: Initial Services Initial Services è il livello base del maturity model SOA e rappresenta la fase iniziale di apprendimento e progettazione dell adozione SOA. In questo livello i progetti sono realizzati per affrontare simultaneamente una specifica necessità per l implementazione di funzionalità consentendo anche di testare tecnologie specifiche di approccio al SOA. Durante questa fase l architettura e il design sono concentrate su: - Integrazione point-to-point della piattaforma tra le varie applicazioni (non necessariamente SOA-oriented); - Piccoli progetti SOA; - Implementazione di progetti; - Integrazioni personalizzate; - SOA stovepipes per implementazioni future; - Un piccolo ma costante aumento del numero dei servizi web. In questo livello sono introdotti i più comuni standard SOA della W3C come XML per la definizione dei formati del messaggio, WSDL per la definizione dell interfaccia del servizio e SOAP per l invocazione dei servizi. Un esempio tipico di progetto iniziale come mostra la Figura 8 è quello di collegare direttamente un Web Portal sia con una nuova applicazione server implementando il sales forecasting e il tracking service sia con un applicazione CRM attraverso un adattore per i Web Services. Services Interface mostrato in questo e nei successivi esempi fornisce il collegamento e la necessaria traduzione tra l implementazione dell applicazione e i protocolli scelti per consentire la comunicazione fra i servizi. Le Services Interfaces possono essere fornite automaticamente attraverso vari tipo di prodotti come un applicazione server o un adattatore ESB come verrà descritto in seguito. Pag. 17 di 55

18 - Figura 8 Esempio di Initial Service I principali vantaggi di questo primo passo forniscono le necessarie funzionalità di business e al tempo stesso forniscono i metodi per sviluppare e distribuire un applicazione SOA di base. Cosi come un implementazione dovrebbe usare il protocollo SOAP tra il server e i servizi supportati, allo stesso modo opereranno il Sales Forecasting e il Tracking Service per ottenere informazioni dall applicazione CRM. Tuttavia, anche un applicazione di base iniziale potrebbe trarre benefici dall uso di qualche componente aggiuntivo dell infrastruttura SOA. Al di là della formazione acquisita dall uso precoce delle tecnologie, la principale motivazione per l introduzione di queste tecnologie sui progetti iniziali è quella di mettere in atto una tecnologia scalabile in modo tale che quando SOA comprende più funzione di business vengono applicati i giusti principi. Pag. 18 di 55

19 La Figura 9 mostra lo stesso esempio precedente con l aggiunta di: - Un Enterprise Service Bus (ESB) che fornisce un modello standard di interazione per i componenti SOA inclusi i Web Services e i database relazionali. L ESB fornisce un largo numero di adattatori per consentire ai servizi implementati in diverse tecnologie di scambiarsi messaggi permettendo, per esempio, ad un applicazione.net di comunicare con applicazione J2EE a livello di servizi; - Un Service Level Management Service che fornisce visibilità delle performance dei Web Service e delle metriche a livello di servizio; - Un Service Registry che fornisce un archivio centrale delle definizioni dei servizi attraverso i progetti iniziali ed è anche un punto di riferimento per gli sviluppatori dei servizi per ottenere le definizioni dei servizi. Figura 9: Infrastruttura SOA avanzata a livello Initial Service Pag. 19 di 55

20 Level 2 : Architected Services Questo rappresenta il secondo livello del Maturity Model SOA in cui i servizi sono progettati per essere flessibili e debolmente accoppiati. Il beneficio di business di questo livello è la riduzione dei costi di sviluppo e diffusione attraverso l uso delle infrastrutture SOA e dei suoi componenti. Questi benefici sono maggiori in ambienti eterogenei tipici della maggior parte delle imprese. Sulla base dell apprendimento e del feedback del livello 1 sono definiti gli standard architetturali e le tecnologie standard di implementazione. I fattori critici di successo che devono essere presi in considerazione durante la progettazione di questi servizi loosecoupled sono i seguenti: - Eterogeneità e sistemi distribuiti; - Messaggi rileggibili; - Integrazione di database; - Integrazione di applicazioni; - Versioning; - Gestione centralizzata della sicurezza; - Routing e trasformazione; - Riuso del Service Minimal; - Facilità di implementazione; - Gestione dell IT performance; La Figura 10 mostra un esempio di sviluppo SOA a questo livello per un esempio di trading finanziario. Il livello di Architected Service include l uso di componenti chiave mostrati precedentemente nella Figura 9 con l aggiunta di alcuni aspetti essenziali di questo esempio: - Una Services e Policies Repository che estende il Service Registry fornendo una repository per un immagazinamento totale e il supporto delle informazioni SOA incluse le policies e le definizioni dei servizi; - Un Exception Management Service che fornisce un meccanismo per localizzare, diagnosticare e automaticamente rimediare ad errori applicativi e di sistema; - Message Transformation per consentire l integrazione dei servizi con eventuali differenze nei contenuti e nei formati di un messaggio. Questo viene realizzato spesso attraverso l utilizzo delle trasformazioni XSLT applicate ad un messaggio XML; Pag. 20 di 55

21 - Un Single Sign-On Service che supporta l autenticazione degli utenti e le diverse autorizzazioni. Figura 10 Applicazione d'esempio dell'architected Service Level 3: Business Services L obiettivo del livello di Business Service riguarda la collaborazione tra la tecnologia e le organizzazioni business con lo scopo di assicurare che l uso dell architettura SOA fornisca risposte di business chiare. Questo livello è definito attraverso due percorsi complementari per realizzare questo obiettivo. Uno, Business Services, focalizzato sul miglioramento dei processi di business interni e l altro, Collaborative Services, focalizzato sul miglioramento dei processi collaborativi con partner esterni. Pag. 21 di 55

22 Certamente entrambi possono essere eseguiti per ottenere il più grande vantaggio dal SOA, ma il livello Business Service può essere raggiunto con un solo percorso se questo fornisce il più grande vantaggio business. La Figura 11 mostra un esempio di sviluppo SOA al livello 3 per un esempio di trading finanziario. L elemento chiave dell implementazione del Business Service è il Business Process Management (BPM) che consiste nella gestione di processi di lunga durata coinvolgendo i messaggi sequenziali tra i servizi. Figura 11 Esempio di Business Service Pag. 22 di 55

23 La Figura 12 mostra l evoluzione del Business Services con l aggiunta di: - Semplice valorizzazione dei processi di business. Un principale vantaggio dell architettura SOA è l attivazione delle modifiche di un processo di business attraverso la riconfigurazione dei servizi. In questo esempio, un nuovo Compliance Service, necessario per la conformità normativa, è inserito nel flusso del messaggio tra l Order Management Service e il Trading Service senza nessun cambiamento nell implementazione dei servizi esistenti; - Riuso dei servizi. In questo esempio, il riuso è mostrato attraverso un applicazione multi-canale (fornisce l accesso alla stessa applicazione mediante differenti metodi di comunicazione customizzati) nella quale l Order Management Service viene condiviso dal Call Center Service e dall Online Service. Figura 12 Evoluzione dell'applicazione a livello Business Services Il percorso alternativo al Business Services è il Collaborative Services il cui obiettivo riguarda il collegamento con partner esterni. La Figura 13 mostra un esempio in cui l azienda viene estesa in un nuovo business di transazioni di scambio a Pag. 23 di 55

24 disposizione su Internet. Gli aspetti principali in questo tipo di implementazione includono: - L utilizzo di protocolli standard SOA che supportano specifiche funzionalità business-to-business (B2B) come quelli definiti da RosettaNet che includono le funzioni standard di messagging XML per ottenere le informazioni sui prodotti, informazioni d inventario e ordini; - Un Collaborator Server che implementa i protocolli B2B e supporta trasformazioni necessarie tra i messaggi usati internamente all enterprise e quelle necessarie per i processi esterni; - La connessione ECN si è spostata da un protocollo proprietario a protocollo di servizi industriali standard ed è quindi gestito attraverso il Collaboration Server. Figura 13 Esempio di Collaboration Services Pag. 24 di 55

25 Level 4: Measured Business Services Mentre il livello Business Services focalizzata sull implementazione di processi esterni e/o interni, il quarto livello è focalizzato sulla misurazione e la presentazione di questi processi a livello business in modo da fornire continui feedback sulle performance e sull impatto business dei processi implementati al livello 3. La Figura 14 mostra un esempio di un processo per configurare, ordinare e produrre, i servizi per ogni funzione principale distribuita attraverso località geografiche. Le caratteristiche chiave in questo esempio sono: - Real-time Event Stream Processing che in questo esempio colleziona tutti gli eventi RFID in un event DB e filtra gli eventi business-meaningful in base a delle specifiche regole e li inoltra per utilizzarli in altri servizi; - Business Activity Monitoring che fornisce i feedback di gestione in tempo reale delle performance di business. Il Service Level Management Service può fornire attività di monitoraggio per gli eventi che sono direttamente collegati all infrastruttura SOA. In altri scenari, gli eventi generati dal Service Level Management Service possono essere passati su più sevizi generici per essere processati e visualizzati. Figura 14 Esempio di Measured Business Services Pag. 25 di 55

26 Level 5: Optimized Business Services Il quinto livello del SOA Maturity Model, Optimized Business Services, aggiunge risposte automatiche alle valutazioni e alle visualizzazioni del Livello 4. In questo modo, il sistema informativo SOA diventa enterprise nervous system e agisce in base agli eventi che si verificano a livello di business in accordo a delle specifiche regole ottimizzando gli obiettivi business. La figura 15 mostra la configurazione, l ordinamento e il processo di fabbricazione migliorato per fornire un costo dinamico in base allo stato dei materiali e del lavoro nell impianto di fabbricazione. Per esempio, se le parti per una particolare versione di un oggetto sono scarse, il costo può essere valorizzato per incoraggiare gli acquirenti ad ordinare un oggetto usando parti alternative. Figura 15 Esempio di Business Optimization Pag. 26 di 55

27 1.5 Service Oriented Integration Uno degli aspetti interessanti di SOA è l integrazione di applicazioni legacy o applicazioni preesistenti in sistemi a servizi. Questo permette infatti di non dovere riscrivere codice funzionante e di cui si vuole tener traccia. Inoltre, ponendosi come obiettivo la "rottura" dei Silos applicativi verticali, implicitamente SOA si occupa di integrazione. Si parla in questo caso di SOI (Service Oriented Integration), ovvero l'applicazione dei principi Service Oriented alle problematiche d'integrazione. In questo modo le funzionalità non sono più ristrette esclusivamente all'interno del proprio silo, bensì sono riusabili anche dalle altre applicazioni all'interno di una architettura a servizi. Questo permette da un lato di salvaguardare gli investimenti pregressi, dall'altro di potere consolidare e riorganizzare la propria architettura. Creando dei servizi secondo i principi architetturali di SOA ed esponendo le loro funzionalità su un Service Bus (cioè ad un software infrastrutturale in grado di esporre e fare comunicare servizi) è possibile integrare il sistema una sola volta. Infatti il servizio conosce come connettersi al bus, che a sua volta è connesso agli altri servizi (integrate once, connect many). In questo modo si evita un approccio punto-punto che spesso sfocia nella cosiddetta Accident Architecture. Dal punto di vista architetturale, il Service Bus è il layer che deve mettere a disposizione uno strato di comunicazione (backbone) tra i servizi. Le applicazioni Legacy, una volta opportunamente "wrappate" con un'interfaccia a servizi (Service Contract) sono in grado di erogare e utilizzare i servizi condivisi mediante il Service Bus. Un Integration Service ha quindi lo scopo di: - Fornire un'interfaccia a servizi di applicazioni già esistenti, esponendo come un servizio un qualcosa che servizio non è. - Utilizzare al suo interno API specifiche della tipologia della risorsa EIS. - Nascondere al consumer la tipologia e la topologia dell'eis. - Aggregare piu' funzionalità esistenti al fine di esporre un servizio con la giusta granularità. - Effettuare il mapping tra il data model della risorsa EIS e il business model disaccoppiando il service consumer dalla Pag. 27 di 55

28 specificità della risorsa. Gli Integration Services possono permettere l'accesso e l'utilizzo di informazioni ("information assets") da parte di qualunque altro servizio, applicazione o utente finale. Possiamo ulteriormente distinguere gli Integration Service sulla base della tipologia di funzionalità che espongono (accesso ai dati piuttosto che funzionalità di business) definendo: Functional Integration Service per i servizi che esportano le funzionalità di business esistenti (in ottica EAI); Data Integration Service o Information Service per i servizi che rendono disponibili i dati enterprise del Sistema Informativo (in ottica EII). Nel caso di integrazione con funzionalità già sviluppate si segue un approccio MEet-In-The-Middle. Tale approccio prevede come punto di partenza l analisi delle risorse esistenti per ottenere dei servizi SOA. A supporto di tale procedimento possono essere utilizzati alcuni Pattern che permettono di impostare correttamente il design dei servizi SOI. Pattern Service Wrapper Il pattern Service Wrapper ha lo scopo di fornire un meccanismo che consenta a sistemi, applicazioni o funzioni che non sono service-oriented (es. funzioni Legacy, CRM, ERP, stored procedure PL-SQL) di poter essere utilizzati da un architettura Service Oriented Architecture. Questo obiettivo viene raggiunto realizzando un servizio che al suo interno invoca la componente software Legacy. Figura 16 Service Wrapper Pag. 28 di 55

29 Pattern Service Proxy Il Pattern Service Proxy ha lo scopo di disaccoppiare l accesso ai servizi di business dai client, nascondendo e centralizzando le operazioni di localizzazione e utilizzo del servizio di business. Tale obiettivo è raggiunto attraverso la realizzazione di una classe Java che ha la funzione di interfacciare il servizio garantendo un astrazione dei servizi al client. Figura 17 Service Proxy Il Service Proxy offre i seguenti vantaggi: - Fornire un interfaccia uniforme ai client; - Riduzione dell accoppiamento tra service consumer e service provider; - Centralizzazione, gestione e risoluzione delle problematiche di reperimento (lookup o discovery) e utilizzazione dei servizi; - Celare le particolarità tecnologiche della specifica comunicazione con l EIS; - Centralizzazione delle modifiche derivanti da variazione dei servizi di business in una sola classe; - Riduzione del numero di interazioni remote fra componenti in comunicazione, con conseguente miglioramento di perfomance; - Garantire la possibilità di trasformare eccezioni tecnologiche (es: java.rmi.remotexception) in eccezioni applicative. Pag. 29 di 55

30 Pattern Service Locator Il Pattern Service Locator garantisce una modalità uniforme e semplificata di localizzazione delle risorse. Questo pattern gestisce le operazioni dei servizi occupandosi di: - Celare la complessità delle operazioni di ricerca (discovery dei servizi); - Fornire una modalità uniforme di lookup e di creazione dei servizi; - Isolare le eventuali operazioni di lookup vendor dependent ; - Nascondere eventuali problematiche di networking; - Gestire eventuali necessità di caching degli handle; - Concentrare la gestione delle problematiche di localizzazione in un singolo punto. Figura 18 Service Locator Pattern Service Facade L'intento del pattern Service Facade è di minimizzare alcuni problemi relativi alla composizione in più Business Object dello strato di business (business tier), componendo l'accesso ai Business Object in un servizio con la giusta granularità, coerentemente ai principi SOA. Il pattern prevede di: - Esporre un'interfaccia del servizio con la giusta granularità "a grana grossa" (coarse-grained); - Fornire un unico punto di accesso in modalità service-oriented; Pag. 30 di 55

31 - Invocare e gestire i Service Wrapper e/o i componenti software legacy che concorrono alla logica del servizio; - Centralizzare l'accesso a servizi infrastrutturali (come il security management ed il transaction management) sul business tier. Questo si ottiene anteponendo, ai Service Wrapper e/o componenti che concorrono all'implementazione del servizio, un servizio di facciata della giusta granularità di business. Figura 19 Service Facade Pattern Virtual Provider L obiettivo del Pattern Virtual Provider è di combinare Pattern Service Facade, Service Proxy e Service Wrapper al fine di fornire un servizio il più completo possibile anche se l ecosistema IT non è ancora consolidato. Il Pattern Virtual Provider provvede quindi a: - Esporre un'interfaccia del servizio con la giusta granularità "a grana grossa" (coarse-grained); - Invocare e gestire i Service Wrapper; - Centralizzare il security management; - Centralizzare logiche di routing, aggregazione, orchestrazione; - Centralizzare transaction management; - Centralizzare le trasformazione dei dati business model o data model; Pag. 31 di 55

32 Figura 20 Virtual Service Provider Utilizzando tale pattern l architettura migra da un modello a componenti ad un modello a servizi. Questo pattern è utile soprattutto nelle situazioni in cui si sta trasferendo il proprio sistema informativo verso un'architettura SOA ma non tutti i componenti software sono esposti a servizi (ad esempio nel caso in cui si è ancora ai primi passi della Roadmap). 1.6 Enterprise Service Bus I servizi SOA devono essere in grado di comunicare tra di loro attraverso un canale di comunicazione: il SOA bus. Da un punto di vista architetturale il SOA bus è un layer che mette a disposizione uno strato di comunicazione tra i servizi. Scopo dell'enterprise Service Bus (ESB) è fornire un'infrastruttura che centralizzi funzionalità quali supporto alla comunicazione sincrona ed asincrona basata su messaggi, intelligent routing, supporto alla trasformazione dei dati, supporto alla connettività verso EIS eterogenei,ecc. Ad oggi non esistono specifiche relative al SOA Bus riguardanti la sua composizione o le sue funzionalità e i suoi servizi. Attualmente, sono percorribili due strade: realizzarlo in modo applicativo sfruttando le tecnologie esistenti (CORBA, J2EE, Web Services), rivolgersi al mercato acquistando un prodotto ESB Pag. 32 di 55

33 (alcuni player importanti sono IBM, Bea, Sonic, Iona, Cape Clear, SeeBeyond, ecc...) o utilizzare un prodotto open source. Un Enterprise Service Bus è un prodotto per l integrazione basato su standard di mercato e su un architettura orientata ai servizi che fornisce funzionalità tipiche dei tradizionali EAI Broker (Enterprise Application Integration Broker). L Integration Broker rappresenta l interfaccia univoca attraverso la quale transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei che devono interoperare. L EAI Broker è il componente fondamentale dell Integration MIddleware e si occupa in modo centralizzato delle operazioni di data mapping, data trasformation e message routing. L Enterprise Service Bus, rispetto all Integration Broker, presenta due sostanziali differenze: 1. Gli ESB espongono tramite "standard" funzionalità che i tradizionali Integration Broker fornivano tramite tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono:jdbc, JCA, JMS, JMX, WSDL, SOAP, JAX-RPC, JAXM, JAXR, SSAJ, XQuery, XPath; 2. Un ESB non si basa su un'architettura "monolitica" di tipo Huband-spoke(come l EAI Broker), ma su di una architettura distribuita a bus condiviso SOA (Service Oriented Architecture) oriented. In altre parole, in un'infrastruttura ESB, tutte le applicazioni sono integrate ed operano come "servizi". La logica d'integrazione non è più centralizzata in un hub centrale, ma è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità teorica ed è possibile effettuare il deploy delle funzionalità d'integrazione strettamente necessarie (selectivedeployment). L'utilizzo degli standard permette di ridurre le soluzioni proprietarie chiuse e costose tipiche dei tradizionali prodotti EAI riducendo il vendor lock-in ed i costi legati alle consulenze specialistiche ed alle licenze. Pag. 33 di 55

34 Figura 21 Enterprice Service Bus Risulta evidente che l'aumento di interoperabilità dato dall'uso di protocolli e tecnologie standard, riduce i rischi aziendali complessivi indotti dall'adozione di un middleware. Utilizzando i Web Services, è possibile disaccoppiare l'interfaccia del servizio (WSDL) dall'implementazione del servizio stesso. Oltre a tale disaccoppiamento l'esb permette di separare la logica del servizio dalla logica di processo. In questo modo le interdipendenze tra i servizi non sono più implementate nei servizi stessi. Ottenuti questi endpoint astratti e omogenei, è possibile "orchestrare" i servizi per ottenere veri "processi di business". Un ESB permette, in linea con le best practices SOA, un'integrazione "incrementale": è possibile infatti integrare in momenti differenti le varie parti di un sistema attraverso un approccio cosiddetto Leaveand-layer. In tale approccio viene lasciato inalterato l'esistente portfolio dei servizi Legacy e di applicazioni esistenti riconciliando le loro differenze (logica e dati) in un nuovo layer (ESB). Ad oggi, praticamente quasi tutti i principali produttori di Software hanno realizzato o intendono realizzare un proprio prodotto ESB da proporre sul mercato. ESB Container In analogia ai container J2EE (che erano contenitori di componenti Java Enterprise), gli ESB sono contenitori di servizi. Si parla quindi di ESB container. Pag. 34 di 55

35 I Container forniscono le facilities nella gestione dei servizi (es: ciclo di vita), nelle modalità di comunicazione (es: gestione degli endpoint dei messaggi e modalità di inoltro) e di gestione delle risorse (es: resource pool). Inoltre forniscono tipiche funzionalità infrastrutturali di middleware come monitoring, logging, audit. Avendo il supporto delle API esposte dal Middleware, lo sviluppatore può concentrarsi sullo sviluppo della logica di business (in questo caso del servizio) rispettando il Service Contract. Pag. 35 di 55

36 2. Code Architects Solution Enterprise Platform Il Code Architects Enterprise Solution Platform (CAESP) è un framework di sviluppo, implementato da Code Architects, mediante il quale è possibile implementare applicazioni di classe enterprise con estrema semplicità e flessibilità. Il CAEP oltre ad essere un framework di sviluppo, e quindi offrire librerie di base, offre un insieme di librerie, metodologie e tool di supporto al developer. Le applicazioni sviluppate con il CAESP implementano una classica architettura a tre livelli: Presentation Layer: Rappresenta il layer delle user interfaces. Questo layer offre una multicanalità, in quanto è possibile sviluppare applicazioni di diverso tipo: Applicazioni Web: Asp.Net, Silverlight. Applicazioni Desktop: Windows Form, Windows Presentation Foundation. Business Layer: Rappresenta il layer nel quale viene modellata la logica di business. Data Layer: Rappresenta il layer di accesso ai dati. Figura 22 Architettura di Code Architects Enterprise Solution Platform Pag. 36 di 55

37 L obiettivo di Code Architects è quello di estendere il framework verso un tipo di architettura Web Oriented Architecture, quindi abilitare la stessa dapprima verso il supporto per lo sviluppo di Service Oriented Architecture (SOA) e successivamente al supporto delle Resource Oriented Architecture (ROA). Allo stato dell arte con il CAESP è possibile sviluppare sia applicazioni SOA che ROA. Se si desidera sviluppare applicazioni SOA è possibile pubblicare i servizi sviluppati come Web Services, ed inoltre orchestrare i processi di business con Microsoft BizTalk. Se invece si desidera sviluppare applicazioni ROA è possibile pubblicare i servizi sviluppati, come servizi REST. In futuro Code Architects implementerà librerie, tool e metodologie di supporto allo sviluppo di applicazioni SOA e ROA. Figura 23 Servizi della piattaforma CAESP Le applicazioni realizzate utilizzando il framework CAESP garantiscono alta affidabilità poichè implementa le proprietà ACID. ACID è l acronimo di: Pag. 37 di 55

38 A: Atomicity Questa proprietà è garantita grazie all uso del Transaction Processing Monitor System fornito da Windows 2000 e/o Windows CAESP assicura che o tutte le operazioni coinvolte in una transazione vengono eseguite o non ne viene eseguita nessuna. Il concetto di base è che tutte le caratteristiche di programmazione COM+, comprese nel Framework.NET, sono completamente invisibili agli utenti CAESP. C: Consistency La consistenza dei dati è garantita precedentemente e conseguentemente ogni processo grazie alla proprietà di atomicità. Questo accade sia nel caso in cui una transazione va a buon fine sia in caso di insuccesso. È importante notare che la presenza di un Resource Manager compatibile con il Transaction Processing Monitor System è essenziale. Esempi di TP-Monitors sono quelli forniti da Windows 2000 e/o Windows 2003 o versioni successive come MSMQ, Oracle, SQL Server. I: Isolation CAESP garantisce che le operazioni non possono accedere o vedere i dati in uno stato intermedio durante una transazione. In questo modo, operazioni concorrenti appartenenti a differenti transazioni non possono danneggiare la consistenza dei dati. Tale proprietà è assicurata rendendo ogni transazione ignara della presenza di altre transazioni concorrenti eseguite nel sistema. D: Durability La persistenza dei dati è garantita attraverso il Data Access Layer. Quindi, una volta notificato all utente il successo della transazione, questa persisterà e non potrà essere annullata. Sviluppo delle applicazioni client side con CAESP Per la realizzazione delle applicazioni desktop client side il framework Code Architects Enterprise Service Platform mette a disposizione diverse tecnologie quali Microsoft WPF (Windows Presentation Foundation) e Windows Forms. Pag. 38 di 55

39 WPF, in particolare, fornisce agli sviluppatori un modello di programmazione unificato per la progettazione delle interfacce dei clients desktop di Windows. Per estendere questa tecnologia è stato introdotto anche l Application Platform Extension for WPF (APE4WPF). APE4WPF è un framework che ha lo scopo di rendere Windows Presentation Foundation più facile da utilizzare. Esso consente di sviluppare applicazioni desktop con WPF usando un approccio MVC. In particolare, esso semplifica e migliora il modello fornito da WPF adattandolo ai bisogni delle applicazioni a livello enterprise. Questa estensione diventa anche un completo ambiente desktop capace di ospitare l applicazione creata. Windows Forms è un applicazione di programmazione di interfaccia grafica (API) incluse nel Microsoft.NET Framework. Essa fornisce l accesso agli elementi di interfaccia di Microsoft Windows. Per quanto riguarda le applicazioni web, invece, CAESP offre in particolare due tecnologie: ASP.NET e Silverlight. ASP.NET è una tecnologia Microsoft che consente la creazione di qualsiasi tipo di applicazione web. In futuro, Code Architects S.r.l rilascerà l Application Platform Extensions for ASP.NET. Silverlight è un Web Application Framework Microsoft. Rispetto ad ASP.NET, esso fornisce un ambiente di esecuzione capace di integrare multimedia, animazioni, interattività e oggetti grafici. Anche di questa tecnologia, Code Architects rilascerà in futuro l Application Platform Extension for Silverlight. Sviluppo delle applicazioni server side con CAESP Per lo sviluppo delle applicazioni server side CAESP mette a disposizione un framework enterprise che consente la realizzazione di applicazioni enterprise-level. Tutte le tecnologie e gli algoritmi usati per la costruzione di questo framework semplificano la fase di sviluppo garantendo l alta qualità dei prodotti. Questo framework è stato realizzato in accordo con il Façade Pattern e fornisce supporto allo sviluppo server side. Infatti, esso consente sia la semplificazione dello sviluppo back-end e fornisce facilitazioni con lo scopo di rendere più semplice l interazione backend. Pag. 39 di 55

40 Gli sviluppatori SOA associano individualmente gli oggetti SOA usando l orchestrazione. Nel processo di orchestrazione gli sviluppatori combinano i servizi in una maniera non gerarchica. Il tool usato per effettuare tali operazioni è Biz Talk, un server di gestione dei processi business (BPM Business Process Management). Quando Windows Workflow Foundation 4.0, compreso nel Windows Communication Foundation 4.0, verrà rilasciato, esso rappresenterà un ottima tecnologia per essere utilizzata insieme a AppFabric con l obiettivo di eseguire l orchestrazione. In alcuni casi esso potrebbe completamente sostituire BizTalk. Per esempio nei casi in cui è sufficiente eseguire processi load balancing invece di processi clustering. Data Layer Il Data Layer è il livello di accesso ai dati che consente l accesso a dati persistenti su un database server. In questo livello è presente un DataObject che nasconde completamente il processo di gestione dei dati fornendo solo due tipi di operazioni per l interazione con i dati (Get and Put). Poi, sarà il Data Object da solo a tradurre ogni commando nell opportuna espressione SQL facendo uso dei DataAdapters. Un DataAdapter agisce come un ponte tra una sorgente dati e una classe di dati disconnessa (come un DataSet). Questo componente specifica sia comandi SQL che forniscono funzionalità elementari come Create, Read, Update e Delete (CRUD) sia funzioni richieste per la creazione di strongly typed Datasets che includono DataRelations. Business Layer Il Business Layer è il livello costituito dal Business Façade Contracts e dal Business Façade. Il Business Façade implementa la logica applicativa e espone questa attraverso il Business Façade Contracts. L obiettivo del Business Façade Contracts è quello di fornire interfacce comuni che sono implementate dal Business Façade e condivise tra client e server. È un dato di fatto che i contracts sono gli unici oggetti condivisi tra client e server. Essi contengono tutte le informazioni utili con lo scopo di rendere possibile la comunicazione client-server. Essi contengono anche alcune costanti condivise in tutta l applicazione. Il grande vantaggio di questo approccio è che diventa più facile cambiare il valore di una singola costante invece di cercarle tutte nell intero codice dell applicazione. Pag. 40 di 55

41 Contracts I Contracts sono una collezione di specifiche che consentono a due applicazioni di interagire. Considerando l architettura CAESP, i contratti consentono ai clients di usufruire dei servizi esposti dai servers.per questa ragione, essi contengono le seguenti informazioni: - Datasets. - Interfaces. - Constants. Datasets Un Dataset è una rappresentazione memory-resident dei dati che fornisce un consistente modello di programmazione relazionale senza tenere conto della sorgente di dati che esso contiene. Esso rappresenta un insieme completo di dati incluse le tabelle che contengono, ordinati, i vincoli sui dati, cosi come le relazioni tra tabelle. Grazie al fatto che il Dataset è condiviso tra client e server diventa più facile gestire i dati in input e quelli in output. Per la creazione di un Dataset è necessario utilizzare il template fornito da Microsoft. Interfaces Un interfaccia è un set di operazioni che possono essere invocate dai clients. Ogni interfaccia fa riferimento ad un oggetto Façade. In pratica, un interfaccia contiene tutte le firme dei metodi che vengono implementati nel corrispondente oggetto Façade. Con lo scopo di definire un interfaccia è necessario eseguire i seguenti task. - Marcare la classe con l attributo WCF ServiceContract. Questo attributo indica semplicemente che l interfaccia definisce un service contract in un applicazione Windows Communication Foundation; - Marcare l interfaccia con la parola chiave public. Questo consentirà al client di chiamare i metodi attraverso l assembly dei Contracts; - Implementare BusinessFacadeInterface fornita dal CAESP; - Aggiungere la definizione della firma del metodo. Ogni definizione del metodo deve essere marcata con due attributi. Pag. 41 di 55

42 Il primo è l attributo WCF OperationContract. Esso indica che il metodo definisce un operazione che fa parte di un service contract in un applicazione WCF. Questo attributo, insieme all attributo di classe definito precedentemente, garantisce che tutti i metodi dichiarati nel contratto sono esposti come servizi WCF. Il secondo è l attributo PlatformDataContractSerializer. Esso indica come serializzare i dati che sono scambiati tra client e server. [ServiceContract] public interface IFacSales : BusinessFacadeInterface { /// <summary> /// Get the list of individual customers. /// </summary> /// <returns></returns> [OperationContract(Name = "GetIndividualCustomers")] [PlatformDataContractSerializer] DsAdventureWorks GetIndividualCustomers(); /// <summary> /// Get the address data related to an individual customer. /// </summary> /// <returns></returns> [OperationContract(Name = "GetIndividualCustomerAdressData")] [PlatformDataContractSerializer] DsAdventureWorks GetIndividualCustomerAdressData(string customerid); } /// <summary> /// Get the list of store customers. /// </summary> /// <returns></returns> [OperationContract(Name = "GetStoreCustomers")] [PlatformDataContractSerializer] DsAdventureWorks GetStoreCustomers(); Esempio 1 Definizione di un'interfaccia Constants Una delle più pratiche di sviluppo software del CAESP è quello di evitare l incorporamento dell input o la configurazione dei dati direttamente nel codice sorgente. Per evitare questo problema, CAESP adotta diverse soluzioni. Una di queste è la definizione delle costanti nei contratti. In questo modo cambiando il valore di una costante significherebbe cambiare solo il valore definito nel contratto invece di cercarle tutte nell intero codice dell applicazione. Pag. 42 di 55

43 CAESP richiede tre tipi di costanti. - Commands. Sono usati per mappare i DataAdapters definiti sui DataObjects di una stringa costante. In particolare, ogni comando è mappato su un DataAdapter. Essi sono usati sia per indirizzare la piattaforma verso quale DataAdapter deve essere applicato ad uno specifico DataObject (cioè nella definizione di un metodo façade) e per scegliere quale DataAdapter deve essere utilizzato dopo aver ritornato un DataObject (cioè durante un processo di validazione). Ciò che lo sviluppatore dovrebbe fare è fornire la stringa costante che identifica il comando desiderato attraverso la corrispondente costante di comando. Essi sono dichiarati come public readonly static String in un classe Commands. /// <summary> /// Command constant definitions. /// </summary> public class Commands { public readonly static String CmdIndividualCustomers = "CmdIndividualCustomers"; }... Esempio 2 Esempio di definizione di una classe Commands - Data. Le costanti di dati vengono usate per specificare il nome del servizio dei DataObjects. Poiché ogni DataObject ha un unico service name, le costanti di dati agiscono come identificatori di un servizio. Grazie a questo, è possibile recuperare un DataObject semplicemente fornendo il suo nome del servizio (cioè la sua costante di dati usata per definire il nome del servizio) ad un metodo Find statico reso disponibile dalla classe DataObject. Le costanti di dati sono dichiarate come public const String in una classe chiamata Data. /// <summary> /// Data constant definitions. /// </summary> public class Data { public const String DataSales = "DataSales";... } Esempio 3 Esempio di definizione di una classe Data Pag. 43 di 55

44 - Façade. Le costanti di tipo Façade vengono utilizzate per specificare il nome del servizio di BusinessFacades. Analogamente alle costanti di tipo Data, le costanti façade agiscono come identificatori per ciascun oggetto BusinessFaçade. Attraverso l utilizzo di queste costanti, i clients hanno la possibilità di recuperare uno specifico oggetto BusinessFaçade semplicemente cercandolo per nome usando un metodo statico Find fornito dalla classe BusinessFaçade. Le costanti façade sono dichiarate come public const String in una classe chiamata Facade". /// <summary> /// Facade constant definitions. /// </summary> public class Facade { public const String FacSales = "FacSales";... } Esempio 4 Esempio di definizione di una classe Facade È necessario marcare le classi costanti con la parola chiave public per renderle accessibili da altre classi. DataObjects I DataObjects sono oggetti che forniscono tutti i requisiti necessari per interagire con i database. Essi sono organizzati insieme in un unico livello chiamato Data Object Layer. In pratica, questo insieme di oggetti compone il livello più basso dell architettura fornita da CAESP. Essi sono capaci di comunicare direttamente con il database management system (DBMS). Questo significa che in caso di cambiamento di database, l unico oggetto del livello che cambierà sarà solo il database. Pag. 44 di 55

45 Figura 24 Data Object Layer I DataObjects forniscono ottimi vantaggi allo sviluppo server side. - I Business Façades possono ricercare il DataObject desiderato usando il metodo statico Find. In questo modo il livello di Business potrà interagire semplicemente con il livello Data Object; - Il largo range di operazioni possibili sui dati è ridotto a due sole operazioni: Get e Put. Questo comporta che qualunque azione viene eseguita sui dati persistenti consisterà in una chiamata di uno solo di quei metodi. Sarà il DataObject che gestirà tutta la complessità. Esso transformerà le operazioni di alto livello in semplici operazioni CRUD. Per poter definire un DataObject è necessario creare un progetto di librerie di Classi in Visual Studio Solution. Lo scopo di tale progetto è quello di collezionare tutti i DataObjects relativa ad una specifica entità. Per esempio, consideriamo un grande industria manufatturiera che deve gestire sia i dati che le vendite dei prodotti. In questo caso, si dovrebbe creare un insieme di DataObjects relativi alle vendite e un altro relativo ai prodotti. Una volta creato il progetto è possibile aggiungere i DataObjects necessari. Per fare questo è possibile o creare un nuovo oggetto DataObject usando il template disponibile con CAESP o creare questo template manualmente. Nel caso venga effettuata la seconda modalità è necessario eseguire le seguenti azioni: Pag. 45 di 55

46 - Aggiungere un nuovo oggetto Component al progetto; - Sostituire la classe Component estesa con la classe BaseDoObject fornita da CAESP. In seguito, indifferentemente dalla modalità scelta, è necessario marcare l intera classe con l attribute DataObject. Questo attributo sta ad indicare semplicemente che la classe considerata rappresenta un DataObject. Per completare la compilazione del DataObject è necessario aggiungere uno o più DataAdapters all oggetto. I DataAdapters possono essere aggiunti semplicemente selezionando e spostando nella classe DataObject l oggetto DataAdapter dalla toolbox di Visual Studio. Figura 25 Data Object Dopo aver configurato in modo appropriato ogni DataAdapter, la costruzione del DataObject è quasi completa. L ultima azione da compiere è quella di legare ogni DataAdapter con un Command precedentemente definito in un Contracts. Questo binding è fondamentale per poter gestire i dati nelle applicazioni client-side. Infatti, usando questo approccio, l unica necessità del client è quella di conoscere, per poter eseguire azioni sui data, il nome del comando desiderato. Grazie al fatto che i comandi sono definiti in assembly di contratti e tra che ogni assembly è condiviso tra client e server l architettura risulta essere completa. Questo binding viene Pag. 46 di 55

47 dichiarato usando il metodo MapDataAdapter fornito da CAESP attraverso la classe BaseDoObject. Inoltre, come mostrato nella Figura 25, un DataObject può contenere più di un DataAdapter. In questo modo esso può eseguire più di un Command. Al fine di comprendere come appare un oggetto SQL DataOBject, si consideri il seguente esempio: un DataObject realizzato per la gestione delle informazioni dei clienti riguardanti le vendite di un azienda produttrice. La Figura 26 mostra la struttura di questo DataObject. Esso contiene solo un DataAdapter che è responsabile della gestione delle informazioni riguardanti i clienti. Figura 26 Esempio di DataObject La parte più interessante è contenuta nel codice alla base del DataObject. Il seguente blocco di codice mostra esattamente come dovrebbe essere il codice riguardante un DataObject. Il DataObject deve essere marcato con l attributo DataObject, estendere la classe BaseDoObject e mappare ogni DataAdapter con il comando corrispondente. L ultima operazione da effettuare, per poter rendere il DataObject più generale possibile, è la chiamata al metodo SetCOnnectionString definita nella classe BaseDoObject. Questo metodo consente di ottenere la stringa di connessione da un file di configurazione. In questo modo si evita di integrare la Pag. 47 di 55

48 stringa di connessione nel codice sorgente e in caso di cambio di tale stringa non sarà necessario ricompilare l intera applicazione ma solamente sostituire la vecchia stringa con la nuova. //Code Architects References using Attributes = CodeArchitects.EnterprisePlatform.Attributes; // AdventureWorks References using Commands = CodeArchitects.AdventureWorks.Server.Contracts.Constants.Comma nds; using CodeArchitects.AdventureWorks.Server.Contracts.Constants; [Attributes.DataObject(ServiceName = Data.DataSales)] public partial class DoSales : BaseDoObject { //Constructors /// <summary> /// Default constructor. /// </summary> public DoSales() : base() { InitializeComponent(); MapDataAdapter(Commands.Sales.CmdIndividualCustomers, DaIndividualCustomers);... base.setconnectionstring(); } /// <summary> /// DoSales constructor. /// </summary> /// <param name="container"></param> public DoSales(IContainer container) : this() { container.add(this); } } Esempio 5 Codice del DataObject di esempio Pag. 48 di 55

49 Façades Gli oggetti Façade contengono un insieme di API in un unica classe. Questa classe fornisce tutte le caratteristiche relative ad un servizio. Ogni oggetto Façade implementa la corrispondente interfaccia definita nei Contracts. Poiché ogni assebly dei Contracts è condiviso tra clients e servers, ogni client ha la possibilità di trovare un servizio cercando semplicemente la relativa interfaccia mediante il metodo statico Find. Una volta trovato il servizio, l client può farne uso come se fosse implementato localmente. Questo approccio semplifica enormemente il processo di ricerca e di utilizzo dei servizi. Esso velocizza l implementazione dell architettura SOA nascondendo la maggior parte della complessità relativa a questo tipo di pattern architetturali. /// <summary> /// Façade class implementation. /// </summary> [Attributes.BusinessFacade(ServiceName = Facade.FacSales)] class FacSales : BusinessFacade, IFacSales { public DsAdventureWorks GetIndividualCustomers() { DsAdventureWorks dsadventureworks = null; try { dsadventureworks = DataObject.Find(Data.DataSales).Get( typeof(dsadventureworks), new CommandSelectHint(Commands.Sales.CmdIndividualCustomers) ) as DsAdventureWorks; } catch (Exception ex) { // Exceptions handling. } return dsadventureworks; }... } Esempio 6 Esempio di oggetto Façade Pag. 49 di 55

50 Il codice sopra riportato mostra un oggetto Business Façade che espone un servizio il cui nome è compreso nella costante Façade.FacSales. Esso implementa un contratto software di tipo IfacSales. In fase di esecuzione, sarà possible istanziare questo oggetto attraverso un metodo generico statico Find semplicemente ricercando il nome del servizio. Il blocco di codice riportato di seguito mostra come sia possibile istanziare un oggetto Façade in fase di esecuzione da un client. // Dataset used by this application. DsAdventureWorks dsadventureworks = null; // Instantiate the sales facade. using (IFacSales facade = BusinessFacade.Find<IFacSales>(Facade.FacSales)) { if (facade!= null) { dsadventureworks = facade.getindividualcustomers(); } } Esempio 7 Esempio di istanziazione dell'oggetto Façade Il metodo generico statico Find permette di instanziare un oggetto Façade che implementa l interfaccia IfacSales. Per poter trovare l oggetto desiderato basta ricercarlo utilizzando il suo nome contenuto nella costante Façade.FacSales. Poiché questa costante è contenuta nei contracts condivisi fra client e server, qualsiasi cambiamento al suo valore non influenzerà in alcun modo l applicazione client. Pag. 50 di 55

51 3. Semantic Web Service Oriented Platform Semantic Web Service Oriented Platform (SWOP) è un progetto di ricerca industriale basato su un programma di sviluppo sperimentale che si prefigge lo scopo di abilitare la piattaforma all annotazione semantica dei Web Services. Il fine è quello di rendere possibile l automazione della operazione di discovery dei Web Services ed estendere il CAESP con una metodologia e librerie di supporto allo sviluppo dei semantic web services. A supporto di tale metodologia verranno implementate delle estensioni (add-in) dell IDE di sviluppo Microsoft Vistual Studio Figura 27 Architettura si SWOP 3.1 Sviluppo di Semantic Web Services Il framework SWOP impone, per lo sviluppo di semantic web services, un processo di sviluppo costituito da due macro-step: - WSD - Web Service Development: Consiste nello sviluppare un web service con il CAESP; - WSA Web Service Annotation: Consiste nel trasformare il web service in un semantic web service mediante un processo di annotazione semantica: Pag. 51 di 55

52 Natural Language Description (NLD): Ad ogni web service deve essere associata una descrizione in linguaggio naturale, che descriva le funzionalità offerte dal web service. Tale operazione deve essere replicata anche per ogni singolo metodo del web service, questo al fine di descrivere la logica funzionale del metodo. Semantic Annotation Process (SAP): Il processo di annotazione semantica permette di generare annotazioni semantiche scritte in un linguaggio compliant al Semantic Web sfruttando un ontologia (SWOP-Ontology). Nel processo SAP è prevista l integrazione di tecniche per il Natural Language Processing (NLP). Repository of Semantic web service annotations (SWSA-R): Le annotazioni semantiche legate al web service sono pubblicate in un repository. Figura 28 Web Service Development & Annotation 3.2 Discovery e Selection di Semantic Web Services Il processo di discovery e selection di semantic web services si compone di due step: Discovery Process: Il processo di discovery impone la composizione, da parte dell utente, di una query semantica, ed infine una operazione di discovery nel repository SWSA-R. Selection Process: Il risultato del processo di discovery fornisce come output una lista di web services che soddisfano la query. La lista di output viene quindi presentata all utente mediante un interfaccia utente (Il processo di selezione è demandato all utente). Pag. 52 di 55

53 3.3 Componenti del Framework SWOP L infrastruttura di un ambiente SWOP è composta da: - Annotator Service: Servizio di supporto all annotazione semantica. - Discovery Service: Servizio di supporto al discovery dei Semantic Web Services. - SWOP-Ontology: Ontologia SWOP. - SWS Annotations Repository: Repository delle annotazione semantiche dei web services. Figura 29 Componenti del Framework SWOP Di seguito sono riportate delle tabelle riassuntive delle componenti software e metodologie da realizzare nel corso del progetto SWOP. Natural Language Description Attività Definizione di una metodologia per la descrizione in linguaggio naturale dei Web Services e dei relativi metodi. Piano di lavoro Nessuna operazione prevista in quanto la documentazione verrà implementata nel codice mediante l uso di tag xml, pertanto al momento non è previsto lo sviluppo di alcuna componente. Pag. 53 di 55

54 Semantic Annotation Process Attività Selezione ed evoluzione di una ontologia esistente per Semantic Web Services. Definizione del processo di annotazione semantica. Piano di lavoro Ricerca di una ontologia esistente da usare come base di partenza. Evoluzione dell ontologia selezionata. Definizione della metodologia di annotazione semantica. Sviluppo delle componenti e dei servizi di supporto a tale metodologia. Definizione del repository delle annotazioni semantiche e delle componenti di supporto all accesso e manipolazione dello stesso. Scegliere il formato/tecnologia e specifiche del repository. Implementare le componenti e i servizi per l accesso e la manipolazione del repository. Discovery Process Attività Selezione di un linguaggio utile ad esprimere query per il processo di discovery. Definire uno strumento per comporre le query semantiche. Implementare un engine per il discovery dei Web Services. Piano di lavoro Studio dello stato dell arte. Definizione del linguaggio di query. Sviluppo di un API di supporto alla composizione delle query semantiche. Studio dello stato dell arte e selezione di componenti da riusare nell engine di discovery. Implementare l engine per il processo di discovery. Pag. 54 di 55

55 3.4 Architettura del Framework SWOP L applicazione software che si intende realizzare prevede lo sviluppo sia del framework di base che di toolkit e servizi di base: - SWOP Framework: Rappresenta il framework di base ed è costituito da: Base Class Library: Insieme delle librerie di base del framework. Discovery Library: Librerie di supporto al processo di discovery. Semantic Annotation Library: Libreria di supporto all annotazione semantica. - Discovery Service: Servizio Web per il discovery. - Annotator Service: Servizio Web per l annotazione semantica. - SWOP Development Studio: IDE per lo sviluppo di Semantic Web Service. - SWOP Toolkit: Add-in Visual Studio per lo sviluppo di Semantic Web Services. - Deployment Toolkit: Toolkit per configurazione e deployment di un ambiente SWOP. Figura 30 Architettura del Framework SWOP Pag. 55 di 55

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

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

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

MAX DOLGICER SOI. (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES

MAX DOLGICER SOI. (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER SOI (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES ROMA 27-29 MAGGIO 2009 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

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. 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

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

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER EAI Architetture, Tecnologie e Best Practices ROMA 26-28 MARZO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT ROMA 23-25 GIUGNO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA Service Oriented Architecture Ormai tutti, nel mondo dell IT, conoscono i principi di SOA e i benefici che si possono ottenere

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

MAX DOLGICER ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

MAX DOLGICER ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER Architettura, Governance, Standards e Tecnologie Modellare, progettare e implementare applicazioni ROMA 17-19 NOVEMBRE 2008 ROMA 20-21 NOVEMBRE 2008 VISCONTI

Dettagli

Come prepararsi concretamente alla SOA: dallo studio di fattibilita' all'integrazione dei sistemi

Come prepararsi concretamente alla SOA: dallo studio di fattibilita' all'integrazione dei sistemi interpreta le TECNOLOGIE sul mercato interagisce con il CLIENTE innova i PROCESSI tecnologici del cliente istruisce con percorsi di SKILL TRANSFER informa con MOKABYTE.it Come prepararsi concretamente

Dettagli

Quando SOA incontra l'enterprise 2.0 Alcune linee guida

Quando SOA incontra l'enterprise 2.0 Alcune linee guida Quando SOA incontra l'enterprise 2.0 Alcune linee guida Agenda SOA e Enterprise 2.0 Definizione di SOA Reference Model e Reference Architecture Architettura di integrazione SOA 10 Best Practices per l'introduzione

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

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

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

MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

E.S.B. Enterprise Service Bus ALLEGATO C11

E.S.B. Enterprise Service Bus ALLEGATO C11 E.S.B. Enterprise Service Bus ALLEGATO C11 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

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

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

Marco Salvato, KPMG. AIEA Verona 25.11.2005

Marco Salvato, KPMG. AIEA Verona 25.11.2005 Information Systems Governance e analisi dei rischi con ITIL e COBIT Marco Salvato, KPMG Sessione di studio AIEA, Verona 25 Novembre 2005 1 Information Systems Governance L'Information Systems Governance

Dettagli

Università della Calabria

Università della Calabria Università della Calabria Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Dipartimento DEIS TESI DI LAUREA Sviluppo di un sistema per la configurazione della rete UTRAN tramite un Enterprise

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

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

Innovazione. Tecnologia. Know How

Innovazione. Tecnologia. Know How > Presentazione FLAG Consulting S.r.L. Innovazione. Tecnologia. Know How SOMMARIO 01. Profilo aziendale 02. Gestione Documentale 03. Enterprise Document Platform 01. Profilo aziendale Il partner ideale

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali

Università degli studi dell Aquila. Sistemi informativi aziendali Università degli studi dell Aquila 6 C.F.U. 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti Web Information System. La

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

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

L iniziativa Cloud DT

L iniziativa Cloud DT L iniziativa Cloud DT Francesco Castanò Dipartimento del Tesoro Ufficio per il Coordinamento Informatico Dipartimentale (UCID) Roma, Luglio 2011 Il Cloud Computing Alcune definizioni Il Cloud Computing

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

Le nuove soluzioni in risposta alle esigenze delle imprese

Le nuove soluzioni in risposta alle esigenze delle imprese Le nuove soluzioni in risposta alle esigenze delle imprese Giuseppe Troncone Partner, Business Consulting Service Financial Services Sector Leader IBM Italia Il Modello competitivo del mercato Corporate

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

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

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

Eclipse Day 2010 in Rome

Eclipse Day 2010 in Rome Living IT Architectures Open Source per la realizzazione del modello XaaS www.spagoworld.org/openevents Engineering Engineering Group: Group: nuovo nuovo approccio approccio per per progetti progetti di

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

Stefano Bucci Technology Director Sales Consulting. Roma, 23 Maggio 2007

Stefano Bucci Technology Director Sales Consulting. Roma, 23 Maggio 2007 L Information Technology a supporto delle ALI: Come coniugare un modello di crescita sostenibile con le irrinuciabili caratteristiche di integrazione, sicurezza ed elevata disponibilità di un Centro Servizi

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014 Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II SOA e Web Service Figure tratte dal testo di riferimento, Copyright

Dettagli

Stefano Mainetti Fondazione Politecnico di Milano

Stefano Mainetti Fondazione Politecnico di Milano Quale Roadmap per il Cloud Computing? Stefano Mainetti Fondazione Politecnico di Milano stefano.mainetti@fondazione.polimi.it La definizione classica del Cloud Computing 4 modelli di deployment Cloud private

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

Il Cloud Computing: uno strumento per migliorare il business

Il Cloud Computing: uno strumento per migliorare il business Il Cloud Computing: uno strumento per migliorare il business Luca Zanetta Uniontrasporti I venti dell'innovazione - Imprese a banda larga Varese, 9 luglio 2014 1 / 22 Sommario Cos è il cloud computing

Dettagli

primario progettare best-of-the- i in: Semplificazione SCENARIO all interno del Reply www.reply.eu

primario progettare best-of-the- i in: Semplificazione SCENARIO all interno del Reply www.reply.eu IL PROGETTO INFOBUS Fattori qualificanti della nuova infrastruttura sono identificat i in: Governance E2E dei processi di integrazionee Semplificazione dei processi di integrazione Allineamento ai processi

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA TUTTO SUL ROMA 17-19 OTTOBRE 2011 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

LA TECHNOLOGY TRANSFER PRESENTA TUTTO SUL ROMA 17-19 OTTOBRE 2011 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA GERHARD BAYER TUTTO SUL CLOUD COMPUTING Concetti, Attori, Tecnologie ROMA 17-19 OTTOBRE 2011 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Corso di Sistemi di elaborazione delle informazioni

Corso di Sistemi di elaborazione delle informazioni Corso di Sistemi di elaborazione delle informazioni Biacco Sabrina ENTERPRISE RESOURCE PLANNING Gli ERP sono delle soluzioni applicative in grado di coordinare l'insieme delle attività aziendali automatizzando

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA MIKE ROSEN ROMA 26-27 APRILE 2011 ROMA 28-29 APRILE 2011 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

LA TECHNOLOGY TRANSFER PRESENTA MIKE ROSEN ROMA 26-27 APRILE 2011 ROMA 28-29 APRILE 2011 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA MIKE ROSEN ALLINEARE BUSINESS E IT Un approccio Business Architecture PROGETTARE MODERNE ARCHITETTURE APPLICATIVE ROMA 26-27 APRILE 2011 ROMA 28-29 APRILE 2011 RESIDENZA

Dettagli

GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI

GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI Già da un certo tempo le architetture orientate ai servizi (SOA) hanno assicurato alle aziende un supporto di considerevole

Dettagli

L'impatto della flessibilità sull'infrastruttura tecnologica. Luca Amato IT Architect, Global Technology Services, IBM Italia

L'impatto della flessibilità sull'infrastruttura tecnologica. Luca Amato IT Architect, Global Technology Services, IBM Italia L'impatto della flessibilità sull'infrastruttura tecnologica Luca Amato IT Architect, Global Technology Services, IBM Italia La mia infrastruttura... Supporterà la SOA? Sarà ottimizzata dalla SOA? Che

Dettagli

Organization Intelligence: Approccio e Tecnologia

Organization Intelligence: Approccio e Tecnologia Organization Intelligence: Approccio e Tecnologia [Knowledge] «In organizations it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices

Dettagli

JOHN KNEILING. Tools, Tecnologie NELL AMBIENTE LA TECHNOLOGY TRANSFER PRESENTA ROMA 19-21 MAGGIO 2008 ROMA 22-23 MAGGIO 2008

JOHN KNEILING. Tools, Tecnologie NELL AMBIENTE LA TECHNOLOGY TRANSFER PRESENTA ROMA 19-21 MAGGIO 2008 ROMA 22-23 MAGGIO 2008 LA TECHNOLOGY TRANSFER PRESENTA JOHN KNEILING WEB SERVICES E Tools, Tecnologie e Architetture SICUREZZA NELL AMBIENTE ROMA 19-21 MAGGIO 2008 ROMA 22-23 MAGGIO 2008 VISCONTI PALACE HOTEL - VIA FEDERICO

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

LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER IL NUOVO MANIFESTO DELL INTEGRAZIONE APPLICAZIONI, DATI, CLOUD, MOBILE E INTERNET OF THINGS

LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER IL NUOVO MANIFESTO DELL INTEGRAZIONE APPLICAZIONI, DATI, CLOUD, MOBILE E INTERNET OF THINGS LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER IL NUOVO MANIFESTO DELL INTEGRAZIONE APPLICAZIONI, DATI, CLOUD, MOBILE E INTERNET OF THINGS ROMA 10-11 DICEMBRE 2015 RESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

Abstract. Reply e il Cloud Computing: la potenza di internet e un modello di costi a consumo. Il Cloud Computing per Reply

Abstract. Reply e il Cloud Computing: la potenza di internet e un modello di costi a consumo. Il Cloud Computing per Reply Abstract Nei nuovi scenari aperti dal Cloud Computing, Reply si pone come provider di servizi e tecnologie, nonché come abilitatore di soluzioni e servizi di integrazione, volti a supportare le aziende

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

IT ARCHITECTURE: COME PREPARARSI AL CLOUD

IT ARCHITECTURE: COME PREPARARSI AL CLOUD IT ARCHITECTURE: COME PREPARARSI AL CLOUD Stefano Mainetti stefano.mainetti@polimi.it L ICT come Commodity L emergere del Cloud Computing e i nuovi modelli di delivery Trend n. 1 - ICT Commoditization

Dettagli

Corso Sviluppatore servizi per il Web (WCF) Lezione 01

Corso Sviluppatore servizi per il Web (WCF) Lezione 01 01 Introduzione Introduzione alla tecnologia WCF Premessa Il corso su WCF di cui state leggendo la prima lezione, vi guiderà alla scoperta di questa nuova tecnologia introdotta da Microsoft per venire

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

Collaborative business application: l evoluzione dei sistemi gestionali Tra cloud, social e mobile

Collaborative business application: l evoluzione dei sistemi gestionali Tra cloud, social e mobile Osservatorio Cloud & ICT as a Service Collaborative business application: l evoluzione dei sistemi gestionali Tra cloud, social e mobile Mariano Corso Stefano Mainetti 17 Dicembre 2013 Collaborative Business

Dettagli

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

SisTabWeb Web. Sistema Tabelle. for Enterprise

SisTabWeb Web. Sistema Tabelle. for Enterprise SisTabWeb Web Sistema Tabelle for Enterprise Overview La condivisione del patrimonio dati a livello aziendale diventa essenziale nel momento in cui il sistema informativo, elemento chiave per l'efficienza

Dettagli

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 SOA e MES Un white paper - 2006-2007 Santin e Associati http://www.santineassociati.com 2 MES E SOA SOA (Services Oriented Architecture)

Dettagli

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI

ALLEGATO 8.1 DESCRIZIONE PROFILI PROFESSIONALI PROCEDURA DI SELEZIONE PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, ANALISI, SVILUPPO, MANUTENZIONE ADEGUATIVA, CORRETTIVA ED EVOLUTIVA DI SISTEMI INFORMATIVI SU PIATTAFORMA IBM WEBSPHERE BPM (EX LOMBARDI)

Dettagli

Master sull Interoperabilità nella Pubblica Amministrazione e nelle Imprese

Master sull Interoperabilità nella Pubblica Amministrazione e nelle Imprese Il Master di secondo livello in "Interoperabilità per la Pubblica Amministrazione e le Imprese" mira a formare professionisti di sistemi di e-government in grado di gestirne aspetti tecnologici, normativi,

Dettagli

Alessandro Huber Chief Technology Officer, Microsoft Italia Claudia Angelelli Service Line Manager, Microsoft Italia

Alessandro Huber Chief Technology Officer, Microsoft Italia Claudia Angelelli Service Line Manager, Microsoft Italia Alessandro Huber Chief Technology Officer, Microsoft Italia Claudia Angelelli Service Line Manager, Microsoft Italia Contenimento dei costi di gestione Acquisizioni/ merge Rafforzare la relazione con

Dettagli

Processo di sviluppo in SECSERVIZI: la metodologia JMC. Versione 1.0 Eclipse-IT 2010 Savona, 30/9/2010

Processo di sviluppo in SECSERVIZI: la metodologia JMC. Versione 1.0 Eclipse-IT 2010 Savona, 30/9/2010 o di sviluppo in SECSERVIZI: la metodologia JMC Versione 1.0 Eclipse-IT 2010 Savona, 30/9/2010 Agenda Premessa ed obiettivi Che cos è JMC Architettura e Tools JMC Il Desktop di Filiale -2- Premessa ed

Dettagli

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

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Ricca - Divisione I.T.

Ricca - Divisione I.T. Ricca - Divisione I.T. Information Technology & Security Partner Profilo B.U. e Offerta Servizi Ricca Divisione I.T. Information Technology & Security Partner La Mission La nostra missione è divenire il

Dettagli

Sistemi di BPM su Cloud per la flessibilità delle PMI

Sistemi di BPM su Cloud per la flessibilità delle PMI Sistemi di BPM su Cloud per la flessibilità delle PMI Marco Brambilla, WebRatio e Politecnico di Milano ComoNEXT Lomazzo, 14 Novembre 2012 Dall esigenza Flessibilità del business Risposta immediata ai

Dettagli

GoCloud just google consulting

GoCloud just google consulting La visione Cloud di Google: cosa cambia per i profili tecnici? GoCloud just google consulting Workshop sulle competenze ed il lavoro degli IT Systems Architect Vincenzo Gianferrari Pini

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l.

2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011. Andrea Carnevali R&D Director GESINF S.r.l. 2G, l evoluzione della piattaforma Team nel Web 2.0 Roma, 7 dicembre 2011 Andrea Carnevali R&D Director GESINF S.r.l. Il progetto 2G è il nome della piattaforma che consentirà l evoluzione tecnologica

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

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi

Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Soluzioni per la gestione di risorse e servizi A supporto dei vostri obiettivi di business Ottimizzate i processi IT, massimizzate il ROA (return on assets) e migliorate il livello dei servizi Utilizzate

Dettagli

L architettura di rete FlexNetwork

L architettura di rete FlexNetwork HP L offerta di soluzioni e servizi per il networking di HP si inserisce nella strategia che concorre a definire la visione di una Converged Infrastructure, pensata per abilitare la realizzazione di data

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

Nell'era della Business Technology: il business e la tecnologia allineati per migliorare i risultati dell'azienda

Nell'era della Business Technology: il business e la tecnologia allineati per migliorare i risultati dell'azienda Nell'era della Business Technology: il business e la tecnologia allineati per migliorare i risultati dell'azienda Giovanni Vecchio Marketing Program Manager - Hewlett Packard Italiana S.r.l. Treviso, 13

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o Navigare verso il cambiamento La St r a d a p i ù semplice verso il ca m b i a m e n t o Le caratteristiche tecniche del software La Tecnologia utilizzata EASY è una applicazione Open Source basata sul

Dettagli

(Service o Oriented Architecture)

(Service o Oriented Architecture) L Parliamo di SOA (Service o Oriented Architecture) Antonio Pintus, Marco Marongiu 1 Chi siamo Antonio Pintus è laureato in Informatica e studente di Dottorato di Ricerca in Informatica con argomenti relativi

Dettagli

Web services. 25/01/10 Web services

Web services. 25/01/10 Web services Web services Tecnologia per il computing distribuito standard W3C non dissimile da RMI, CORBA, EJB... Relazione con il Web Websites for humans, Web Services for software :-) un Web service ha un indirizzo

Dettagli

L intercanalità in Findomestic: l agilità bancaria raggiunta tramite le tecnologie informatiche: SOA e BPM

L intercanalità in Findomestic: l agilità bancaria raggiunta tramite le tecnologie informatiche: SOA e BPM gg.mm.aa L intercanalità in Findomestic: l agilità bancaria raggiunta tramite le tecnologie informatiche: SOA e BPM Antonello Rossi Responsabile evoluzioni applicative e DWH Silvano Laurenti Direttore

Dettagli

Progettare, sviluppare e gestire seguendo la Think it easy philosophy

Progettare, sviluppare e gestire seguendo la Think it easy philosophy Progettare, sviluppare e gestire seguendo la Think it easy philosophy CST Consulting è una azienda di Consulenza IT, System Integration & Technology e Servizi alle Imprese di respiro internazionale. E

Dettagli

Applicazione: Piattaforma di Comunicazione Unificata

Applicazione: Piattaforma di Comunicazione Unificata Riusabilità del software - Catalogo delle applicazioni: Amministrativi/Contabile Applicazione: Piattaforma di Comunicazione Unificata Amministrazione: Regione Piemonte - Direzione Innovazione, Ricerca

Dettagli

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2 DIB 1 Sommario Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 2 Architettura a 3 Livelli DIB 3 Architettura a 3 Livelli Presentazione Gestione dell interazione degli

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

Introduzione a SOA. Il Gap tra IT e Business

Introduzione a SOA. Il Gap tra IT e Business Introduzione a SOA Information Systems Design Il Gap tra IT e Business I Servizi hanno a che fare con entrambi i mondi Process modeling Business analysis & modeling modeling Enterprise IT concerns Function

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA GERHARD LO SVILUPPO APPLICATIVO NELL ERA DEL CLOUD E DEL MOBILE

LA TECHNOLOGY TRANSFER PRESENTA GERHARD LO SVILUPPO APPLICATIVO NELL ERA DEL CLOUD E DEL MOBILE LA TECHNOLOGY TRANSFER PRESENTA GERHARD BAYER LO SVILUPPO APPLICATIVO NELL ERA DEL CLOUD E DEL MOBILE ROMA 4-5 NOVEMBRE 2015 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

Corso Base ITIL V3 2008

Corso Base ITIL V3 2008 Corso Base ITIL V3 2008 PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it L informazione come risorsa strategica Nelle aziende moderne l informazione

Dettagli

RRF Reply Reporting Framework

RRF Reply Reporting Framework RRF Reply Reporting Framework Introduzione L incremento dei servizi erogati nel campo delle telecomunicazioni implica la necessità di effettuare analisi short-term e long-term finalizzate a tenere sotto

Dettagli

Introduzione a SOA. Il Gap tra IT e Business

Introduzione a SOA. Il Gap tra IT e Business Introduzione a SOA Information Systems Design Il Gap tra IT e Business I Servizi hanno a che fare con entrambi i mondi Process modeling Business analysis & modeling Component modeling Enterprise IT concerns

Dettagli

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli