Programmation axée sur les services

La programmation orientée services (POS) est un paradigme de programmation qui utilise les « services » comme unité de travail informatique pour concevoir et implémenter des applications métier intégrées et des logiciels critiques . Les services peuvent représenter des étapes de processus métier ; ainsi, l’une des principales applications de ce paradigme est la livraison économique d’applications métier autonomes ou composites capables de s’intégrer de l’intérieur vers l’extérieur. Bien qu’elle favorise intrinsèquement l’architecture orientée services (SOA), la POS s’en distingue. Alors que la SOA se concentre sur la communication entre systèmes via des « services » , la POS propose une nouvelle technique pour construire des modules d’application agiles en utilisant des services en mémoire comme unité de travail.

Dans SOP, un service en mémoire peut être externalisé de manière transparente en tant qu'opération de service web . Grâce à ses standards de services web indépendants du langage et de la plateforme, SOP prend en charge tous les paradigmes de programmation, langages et plateformes existants. En SOP, la conception des programmes s'articule autour de la sémantique des appels de service, du routage logique et de la description des flux de données à travers des interfaces de service bien définies. Tous les modules de programme SOP sont encapsulés sous forme de services, et un service peut être composé d'autres services imbriqués de manière hiérarchique, avec une profondeur quasi illimitée pour cette hiérarchie de services. Un service composite peut également contenir des constructions de programmation, dont certaines sont spécifiques et uniques à SOP. Un service peut être un composant système externalisé, accessible via n'importe quelle API propriétaire ou standard de service web utilisant une technique de plug-in en mémoire.

Bien que SOP prenne en charge les constructions de programmation de base pour le séquençage, la sélection et l'itération, il se distingue par une multitude de nouvelles constructions offrant des fonctionnalités natives intégrées dédiées à la manipulation de listes de données, l'intégration de données , le multithreading automatisé des modules de service, la gestion déclarative du contexte et la synchronisation des services. La conception de SOP permet aux programmeurs de synchroniser sémantiquement l'exécution des services afin d'en garantir l'exactitude, ou de déclarer un module de service comme une limite de transaction avec un comportement de validation/annulation automatisé.

Des outils de conception sémantique et des plateformes d'automatisation d'exécution peuvent être conçus pour prendre en charge les concepts fondamentaux de l'architecture orientée services (SOA). Par exemple, une machine virtuelle de services (SVM) qui crée automatiquement des objets de service en tant qu'unités de travail et gère leur contexte peut être conçue pour s'exécuter à partir des métadonnées du programme SOP stockées en XML et créées par un outil d'automatisation lors de la conception. En termes d'architecture orientée services (SOA), la SVM est à la fois un producteur et un consommateur de services.

Les concepts SOP constituent une base solide pour une approche sémantique de l'intégration de la programmation et de la logique applicative. Cette approche présente trois avantages majeurs :

• Sur le plan sémantique, cela peut élever le niveau d'abstraction pour la création d'applications métier composites et ainsi accroître considérablement la réactivité au changement (c'est-à-dire l'agilité de l'entreprise ).
• Elle permet d'unifier les techniques d'intégration et de développement de composants logiciels sous un concept unique, réduisant ainsi considérablement la complexité de l'intégration. Cette approche unifiée autorise une intégration « de l'intérieur vers l'extérieur » sans duplication des données, diminuant de ce fait le coût et la complexité de l'ensemble du processus.
• Automatisez le multithreading et la virtualisation des applications au niveau granulaire (unité de travail).

Voici quelques-uns des concepts clés des procédures opérationnelles standard (SOP) :

Dans l'architecture orientée services (SOP), les modules logiciels en mémoire sont rigoureusement encapsulés par des interfaces de service bien définies, pouvant être externalisées à la demande sous forme d'opérations de service web. Cette unité d'encapsulation minimale maximise les possibilités de réutilisation au sein d'autres modules de service en mémoire, ainsi qu'avec les systèmes logiciels existants et hérités . En utilisant les interfaces de service pour masquer les informations , la SOP étend les principes de conception orientée services de l'architecture orientée services (SOA) afin d'assurer la séparation des préoccupations entre les modules de service en mémoire.

Dans SOP, une interface de service est un objet en mémoire qui décrit une tâche logicielle bien définie, avec des structures de données d'entrée et de sortie également bien définies . Les interfaces de service peuvent être regroupées en packages. Une interface de service SOP peut être externalisée sous forme d' opération WSDL , et un service unique ou un ensemble de services peut être décrit à l'aide de WSDL. De plus, les interfaces de service peuvent être affectées à un ou plusieurs groupes de services en fonction de propriétés partagées.

Dans SOP, les propriétés d'exécution stockées dans les métadonnées de l'interface de service servent de contrat avec la machine virtuelle de service (SVM). Un exemple d'utilisation de ces propriétés est la synchronisation déclarative de services . Une interface de service peut être déclarée comme entièrement synchronisée, ce qui signifie qu'une seule instance de ce service peut s'exécuter à un instant donné. Elle peut également être synchronisée en fonction de la valeur réelle des entrées clés lors de l'exécution, empêchant ainsi l'exécution simultanée de deux instances de ce service ayant la même valeur pour leurs données d'entrée clés. De plus, la synchronisation peut être déclarée entre les interfaces de services appartenant au même groupe de services. Par exemple, si deux services, « CompteCrédit » et « CompteDébit », appartiennent au même groupe de services de synchronisation et sont synchronisés sur le champ d'entrée « nom_du_compte », alors deux instances de « CompteCrédit » et « CompteDébit » ayant le même nom de compte ne peuvent s'exécuter simultanément.

Un invocateur de service effectue des requêtes de service. Il s'agit d'une interface mémoire extensible qui masque l'emplacement du producteur de service ainsi que le protocole de communication utilisé entre le consommateur et le producteur lors des échanges en mémoire, à l'environnement d'exécution SOP, tel qu'une SVM. Le producteur peut être intégré au processus (c'est-à-dire en mémoire), situé en dehors du processus sur la même machine serveur, ou virtualisé sur un ensemble de machines serveurs en réseau. L'utilisation d'un invocateur de service dans SOP est essentielle à la transparence de localisation et à la virtualisation. Une autre caractéristique importante de la couche d'invocateur de service est sa capacité à optimiser la bande passante et le débit lors des communications inter-machines. Par exemple, un « invocateur SOAP » est l'invocateur de service par défaut pour les communications distantes entre machines utilisant les standards des services web . Cet invocateur peut être remplacé dynamiquement si, par exemple, le producteur et le consommateur souhaitent communiquer via une API propriétaire encapsulée pour une sécurité renforcée et une utilisation plus efficace de la bande passante.

Un écouteur de service reçoit les requêtes de service. Il s'agit d'une interface mémoire enfichable qui abstrait le protocole de communication des requêtes de service entrantes adressées à l'environnement d'exécution SOP, tel que le SVM. Grâce à cette couche d'abstraction, l'environnement d'exécution SOP peut être virtuellement intégré à l' adresse mémoire de n'importe quel environnement de programmation ou service applicatif traditionnel.

Dans le cadre de l'architecture SOP, un module de service peut être implémenté comme un service composite ou atomique. Il est important de noter que les modules de service construits selon le paradigme SOP sont extravertis et peuvent être externalisés de manière transparente via des standards tels que SOAP ou tout protocole propriétaire .

L'une des caractéristiques les plus importantes de SOP est sa capacité à prendre en charge une approche de programmation entièrement sémantique. De plus, cette approche sémantique peut être intégrée à un environnement visuel reposant sur une couche de métadonnées dédiée au stockage des définitions d'interface et de module de service. Par ailleurs, si l'environnement d'exécution SOP est pris en charge par un SVM capable d'interpréter cette couche de métadonnées, la génération automatique de code devient superflue. Il en résulte un gain de productivité considérable lors du développement, une simplification des tests et une agilité de déploiement significative.

L'implémentation d'un service composite est la définition sémantique d'un module de service basée sur les techniques et concepts de la programmation orientée services (SOP). En examinant la définition d'interface (dont le fonctionnement est opaque) d'un service composite, on peut observer d'autres interfaces de service interconnectées et reliées à des constructions de programmation SOP. Un service composite possède une définition récursive : tout service interne peut être un autre service atomique ou composite. Un service interne peut également être une référence récursive au service composite qui le contient.

SOP prend en charge les constructions de programmation de base pour le séquençage, la sélection et l'itération, ainsi que des comportements avancés intégrés. De plus, SOP prend en charge les constructions sémantiques pour le mappage, la traduction, la manipulation et le flux automatiques des données entre les services internes d'un service composite.

Un service inclus dans la définition d'un service composite (un « service interne ») est implicitement séquencé par la connectivité sémantique des ports de succès ou d'échec intégrés aux autres services internes et son port d'activation intégré. Lorsqu'un service interne s'exécute correctement, tous les services internes connectés à son port de succès s'exécutent ensuite. En cas d'échec d'un service interne, tous les services connectés à son port d'échec s'exécutent ensuite.

La sélection logique s'effectue grâce à des structures de branchement pilotées par les données et d'autres structures configurables. De manière générale, les structures configurables sont des services intégrés à la plateforme SOP, dotés d'entrées et de sorties pouvant adopter le format d'entrée/sortie d'autres services connectés. Par exemple, une structure configurable utilisée pour filtrer les données de sortie des services peut prendre une liste de commandes clients, de commandes fournisseurs ou toute autre structure de données, et filtrer ces données en fonction des propriétés de filtrage définies par l'utilisateur et stockées sur l'interface de cette instance de la structure de filtrage. Dans cet exemple, la structure à filtrer devient l'entrée de l'instance concernée de la structure de filtrage, et la même structure représentant les données filtrées devient la sortie de la structure configurable.

Un service composite peut être déclaré comme s'exécutant en boucle. Cette boucle peut être limitée à un nombre fixe d'itérations, avec un délai intégré optionnel entre elles, et peut se terminer dynamiquement à l'aide d'une instruction « sortie de service avec succès » ou « sortie de service avec échec » au sein du service composite en cours de boucle. De plus, toute interface de service peut s'exécuter automatiquement en mode boucle ou « foreach » si elle reçoit au moins deux composants d'entrée lors de sa préparation automatique. Ce comportement est pris en charge dès la conception lorsqu'une structure de liste de données d'un service est connectée à un service qui prend une seule structure de données (c'est-à-dire non plurielle) en entrée. Si une propriété d'exécution de l'interface de service composite est déclarée pour prendre en charge l'exécution parallèle de « foreach », l'environnement d'automatisation d'exécution peut automatiquement multithreader la boucle et l'exécuter en parallèle. Ceci illustre comment les constructions de programmation SOP offrent des fonctionnalités avancées intégrées.

Les mécanismes de mappage , de traduction et de transformation des données permettent le transfert automatique de données entre les services internes. Un service interne est prêt à s'exécuter lorsqu'il est activé et que toutes ses dépendances d'entrée sont résolues. Tous les services internes préparés au sein d'un service composite s'exécutent en parallèle, formant une séquence appelée « hypercycle ». C'est l'un des moyens par lesquels le traitement parallèle automatique est pris en charge par SOP. La définition d'un service composite contient un graphe orienté implicite des dépendances des services internes. L'environnement d'exécution de SOP peut créer un graphe d'exécution à partir de ce graphe orienté en instanciant et en exécutant automatiquement les services internes en parallèle chaque fois que cela est possible.

La gestion des exceptions est une erreur d'exécution en Java. Dans SOP, elle s'effectue simplement en connectant le port d'échec des services internes à un autre service interne, ou à une construction de programmation. Les constructions « Exit with failure » ​​et « Exit with success » sont des exemples de constructions utilisées pour la gestion des exceptions. Si aucune action n'est entreprise sur le port d'échec d'un service, le service externe (parent) échouera automatiquement et les messages de sortie standard du service interne défaillant seront automatiquement transmis à la sortie standard du parent.

Un service composite peut être déclaré comme limite de transaction . L'environnement d'exécution de SOP crée et gère automatiquement un contexte hiérarchique pour les objets de service composite utilisés comme limite de transaction. Ce contexte effectue automatiquement une validation ou une annulation en cas de succès de l'exécution du service composite.

Des services composites spéciaux, appelés services de compensation, peuvent être associés à n'importe quel service au sein de SOP. Lorsqu'un service composite déclaré comme limite de transaction échoue sans gestion des exceptions, l'environnement d'exécution SOP déclenche automatiquement les services de compensation associés à tous les services internes ayant déjà été exécutés avec succès.

Un service atomique est une extension en mémoire de l'environnement d'exécution SOP via une interface native de service (SNI). Il s'agit essentiellement d'un mécanisme de plug-in. Par exemple, si SOP est automatisé via une SVM , un plug-in de service est chargé dynamiquement dans la SVM lorsqu'un service associé est consommé. Un exemple de plug-in de service serait un plug-in de communication SOAP capable de traduire à la volée toute donnée d'entrée d'un service en mémoire en une requête SOAP de service Web, de l'envoyer à un producteur de service, puis de traduire la réponse SOAP correspondante en données de sortie en mémoire sur le service. Un autre exemple de plug-in de service est un plug-in SQL de base de données standard prenant en charge les opérations d'accès, de modification et d'interrogation des données. Un autre exemple illustrant l'importance fondamentale des services atomiques et des plug-ins de service est l'utilisation d'un invocateur de service comme plug-in de service pour virtualiser de manière transparente les services sur différentes instances d'une plateforme SOP. Cette virtualisation unique au niveau des composants est appelée « virtualisation de grille de services » afin de la distinguer de la virtualisation traditionnelle au niveau des applications ou des processus .

L'approche SOP offre d'importantes possibilités de prise en charge des problématiques transversales pour toutes les applications développées à l'aide de cette technique. Les sections suivantes présentent certaines de ces possibilités :

L'environnement d'exécution SOP peut fournir systématiquement un profilage, une journalisation et une mesure intégrés et optimisés pour tous les services en temps réel.

En fonction des valeurs d'entrée déclarées d'une instance de service, les sorties d'un service interne non sensible au temps peuvent être mises en cache par l'environnement d'exécution SOP lors de son exécution dans le contexte d'un service composite particulier. Lorsqu'un service est mis en cache pour certaines valeurs d'entrée, l'environnement d'exécution SOP récupère les sorties correspondantes depuis son cache de services au lieu de consommer le service. La mise à disposition de ce mécanisme intégré pour le développeur d'applications SOP peut réduire considérablement la charge sur les systèmes back-end.

SOP offre un mécanisme permettant d'associer un service composite particulier, appelé service de déclenchement, à n'importe quel autre service. Lors de l'utilisation de ce service, la plateforme SOP crée et utilise automatiquement une instance du service de déclenchement associé, avec une copie en mémoire des entrées du service déclencheur. Cette utilisation est non intrusive pour l'exécution du service déclencheur. Un déclencheur de service peut être configuré pour s'exécuter lors de l'activation, de l'échec ou de la réussite de l'exécution du service déclencheur.

Outre la possibilité d'appeler n'importe quel service, les événements de requête de service et la mémoire partagée sont deux mécanismes intégrés de SOP permettant la communication entre services. La consommation d'un service est traitée comme un événement dans SOP. SOP fournit un mécanisme d'événements basé sur la corrélation, qui entraîne la préemption d'un service composite en cours d'exécution ayant déclaré, via une instruction « wait », la nécessité d'attendre la survenue d'un ou plusieurs autres événements de consommation de service avec des valeurs de données d'entrée spécifiques. L'exécution du service composite se poursuit lorsque des services sont consommés avec les entrées clés de corrélation spécifiques associées à l'instruction « wait ». SOP fournit également un espace de mémoire partagée avec contrôle d'accès, où les services peuvent accéder et mettre à jour une structure de données bien définie , similaire à la structure d'entrée/sortie des services. Le mécanisme de mémoire partagée de SOP est accessible par programmation via les interfaces de service.

Dans SOP, les personnalisations sont gérées grâce à une fonctionnalité innovante appelée « Surcharges de service ». Cette fonctionnalité permet de surcharger statiquement ou dynamiquement une implémentation de service par l'une des nombreuses implémentations possibles lors de l'exécution. Elle est analogue au polymorphisme en programmation orientée objet . Chaque implémentation de surcharge peut être associée à un ou plusieurs portefeuilles de configuration de surcharges afin de gérer l'activation de groupes de surcharges connexes dans différentes installations de l'application SOP au moment du déploiement .

Certains services peuvent être déployés en toute sécurité pour une utilisation externe par une interface graphique ( GUI ) ou d'autres applications. Une fois les comptes de service définis, l'environnement d'exécution SOP gère automatiquement l'accès via des mécanismes de provisionnement de comptes consommateurs .

L'environnement d'exécution SOP assure une authentification et une autorisation de service intégrées et systématiques . À des fins d'autorisation, les projets de développement SOP, les comptes clients, les packages et les services sont considérés comme des ressources soumises à un contrôle d'accès. L'environnement d'exécution SOP fournit ainsi une autorisation intégrée. La sécurité des autorisations et des communications, qu'elles soient standard ou propriétaires, est personnalisée grâce aux surcharges de service, aux modules d'appel de plug-in et aux modules d'écoute de service.

Étant donné que tous les artefacts de SOP sont des services bien encapsulés et que tous les mécanismes SOP, comme la mémoire partagée, peuvent être fournis sous forme de services distribuables, la virtualisation à grande échelle peut être automatisée par l'environnement d'exécution SOP. De plus, la pile de services hiérarchique d'un service composite, avec les multiples graphes d'exécution associés à ses services internes à chaque niveau, offre d'immenses possibilités d'automatisation du multithreading à l'environnement d'exécution SOP.

Le terme « programmation orientée services » a été publié pour la première fois en 2002 par Alberto Sillitti, Tullio Vernazza et Giancarlo Succi dans un ouvrage intitulé « Software Reuse: Methods, Techniques, and Tools ». La programmation orientée services (SOP), telle que décrite ci-dessus, reflète certains aspects de l'utilisation du terme proposé par Sillitti, Vernazza et Succi.

Aujourd'hui, le paradigme des procédures opérationnelles standard (SOP) n'en est qu'à ses débuts en matière d'adoption généralisée. Quatre facteurs de marché alimentent cette adoption :

• Architecture des processeurs multicœurs : face aux problèmes de dissipation thermique liés à l’augmentation de la fréquence d’horloge des processeurs au-delà de 4 GHz, les principaux fabricants de processeurs, tels qu’Intel, se sont tournés vers l’architecture multicœur afin d’offrir des performances toujours plus élevées. Voir l’article « La fin des avantages indus ». Ce changement de conception impose une évolution dans le développement des modules logiciels et des applications : ces dernières doivent être conçues pour la concurrence afin d’exploiter les processeurs multicœurs , et la programmation concurrente représente un véritable défi. Le protocole SOP offre une solution intégrée pour le multithreading automatisé .
• Virtualisation d'applications : SOP favorise un microcontrôle intégré de la transparence de localisation des composants de service de tout module de service. Il en résulte une virtualisation automatique et granulaire des composants d'une application (et non de l'ensemble du processus applicatif) sur un cluster ou une grille de plateformes d'exécution SOP.
• Architecture orientée services (SOA) et demande d'applications intégrées et composites : dans un premier temps, l'adoption des processus orientés services (SOP) suivra la courbe d'adoption de la SOA, avec un léger décalage. En effet, les services générés par la SOA peuvent être facilement assemblés et utilisés via les SOP. Plus les services Web prolifèrent, plus il devient pertinent de tirer parti de la nature sémantique des SOP. Par ailleurs, la SOA étant intrinsèquement liée aux SOP, ces derniers offrent une solution économique pour déployer la SOA sur les marchés grand public.
• Logiciel en tant que service (SaaS) : les plateformes SaaS actuelles ne permettent pas de répondre aux exigences de personnalisation et d’intégration des grandes entreprises. Les solutions logicielles intégrées (SOP) peuvent considérablement simplifier ces processus, ce qui favorisera leur intégration dans les plateformes SaaS de nouvelle génération.