Da un pò di tempo è stata annunciata la nuova versione di BizTalk la 2010 R2.
Devo essere sincero, chi mi conosce sa che non sono persona di parte, in rete leggo molti post, sia su vari blogs che articoli e commenti su linkedin, sono commenti che inneggiano ad AppFabric quale prossima soluzione ai problemi di integrazione.

La proposta Appfabric si divide in due parti principali, la prima è AppFabric Service Bus e copre la parte di servizi, ESB (Enterprise Service Bus) e BPM, questo mediante meccanismi legati a code (queue), topics (sottoscrittori), binding e altro, la seconda è AppFabric Integration Services (AppFabric Connect) che copre la parte di integratione.

Rispetto a BizTalk AppFabric manca ancora di tante features quali BAM (Business Activity Monitoring), BRE (Business Rules Engine) , tutta una parte di monitoring e traking molto complessa presente in BizTalk, tutta la parte  di persisting state, tutta la parte di context e contest subscription, potrei andare avanti ore , questi sono solo i principali.
Mettiamo a confronto le maggiori e tiriamo noi stessi le conclusioni.

AppFabric

BizTalk 2010

Se volete studiare meglio i componenti potete scaricare da quì versione integrale delle capabilities di BizTalk

Non e’ solo prematuro pensare che appFabric sostituirà BizTalk, è semplicemente sbagliato.
Sono due cose diverse perchè vivono in due contesti completamente differenti, BizTalk è On Premise (al di fuori della cloud), AppFabric no, di conseguenza l’ approccio a una soluzione è totalmente differente.

Ecco un esempio riportato dalla stessa Microsoft su una soluzione ormai conosciutissima, la famosa Woodgrove Bank

Il mondo dell’ integrazione non è “semplice” come quello legato allo storage delle informazioni o quello puramente applicativo o gestionale, in entrambi la problematica è legata strettamente al fatto che utilizziamo un unico punto per gestire dati e informazioni.
Mi spiego meglio, se in azienda ho i dati in un database SQL Server e decido di portare i miei dati in cloud, la problematica è abbastanza semplice, una volta portati i dati su SQL Azure devo solo arrivare al mio database e il gioco è fatto.
Se ho un’ applicazione ERP e intendo portarla in cloud, devo solo eseguire un porting in cloud che prevederà una certa revisione del codice.
Tutto cambia se si parla di integrazione, se la mia applicazione ERP interfacciava varie verticalizzazioni quali SAP, DB2, EDI, Oracle, Siebel, RFID,HL7, AS400 Application, UX e queste stesse contengono logiche di processo legate al motore di integrazione, beh, ripeto, tutto cambia.
Molte aziende hanno logiche di processo estremamente legate alla parte On Premise, sono logiche spesso complicate e per definizione residenti in sede, sono logiche di processo legate alla parte di integrazione.
Spesso penso che le persone non inquadrino il fatto che la realtà non è strettamente legata al proprio modo di risolvere i problemi, faccio un esempio semplice e molto chiaro.
Mi è capitato di definire un’ architettura totalmente disconessa, cosa significa?, significa legata al fatto che ogni nodo potesse essere connesso o meno a una logica di processo generale e centrale.
Questo comporta che ogni nodo, in caso di disconnessione, debba essere in grado di lavorare in modo autonomo.
Ogni nodo era una realtà a parte e viveva di vita propria e molto complessa e richiedeva l’integrazione di varie tecnologie e aree tra le quali SAP, Oracle e applicativi vari client server e web.
Queste realtà erano navi, non voglio fare pubblicità, ma vi garantisco che parlo di vere aziende mobili e galleggianti.

Un grattacelo in mare, una piccola cittadina…

Ogni nave comprendeva un BizTalk in Group e in NLB (Network Load Balancing ) in grado di gestire tutto il flusso informativo di messaggistica interno, sia system che human workflow e un BizTalk (chiaramente parlo di varie istanze centralizzate) per gestire la centralizzazione di tutti i processi disconnessi.

Ecco dove vedo bene AppFabric, ho fatto questo esempio per essere chiaro, lo vede bene centralizzato e dedicato alla gestione di ESB disconnessi.
Lo vedo molto bene legato alla possibilità di fornire una scalabilità verticale e orizzontale di processi dedicati molto alta e semplice.
Un giorno parlando con una persona di tutto questo mi sono sentito dire…
“ma scusa, io invece di usare BizTalk On Premise, utilizzo WAS (Windows Activation Services)”

A quel punto lo sconforto si è fatto grande nella mia mente.
Era la domanda che mi assillava da sempre, era la domanda che non mi faceva dormire alla notte e mi teneva sveglio… (by Matrix )

Ma troverò mai qualcuno con il quale parlare di integrazione e servizi e che non sia un semplice smanettone WCF?

WAS e BizTalk sono due cose molto simili ma allo stesso tempo estremamente diverse, diciamo che WAS sta allo smanettone come BizTalk sta all’ architetto.
Mi spiego meglio, BizTalk è un ESB consolidato, WAS è un framework sul quale costruire un ESB consolidato.
Se dovessi rappresentare il paragone alla Stan Lee ecco come lo vedrei

AppFabric ha un ESB consolidato in parte, mancano ancora BAM un BRE e un tracking nativo a 360 gradi sui processi, la parte di integrazione è interessante e chiaramente copre problematiche legate normalmente a realtà enterprise, a tal proposito EDI appunto.

La versione 2010 R2 di BizTalk conferma quello che penso, basta dare una veloce occhiata alla lista delle features annunciate da Microsoft:

Below is the detailed view of the features we are releasing:

Platform Support

Improved B2B

Ready for the Cloud

New Platforms and Infrastructure

  • Windows Server 8*
  • SQL Server 2012*

Increased Developer and IT Productivity

  • Visual Studio 11* and Windows 8* to develop solutions
  • In-place migration from BizTalk Server 2010

Extended Platform Integration

  • DB2 client connectivity to SQL Server, conversion of commands to T-SQL, migration of packages to stored procedures
  • Adapter connectivity to new data sources, including IBM Informix V11 and IBM IMS/DB V11
Agile Alignment to Industry Standards

  • Regular updates to schemas, accelerators certifications and adapters. Highlights include:
  • Healthcare: HIPPA 5010 extensions: 2777CA, 999, HL7 2.5.1
  • Finance: SWIFT SRG 2011 support, SWIFT SRG 2012, SWIFTNet 7.0 (new messaging platform)

Improved Performance and Scalability

  • HL7 MLLP adapter performance improvements
  • Better performance with ordered send ports
  • Enhanced scale out configuration with multiple hosts
  • Expanded adapter options for faster batch processing
Extend on-premises solutions to the cloud

  • Easily extend your on-premises BizTalk Server solution to the cloud in a secure manner
  • Tighter integration of on-premises BizTalk Server applications with Windows Azure Service Bus

Improved Licensing

  • Adjustments to licensing that are geared towards cloud hosting, including:
  • Purchase from a hoster on a monthly basis (SPLA)
  • Register your existing license with a hoster (License Mobility)

Una colonna è dedicata a questo argomento:
Ready for the Cloud (Pronto alla Cloud)
Credo siano molto chiare e condivido in pieno la visione di Microsoft, non è accettabile pensare di poter fare a meno di una offerta ESB On Premise consolidata come BizTalk.

Ecco come BizTalk è in grado di parlare con AppFabric Connect
definizione di un Service Bus endpoint…

Altro esempio…
Mi è capitato di dover gestire una situazione simile alla precedente ma non erano navi ma ospedali.
Messaggistica interna in HL7, tutti gli impianti ospedalieri erano in comunicazione tra loro e con un ESB centrale, il tipo di protocollo era HL7.
Tutti i quattro ospedali e molte USL governative dovevano ricevere le vari comunicazioni dai rispettivi ospedali e viceversa e una parte del tutto doveva essere centralizzato.
Non cambia nulla rispetto al precedente esempio, un ospedale è una realtà a se stante, le problematiche di integrazione e servizio sono interne e legate al fatto principale che un ospedale non può e non deve mai fermarsi, la mancanza di servizio è inaccettabile.

Dall’ overview della pagina di Microsoft di AppFabric:
“Windows Server AppFabric is a set of application services focused on improving the performance and management of Web, Composite, and Enterprise applications.”

AppFabric è in cloud, AppFabric richiede una connessione, AppFabric è un valido supporto a BizTalk per risolvere problemi di scalabilità su grande scala, AppFabric non è On Premise.

Se dovessi figurare i tre li raffigurerei così…

WAS, accattivante, ma necessita di addestramento sul campo e manca di strumenti nativi.

AppFabric un valido compagno, giovane, pronto a supportarti, deve ancora maturare ma promette molto bene.

BizTalk un combattente di grossa esperienza sul campo e consolidato, con tutta l’ esperienza e le armi necessarie per affrontare la battaglia senza indugi.

Nel futuro?
Beh qui ci vuole Stan Lee…, li vedrei così

pura potenza, ma che va controllata e gestita nel modo migliore.

1 COMMENT

  1. Nino, condivido in pieno quanto detto. Chiaramente è sempre meglio avere alternative che, dipendentemente dal contesto, ti permettono di scegliere ed adottare la soluzione più opportuna. Le tecnologie citate hanno caratteristiche e scopi differenti proprio perchè legate a contesti d’uso differenti (On-Premises e Cloud, framework e “ESB consolidato”).
    Però sottolinerei meglio la differenza tra Windows Server AppFabric (Hosting e Caching) e Windows Azure AppFabric (ACS, Service Bus. Integration, Caching, …). Offrono differenti set di servizi, ad eccezione del caching, in differenti ambiti: il primo è On Premises, il secondo Cloud.
    Ad ogni modo per parlare di questo, il mio skype è sempre aperto 🙂

    • Ciao Fabio, è sempre un piacere leggerti e sentirti.
      Hai perfettamente ragione sul fatto di distinguere i due principali aspetti di AppFabric (Connect e Services).
      E’ sicuramente un valido spunto per una futura mia, e magari nostra 🙂 riflessione, e una valida occasione per scrivere un’ altro post.
      Questo post è nato dal fatto che da un mese a questa parte sento in giro proclami pazzaesci, inererenti il fatto che AppFabric, e qui generalizzano, sia il successore di BizTalk a tutti gli effetti.
      Questo proclami arrivano da persone del campo, forse con un pochino di confusione in testa, ma che chiaramente alimentano ulteriore confusione.
      Proclami su Linkedin, blogs… questo mi lascia mmolto perplesso…
      Grazie per la tua interessante osservazione, è sempre un piacere sapere che una persona che reputo estremamente esperta e competente nel campo, legga con interesse un mio post.

      Un abbraccio
      Nino

LEAVE A REPLY

Please enter your comment!
Please enter your name here