Parlare di integrazione non è cosa semplice, è un argomento vastissimo e carico di sfaccettature, limitarlo ad una singola tecnologia sminuisce sicuramente la sua importanza.
Ad oggi è possibile utilizzare tantissime soluzioni diverse per integrare diversi sistemi, agnuno di loro ha i suoi vantaggi e svantaggi.
Microsoft presenta alternative quali Integration Service di SQL Server, Host Integration Server , BizTalk Adapter Pack, BizTalk, tutti molto diversi tra loro sia per architettura che per scopo.
Lo sappiamo tutti che è possibile fare qualsiasi cosa con ognuno di questi attori ma solo uno è migliore degli altri in una particolare soluzione.
Nell’ arco di quest’ anno parlerò tantissimo di integrazione e non mi limiterò solo a BizTalk, perchè ritengo che l’integrazione sia una filosofia e una scienza molto articolata.
L’altra sera stavo sul balcone e ho iniziato a ragionare su tutto questo iniziando a fare tantissime considerazioni e domande a me stesso, da lì ho deciso di iniziare a scrivere perchè voglio tenere traccia delle mie ricerche.
Chiaramente da buon MVP sono felice di condividerle con tutti le mie considerazioni sperando possano essere di aiuto.
Una cosa che mi fa sorridere è che ad oggi quando si parla di integrazione sembra si debba parlare obbligatoriamente di BizTalk.
Limitare BizTalk alla semplice integrazione tra sistemi è il segnale che identifica che non si è compreso esattamente cosa sia esattamente BizTalk.
Che dire..., partirei propio da questo.
Ma che cosa è BizTalk?
Direi che è la domanda principe, quella che solitamente mi sento fare per prima.
Credo che questa mancanza di vision non sia dovuta al fatto che manchi un sistema di informazione adeguato, ma alla natura stessa del prodotto, se di prodotto possiamo parlare.
BizTalk è un framework per l’integrazione e la gestione dei flussi tra diversi sistemi.
Si, quando parlo di flussi intendo workflow, ma attenzione ne esistono due principli diversi tipi, human e system workflow.
BizTalk è sicuramente la soluzione numero uno proposta da Microsoft per creare system workflow, non direi lo stesso per quello che riguarda l’aspetto human workflow.
A tal proposito esistono diverse soluzioni, quali Sharepoint e chiaramente Workflow Foundation (WF), è scontato che se dobbiamo arrivare ad ottenere architetture che necessitano di processi di tipo human piuttosto che system, la soluzione ottimale può essere utilizzare MOSS + WF + BizTalk, futura vision Microsoft di nome OSLO.
E gli adapter Pack?, ne parliamo un’ altra volta, ma sono certamente una validissima alternativa per integrare sistemi LOB.
Ok andiamo più sull’ amichevole e partiamo da zero, BizTalk è alla sua quinta versione, le versioni sono la 2000, 2002, 2004, 2006, 2006 R2, siamo in attesa della versione R3.
La versione 2004 rappresenta un vero salto epocale, infatti le architetture precedenti non hanno nulla a che vedere con essa, a tal proposito, infatti, non si può parlare nemmeno di migrazione dalla versione 2000 e 2002 ma di totale riscrittura e rivisitazione architetturale della soluzione.
A differenza di quello che si possa pensare BizTalk è molto diffuso ed utilizzato, chiaramente per correttezza non voglio fare nomi ma in Italia conta di oltre 180 installazioni delle quali 3 oltrepassano i 130 processori.
I diretti concorrenti coprono circa il 30% del mercato con tendenza a diminuire, quali sono i diretti concorrenti?, mmh ripeto non mi sembra corretto fare nomi.
La prima cosa che viene in mente pensando a BizTalk è ad un tool per integrare diversi flussi e che se serve ad eseguire trasformazioni, in sostanza viene paragonato ad un motore di ETL (Extract Transform Load), come Integration Service di SQL Server o T.... ops.
Ritengo che sia questo il più grave errore, un errore che porta solitamente ad una ingenua sottovalutazione della tecnologia in questione e, di conseguenza, ai relativi lasagne projects.
BizTalk non è stato creato per eseguire semplice ETL, anche se potrebbe farlo, ma ripeto non è stato progettato per questo, se dovessi decidere cosa utilizzare per replicare e trasformare i dati tra due tabelle SQL di un milione di records uilizzerei sicuramente Integration Service di SQL Server o altre tecnologie ma non certamente BizTalk.
A questo punto, di solito, la curiosità inizia a crescere e la domanda sorge spontanea.
Se non è un ETL, o perlomeno, non è tra i suoi targets primari, quali lo sono?
BizTalk è fondamentalmente un HUB Messaging Router, questa sua particolarità lo rende unico nel suo genere.
Sostanzialmente BizTalk riceve messaggi, questi messaggi possono arrivare da sistemi diversi ma al suo interno sono sempre e comunque messaggi.
A cosa è dovuta questa particolarità, è dovuta a un layer esterno chiamato adapter che lui stesso espone.
BizTalk ha tantissimi adapters a disposizione, ognuno di loro è specializzato a parlare con un diverso tipo di sistema, la cosa importante è che a prescindere da quale sia il tipo di sistema o il tipo di protocollo, quando l’adapter riceve qualcosa lo deserializza in una forma BizTalk standard, che corrisponde al famoso messaggio, tecnicamente farlando è un XML Document contenente puro XML.
BizTalk utilizza un pattern architetturale interno molto conosciuto che si chiama Publish/Subscriber.
Un volta entrato in BizTalk questo messaggio può essere sottoscritto a diversi Subscribers, questi possono essere processi molto complessi o semplicemente porte di invio su altri sistemi.
A differenza di quando si lavora su un classico ETL, nel quale esiste uno stretto legame tra un processo e l’altro, in BizTalk esiste solo la sottoscrizione e su questo si basa l’intero funzionamento.
Un messaggio può essere sottoscritto con tantissime regole, basandosi sul valore di uno o più campi, sul fatto che arrivi da un determinato partner, dal fatto che sia un determinato tipo di messaggio e tanto altro ancora.
Sostanzialmente il messaggio viene pubblicato al suo interno ed uno o più Subscriber possono riceverlo, questi Subscribers possono essere processi, porte e altro.
In BizTalk non si può parlare di soluzioni chiuse perchè una soluzione è composta da vari tipi di messaggi e processi che possono essere estesi in qualsiasi momento.
Per capire meglio prendiamo in esame alcune tipiche architetture nelle quali BizTalk può essere utilizzato.
Esistono vari tipi di possibili patterns sia architetturali che di sviluppo, è un discorso molto lungo, complicato e interessantissimo, a dire il vero è l’ argomento di un prossimo articolo.
Dovendo anticipare qualcosa e senza scendere nei particolari prendiamo le due più semplici e diffuse, HUB & Spoke e ESB.
HUB & Spoke Fig 1
FIG 1
In questo caso abbiamo i vari BizTalk dislocati sulle varie agenzie o reparti aziendali (SPOKES) e uno centralizzato (HUB)
I vari BizTalk decentralizzati si occupano di integrare le varie tecnologie in periferia e quello centrale “orchestra” i vari messaggi che arrivano dalle sedi.
In questo tipo di soluzione gli stessi BizTalk decentralizzati fungono da Subscribers, internamente all’ HUB centrale è possibile rappresentare i vari attori come “Partners” e creare politiche di smistamento dei messaggi e di comunicazione assolutamente uniche nel suo genere ma anche questo sarà argomento a parte di un futuro articolo.
La natura stessa di BizTalk porta a creare queste architetture in modo naturale.
ESB Fig 2
FIG 2
Enterprise Service BUS, questa è tra le più frequenti, a differenza della precedente sono le varie tecnologie ad essere interfacciate direttamente a BizTalk, ad essere sincero il concetto di ESB è molto più complicato e include concetti molto profondi , standard di interfaccia, di comunicazione, ma adesso quello che desidero è essere semplicemente chiaro.
Nell’ esempio in figura abbiamo un database SQL Server un SAP, un sistema AS/400 e un database Oracle.
Il compito di BizTalk può essere molteplice, dal permettere ai vari sistemi di interscambiarsi le informazioni al gestire un processo di workflow o di business prelevando o ricevendo le informazioni necessarie dai vari attori e nel caso utilizzarle congiuntamente per poi smistarle (Sottoscriverle).
Solitamente è una soluzione interna all’ azienda ed il focus è ottenere un layer assolutamente standard per comunicare con tutte le diverse tecnologie, certo, un layer assolutamente standard quali dei servizi Web come Web Services o WCF (Fig 3)
FIG 3
Questo discorso / percorso intrapreso mi porta a fare tantissime considerazioni, saranno sicuramente stimoli per prossimi articoli...
Vi prego di contattarmi e scrivere per eventuali considerazioni, che potranno sicuramente arricchire e stimolare a nuove discussioni.
Quanto mi diverte l' integrazione! 