Microsoft sta fornendo nuove proposte nel mercato dell’ integrazione e service bus, questo mondo è molto complesso e pieno di insidie.
Io mi ritengo molto fortunato, ho iniziato ad avvicinarmi a questo mondo intorno al 2002, ormai sono più di 10 anni, ho avuto l’ opportunità di lavorare con le più grandi realtà italiane e internazionali e integrare le verticalizzazioni più grandi e complicate.
Molti miei clienti e persone che seguono il blog hanno espresso una certa perplessità intorno alle nuove proposte Microsoft, io stesso sono stato da poco ad una interessantissima conferenza sullo sviluppo di nuove soluzioni su Web, Windows 8 e così via.
La cosa che mi è piaciuta veramente è che per la prima volta, dopo 10 anni, inizio a sentire parlare di Service Bus, vi chiederete, parlavano di BizTalk?, no di (N)ServiceBus.
Le persone mi conoscono, sanno chi sono, e all’ uscita delle due sessioni, una su (N)Service Bus e l’altra su WCF, mi ponevano molte domande, anche adesso via Skype, Windows Live Messenger ecc.
Tutte le domande erano dirette a capire quale fosse la proposta intorno a (N)Service Buse e come si pone questo tool per sviluppatori nel complicato mondo dei service bus e integrazione.
Il primo errore è parlare di integrazione con (N)ServiceBus, questo tool non è provvisto di nessun tipo di adapter, al massimo, per i sistemi LOB (SAP, Siebel, Oracle) è possibile sfruttare gli adapter pack forniti da BizTalk.
Ma la cosa che ha fatto scattare in me questo post è la frase che ha detto uno dei rarissimi sviluppatori che secondo me hanno capito (N)ServiceBus, la frase diceva:.
”gli sviluppatori hanno bisogno anche di qualcosa di piccolo e semplice per poter realizzare semplici Service Bus”
si è vero, (N)ServiceBus è sostanzialmente un tool per gli sviluppatori che fornisce una semplicissima struttura di base per eseguire hosting si sevizi WCF su Windows.
Ha chiaramente logiche molto semplici di persistenza e sottoscrizione legate a Message Queue, questo però limita spaventosamente la scalabilità, per questa ragione (N)ServiceBus non è adatto ad architetture Enterprise, più avanti parlerò di cosa si intenda per un ESB enterprise.
Purtropppo in Italia, a differenza del resto del mondo , si tende a lasciare a chi sviluppa codice, la responsabilità di decidere quale tecnologia utilizzare e spesso le scelte portano a esiti molto infausti.
Tantissimi non hanno ancora capito cosa sia BizTalk o Tibco, persino persone che lavorano su service bus.
Per capire meglio la cosa parliamo di ESB enterprise.
Molti persone pensano che un Service Bus sia tale nel momento in cui entrano in gioco una paio di servizi wcf in hosting, un paio di code per serializzare i messaggi,
e un paio sottoscrizioni ai servizi.
(N)ServiceBus è al livello di BizTalk 2002 con in più un layer WCF.
BizTalk 2002 era basato sulla stessa logica e semplicità (nel 2002 ancora si cercava di capire cosa fosse un service bus), code su message queue, serializzazione dei processi e sottoscrizione.
BizTalk è stato creato per affrontare architetture in scala enterprise e di conseguenza nel 2004 / 2005 l’uso di message queue su service bus è stato deprecato per chiara mancanza di scalabilità e performance su grandi carichi di messaggi.
Ci sono voluti più di 10 anni per arrivare a un service bus vero, BizTalk 2010 R2.
Ma cosa è un service bus?
La risposta richiederebbe un libro, ma se seguite i miei futuri articoli avrete certamente occasione
Da wikipedia Italia
”Un Enterprise Service Bus (ESB) è un’infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse. Un ESB si basa su sistemi disparati, interconnessi con tecnologie eterogenee, e fornisce in maniera consistente servizi di orchestration, sicurezza, messaggistica, routing intelligente e trasformazioni, agendo come una dorsale attraverso la quale viaggiano servizi software e componenti applicativi. Un ESB si contraddistingue come soluzione migliorativa, rispetto ad altre più classiche di tipo SOA oriented in quanto ad esso sono delegati i servizi comuni denominati core service che andrebbero altresì realizzati. L’ESB concettualmente prevede la suddivisione in isole tecnologiche e/o applicative, la connessione al BUS infrastrutturale è assicurata attraverso principi di binding multiplo sia in modalità loose coupling che via adapting”
Abbastanza vicino, ma troppo semplicistico, passiamo a quello più internazionale
Da wikipedia EN
”An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in Service Oriented Architecture. As a software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes strictly asynchronous message oriented design for communication and interaction between applications. Its primary use is in Enterprise Application Integration of heterogeneous and complex landscapes”.
Ma per capire meglio andiamo nel dettaglio:
The prime duties of an ESB are:
- Monitor and control routing of message exchange between services
- Resolve contention between communicating service components
- Control deployment and versioning of services
- Marshal use of redundant services
- Cater for commonly needed commodity services like event handling and event choreography, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service
Tutto questo è un parte di BizTalk, con questo non voglio dire che non sia possibile ricreare a mano tantissimi dei servizi offerti da un service bus completo come BizTalk, ma che renderlo altrettanto efficente e scalabile richiederebbe costi improponibili.
BizTalk è un serice bus estremamente complesso e articolato, fatto per supportare soluzioni enterprise.
Ecco una tabella che riassume cosa sia in grado di fare BizTalk a regime
| Scenario | Server BizTalk | SQL instance | Num. Messages / 24h | Num. Orchestration / 24h |
| Single | 1 | 1 | 94 M | 37 M |
| Tiers | <> | <> | 182 M | 86 M |
La M significa milioni di messaggi, ebbene sì parliamo di 94 milioni di messaggi nelle 24 ore e 37 milioni di orchestrazioni nelle 24 ore, e questo per una solo istanza BizTalk.
Questi test non riguardano due semplici servizi WCF che scambiano messaggi.
Parliamo di uno scenario tipo, implementato su un service bus, perciò partendo dalle basi di quello che possiamo definire un service bus:
- ricezione streaming da parte dell’ adapter
- Prima transazione di processo (Punto di persistenza primario)
- incapsulamento verso pipeline
- check di validazione
- creazione di un oggetto messaggio
- creazione delle proprietà di contesto
- trasformazione
- Seconda transazione di processo (Punto di persistenza primario)
- Risoluzione sottoscrizioni
- invio a un sottoscrittore di processo (orchestrazione)
- Terza transazione di processo (Punto di persistenza secondario)
- esecuzione processo sottoscritto
- Quarta transazione di processo (Punto di persistenza secondario)
- Risoluzione sottoscrizioni
- trasformazione
- Quinta transazione di processo (Punto di persistenza di terzo livello)
- incapsulamento verso pipeline
- creazione delle proprietà di contesto
- check di validazione
- Sesta transazione di processo (Punto di persistenza di terzo livello)
- invio streaming da parte dell’ adapterqueste sono le operazioni principali effettuate da BizTalk per un processo estremamente base e semplice, ecco in basso la figura:
BizTalk è un service bus completo, capace di elaborare milioni di messaggi e scalare i processi in modo sia verticale che orrizzontale senza interromper alcun servizio.
Unico concorrente di BizTalk è Tibco, ma Tibco ha due grossi problemi, i costi, l’ impossibilità di scalare in orizzontale a caldo, cioè senza interrompere alcun servizio.
Tibco ha altre grandi differenze, un giorno io e un caro collega che lavora su Tibco abbiamo fatto alcuni confronti precisi, per esempio ho scoperto che su Tibco la modifica del tipo di adapter in uso da un processo richiede una sospensione di servizio, ho scoperto anche che il trattamento di messaggi di grandi dimensioni (parlo dell’ ordine sopra i 200 mega byte), richiede un intervento piuttosto pesante da parte della sviluppatore per implementare una sorta interchange di processo.
Nella figura in basso un tipico scenario enterprise realizzato con BizTalk.
Questo in figura è uno scenario in grado di lavorare un numero enorme di messaggi, siamo sull’ ordine degli oltre 180 milioni di messaggi in 24 ore.
Per maggiori dettagli
http://msdn.microsoft.com/en-us/library/ee377068(BTS.10).aspx
http://msdn.microsoft.com/en-us/library/ee377036(BTS.10).aspx
http://msdn.microsoft.com/en-us/library/ee377057(BTS.10).aspx
Per questa sua versatilità BizTalk si presta benissimo per utilizzi Enterprise.
BizTalk ha un set di adapters impressionante, per maggiori dettagli: http://www.microsoft.com/biztalk/en/us/adapters-included.aspx
Ultimamente Microsoft sta rilasciando nuove interessanti soluzioni di integrazione su BizTalk per CRM
Il business di una società è basato totalmente sui propri clienti, CRM è sicuramente una valida soluzione ed è naturale che sia necessario integrare i propri clienti con il sistema CRM.
Questa esigenza è talmente sentita che Microsoft ha iniziato a implementare adapter per BizTalk in grado di offrire questo tipo di servizio, la cosa ancora più interessante è che CRM è presente anche online in cloud.
Nella foto in basso è possibile vedere uno scenario di integrazione con BizTalk Server e CRM.
Questo scenario è interessante per due motivi:
- L’ utilizzo di AppFabric Service Bus per il delivering e relay sui partners, sia da parte di CRM che di BizTalk
- L’utilizzo di BizTalk quale ESB per la parte OnPremise
Maggiori dettagli a questo indirizzo
http://blogs.msdn.com/b/pkelcey/archive/2011/03/10/crm-2011-integration-how-to-video-1-biztalk-on-premise-to-crm-2011.aspx
in questo momento sono a Seattle al Microsoft MVP Summit , è una grande occasione per ascoltare le novità dei prossimi tre anni.
Ci sono molte novità su tutta la linea di integrazione e Cloud
BizTalk 2010 R2 promette tanto, in un prossimo articolo ne parlerò in modo dettagliato
Nei prossimi due articoli tratterò BizTalk Futures e (N)ServiceBus
