Uno dei requisiti principali di una piattaforma di integrazione come servizio (iPaaS) e del motivo per cui il patrimonio di integrazione è importante in cloud è che la tecnologia sia costruita su standard web moderni, in particolare JSON e REST.
Notazione degli oggetti JavaScript (JSON)
"È facile inserire righe e colonne in un documento, ma il contrario non funziona".
- Craig Stewart, direttore della gestione dei prodotti SnapLogic in questa dimostrazione registrata
SnapLogic tratta i documenti, piuttosto che le righe e le colonne degli strumenti tradizionali di tipo ETL. Nel suo post " Technical Advantages of JSON-centric iPaaS", Greg Benson, Chief Scientist di SnapLogic, esamina 5 vantaggi per l'elaborazione dei dati e per gli utenti finali derivanti dall'utilizzo di documenti come tipo di dati nativi:
- I documenti si adattano meglio ai moderni servizi web.
- I documenti si traducono in pipeline più sintetiche.
- Un modello documentale consente alle Pipeline di essere accoppiate in modo lasco.(Guardate questo video del cliente per conoscere i vantaggi dell'"integrazione senza schema")
- Un modello di documento consente un maggiore riutilizzo della pipeline.
- I documenti sono un sottoinsieme dei record.
Per quanto riguarda il supporto fondamentale di SnapLogic ai moderni standard web, scrive:
"Il supporto per i documenti consente ai nostri endpoint Snap di consumare direttamente i dati gerarchici in formato nativo e di inviarli agli Snap a valle in una pipeline. Ciò significa che non è necessario appiattire i dati in record o trasformare un documento JSON in una stringa o in un BLOB".
Per quanto riguarda i vantaggi di un approccio incentrato su JSON che supporta i dati strutturati e non strutturati senza soluzione di continuità, conclude: "Questo supporto nativo per i documenti è una delle tante innovazioni architettoniche che abbiamo sviluppato per aiutare le aziende a collegare sia i servizi web che i data store tradizionali".
Ecco una vista JSON e tabellare di una query Snap di Twitter in SnapLogic Elastic Integration Platform Designer:
Trasferimento di stato rappresentativo (REST)
Come abbiamo scritto nel Perché gli autobus non volano Carta bianca, "Le API mobili e aziendali sono esposte principalmente tramite il protocollo REST con i dati codificati tramite JSON. Dal punto di vista delle piattaforme di integrazione, REST e JSON insieme stanno sostituendo sempre più SOAP e XML, rendendo gli ESB meno rilevanti nell'attuale architettura SMAC aziendale".
L'architettura di SnapLogic è interamente basata su REST. Abbiamo REST Snaps (come mostrato nella schermata a destra) e REST è il modo in cui il piano di controllo comunica con il piano dati (si veda il post sulla Software Defined Integration e il diagramma dell'architettura di alto livello qui sotto). Come abbiamo descritto nel 2011, agli inizi della costruzione della nostra nuova Elastic Integration Platform:
"REST consente di pubblicare i propri dati e di farli utilizzare ad altri, indipendentemente da dove si trovino. Basta guardare l'URI per avere un'indicazione su come procedere. Tuttavia, nonostante tutti questi vantaggi, basare SnapLogic su REST ci ha garantito la stessa sicurezza e la stessa scalabilità massiccia del Web in generale".
Nel prossimo post sui requisiti di integrazione moderna, tratteremo la connettività in modo più dettagliato.
