| In un ambiente industriale competitivo e dinamico come quello attuale, piattaforme applicative come Supply Chain Management, Enterprise Resource Planning, Customer Relationship Managment e Business Intelligence hanno acquisito cruciale importanza ma anche contribuito alla creazione di disallineamenti tra architetture, impossibilitate a comunicare fra loro a causa di protocolli differenti.
Anche le moderne tecniche di integrazione si fermano laddove software proprietari non espongano interfacce cosiddette standard, che possano quindi essere utilizzate nel dialogo fra sistemi di natura eterogenea.
Sunnyvale, nel suo intento di creare valore aggiunto nel campo dell'Enterprise Application Integration, sviluppa e lancia sul mercato A.L.A., l'adapter di nuova concezione che supera le barriere imposte dalla mancata condivisione di un linguaggio comune tra applicazioni. |
 La necessità di introdurre un adapter
| |
 Come funziona Adapter-Logic Application
| Come funziona Posto come frontend ad applicazioni difficilmente integrabili, A.L.A. è in grado di ricevere richieste tramite protocolli standard, si pensi a SOAP o JMS dove il payload del messaggio è un documento XML, e tradurle in formato comprensibile esclusivamente al server posto nel back-end.
Viceversa, applicazioni che utilizzano protolli proprietari, riescono a reperire dati da contesti esterni grazie alle operazioni di traduzione e trasformazione che A.L.A. svolge tra architetture differenti.
Con un occhio di riguardo verso i sistemi legacy, A.L.A. è stato progettato per un bassissimo utilizzo di risorse computazionali in termini di spazio disco, memoria, operazioni di input/output e carico della CPU.
Si configura tramite un semplice file XML, studiato apposta nella sintassi in modo da essere comprensibile dall'ammistratore di sistema che decide quali interfacce di frontend debbano essere eseguite al boot ed i sistemi di beckend che verranno collegati.
Il risultato è una completa integrazione di tutti quei sistemi che, pur fornendo applicazioni di vitale importanza per il business dell'azienda, incontrano notevoli difficoltà a collocarsi in architetture moderne orientate ai servizi (SOA) dove ad esempio il protocollo di scambio dati è quello web. | Standard e tecnologie Scritto interamente in Java, tiene fede alla promessa "Write once, run everywhere"; A.L.A., infatti, può essere eseguito su svariate combinazioni di architetture hardware e sistemi operativi dove sia installata una Java Virtual Machine di versione 1.6 o superiori.
E' stato sviluppato seguendo il pattern architetturale Model-View-Controller e disaccoppia le interfacce di frontend (dette Controller) e quelle di backend (Connector) dal motore vero e proprio dell'applicazione.
Un Controller all'avvio espone un punto di ingresso a seconda del protocollo che gestisce (JMS, SOAP, RFC/IDOC sono solo alcuni) ed accetta messaggi esclusivamente in formato XML.
In seguito, internamente ad A.L.A., il messaggio viene "normalizzato" sottoforma di Document Object Model per facilitarne la trasformazione con l'uso di XSLT (XML Stylesheet Language Trasformation). Il Router è in grado di localizzare nel file di configurazione il servizio di cui si intende usufruire così l'oggetto DOM dopo aver subito trasformazioni had-oc raggiunge il Connector per poi essere inoltrato al sistema di backend.
In caso di servizio sincrono, una risposta viene spedita seguendo il canale in senso inverso, partendo dal sistema di backend fino al client, anche in questo caso opportunamente tradotta da garantire completa trasparenza. | Scalabilità Sviluppando le interfacce di frontend e backend si è deciso fin da subito che ogni Controller fosse compatibile con ogni Connector e viceversa. Ottenendo questo gran risultato, il team di Sunnyvale ha dato la possibilità all'utilizzatore di combinare Controller e Connector fra loro, aumentando così il numero di piattaforme applicative che A.L.A. è in grado di gestire.
Sono disponibili e pronti all'uso Controller di tipo HTTP, JMS, TIBCO Rendezvous (Reliable/Certified transports), SAP R/3 (IDOC/RFC), Flat file, SOAP (XML-RPC/Document) e Raw socket.
Allo stesso modo, esistono Connector che integrano applicazioni Web Service, SAP, Tibco, JMS e molti saranno disponibili con le prossime release del prodotto.
Per tutti quei casi specifici che necessitano soluzioni personalizzate, l'utente è incoraggiato da Sunnyvale a sviluppare i propri Controller o Connector, fatto reso possibile con la semplice implementazione di interfacce o estendendo classi provenienti dalle librerie che A.L.A. mette a disposizione. |
 Scalabilità
| | Alta affidabilità del software Entrare nel mercato enterprise significa anche raccogliere la sfida che richiede alta affidabilità del proprio prodotto; in altre parole occorre garantire al cliente un'installazione ridondante del software che lo tuteli da incidenti hardware, guasti di rete o malfunzionamenti del server ospitante.
A.L.A. implementa meccanismi di alta affidabilità a livello di Controller i quali sono in grado di funzionare in modalità cluster "active/passive" o bilanciando il carico in ingresso "active/active" a seconda del protocollo che gestiscono.
Utilizzano quest'ultima modalità i Controller SOAP posizionati dietro ad un bilanciatore HTTP sia esso hardware (CISCO CSS, Radware) o software (Apache), consentendo così a più istanze A.L.A. di suddividersi il carico di lavoro, fermo restando che, qualora un'istanza venisse a meno, le rimanenti saranno comunque in grado di evadere le richieste in maniera totalmente trasparente al client.
Un esempio di cluster "active/passive" lo fornisce invece il Controller per SAP R/3; in questa modalità è possibile replicare la stessa configurazione di Controller su più istanze A.L.A. formando così un "Cluster Group". All'interno dello stesso, solo un Controller, posizionandosi in stato "Active", potrà accettare richieste RFC o IDOC provenienti dal SAP Gateway mentre lo stato di tutti i Controller viene condiviso ad intervalli regolari utilizzando protocolli come UDP, IP Multicast o TCP (configurabile).
Un eventuale malfunzionamento del Controller attivo verrà rilevato dalle altre istanze ed una sola, quella più avanti all'interno della coda di attivazione, prenderà il suo posto dichiarandosi "Active" con tempi al di sotto della frazione di secondo e continuando ad accettare richieste di integrazione da SAP.
Tramite queste due tecnologie, A.L.A., vince la sfida più importante: saper garantire l'erogazione del servizio anche in contesti dove il minimo malfunzionamento si tradurrebbe in un danno ingente per il business dell'azienda. |
 Configurazione cluster Active/Passive
 Configurazione cluster Active/Active
| Storie di successo Un'importante azienda italiana di distribuzione del gas, dopo aver messo a confronto gli adapter fino ad allora utilizzati per l'integrazione di SAP R/3 e la soluzione proposta da Sunnyvale, ha ritenuto che quest'ultima fosse in vantaggio su almeno tre aspetti:
- Una singola installazione di A.L.A. può esser configurata per la gestione di una vasta serie di servizi, protocolli ed applicazioni, evitando di installare un adapter per ogni architettura che si intende integrare.
- Multithreading: a differenza di altre soluzioni che accettano un massimo di una richiesta alla volta serializzando le successive, A.L.A. grazie al multithreadning offerto dalle istanze Controller, è in grado di gestire oltre cinquanta chiamate simultaneamente. Fino ad allora un risultato simile era stato ottenuto solamente replicando il numero di processi adapter con un aumento significativo dei costi di gestione.
- Anti deadlock protection: esistono situazioni in cui, a causa di errori interni a SAP, una risposta a seguito di un'invocazione RFC non venga mai restituita al client; in quei casi altri adapter non sono in grado di rilevare l'errore e rimangono in attesa scartando tutte le richieste a seguire fino al restart del processo. Ragionando in termini di thread e non di processi server, con A.L.A. una situazione simile verrebbe gestita bloccando solamente un thread ma garantendo alle altre richieste di venire ugualmente evase; nessun riavvio dell'applicazione che causerebbe un fermo degli altri servizi funzionanti verrà mai richiesto.
Sulla base di quanto affermato, la società caso di studio ha scelto A.L.A. come componente chiave per la creazione degli ordini di servizio su SAP tramite protocollo SOAP. Visualizza la presentazione su SlideShare (Inglese) |
