In questo articolo introduciamo SOI, cioè come utilizzare le architetture a servizi per l‘integrazione. Descriviamo inoltre alcuni design pattern che possiamo utilizzare per produrre servizi SOI.

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 [1]) sia metodologico (vedere [2]) .
Abbiamo introdotto inoltre il concetto di Maturity Model (vedere [3]) e spiegato l‘importanza di avere una Roadmap che definisca i passi per “traghettare” verso un‘architettura full-SOA (vedere [4]).

In questo articolo introduciamo SOI, cioè come utilizzare le architetture a servizi per l‘integrazione. Descriviamo inoltre alcuni design pattern che possiamo utilizzare per produrre servizi SOI.
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 1, 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.

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.

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.

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 [2]).

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.

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

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

Il Service Proxy è una specializzazione del pattern Proxy del [5] in un contesto a servizi ed è l‘analogo del pattern Business Delegate (vedere [19]) 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.

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

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 [8]) è 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.

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.

1M. Piraccini, S. Rossini”SOA: Introduzione” – MokaByte 100 – Ottobre 2005https://www.mokabyte.it/2005/10/soa-1.htm2M. Piraccini, S. Rossini”SOA: Metodologia” – MokaByte 101 – Novembre 2005https://www.mokabyte.it/2005/11/soa-2.htm3M. Piraccini, S. Rossini”SOA (III): Il Maturity Model” – MokaByte 102 – Dicembre 2005https://www.mokabyte.it/2005/12/soa-3.htm4M. Piraccini, S. Rossini”SOA (IV) Roadmap” – MokaByte N.103 – Gennaio 2006https://www.mokabyte.it/2006/01/soa-4.htm5Gamma, Helm, Johnson, Vlissides “Design Patterns-Elements of Reusable Object-Oriented Software”6G. Hohpe, B. Woolf”Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” Addison-Wesley, 20047Gregor Hohpe”Enterprise Integration Pattern web site”http://www.eaipatterns.com/index.html8A. Arsanjani”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/9Alur, Crupi, Malks Core”J2EE Patterns: Best Practices and Design Strategies”10Floyd Marinescu “EJB Design Patterns: Advanced Patterns, Processes and Idioms” 11Ed Roman, Scott Ambler, Tyler Jewell”Mastering Enterprise JavaBeans”12Sun Java Center J2EE Patternshttp://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGlance.html13Sun blueprints-Design Patterns Cataloghttp://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html14Stefano Rossini”Integration Patterns (I)” Mokabyte 100 Ottobre 2005https://www.mokabyte.it/2005/10/integrationpatterns-1.htm15Stefano Rossini”Integration Patterns (II)” Mokabyte 101 Novembre 2005https://www.mokabyte.it/2005/11/integrationpatterns-2.htm16Stefano Rossini”Integration Patterns (III)” Mokabyte N.102 -Dicembre 2005https://www.mokabyte.it/2005/12/integrationpatterns-3.htm17Stefano Rossini”Data Access Object” Mokabyte 62 Aprile 2002https://www.mokabyte.it/2002/04/pattern-dao.htm18Stefano Rossini”SessionFacade” Mokabyte 64 Giugno 2002″https://www.mokabyte.it/2002/06/pattern-facade.htm19Stefano Rossini”Business Delegate”, Mokabyte 65 Luglio 2002https://www.mokabyte.it/2002/07/pattern-bd.htm20Stefano Rossini “Service Locator” Mokabyte 67 Ottobre 2002https://www.mokabyte.it/2002/10/pattern_sl.htm21Stefano Rossini”Value Object” Mokabyte 69 Dicembre 2002https://www.mokabyte.it/2002/12/pattern_vo.htm22Stefano Rossini”Front Controller” Mokabyte 70 Gennaio 2003https://www.mokabyte.it/2003/01/pattern_fc.htm