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

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

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

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

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

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

La collaborazione come strumento per l'innovazione.

La collaborazione come strumento per l'innovazione. La collaborazione come strumento per l'innovazione. Gabriele Peroni Manager of IBM Integrated Communication Services 1 La collaborazione come strumento per l'innovazione. I Drivers del Cambiamento: Le

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Milano, Settembre 2009 BIOSS Consulting

Milano, Settembre 2009 BIOSS Consulting Milano, Settembre 2009 BIOSS Consulting Presentazione della società Agenda Chi siamo 3 Cosa facciamo 4-13 San Donato Milanese, 26 maggio 2008 Come lo facciamo 14-20 Case Studies 21-28 Prodotti utilizzati

Dettagli

CORPORATE OVERVIEW. www.akhela.com

CORPORATE OVERVIEW. www.akhela.com CORPORATE OVERVIEW www.akhela.com BRIDGE THE GAP CORPORATE OVERVIEW Bridge the gap Akhela è un azienda IT innovativa che offre al mercato servizi e soluzioni Cloud Based che aiutano le aziende a colmare

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Rational Unified Process Introduzione

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

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese CMMI-Dev V1.3 Capability Maturity Model Integration for Software Development, Version 1.3 Roma, 2012 Agenda Che cos è il CMMI Costellazione di modelli Approccio staged e continuous Aree di processo Goals

Dettagli

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it

Profilo Aziendale ISO 9001: 2008. METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it ISO 9001: 2008 Profilo Aziendale METISOFT spa - p.iva 00702470675 - www.metisoft.it - info@metisoft.it Sede legale: * Viale Brodolini, 117-60044 - Fabriano (AN) - Tel. 0732.251856 Sede amministrativa:

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

IT Service Management, le best practice per la gestione dei servizi

IT Service Management, le best practice per la gestione dei servizi Il Framework ITIL e gli Standard di PMI : : possibili sinergie Milano, Venerdì, 11 Luglio 2008 IT Service Management, le best practice per la gestione dei servizi Maxime Sottini Slide 1 Agenda Introduzione

Dettagli

BPEL: Business Process Execution Language

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

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA SAP World Tour 2007 - Milano 11-12 Luglio 2007 THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA Agenda Presentazione Derga Consulting Enterprise SOA Allineamento Processi & IT Il

Dettagli

IBM UrbanCode Deploy Live Demo

IBM UrbanCode Deploy Live Demo Dal 1986, ogni giorno qualcosa di nuovo Marco Casu IBM UrbanCode Deploy Live Demo La soluzione IBM Rational per il Deployment Automatizzato del software 2014 www.gruppoconsoft.com Azienda Nata a Torino

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Enterprise Services Infrastructure ESI 2.0

Enterprise Services Infrastructure ESI 2.0 Enterprise Services Infrastructure ESI 2.0 Caratteristiche e Posizionamento ver. 2.1 del 21/01/2013 Cos è ESI - Enterprise Service Infrastructure? Cos è ESI? ESI (Enteprise Service Infrastructure) è una

Dettagli

IT Service Management

IT Service Management IT Service Management ITIL: I concetti chiave ed il livello di adozione nelle aziende italiane Matteo De Angelis, itsmf Italia (I) 1 Chi è itsmf italia 12 th May 2011 - Bolzano itsmf (IT Service Management

Dettagli

B.P.S. Business Process Server ALLEGATO C10

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

Dettagli

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

Dettagli

PASSIONE PER L IT PROLAN. network solutions

PASSIONE PER L IT PROLAN. network solutions PASSIONE PER L IT PROLAN network solutions CHI SIAMO Aree di intervento PROFILO AZIENDALE Prolan Network Solutions nasce a Roma nel 2004 dall incontro di professionisti uniti da un valore comune: la passione

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e'

ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il continuous improvement ed e' ITIL v3 ITIL v3 e' parte di un processo teso a migliorare le best practices ITIL. In effetti, ITIL predica il "continuous improvement" ed e' giusto che lo applichi anche a se' stessa... Naturalmente una

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

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

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI?

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? Le offerte di public cloud proliferano e il private cloud è sempre più diffuso. La questione ora è come sfruttare

Dettagli

progettiamo e realizziamo architetture informatiche Company Profile

progettiamo e realizziamo architetture informatiche Company Profile Company Profile Chi siamo Kammatech Consulting S.r.l. nasce nel 2000 con l'obiettivo di operare nel settore I.C.T., fornendo servizi di progettazione, realizzazione e manutenzione di reti aziendali. Nel

Dettagli

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT Executive Master in Governance dei Progetti e dei Servizi IT GPSIT OBIETTIVI Il Master ha l obiettivo di formare executive e professional nella governance dei progetti e dei servizi IT, integrando quelle

Dettagli

EMC Documentum xcp for Business Process Management

EMC Documentum xcp for Business Process Management Analisi dettagliata Abstract Oggi le aziende devono affrontare una sfida comune: ottimizzare i processi di business e la loro efficienza operativa. Per vincere questa sfida, EMC Documentum xcelerated Composition

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

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

Dettagli

PMI. Management Maturity Model, OPM3 Second Edition 2008

PMI. Management Maturity Model, OPM3 Second Edition 2008 Nuovi standard PMI, certificazioni professionali e non solo Milano, 20 marzo 2009 PMI Organizational Project Management Maturity Model, OPM3 Second Edition 2008 Andrea Caccamese, PMP Prince2 Practitioner

Dettagli

DigitPA egovernment e Cloud computing

DigitPA egovernment e Cloud computing DigitPA egovernment e Cloud computing Esigenze ed esperienze dal punto di vista della domanda RELATORE: Francesco GERBINO 5 ottobre 2010 Agenda Presentazione della Società Le infrastrutture elaborative

Dettagli

Completezza funzionale KEY FACTORS Qualità del dato Semplicità d'uso e controllo Tecnologie all avanguardia e stabilità Integrabilità

Completezza funzionale KEY FACTORS Qualità del dato Semplicità d'uso e controllo Tecnologie all avanguardia e stabilità Integrabilità Armundia Group è un azienda specializzata nella progettazione e fornitura di soluzioni software e consulenza specialistica per i settori dell ICT bancario, finanziario ed assicurativo. Presente in Italia

Dettagli

Realizzare un architettura integrata di Business Intelligence

Realizzare un architettura integrata di Business Intelligence Realizzare un architettura integrata di Business Intelligence Un sistema integrato di Business Intelligence consente all azienda customer oriented una gestione efficace ed efficiente della conoscenza del

Dettagli

ITIL. Introduzione. Mariosa Pietro

ITIL. Introduzione. Mariosa Pietro ITIL Introduzione Contenuti ITIL IT Service Management Il Servizio Perchè ITIL ITIL Service Management life cycle ITIL ITIL (Information Technology Infrastructure Library) è una raccolta di linee guida,

Dettagli

IT Service Management

IT Service Management IT Service Management L'importanza dell'analisi dei processi nelle grandi e medie realtà italiane Evento Business Strategy 2.0 Firenze 25 settembre 2012 Giovanni Sadun Agenda ITSM: Contesto di riferimento

Dettagli

STS. Profilo della società

STS. Profilo della società STS Profilo della società STS, Your ICT Partner Con un solido background accademico, regolari confronti con il mondo della ricerca ed esperienza sia nel settore pubblico che privato, STS è da oltre 20

Dettagli

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Data Sheet IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Panoramica Le medie aziende devono migliorare nettamente le loro capacità

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

Business Process Management

Business Process Management Business Process Management Come si organizza un progetto di BPM 1 INDICE Organizzazione di un progetto di Business Process Management Tipo di intervento Struttura del progetto BPM Process Performance

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

Storia ed evoluzione dei sistemi ERP

Storia ed evoluzione dei sistemi ERP Storia ed evoluzione dei sistemi ERP In questo breve estratto della tesi si parlerà dei sistemi ERP (Enterprise Resource Planning) utilizzabili per la gestione delle commesse; questi sistemi utilizzano

Dettagli

Pronti per la Voluntary Disclosure?

Pronti per la Voluntary Disclosure? Best Vision GROUP The Swiss hub in the financial business network Pronti per la Voluntary Disclosure? Hotel de la Paix, 21 aprile 2015, ore 18:00 Hotel Lugano Dante, 22 aprile 2015, ore 17:00 Best Vision

Dettagli

RedDot Content Management Server Content Management Server Non sottovalutate il potenziale della comunicazione online: usatela! RedDot CMS vi permette di... Implementare, gestire ed estendere progetti

Dettagli

PROFILI ALLEGATO A. Profili professionali

PROFILI ALLEGATO A. Profili professionali ALLEGATO A Profili professionali Nei profili di seguito descritti vengono sintetizzate le caratteristiche di delle figure professionali che verranno coinvolte nell erogazione dei servizi oggetto della

Dettagli

Il business risk reporting: lo. gestione continua dei rischi

Il business risk reporting: lo. gestione continua dei rischi 18 ottobre 2012 Il business risk reporting: lo strumento essenziale per la gestione continua dei rischi Stefano Oddone, EPM Sales Consulting Senior Manager di Oracle 1 AGENDA L importanza di misurare Business

Dettagli

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix I veri benefici dell Open Source nell ambito del monitoraggio IT Georg Kostner, Department Manager Würth Phoenix IT Service secondo ITIL Il valore aggiunto dell Open Source Servizi IT Hanno lo scopo di

Dettagli

Microsoft Innovation Center Roma. Pierluigi Del Nostro Stefano Paolozzi Maurizio Pizzonia

Microsoft Innovation Center Roma. Pierluigi Del Nostro Stefano Paolozzi Maurizio Pizzonia Microsoft Innovation Center Roma Pierluigi Del Nostro Stefano Paolozzi Maurizio Pizzonia Il MIC Roma Cos è Uno dei risultati dei protocolli di intesa tra il Ministero della Pubblica Amministrazione e l

Dettagli

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult KM, ECM e BPM per creare valore nell impresa Giovanni Marrè Amm. Del., it Consult Terminologia Ci sono alcuni termini che, a vario titolo, hanno a che fare col tema dell intervento KM ECM BPM E20 Enterprise

Dettagli

IT Service Management: il Framework ITIL. Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy

IT Service Management: il Framework ITIL. Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy IT Service Management: il Framework ITIL Dalmine, 20 Gennaio 2012 Deborah Meoli, Senior Consultant Quint Italy Quint Wellington Redwood 2007 Agenda Quint Wellington Redwood Italia IT Service Management

Dettagli

IL PROGETTO MINDSH@RE

IL PROGETTO MINDSH@RE IL PROGETTO MINDSH@RE Gruppo Finmeccanica Attilio Di Giovanni V.P.Technology Innovation & IP Mngt L'innovazione e la Ricerca sono due dei punti di eccellenza di Finmeccanica. Lo scorso anno il Gruppo ha

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

Processi ITIL. In collaborazione con il nostro partner: Processi ITIL In collaborazione con il nostro partner: NetEye e OTRS: la piattaforma WÜRTHPHOENIX NetEye è un pacchetto di applicazioni Open Source volto al monitoraggio delle infrastrutture informatiche.

Dettagli

Ottimizzazione della gestione del data center con Microsoft System Center

Ottimizzazione della gestione del data center con Microsoft System Center Ottimizzazione della gestione del data center con Microsoft System Center Declinazione di responsabilità e informazioni sul copyright Le informazioni contenute nel presente documento rappresentano le conoscenze

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Tobia Castaldi Alessandro Amirante Lorenzo Miniero Simon Pietro Romano Giorgio Ventre 02/10/2009 GARR 2009 "Network

Dettagli

MARKETING INTELLIGENCE SUL WEB:

MARKETING INTELLIGENCE SUL WEB: Via Durini, 23-20122 Milano (MI) Tel.+39.02.77.88.931 Fax +39.02.76.31.33.84 Piazza Marconi,15-00144 Roma Tel.+39.06.32.80.37.33 Fax +39.06.32.80.36.00 www.valuelab.it valuelab@valuelab.it MARKETING INTELLIGENCE

Dettagli

CAPITOLO CAPIT Tecnologie dell ecnologie dell info inf rmazione e controllo

CAPITOLO CAPIT Tecnologie dell ecnologie dell info inf rmazione e controllo CAPITOLO 8 Tecnologie dell informazione e controllo Agenda Evoluzione dell IT IT, processo decisionale e controllo Sistemi di supporto al processo decisionale Sistemi di controllo a feedback IT e coordinamento

Dettagli

agility made possible

agility made possible SOLUTION BRIEF CA IT Asset Manager Come gestire il ciclo di vita degli asset, massimizzare il valore degli investimenti IT e ottenere una vista a portfolio di tutti gli asset? agility made possible contribuisce

Dettagli

MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING

MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING MS OFFICE COMMUNICATIONS SERVER 2007 IMPLEMENTING AND MAINTAINING AUDIO/VISUAL CONFERENCING AND WEB CONFERENCING UN BUON MOTIVO PER [cod. E603] L obiettivo del corso è fornire le competenze e conoscenze

Dettagli

Consulenza tecnologica globale

Consulenza tecnologica globale Orientamento al cliente Innovazione Spirito di squadra Flessibilità Un gruppo di professionisti dedicati alle imprese di ogni settore merceologico e dimensione, capaci di supportare il Cliente nella scelta

Dettagli

IBM Cloud Computing - esperienze e servizi seconda parte

IBM Cloud Computing - esperienze e servizi seconda parte IBM Cloud Computing - esperienze e servizi seconda parte Mariano Ammirabile Cloud Computing Sales Leader - aprile 2011 2011 IBM Corporation Evoluzione dei modelli di computing negli anni Cloud Client-Server

Dettagli

Managed Services e Unified Communication & Collaboration: verso il paradigma del Cloud Computing

Managed Services e Unified Communication & Collaboration: verso il paradigma del Cloud Computing Managed Services e Unified Communication & Collaboration: verso il paradigma del Cloud Computing Claudio Chiarenza (General Manager and Chief Strategy Officer) Italtel, Italtel logo and imss (Italtel Multi-Service

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto Scheda descrittiva del programma Open-DAI ceduto in riuso CSI-Piemonte in rappresentanza del Consorzio di progetto Agenzia per l Italia Digitale - Via Liszt 21-00144 Roma Pagina 1 di 19 1 SEZIONE 1 CONTESTO

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com

IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com 2 Tecnoteca è nata nel 2000 con sede a Tavagnacco ha scelto da subito di lavorare

Dettagli

IL RUOLO E LE COMPETENZE DEL SERVICE MANAGER

IL RUOLO E LE COMPETENZE DEL SERVICE MANAGER IL RUOLO E LE COMPETENZE DEL SERVICE MANAGER Alessio Cuppari Presidente itsmf Italia itsmf International 6000 Aziende - 40000 Individui itsmf Italia Comunità di Soci Base di conoscenze e di risorse Forum

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

Curriculum Vitae INFORMAZIONI PERSONALI FARHANG DAREHSHURI, NUSHIN ESPERIENZA LAVORATIVA. Nome. Data di nascita 28 gennaio 1969

Curriculum Vitae INFORMAZIONI PERSONALI FARHANG DAREHSHURI, NUSHIN ESPERIENZA LAVORATIVA. Nome. Data di nascita 28 gennaio 1969 Curriculum Vitae INFORMAZIONI PERSONALI Nome FARHANG DAREHSHURI, NUSHIN Nazionalità Italiana Data di nascita 28 gennaio 1969 Titolo di studio Laurea in Ingegneria Elettronica conseguita presso il politecnico

Dettagli

Servizi di consulenza e soluzioni ICT

Servizi di consulenza e soluzioni ICT Servizi di consulenza e soluzioni ICT Juniortek S.r.l. Fondata nell'anno 2004, Juniortek offre consulenza e servizi nell ambito dell informatica ad imprese e professionisti. L'organizzazione dell'azienda

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

OPEN DAY: ELOCAL GROUP RELOADED

OPEN DAY: ELOCAL GROUP RELOADED L'ingegneria di Elocal Roberto Boccadoro / Luca Zucchelli OPEN DAY: ELOCAL GROUP RELOADED ELOCAL GROUP SRL Chi siamo Giorgio Dosi Lorenzo Gatti Luca Zucchelli Ha iniziato il suo percorso lavorativo in

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO

REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06) ALLEGATO N. 1 CARATTERISTICHE TECNICHE DEL SERVIZIO REGIONE BASILICATA PROCEDURA NEGOZIATA PER L AFFIDAMENTO DEL SERVIZIO DI PROGETTAZIONE, REALIZZAZIONE E GESTIONE DEL SISTEMA INTEGRATO SERB ECM DELLA REGIONE BASILICATA (ART. 125 DEL D.LGS. N. 163/06)

Dettagli

ITIL Versione 3: un contributo all importanza crescente del Business Service Management

ITIL Versione 3: un contributo all importanza crescente del Business Service Management BEST PRACTICES WHITE PAPER ITIL Versione 3: un contributo all importanza crescente del Business Service Management Sharon Taylor, Presidente di Aspect Group, Chief Architect e Chief Examiner per ITIL Ken

Dettagli

Rational Asset Manager, versione 7.1

Rational Asset Manager, versione 7.1 Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Note Prima di utilizzare queste informazioni e il prodotto

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE

PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE PROGRAMMAZIONE ORIENTATA AGLI ASPETTI: SCENARI DI ADOZIONE INDUSTRIALE Il grande successo della programmazione orientata agli oggetti non ha limitato la ricerca di nuovi paradigmi e tecnologie che possano

Dettagli

Sistemi di gestione dei dati e dei processi aziendali. Information Technology General Controls

Sistemi di gestione dei dati e dei processi aziendali. Information Technology General Controls Information Technology General Controls Indice degli argomenti Introduzione agli ITGC ITGC e altre componenti del COSO Framework Sviluppo e manutenzione degli applicativi Gestione operativa delle infrastrutture

Dettagli

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI CSC ritiene che la Business Intelligence sia un elemento strategico e fondamentale che, seguendo

Dettagli