Architecture Orientée Service

L'architecture orientée services est un modèle d'interaction applicative qui met en œuvre des services (composants logiciels) :

• avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML)

• des couplages externes « lâches » (par l'utilisation d'une couche d'interface interopérable, le plus souvent un service web WS-*)

L'objectif d'une architecture orientée services est donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma d'interaction entre ces services.

Notion de Service

C'est une fonction encapsulée dans un composant que l'on peut interroger à l'aide d'une requête composée d'un ou plusieurs paramètres et fournissant une ou plusieurs réponses. Idéalement chaque service doit être indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité.

Description du service

La description du service, consiste à décrire les paramètres d'entrée du service et le format et le type des données retournées.

Le principal format de description de services est WSDL (Web Services Description Language), normalisé par le W3C.

Publication et Découverte

La publication consiste à publier dans un registre (en anglais registry ou repository) les services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par l'OASIS. L'UDDI est un annuaire de services fondé sur XML et plus particulièrement destiné aux services Web. Un annuaire UDDI permet de localiser sur le réseau le service Web recherché.

Invocation

L'invocation, représentant la connexion et l'interaction du client avec le service. Le principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access Protocol).

WebServices

Les services web représentent un mécanisme de communication entre applications distantes à travers le réseau internet indépendant de tout langage de programmation et de toute plate-forme d'exécution :

• utilisant le protocole HTTP comme moyen de transport. Ainsi, les communications s'effectuent sur un support universel, maîtrisé et généralement non filtré par les pare-feux ;

• employant une syntaxe basée sur la notation XML pour décrire les appels de fonctions distantes et les données échangées

• organisant les mécanismes d'appel et de réponse.

Description

Le protocole standard le plus utilisé pour la description de services est WSDL.

Découverte

Le protocole standard le plus utilisé pour la découverte de services est UDDI.

Invocation

Il existe deux grands standards de services web, tous deux basés sur XML :

• XML-RPC (XML Remote Procedure Call) , le plus ancien, fonctionnant sur un principe procédural et sans gestion des états.

• SOAP (Simple Object Access Protocol), fonctionnant selon le modèle objet.

Windows Communication Foundation

C'est l'un des quatre composants majeurs du framework .NET 3.0 (avec WPF, CardSpace et WF). Le modèle de programmation WCF est une couche d'abstraction qui unifie et simplifie la mécanique d'intégration des services Web, .NET Remoting, Microsoft Transaction Server, et Microsoft Message Queuing.

Cette couche permet en outre la redistribution des rôles:

• Le développeur conçoit et développe son service sans se soucier de son implémentation à cible. C'est-à-dire qu'il ne s'intéresse qu'aux caractéristiques structurantes du service pour son intégration au sein d'une Architecture orientée services : le service fonctionne-t-il en mode singleton, en mode asynchrone, avec un callback, etc.

• L’intégrateur (ou l’administrateur), lui, détermine le protocole mais aussi le niveau et le mode de sécurisation du service ainsi développé.

WCF utilise des messages SOAP pour les communications entre processus. Quand un processus WCF discute avec un processus non WCF, le langage XML est utilisé pour les messages SOAP. Pour les messages entre processus WCF, les messages SOAP sont encodés au format binaire.

Un service WCF est composé de trois parties

• une classe service

• un environnement hôte

• un ou plusieurs points finaux (Endpoint)

Point Finaux (Endpoint)

Un client se connecte à un service WCF via un Endpoint. Chaque service expose son contrat via un ou plusieurs Endpoint. Un endpoint a une adresse (url) et des bindings qui exposent comment les données seront transferées.

A/B/C : Address, Binding, Contract

Depuis le framework 3.5 on peut également utiliser un encodeur JSON.

Binding

Un binding détermine les protocoles de communication qui seront utilisés pour un service, les mécanismes de sécurité. Les bindings par défaut définissent des protocoles tels que SOAP over HTTP, SOAP over TCP, SOAP over MQ...

SOAP

SOAP est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.

Le protocole SOAP est composé de deux parties :

• une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement,

• un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre.

==== Contrat (Contract) ====

Le Contrat d'un service web correspond à l'ensemble des opérations qui sont proposées et mises à disposition de ses clients.

On définit le contrat par une interface .Net décorée d’attributs de compilation pour WCF :

<code>

[ServiceContract]

public interface IOrderService

{

    [OperationContract]

    void Process(Order o);

    [OperationContract]

    Info GetInfo(Query q);

}

[DataContract]

public class Order

{

    [DataMember]

    public int orderID;

    [DataMember]

    public int partNumber;

    [DataMember]

    public int price;

    [DataMember]

    public string info;

}

[DataContract]

public class Query

{

    [DataMember]

    public int orderID;

}

[DataContract]

public class Info

{

    [DataMember]

    public string info;

}

</code>

=====Comportements (Behaviors)=====

Les Behaviors apportent des fonctions additionnelles :

  * Garantie de service (Accès concurrents, Instanciation, Throttling, Thread-Binding)

  * Gestion d’erreurs (Faults, Exceptions)

  * Gestion de la Performance (Instance Pooling and JITA)

  * Gestion de la Sécurité (Impersonation, Protection, Authorization)

  * Gestion des Transactions (AutoEnlist, Isolation, AutoComplete)

  * Extensibilité (Metadata customization)

Les Behaviors peuvent être attribués (par simple configuration) :

  * A un service

  * A un endpoint

  * A une opération

==== SOAP ====

SOAP est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP.

Le protocole SOAP est composé de deux parties :

  - une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement,

  - un modèle de données, définissant le format du message, c'est-à-dire les informations à transmettre.

MicroServices

Dans une architecture de microservices, une application de grande envergure est divisée en un ensemble de services plus petits. Chaque service s’exécute dans son propre processus et communique avec d’autres processus à l’aide de protocoles tels que HTTP/HTTPS, WebSocket ou AMQP (Advanced Message Queuing Protocol). Chaque microservice implémente un domaine ou une fonctionnalité métier spécifique de bout en bout dans une certaine limite de contexte. Chaque microservice doit être développé de manière autonome et doit être déployable indépendamment. Enfin, chaque microservice doit avoir son modèle de données de domaine et sa logique de domaine associés. Les microservices peuvent être basés sur différentes technologies de stockage de données (SQL, NoSQL) et différents langages de programmation.

Voici quelques-unes des principales caractéristiques des microservices :

Ils sont petits, indépendants et faiblement couplés.

Chaque microservice dispose d’un codebase distinct qui peut être géré par une petite équipe de développement.

Ils sont déployés de manière indépendante. Une équipe peut mettre à jour un microservice existant sans avoir à regénérer et redéployer l’application tout entière.

Ils conservent leurs données ou l’état externe dans leurs bases de données respectives. Contrairement à une architecture monolithique, les microservices ne partagent pas de bases de données.

Ils communiquent entre eux à l’aide d’API bien définies. Les détails de l’implémentation interne de chaque service sont cachés aux autres services.

Ils prennent en charge la programmation polyglotte. Par exemple, les microservices qui composent une application web n’ont pas besoin de partager une pile technologique, des bibliothèques ou des infrastructures.