Le terme «architecture orientée services» est-il devenu un jargon vide de sens? [fermé]

On m'a demandé aujourd'hui si j'avais de l'expérience avec "l'architecture orientée services" et bien que je pense que oui. Le concept, pour moi, semble si confus que je ne sais plus comment vous pourriez honnêtement répondre à cette question.

J'ai recouru à Googler le terme dans un effort pour obtenir une définition concise du concept et comment il diffère des autres architectures. Après avoir lu un certain nombre d'articles dessus, le seul fil conducteur que je semble être en mesure de trouver est un système avec plusieurs composants qui se parlent sur une sorte d'interface, avec peut-être une légère préférence pour XML / SOAP.

Il semble que presque toutes les applications puissent être définies comme SOA, en particulier une application Web. Ce terme est-il tombé dans le piège du "Web 2.0" et est-il devenu un terme signifiant ce que vous voulez qu'il signifie?

Suis-je loin de la base ici? Quand vous entendez le terme, cela signifie-t-il quelque chose de spécifique pour vous? Si c'est le cas, j'aimerais une définition concise qui démontre clairement ce qui est et ce qui n'est PAS spécifiquement SOA.

Je crois que la signification originale de SOA était basée sur des services avec des interfaces bien définies qui peuvent être consommées par programme . L'accent était mis sur les interfaces de service plutôt que sur les terminaux d'interface utilisateur, les communications ou les bases de données. L'élément clé était les services consommant d'autres services. Le service A peut appeler le service B, obtenir le résultat et appeler le service C ou D. Vous pouvez avoir un ensemble de services spécialisés et en concevoir une solution en les combinant de manière à résoudre le problème du client.

SOA est souvent confondu avec SaaS (logiciel en tant que service), qui fait référence au modèle de tarification dans lequel l'utilisateur paie pour l'utilisation du service auquel il s'est abonné, plutôt que d'acheter une licence pour une copie du produit logiciel. Pour répondre au troisième paragraphe de votre question, une application Web n'est probablement pas SOA, mais peut être SaaS.

Le terme a définitivement perdu une partie de sa signification. Dans l'organisation où je travaille, le terme SOA est souvent utilisé de manière interchangeable avec SaaS et fait référence à une équipe de professionnels de l' informatique ( technologies de l'information par opposition au développement de produits logiciels ) qui configurent les serveurs et les routeurs et installent les produits logiciels à exécuter sur eux. Certains d'entre eux ont des titres comme «SOA Architect», mais aucun d'entre eux n'a rien à voir avec l'architecture, la conception, l'implémentation ou le test du logiciel.

J'ai fait la même chose googler SOA pour voir ce que c'est vraiment, et oui, il est un peu abusé. Quand je pense à SOA, je pense à ce qui suit:

1. Un programme décapité sans tête ...
2. Cela utilise la connectivité sans état (ala HTTP) ...
3. Communiquer dans des formats indépendants de la plateforme

SOA peut être contrasté avec l'architecture client-serveur (une architecture de service avec état) et les bibliothèques, qui sont des modules connectés aux programmes via un éditeur de liens.

Donc, quand les gens en parlent, je le prends généralement avec un grain de sel. J'ai aussi tendance à l'appeler simplement «services Web». Avec les services Web, l'architecture est implicite.

Les définitions strictes de la SOA dépassent de loin la ligne de coût / bénéfice car elles sont théoriques dans de nombreux cas.

À moins que votre produit ne soit les services eux-mêmes, vous avez souvent besoin d'un point de vue différent.

Une définition utilisable de SOA signifie que votre architecture globale est conviviale. Un système entièrement construit à partir de services atomiques n'est généralement pas le bon plan, et certains services seront organisés de manière fonctionnelle tandis que d'autres seront à responsabilité unique. J'ai peut-être des boîtes noires, j'ai peut-être des processus hors ligne, mais s'il existe une collection de services découvrable à travers laquelle je peux obtenir une quantité significative de travail, c'est ma définition minimale.

Mis à part le débat sur ce qu'il signifie réellement, le concept (quoi qu'il signifie) a souffert dans de nombreux milieux en étant appliqué à des endroits où il ne correspond tout simplement pas.

Par exemple, si je construis quelque chose qui est censé être un processus de boîte noire et évolue à travers le parallélisme et non la segmentation et la distribution, je peux avoir un service pour exposer / parler à la boîte noire, mais certaines personnes continuent d'essayer de mettre les services à l'intérieur du boîte.

En tant que définition technique stricte, elle a toujours été indéfinie, mais l'idée n'est pas sans fondement là où elle se situe.

J'ai eu la malchance de travailler sur quelques systèmes d'entreprise où la gestion a été vendue sur SOA. En tant que développeur, je regarde les systèmes et je vois un tas de logiciels derrière un service Web qui fait des choses. Il aurait pu être rédigé dans une variété de langues et d'architectures, dont aucune n'aurait d'importance ou ne serait pertinente pour les clients appelant les services et dont aucune ne porte en réalité l'acronyme "SOA" n'importe où dans sa documentation.

Mais la direction veut "SOA" !!! Ils ont donc acheté des serveurs très chers d'une certaine grande entreprise qui ont des autocollants "SOA" appliqués sur les autocollants "Web Service" précédents qui ont été appliqués sur les autocollants "JEE" précédents qui ont été appliqués sur .... vous avez eu l'idée. Et en conséquence, en tant que développeurs, nous nous asseyons en faisant glisser et en déposant des icônes minuscules autour d'un écran pour créer des "COMPOSANTS" "SOA" qui fonctionnent à moitié aussi bien que si nous l'avions fait avec quelque chose de simple comme les haricots EBJ3, les composants de printemps, etc. .

Donc, mon conseil est si vous êtes interrogé sur SOA, dites "Oui, j'ai fait SOA, j'ai écrit de nombreux systèmes qui utilisent une architecture orientée services pour faire des choses. De quelle technologie SOA parlez-vous?". Et s'ils commencent à parler avec des yeux brillants et des regards nostalgiques sur les COMPOSANTS DU SOA, DRAG AND DROP, et comment cela facilite le développement. Reculez lentement et évitez tout contact visuel!

Je pense que cela pourrait avoir un sens: une chose est lorsque vous avez des modules "esclaves" appelés en cas de besoin, et une autre chose est lorsque vous avez des processus de service / démon fonctionnant indépendamment et répondant à vos demandes, se parlant éventuellement, vivant leur propre vie en d'autres termes. Avec cette approche, vous pouvez avoir un système énorme, évolutif et physiquement distribué. J'en ai vu par exemple dans le domaine de la téléphonie mobile. Mais ce n'est qu'une supposition.

(Voyons maintenant ce que Wikipedia dit sur SOA ... Whoa.)