Introduzione
SOA è un paradigma architetturale che investe tutti gli aspetti associati alla definizione di un Information System: architetturali, metodologici, di processo, organizzativi, tecnologici e … culturali.
Negli scorsi articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [MOKA_SOA_I]) sia metodlogico (vedere [MOKA_SOA_II]) .
Abbiamo introdotto inoltre il concetto di Maturity Model (vedere [MOKA_SOA_III]) e spiegato l’importanza di avere una Roadmap che definisca i passi per “traghettare” verso un’architettura full-SOA (vedere [MOKA_SOA_IV]).

Service-Oriented Integration (SOI)
I principi Service Oriented applicati alle problematiche d’integrazione vengono indicati con il termine Service Oriented Integration (SOI). Ponendosi come obiettivo la “rottura” dei Silos, cioè dei sistemi informativi costituiti
da applicazioni verticali e a sé stanti, implicitamente SOA si occupa di Integrazione. SOI definisce quindi i dettami SOA applicati ad un’architettura avente come scopo l’integrazione di applicazioni esistenti mediante servizi. In questo modo le funzionalità non sono più confinate (locked) 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. In sostanza l'obiettivo di SOI è definire i principi architetturali e tecnologici per potere esporre ed integrare applicazioni esistenti come servizi. Creando dei servizi secondo i dettami architetturali di SOA ed esponendo le loro funzionalità su un 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 “Spaghetti Integration” (o Accident Architecture). Come da figura sotto, le funzionalità sono esposte a servizi collegati ad un bus condiviso di comunicazione, quindi non mediante N collegamenti punto-punto. Dal punto di vista architetturale (come si vedrà meglio nei prossimi articoli), 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.

Figura 1: Service Bus: Integrate once, connect many

Per raggiungere il corretto livello di riuso, è ovviamente critica la granularità data ai servizi e la struttura organizzativa a supporto (tematica classica di riuso, indipendente da SOA, ma valida per qualunque scenario). 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 specificità della risorsa.

Un Integration Service ha quindi lo scopo di fornire un’interfaccia a servizi di applicazioni esistenti portando a fattore comune funzionalità trasversali alle applicazioni. 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 utlteriormente 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 Sistem Informativo (in ottica EII). Questo è utile in fase di design, in quanto possono essere seguite le regole di design che abbiamo definito quando si parlava di SOAD (servizi entity-centric vs task-centic), anche se in questo caso non è possibile applicare una metodologia Top-Down.

Figura 2: Data e Functional Integration Service

Gli Integration Services hanno l’obiettivo principe di integrare e differiscono in più aspetti dai Business Services, anche se in taluni casi vengono visti come sinonimi o quantomeno ricadono entrambi sotto un generico termine di ”servizio”. La differenza è che, mentre gli Integration Services si collocano nel layer 2 dello stack SOA (permettono l’accesso alle risorse enterprise del layer 1), i business service sono al layer soprastante perché forniscono l'astrazione del servizio a livello di business.

Figura 3: Integration Service (IS) & Business Services (BS)

Al contrario dei Business Service dove si deve seguire una metodologia di design Top-Down, nel caso di integrazione con funzionalità già sviluppate si segue un approccio Meet-In-The-Middle (vedere [MOKA_SOA_II]). Tale approccio prevede di partire dall'analisi di ciò che è già presente per ottenere dei servizi SOA.

• Si parte da una funzionalità d’interesse di un’applicazione esistente
  
• Si crea un servizio con il compito di interfacciare la funzionalità d’interesse con le opportune API
  
• Si definisce nel service contract il business model da esportare

A supporto di questo procedimento possono essere utilizzati alcuni Pattern che ci permettono di impostare correttamente il design dei servizi SOI.

Il Pattern Service Wrapper
L’intento del pattern Service Wrapper è di fornire un meccanismo per permettere a sistemi/applicazioni/funzioni che non sono service-oriented (es: funzioni Legacy, applicazione packaged come CRM, ERP, stored procedure PL-SQL, …) di poter essere utilizzati da un’architettura SOA.
Lo scopo è quindi di definire un servizio a partire da software già presente. Tutto questo lo si ottiene realizzando un servizio che al suo interno invoca la componente sofware Legacy.

Figura 4: Service Wrapper

Il Service Wrapper è anche conosciuto come Service Adapter (vedere [TPLSOA]).

Il Pattern Service Proxy
L’intento del pattern Service Proxy è di disaccoppiare l’accesso ai servizi di business dai client, nascondendo e centralizzando le operazioni di localizzazione e utilizzo del servizio di business.
Il Service Proxy permette di avere i seguenti vantaggi :

• fornire un’interfaccia uniforme ai client
  
• ridurre l’accoppiamento tra service consumer e service provider
  
• nascondere, centralizzare e gestire le problematiche di reperimento (lookup / discovery) e utilizzo dei servizi
  
• nascondere le particolarità tecnologiche della specifica comunicazione con l’EIS
  
• centralizzare le modifiche derivanti da variazione dei servizi di business in una sola classe
  
• ridurre il numero di interazioni remote fra componenti in comunicazione, con conseguente miglioramento di performance
  
• garantire la possibilità di trasformare eccezioni tecnologiche (es: java.rmi.RemoteException, javax.xml.rpc.ServiceException, …) in eccezioni applicative

Tutto questo lo si ottiene realizzando una classe Java che ha il compito di interfacciare il servizio garantendo un'astrazione dei servizi al client.

Figura 5 : Service Proxy

Il Service Proxy è una specializzazione del pattern Proxy del [GOF] in un contesto a servizi ed è l’analogo del pattern Business Delegate (vedere [MOKA_BD]) applicato ai componenti Enterprise.

Il Pattern Service Locator
La localizzazione dei servizi e la relativa creazione sono operazioni complesse che tipicamente richiedono accessi a risorse di rete.
Il pattern Service Locator gestisce le operazioni dei Servizi occupandosi di :

• “nascondere” la complessità delle operazioni di ricerca (discovery) dei servizi
  
• fornire una modalità uniforme di lookup e 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

Il pattern garantisce una modalità uniforme e semplificata di localizzazione di risorse. Se la modalità di recupero del servizio cambia (es: da punto-punto si decide di inserire l’utilizzo di un Service Registry) è il solo Service Locator che deve essere modificato.

Figura 6: Service Locator

Il Pattern Service Facade
I componenti di business espongono i loro servizi mediante le relative interfacce. Un business tier formato da più business objects (BO) comporta alcuni rischi:

• forte accoppiamento (tight coupling) tra client e i BO
  
• accesso complesso e non uniforme alle risorse di business
  
• problemi di performance sulla rete a causa delle complesse e numerose interazioni client–BO

L’intento del pattern Service Facade è di minimizzare questi problemi, componendo l'accesso ai BO in un servizio con la giusta granularità (coerentemente con i 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
  
• 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 7 : Service Facade

Il pattern individua nel Service Facade il controllore e aggregatore degli elementi che concorrono al servizio.

Il Pattern Virtual Provider
Questo pattern è utile soprattutto nelle situazioni in cui si sta migrando 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).
In questi casi può essere richiesto di sviluppare servizi in modalità “tattica” o servizi per scopo di applicazione pilota o per esigenze pure d’integrazione. L’intento del pattern Virtual Provider (vedere (vedere [TPLSOA]) è di combinare i pattern service facade, service proxy e service wrapper al fine di fornire un servizio il piu’ completo possibile anche se l’ecosistema IT non è ancora consolidato.
Il Virtual provider deve:

• 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/data model

Qualsiasi modifica di policy e/o di configurazione del servizio deve impattare il Virtual Service Provider ma non gli elementi che concorrono al servizio ne tantomeno il client.

Figura 8: Integration Service Pattern

Il pattern Virtual Service Provider è anche conosciuto come Integration Service Pattern. Utilizzando tale pattern l’architettura si sposta da un modello a componenti verso un modello a servizi. Una volta migrata l’architettura verso un modello SOA, è possibile “agganciare” il servizio d’integrazione direttamente all’ESB.

Conclusione
In questo articolo abbiamo introdotto SOI e i principali design pattern correlati. In sostanza si tratta di applicare i dettami architetturali SOA all’integrazione di funzionalità esistenti.
La differenza tra servizi SOA e servizi SOI è che, mentre nel primo caso i servizi sono business-driven, nel secondo sono integration-driven. Questo porta ad un approccio diverso nel disegno dei servizi (Meet-In-The-Middle piuttosto che Top-Down) che può essere aiutato dall'utilizzo del pattern descritti.

Bibliografia
[MOKA_SOA_I] M. Piraccini, S. Rossini: SOA: Introduzione - MokaByte 100 - Ottobre 2005
http://www.mokabyte.it/2005/10/soa-1.htm
[MOKA_SOA_II] M. Piraccini,S. Rossini: SOA: Metodologia - MokaByte 101 - Novmbre 2005
http://www.mokabyte.it/2005/11/soa-2.htm
[MOKA_SOA_III] M. Piraccini,S. Rossini: SOA (III): Il Maturity Model - MokaByte 102 - Dicembre 2005
http://www.mokabyte.it/2005/12/soa-3.htm
[MOKA_SOA_IV] M. Piraccini,S. Rossini: SOA (IV) Roadmap - MokaByte N.103 - Gennaio 2006
http://www.mokabyte.it/2006/01/soa-4.htm
[GOF] Gamma,Helm,Johnson,Vlissides: Design Patterns-Elements of Reusable Object-Oriented Software
[EAI_PATTERNS] G.Hohpe, B.Woolf: Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions - Addison-Wesley, 2004
[EAI_PATT_WS] Gregor Hohpe Enterprise Integration Pattern web site: http://www.eaipatterns.com/index.html
[TPLSOA] A. Arsanjani, Ph.D.: Toward a pattern language for Service-Oriented Architecture and Integration, Part 1: Build a service eco-system-http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi/
[CJ2EE] Alur,Crupi,Malks: Core J2EE Patterns - Best Practices and Design Strategies
[FMEDP] Floyd Marinescu: EJB Design Patterns – Advanced Patterns, Processes and idioms
[ERMEJB] Ed Roman, Scott Ambler, Tyler Jewell: Mastering Enterprise JavaBeans
[AUNJ2EE] Sun Java Center J2EE Patterns:
http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html
[SBPDPC] Sun blueprints-Design Patterns Catalog:
http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html
[MOKA_INT_PATT_1] S.Rossini: Integration Patterns (I),Mokabyte N.100-Ottobre 2005
[MOKA_INT_PATT_2] S.Rossini: Integration Patterns (II),Mokabyte N.101-Novembre 2005
[MOKA_INT_PATT_3] S.Rossini: Integration Patterns (III),Mokabyte N.102-Dicembre 2005
[MOKA_DAO]S.Rossini: Data Access Object, Mokabyte N.62-Aprile 2002
[MOKA_FAC] S.Rossini: SessionFacade,Mokabyte N.64-Giugno 2002
[MOKA_BD] S.Rossini: Business Delegate, Mokabyte N.65-Luglio 2002
[MOKA_SL] S.Rossini: Service Locator, Mokabyte N.67-Ottobre 2002
[MOKA_VO] S.Rossini,: Value Object ,Mokabyte N.69-Dicembre 2002
[MOKA_FC] S.Rossini: Front Controller, Mokabyte N.70-Gennaio 2003