Pourquoi n'y a-t-il pas de langage orienté services?

Éditer:

Pour éviter toute confusion: je ne parle pas des services Web et autres. Je parle de structurer des applications en interne, il ne s'agit pas de la façon dont les ordinateurs communiquent. Il s'agit des langages de programmation, des compilateurs et de la façon dont le paradigme de programmation impératif est étendu.

Original:

Dans le domaine de la programmation impérative, nous avons vu deux paradigmes au cours des 20 dernières années (ou plus): orienté objet (OO) et orienté service (SO). à base de composants (CB).

Les deux paradigmes étendent le paradigme de programmation impérative en introduisant leur propre notion de modules. OO les appelle objets (et classes) et leur permet d'encapsuler à la fois les données (champs) et les procédures (méthodes). SO, en revanche, sépare les données (enregistrements, beans, ...) du code (composants, services).

Cependant, seul OO possède des langages de programmation qui prennent en charge nativement son paradigme: Smalltalk, C ++, Java et tous les autres compatibles JVM, C # et tous les autres compatibles .NET, Python, etc.

SO n'a pas une telle langue maternelle. Il n'existe que par-dessus les langages procéduraux ou langages OO: COM / DCOM (binaire, C, C ++), CORBA, EJB, Spring, Guice (tout Java), ...

Ces frameworks SO souffrent clairement du manque de prise en charge en langue maternelle de leurs concepts.

• Ils commencent à utiliser des classes OO pour représenter des services et des enregistrements. Cela conduit à des conceptions où il existe une distinction claire entre les classes qui ont uniquement des méthodes (services) et celles qui ont uniquement des champs (enregistrements). L'héritage entre services ou enregistrements est ensuite simulé par héritage de classes. Techniquement, ce n'est pas gardé si strictement mais en général les programmeurs sont invités à faire des classes pour jouer seulement un des deux rôles.
• Ils utilisent des langages externes supplémentaires pour représenter les parties manquantes: IDL, configurations XML, annotations en code Java, ou même DSL intégré comme dans Guice. Cela est particulièrement nécessaire, mais sans s'y limiter, car la composition des services ne fait pas partie du code de service lui-même. Dans OO, les objets créent d'autres objets, il n'y a donc pas besoin de telles fonctionnalités, mais pour SO, c'est parce que les services n'instancient ni ne configurent d'autres services.
• Ils établissent un effet de plate-forme interne au-dessus d'OO (début EJB, CORBA) où le programmeur doit écrire tout le code nécessaire pour "piloter" SO. Les classes ne représentent qu'une partie de la nature d'un service et de nombreuses classes doivent être écrites pour former un service ensemble. Toute cette plaque de chaudière est nécessaire car il n'y a pas de compilateur SO qui le ferait pour le programmeur. C'est comme certaines personnes l'ont fait en C pour OO quand il n'y avait pas de C ++. Vous passez simplement l'enregistrement qui contient les données de l'objet comme premier paramètre à la procédure qui est la méthode. Dans un langage OO, ce paramètre est implicite et le compilateur produit tout le code dont nous avons besoin pour les fonctions virtuelles, etc. Pour SO, cela est clairement manquant.
• En particulier, les nouveaux cadres utilisent largement AOP ou introspection pour ajouter les parties manquantes à un langage OO. Cela n'apporte pas l'expressivité du langage nécessaire mais évite le code de la plateforme de la chaudière décrit au point précédent.
• Certains cadres utilisent la génération de code pour produire le code de plaque de chaudière. Les fichiers de configuration en XML ou les annotations en code OO en sont la source d'informations.

Tous les phénomènes que j'ai mentionnés ci-dessus ne peuvent pas être attribués à SO, mais j'espère que cela montre clairement qu'il existe un besoin pour un langage SO. Puisque ce paradigme est si populaire: pourquoi n'y en a-t-il pas? Ou peut-être y en a-t-il des universitaires, mais au moins l'industrie n'en utilise pas.

Parce que <5% du code définit en fait un service, et je dirais un temps considérablement moins long. Une fois l'interface définie, c'est largement fait. Le reste du temps est passé en OO (ou alternatives) pour faire fonctionner les choses .

Autrement dit, ce n'est pas une grande victoire de faire un langage spécialisé pour cette petite tranche du problème. Si quoi que ce soit, avoir deux langues (une pour le service et une pour la mise en œuvre / consommation) demande simplement une complexité d'intégration accrue.

[modifier pour la clarification OP que c'est la disposition interne de l'application, pas la limite de l'application]:

L'objectif principal d'une telle configuration de service est d'avoir des points de contact minces entre les services. Ma raison d'origine tient toujours (imo) et ajoute à cette réponse le fait que relativement peu de problèmes conviennent bien à une structure d'application interne basée sur le service. Donc, non seulement vous abordez une petite partie du problème, mais un pourcentage global de problèmes plus faible.

Les langages fonctionnels sont très axés sur les services dans leur noyau. Au lieu de créer des objets et d'appeler des fonctions dessus, vous créez des fonctions et leur passez des messages. Erlang est un excellent exemple de cette technique car, même au-delà des aspects fonctionnels du langage, une communication inter-processus et même inter-machine est intégrée dans son cadre principal, vous permettant d'envoyer des messages à un processus distant comme s'il s'agissait d'un processus local. .

D'autres langages tels que Scala, Clojure et F # fournissent également une sémantique "orientée service". Le problème n'est pas qu'ils n'existent pas, c'est que la population en général a peur d'eux et qu'ils ne sont donc pas aussi populaires.

L'orientation service était / est une réponse architecturale aux problèmes d'intégration. L'intégration est idéalement une solution tout compris qui adapte n'importe quelle langue, produit, appareil, ressource existante dans une image plus grande.

Aucun nouveau langage n'est nécessaire, car le problème est déjà d'avoir trop de langues , ce qui entraîne des coûts d'interopérabilité élevés.

Cependant, un type de langage a été introduit, le langage de définition de service Web. WSDL est un méta-langage de SOA (et il y en a un autre abandonné pour REST nommé WADL)

Je vais tourner la question et demander "à quoi ressemblerait un langage SO?"

Comment ces contrats entre modules seraient-ils rédigés?
Comment les mécanismes fondamentaux de fonctionnement seraient-ils exécutés?

Les services orientés sont une propriété de l'application, pas nécessairement la langue utilisée. Le service est une construction qui repose sur une fonction. La fonction est une construction qui s'appuie sur la mécanique d'un langage de programmation pour traduire l'opération en instructions exécutables par la machine.

BPEL est un exemple possible de langage SO, mais il est de très haut niveau et repose sur la disponibilité de modules à utiliser. Ces modules sont à leur tour écrits dans des langages non-BPEL afin que le travail puisse être effectué (alias traduit en langage machine).

Great Q et m'a donné un bon moment de réflexion.

Je vais répondre à ma propre question pour voir combien de personnes sont d'accord et en désaccord.

Quelques possibilités:

• Il semble difficile de construire un langage SO. Principalement à cause de la séparation de la mise en œuvre des services et de leur composition. Il y a quelques solutions académiques dont j'ai entendu parler à l'université (sans référence, désolé), mais cela ne semble pas faire son entrée dans l'industrie. Mais je considère cela comme une excuse, pas une vraie raison. Les langages OO et les compilateurs sont également assez difficiles à implémenter, mais il existe depuis longtemps des solutions sur le marché.

• Les programmeurs utilisent des langages OO pour SO parce qu'ils ne comprennent pas OO et l'utilisent de manière incorrecte. Je dis mal parce qu'il y a deux concepts fondamentaux en OO qui contredisent SO:

  1. La fonctionnalité va à la classe où se trouvent les données sur lesquelles ils travaillent. Le code et les données sont couplés ensemble dans le même module. Ce n'est pas le style OO d'avoir des classes distinctes qui fonctionnent sur les données d'autres classes. C'est l'approche des outils et matériaux (WAM) de Züllighofen qui correspond au paradigme SO.

  2. Les objets créent d'autres objets et forment des réseaux d'objets. Ils peuvent créer des hiérarchies ou toutes relations complexes. Les services forment toujours des réseaux plats composés de l'extérieur. Les services n'ont généralement qu'une seule instance (Singleton) tandis que les objets sont instanciés aussi souvent que l'entité qu'ils représentent existe. Les enregistrements dans SO ne sont pas connectés dans les réseaux.

• Certaines fonctionnalités d'OO ressemblent à SO, ou peuvent être utilisées pour faciliter ce qui est nécessaire pour SO, il est donc pratique d'utiliser un langage OO.

  1. Le principe d'inversion de dépendance dans OO est similaire à la façon dont les services sont composés en externe.

  2. Les objets singleton sont comme des services, les usines d'objets sont comme des localisateurs de services.

  3. OO possède également des interfaces similaires aux interfaces de service.

  4. L'héritage de classes peut être similaire (le même?) À l'héritage de services et d'enregistrements.

• OO et SO sont utiles pour différents types de problèmes. Donc, dans toutes les applications, il est tentant d'utiliser le paradigme ici ou là. Avoir une langue distincte empêcherait de basculer entre les deux dans le même programme.

• SO n'est pas seulement un paradigme de programmation mais aussi un comportement de programme: les services Web, les composants du système d'exploitation, etc. sont SO mais n'ont pas nécessairement besoin d'être écrits dans un langage SO. Ce type de "composants binaires" est très naturel et réussi. Mais c'est autre chose: c'est la façon dont les programmes communiquent entre eux, et non la façon dont le programme communique en interne. Je suppose que les gens mélangent ça assez souvent.