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