Question

L'architecture orientée services semble être de plus en plus une citation populaire ces jours-ci, mais après avoir interrogé autour du bureau, j'ai découvert que je semblais obtenir de nombreuses définitions différentes pour cela.Comment définiriez-vous SOA ?Selon vous, quelle est la définition officielle ?

Était-ce utile?

La solution

Comme le dit Martin Fowler, cela signifie différentes choses pour différentes personnes.Son article sur le sujet est plutôt bon même s'il ne s'agit pas vraiment d'une définition.

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

Cela peut expliquer la difficulté de parvenir à une définition concrète.

Autres conseils

Wikipédia:"Une SOA est une architecture logicielle qui utilise des services logiciels faiblement couplés pour répondre aux exigences des processus métier et des utilisateurs de logiciels.Les ressources sur un réseau dans un environnement SOA sont mises à disposition sous forme de services indépendants accessibles sans connaissance de la mise en œuvre de leur plate-forme sous-jacente.

La SOA n’est pas si nouvelle, mais elle a le potentiel de réaliser des choses étonnantes.Mais l’organisation doit s’y préparer :l'entreprise doit penser en processus et c'est le gros problème

J'irais avec :

Définition d'une série d'opérations commerciales agnostiques sans état sans état créées pour être exploitées dans plusieurs applications.

Une conception SOA comprend des composants (c'est-à-dire prestations de service) qui peut être utilisé par le code quelle que soit l'implémentation (c'est-à-dire n'importe quel système d'exploitation ou langage).Une seule instance d'un service peut également être utilisée par plusieurs applications, alors que, par exemple, une DLL devrait être dupliquée pour chaque application et nécessiter la même technologie d'implémentation que l'application de liaison.

Les services dans une conception SOA sont généralement implémentés sous forme de services Web interopérables.

Il n’y a pas de définition officielle comme Ryan l’a mentionné plus tôt.Cependant, je trouve que la vision de Thomas Erl sur l'ensemble de l'orientation service est assez bien structurée et pertinente.Voici la définition de SOA de son Glossaire SOA (plus):

L'architecture orientée services représente un modèle architectural qui vise à améliorer l'agilité et la rentabilité d'une entreprise tout en réduisant la charge globale de l'informatique sur une organisation.

Thomas Erl est l'auteur de nombreux titres SOA, dont la plupart ont reçu l'approbation de fournisseurs SOA, notamment IBM, Oracle et Microsoft.Ce qu'il y a de bien avec ses livres est qu'ils sont aussi indépendants que possible du fournisseur SOA.Cela signifie que vous en apprendrez davantage sur l'orientation service elle-même et moins sur les middlewares de certains fournisseurs prenant en charge SOA.

Je suis d'accord avec toutes les personnes qui vous renvoient à Fowler à ce sujet.En gros, ça marche comme ça :L'architecture orientée services a la réputation d'être bonne, donc tout ce que les gens veulent associer au bien, ils l'appellent SOA.En réalité, il présente de nombreux inconvénients et peut créer un blocage orienté services ou une architecture orientée dépendances.

Voici ma définition :L'architecture orientée services est une approche d'intégration de systèmes et de réutilisation de code dans laquelle les applications dépendent de la connexion aux services fournis par d'autres applications en cours d'exécution sur le réseau.Ceci se distingue des architectures de composants, où les composants logiciels sont partagés de manière statique entre les applications sous forme de bibliothèques ou de SDK, par exemple.

Une précision ici - "L'architecture orientée services est un Intégration de systèmes et une approche de réutilisation du code où les applications dépendent de connexion aux services fournis par d'autres applications en cours d'exécution sur le réseau."

J'ai un scénario dans lequel deux applications j2ee ont été intégrées à l'aide d'une messagerie événementielle.Voici les phrases ci-dessus de Intégration de systèmes et connexion aux services fournis par d'autres applications en cours d'exécution sur le réseau valoir.Puis-je appeler cela SOA ?

Les principes suivants tiendraient du bien ici 1) apatritude 2) orienté par message - couplé à couplé lâchement déjouet 3) extensible.

Cependant, les éléments suivants n'appliquent pas 1) l'indépendance de la plate-forme - aucune des applications intégrée n'a été conçue pour fonctionner sur une plate-forme différente.2) Les applications sont des applications simples j2ee qui n'ont pas été conçues avec tous les concepts SOA.

J'ai essayé de définir SOA dans un de mes articles de blog.Voici un extrait...

Depuis des années, il est courant de séparer les fonctionnalités en fonctions, classes et modules.L’idée a toujours été que ces composants plus petits et hautement spécialisés sont plus faciles à partager et à maintenir que des blocs de code monolithiques.

Sur le plan fonctionnel, la SOA n'est pas très différente.Les objectifs sont les mêmes : réutilisabilité et maintenance facile.La plus grande différence - dans le cas d'un service Web SOA - est que la bibliothèque partagée incluse dans votre application est remplacée par un appel HTTP.

Voici une définition pour vous :

SOA - Logiciel sur architecture.L'inclusion d'un cadre d'interface fonctionnel inutile et surchargé appelé architecture dans un joli site Web avec un dossier graphique 3D volant d'un côté à l'autre où "dir /s > a.txt | ftp -s:upload.ftp" a fait le travail.

Les composants logiciels ne sont pas des briques, ne peuvent pas être généralisés par des modèles fonctionnels communs et l'architecture émerge dans l'entreprise à partir de bonnes pratiques et non d'une bonne conception.Le logiciel n’est pas architecturé, il est conçu.

SCRUM ON!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top