Cloud Exigences d'intégration : JSON et REST natifs

L'une des principales exigences d'une intégration plateforme en tant que service (iPaaS) et la raison pour laquelle l'héritage de l'intégration est important dans le site cloud est que la technologie est construite sur des normes web modernes - en particulier JSON et REST.

Notation d'objets JavaScript (JSON)

"Il est facile d'insérer des lignes et des colonnes dans un document, mais l'inverse ne fonctionne pas.

- Craig Stewart, directeur de la gestion des produits SnapLogic, dans cette démonstration enregistrée.

SnapLogic traite des documents, plutôt que les lignes et les colonnes des outils traditionnels de type ETL. Dans son article intitulé Technical Advantages of JSON-centric iPaaS, Greg Benson, Chief Scientist de SnapLogic, passe en revue 5 avantages pour le traitement des données et les utilisateurs finaux de l'utilisation de documents comme type de données natif :

  1. Les documents correspondent mieux aux services web modernes.
  2. Les documents se traduisent par des pipelines plus succincts.
  3. Un modèle de document permet aux pipelines d'être couplés de manière souple.(Regardez cette vidéo d'un client pour découvrir les avantages d'une "intégration sans schéma").
  4. Un modèle de document permet une plus grande réutilisation du pipeline.
  5. Les documents sont un surensemble des enregistrements.

En ce qui concerne la prise en charge fondamentale des normes web modernes par SnapLogic, il écrit :

"Notre prise en charge des documents permet à nos points d'accès Snap de consommer directement des données hiérarchiques au format natif et de les envoyer aux points d'accès Snaps en aval dans un pipeline. Cela signifie qu'il n'est pas nécessaire d'aplatir les données en enregistrements ou de transformer un document JSON en chaîne de caractères ou en BLOB.

En ce qui concerne les avantages d'une approche centrée sur JSON, qui prend en charge les données structurées et non structurées de manière transparente, il conclut : "Cette prise en charge native des documents est l'une des nombreuses innovations architecturales que nous avons développées pour aider les entreprises à connecter à la fois les services web et les magasins de données traditionnels."

Voici une vue JSON et tableau d'une requête Twitter Snap dans le concepteur de la plateforme d'intégration élastique SnapLogic :

SnapLogic_Native_JSON

SnapLogic_Rows_Columns

Transfert d'état représentationnel (REST)

REST_SnapsComme nous l'avons écrit dans le Livre blanc sur les raisons pour lesquelles les bus ne volent pas, "Les API mobiles et d'entreprise sont principalement exposées via le protocole REST, les données étant encodées via JSON. Du point de vue de l'intégration plateforme , REST et JSON remplacent de plus en plus SOAP et XML, ce qui rend les ESB moins pertinents dans l'architecture SMAC de l'entreprise d'aujourd'hui".

L'architecture de SnapLogic est entièrement basée sur REST. Nous avons des Snaps REST (comme le montre la capture d'écran à droite) et REST est la façon dont le plan de contrôle communique avec le plan de données (voir l'article sur l'intégration définie par logiciel et le diagramme d'architecture de haut niveau ci-dessous). Comme nous l'avons souligné en 2011, dans les premiers jours de la construction de notre nouvelle plateforme d'intégration élastique:

"REST vous permet de publier vos données et de les faire utiliser par d'autres personnes, où qu'elles se trouvent. Le simple fait de regarder l'URI vous donne une indication sur la manière de procéder. Malgré tous ces avantages, le fait de baser SnapLogic sur REST nous a permis de bénéficier de la même sécurité et de la même évolutivité que le Web dans son ensemble.

Architecture SnapLogic

Dans le prochain article sur les exigences en matière d'intégration moderne, nous aborderons la connectivité plus en détail.

Nous recrutons !

Découvrez votre prochaine grande opportunité de carrière.