Qu’est-Ce que La SOA ? 7 Étapes SOA

Ce blog décrit les étapes SOA qu’une organisation doit suivre avant de pouvoir réellement réussir à réaliser les avantages en termes de coûts et d’agilité offerts par une architecture orientée services d’entreprise. Il décrit ce que représente la SOA et les différentes étapes de l’adoption de la SOA en décrivant les technologies, les processus et les meilleures pratiques disponibles pour aider les entreprises à réussir leurs initiatives d’architecture orientée services.

Qu’Est-Ce Que Le SOA ?

L’architecture orientée service (SOA) est un type d’architecture utilisé dans la conception de logiciels qui prend en charge l’orientation service, dans laquelle des services sont fournis à d’autres composants via un protocole de communication sur un réseau.

Que Signifie SOA?

La définition de SOA, telle que fournie par Wikipedia:

L’architecture orientée services (SOA) est un style de conception logicielle où les services sont fournis aux autres composants par des composants d’application, via un protocole de communication sur un réseau. Les principes de base de l’architecture orientée services sont indépendants des fournisseurs, des produits et des technologies. Un service est une unité de fonctionnalité discrète accessible à distance, qui peut être utilisée et mise à jour indépendamment, comme la récupération d’un relevé de carte de crédit en ligne.

Un service a quatre propriétés selon l’une des nombreuses définitions de SOA:

1. Il représente logiquement une activité commerciale avec un résultat spécifié.
2. Il est autonome.
3. C’est une boîte noire pour ses consommateurs.
4. Il peut s’agir d’autres services sous-jacents.

Différents services peuvent être utilisés conjointement pour fournir les fonctionnalités d’une grande application logicielle, un principe que SOA partage avec la programmation modulaire. L’architecture orientée services intègre des composants logiciels distribués, entretenus séparément et déployés. Il est rendu possible par des technologies et des normes qui facilitent la communication et la coopération des composants sur un réseau, en particulier sur un réseau IP.

Cela fournit une réponse concise à ce que signifie la SOA, mais ne décrit pas les raisons pour lesquelles une organisation voudrait évoluer vers une architecture orientée services, ni les avantages de la SOA.

Également de Wikipedia sur ce que signifie SOA:

Certains architectes d’entreprise pensent que SOA peut aider les entreprises à réagir plus rapidement et de manière plus rentable à l’évolution des conditions du marché.Ce style d’architecture favorise la réutilisation au niveau macro (service) plutôt qu’au niveau micro (classes). Il peut également simplifier l’interconnexion et l’utilisation des actifs informatiques existants (hérités).

À certains égards, la SOA pourrait être considérée comme une évolution architecturale plutôt que comme une révolution. Il capture un grand nombre des meilleures pratiques des architectures logicielles précédentes. Dans les systèmes de communication, par exemple, peu de solutions utilisant des liaisons réellement statiques pour communiquer avec d’autres équipements du réseau ont été développées. En adoptant une approche SOA, de tels systèmes peuvent se positionner pour souligner l’importance d’interfaces bien définies et hautement interopérables.

En fouillant dans ces concepts, nous pouvons voir qu’il existe un ensemble de capacités de base nécessaires pour obtenir les avantages potentiels de la SOA. Wikipédia discute un certain nombre de ces principes directeurs, parmi lesquels:

• Réutilisation – la capacité d’encapsuler et d’exposer des fonctions commerciales à gros grains en tant que services
• Couplage lâche – s’assurer que les consommateurs de services sont suffisamment abstraites de la mise en œuvre physique d’un service
• Identification et catégorisation (découvrabilité) – s’assurer que les consommateurs potentiels peuvent trouver les services dont ils ont besoin

Quelle que soit la définition SOA que vous utilisez, ces principes fondamentaux conduisent à un ordre naturel d’activités qu’une organisation doit accomplir pour réaliser progressivement les avantages d’une approche axée sur les services architecture.

Découvrez pourquoi Akana est très performant dans le rapport Forrester Wave™: API Management Solutions, T3 2020.

Télécharger le rapport

Quelles sont les sept étapes SOA?

Il y a sept étapes SOA:

1. Créer/Exposer des Services
2. Enregistrer des Services
3. Services sécurisés
4. Gérer (surveiller) des Services
5. Médier et virtualiser des Services
6. Régir la SOA
7. Intégration de la SOA Avec ESB

Les étapes SOA 2 à 6 décrivent les préoccupations interentreprises qui devraient être traitées avec une plate-forme d’infrastructure SOA centralisée. Les étapes 1 et 7 répondent à des besoins spécifiques et sont souvent fournies dans le cadre d’une pile d’applications d’entreprise existante. Suivre ces étapes mènera une organisation sur la bonne voie pour réaliser les avantages de la SOA. Continuez à lire pour approfondir chaque étape SOA.

Créer / exposer des services

La première étape pour faire évoluer une organisation vers la SOA est évidente. Il ne peut y avoir d’application SOA sans services, la première étape doit donc être d’exposer ou de créer des services qui peuvent facilement être consommés par les applications compatibles avec les services Web.

Il existe un certain nombre de décisions intéressantes auxquelles les entreprises sont confrontées au début de ce processus, notamment la décision de reconstruire des applications existantes à l’aide d’un paradigme orienté services ou d’exposer la logique d’application existante en tant qu’ensemble de services. Ce n’est bien sûr pas une décision binaire, et la plupart des organisations construiront de nouveaux services à partir de zéro, souvent en utilisant J2EE et / ou .NET, et exposeront également des services à partir d’applications mainframe existantes et d’autres applications métier.

Il existe une large gamme de solutions différentes pour les entreprises qui cherchent à exposer les applications existantes en tant que services, y compris la solution SOLA leader sur le marché d’Akana permettant aux applications CICS mainframe d’exposer et de consommer des services fiables, sécurisés et performants.

Toute entreprise ayant un investissement significatif (plus de 1000 MIPS selon Gartner) dans le mainframe devrait étudier les moyens de mieux tirer parti des avantages de cette plate-forme et devrait utiliser des services Web pour intégrer facilement ses applications mainframe aux systèmes modernes. Le SOLA d’Akana a fait ses preuves en production chez des clients comme Merrill Lynch, où il traite plus de 2 millions de transactions par jour à partir de plus de 600 services Web. SOLA est le seul produit qui offre aux programmeurs mainframe une interface Web facile à utiliser pour exposer et consommer les services des applications CICS. Il inclut une prise en charge intégrée des fonctionnalités avancées de services Web telles que la sécurité WS, le cryptage XML et la signature XML.

La plupart des entreprises traditionnelles d’intégration d’applications d’entreprise (EAI) fournissent également des versions de leurs adaptateurs qui exposent les services Web plutôt que leurs protocoles propriétaires traditionnels. En fait, bon nombre de ces plates-formes EAI réapparaissent en tant que produits de bus de service d’entreprise. L’ESB aborde plusieurs problèmes différents, dont la fonctionnalité de type services de données de base utilisée pour exposer les interfaces de services Web des adaptateurs traditionnels.

Qu’est-ce qu’un service Web ?

De Wikipédia:

En ce qui concerne les services Web du W3C, le W3C a défini un service Web comme suit :  » Un service Web est un système logiciel conçu pour prendre en charge l’interaction interopérable de machine à machine sur un réseau. Il a une interface décrite dans un format pouvant être traité par machine (en particulier WSDL). D’autres systèmes interagissent avec le service Web d’une manière prescrite par sa description en utilisant des messages SOAP, généralement transmis en utilisant HTTP avec une sérialisation XML en conjonction avec d’autres normes liées au Web. »

Cette définition est intéressante d’un point de vue technique, mais elle n’entre pas vraiment au cœur de la valeur qui peut être dérivée de la SOA et des services Web. Un aspect fondamental des services Web est qu’ils doivent exposer la logique métier via une interface basée sur des normes. Un aspect important de l’exposition ou de la création d’un service est sa granularité. Il existe de nombreuses écoles de pensée différentes sur ce qui constitue un service (voir ci-dessus), mais la plupart des architectes d’entreprise conviendraient que pour être utile dans une SOA, un service doit être suffisamment grossier pour être utile à de multiples applications différentes.

Ceci, bien sûr, est lié à l’un des principes fondamentaux des services en SOA – pour qu’un service soit réutilisé; il doit être généralement utile et utilisable. Un exemple de service généralement utile peut être un service « getCustomerInfo » qui renverra des détails sur un client à partir d’un identifiant client. Un service plus fin qui peut ne pas être généralement utile pourrait être quelque chose de spécifique à une application particulière, « setApplicationState » par exemple.

Il est important de prendre en compte la granularité des services à la fois lors de la création de nouveaux services et lors de l’exposition de la logique métier existante en tant que service. Par exemple, il serait facile de prendre une transaction CICS et d’exposer plusieurs services différents pour définir et obtenir divers paramètres, alors que la réalité est qu’un service plus grossier qui expose l’ensemble de la transaction en tant que service unique pourrait être beaucoup plus généralement utile, et donc précieux.

Lecture connexe : Découvrez comment l’API Mainframe SOLA d’Akana fournit aux clients un processus simple et rapide pour exposer les applications mainframe en tant que services Web sécurisés et permet aux applications mainframe de consommer des services Web.

Enregistrez

Ok, vous avez donc un ou plusieurs services disponibles dans votre entreprise. Et maintenant ?

Pour qu’un service soit utilisé, et encore moins réutilisé, les architectes d’applications et les développeurs qui pourraient bénéficier de ce service doivent savoir qu’il existe. C’est là qu’un registre entre en jeu. À son niveau le plus simple, un registre n’est rien de plus qu’un index de bibliothèque qui aide les utilisateurs potentiels de services à trouver des services qui pourraient les intéresser. Le registre devrait offrir à la fois des interfaces de recherche et de navigation, et devrait être organisé de manière logique pour faciliter la découverte rapide et précise des services.

Dans la SOA actuelle, la norme acceptée pour les services de registre de base est UDDI (Universal Discover, Description et Integration). La spécification UDDI fournit un modèle de données et un ensemble d’interfaces (tous les services Web eux-mêmes) pour la publication et la découverte de services, ainsi qu’un ensemble supplémentaire d’interfaces pour la gestion du serveur de registre lui-même.

De nombreux fournisseurs de registres ont poussé le concept original de registre un peu plus loin et utilisent les technologies de registre comme base pour un référentiel plus complet. Les fournisseurs de registres ajoutent également des filtres basés sur des « politiques  » à leurs outils de publication et proposent des « solutions de gouvernance au moment de la conception « .

Akana considère le registre comme un élément fondamental de la SOA. Tous nos produits utilisent UDDI comme un magasin central unique pour obtenir des informations faisant autorité sur les services d’une SOA. Les produits peuvent fonctionner avec n’importe quel registre compatible UDDI, et Akana inclut son propre serveur de registre UDDIv3 avec son produit Service Manager pour les entreprises qui n’ont pas déjà de registre. À cet égard, registry remplit le rôle de SOA que LDAP a rempli pour les solutions de gestion des identités et des accès.

Les produits d’Akana se concentrent sur la gouvernance de l’exécution et exploitent le registre en tant que lieu central pour trouver des stratégies d’exécution à mettre en œuvre et à appliquer. Bien sûr, le registre intégré est un serveur UDDIv3 entièrement fonctionnel et constitue donc également un référentiel de service idéal au moment de la conception.

Au-delà du registre est l’ensemble du concept de services de stratégie et de métadonnées qui fournissent des référentiels complets pour tous les artefacts de conception et d’exécution des services dans SOA. Ce concept est traité plus en détail dans le livre blanc d’Akana, Le Modèle de référence de l’infrastructure SOA.

Sécurisé

Le monde de la SOA et des services Web n’est pas que du vin et des roses. En supposant que vous avez maintenant terminé les étapes une et une étape, prenez du recul et considérez ce que vous avez fait. En supposant que vous recherchiez une valeur commerciale maximale, vous avez probablement pris des applications critiques, les avez décomposées en fonctionnalités grossières, exposé cette fonctionnalité en tant que services, puis publié ces services dans un registre universellement accessible.

Tout cela peut sembler une bonne chose, et dans la plupart des cas, c’est une bonne chose, mais vous avez peut-être créé par inadvertance des failles de sécurité béantes dans votre organisation et exposé des informations sensibles ou des transactions de grande valeur à toute personne possédant des compétences rudimentaires en services Web. Assurer la sécurité des services signifie créer une couche d’application de la sécurité chez les fournisseurs de services et une couche d’implémentation de la sécurité chez les consommateurs de services.

Un bon moyen de comprendre les risques de sécurité liés aux services Web est de revenir aux applications mainframe traditionnelles à écran vert. La seule sécurité requise par ces applications était la sécurité de connexion, si vous pouviez accéder à l’application, vous y étiez. Ces applications contenaient les mêmes éléments de base qu’une application moderne (interface, logique métier, services de données), mais seule l’interface était accessible en dehors de l’application. Dans le monde des services Web, il est probable que certains des services de données de base seront exposés en tant que services, une partie de la logique métier devrait certainement être exposée et l’application n’a pas été écrite avec l’un ou l’autre de ces points d’accès à l’esprit. Cela signifie qu’il est essentiel de sécuriser les services que vous exposez individuellement, vous ne pouvez pas compter sur les composants internes de l’application pour assurer sa propre sécurité.

Alors, qu’est-ce que cela signifie de sécuriser un service Web? Les mêmes 5 principes de sécurité qui s’appliquent à d’autres applications s’appliquent également aux services Web:

• Authentification – assurez-vous que vous connaissez l’identité du demandeur de service (et assurez-vous également que le demandeur connaît l’identité du service qu’il contacte). Il existe plusieurs normes de services Web différentes pour l’authentification des requêtes, allant d’approches simples comme l’authentification de base http à des mécanismes plus complexes comme la signature SAML ou X.509. Un bon outil de sécurité des services Web devrait prendre en charge toutes ces différentes options.
• Autorisation – s’assurer que le demandeur est autorisé à accéder au service ou à l’opération qu’il demande. L’autorisation est une question complexe et de nombreux produits de décision politique sont disponibles. La plupart des grandes entreprises disposeront d’une solution d’autorisation existante (CA SiteMinder, IBM TAM, etc.), et une bonne solution de sécurité des services Web devrait pouvoir s’intégrer à celles-ci et fournir ses propres capacités d’autorisation.
• Confidentialité – assurez-vous que les messages de demande et de réponse ne peuvent pas être lus par des tiers non autorisés. C’est là que des normes telles que le chiffrement XML prennent leur place, mais pour utiliser avec succès le chiffrement XML, la solution de sécurité des services Web doit fournir des capacités efficaces de gestion et de distribution des clés et des certificats, et idéalement des outils côté client pour aider les développeurs consommateurs.
• Non-Répudiation – assurez-vous que le demandeur ne peut pas refuser l’envoi d’une demande et que le service ne peut pas refuser l’envoi de sa réponse. C’est le rôle de la signature XML, avec la même disposition de gestion et de distribution des clés que pour la confidentialité.
• Audit – s’assurer que le système peut conserver un enregistrement précis et opportun des demandes et des réponses au besoin.

Une question intéressante, et un point de débat, qui se pose autour de la sécurité des services Web est de savoir où cette sécurité devrait être appliquée. Certains fournisseurs diront que la sécurité devrait être une fonction centrale appliquée par le biais d’un groupe de mandataires déployés de manière centralisée, tandis que d’autres diront qu’elle devrait être exclusivement le domaine du fournisseur de services ou du conteneur. La réalité se situe bien sûr quelque part entre ces deux positions. Il y a certainement un rôle important pour un proxy (ou un groupe de proxy) dans la fourniture de services d’authentification et de détection des menaces à la périphérie du réseau pour se protéger contre les menaces externes. Il y a également un rôle tout aussi important pour la sécurité basée sur le fournisseur ou le conteneur pour assurer la sécurité du service jusqu’au dernier kilomètre.

De nombreuses entreprises ont tendance à négliger les recherches qui montrent que la majorité des menaces de sécurité sont internes à l’entreprise et non externes, et délèguent donc la sécurité à une solution de type pare-feu. Akana propose un proxy hautes performances qui exécute des fonctions de sécurité centralisées ou en périphérie du réseau, ainsi qu’une large gamme d’agents in container pour assurer la sécurité du dernier kilomètre des services déployés.

La sécurisation des services Web nécessite:

• Déployer des agents en conteneur entièrement fonctionnels pour assurer la sécurité du dernier kilomètre et répartir la charge des opérations cryptographiques
• Déployer des intermédiaires réseau hautes performances pour le routage et l’application de la sécurité en périphérie du réseau
• Fournir une gestion et une distribution complètes des clés et des certificats pour garantir que les fournisseurs de services et les développeurs grand public peuvent mettre en œuvre avec succès les politiques de sécurité requises
• Fournir des boîtes à outils aux développeurs grand public pour soustraire les développeurs grand public à la complexité de la découverte et de la mise en œuvre de la sécurité d’entreprise politiques

Lectures connexes : En savoir plus sur les meilleures pratiques de sécurité des API.

Gérez

Trois étapes dans l’approche en 7 étapes de la SOA et nous commençons à faire des progrès vers l’obtention d’une valeur réelle de la SOA d’entreprise. Nous avons certains services, ils sont publiés dans un registre et peuvent être découverts par des utilisateurs potentiels, et nous nous sommes assurés qu’ils sont sécurisés. De quoi d’autre pourrions-nous avoir besoin?

Pour répondre à cette question, nous devrions d’abord examiner un scénario de catastrophe potentiel. Que se passe-t-il lorsque mes services sont victimes de leur propre succès? C’est-à-dire un service est devenu si populaire qu’il existe plusieurs (dizaines, ou centaines, ou milliers) applications différentes qui le consomment et il commence à se plier sous la charge. Nous avons soudainement des dizaines, ou des centaines, ou des milliers d’applications qui échouent ou qui fonctionnent mal et nous ne savons pas pourquoi, ni comment l’arrêter.

Nous devons surveiller nos services afin de savoir s’ils fonctionnent dans les paramètres d’exploitation normaux et de voir les problèmes potentiels avant qu’ils ne surviennent en mettant en œuvre des modèles de planification des capacités.

La solution de surveillance que nous déployons devrait être capable de surveiller les services pour la disponibilité de base, les performances (temps de réponse), le débit, et même de s’étendre au contenu et à la surveillance basée sur les utilisateurs. Il devrait être en mesure de surveiller et d’alerter sur des seuils de SLA spécifiques, et devrait être en mesure d’appliquer différents SLA à différents utilisateurs d’un même service ou d’une même opération.

De nombreux fournisseurs définissent cette catégorie de produits comme une solution de gestion des services Web, bien que de nombreux analystes conviennent que la gestion est beaucoup plus large qu’une simple solution de surveillance et devrait inclure une grande partie des fonctionnalités décrites dans l’étape suivante.

Idéalement, bien sûr, nous ne devrions pas avoir à déployer des solutions distinctes pour la sécurité et la surveillance, car chaque fois que nous interceptons des messages via un agent ou un intermédiaire, nous ajoutons un autre goulot d’étranglement des performances. C’est pourquoi le Service Manager d’Akana s’associe à Network Director pour fournir une plate-forme de sécurité, de surveillance et de gestion SOA complète dans une solution unique, performante et facile à déployer.

Certains fournisseurs de gestion de services Web (surveillance) positionnent leurs solutions comme des plates-formes de surveillance des activités commerciales (BAM), bien que BAM soit une solution complexe nécessitant une intégration avec de nombreux systèmes et bases de données back-office et front-office. La surveillance des interactions des services Web pour le contenu ne doit pas être considérée comme une alternative à une solution BAM d’entreprise.

Lectures connexes: En savoir plus sur la Solution de gestion des API de bout en bout d’Akana.

5. Médiez et virtualisez

À ce stade, il semblerait que notre SOA soit prête pour les heures de grande écoute. Et c’est ainsi, pour un moment au moins…

La prochaine série de défis survient à mesure que votre SOA mûrit. Vous devez introduire de nouvelles versions de services ou augmenter la capacité d’un service en exécutant plusieurs instances de celui-ci, vous devez provisionner des applications pour utiliser des instances spécifiques de services et vous devez offrir des services qui exposent un plus large éventail de types d’interface différents.

C’est là qu’intervient la virtualisation des services. La virtualisation semble complexe, mais la réalité est assez simple. Un service virtuel est un service entièrement nouveau, défini par son propre WSDL, avec ses propres paramètres d’adresse réseau et de transport. Il n’implémente aucune logique métier ; il agit simplement comme un proxy pour un ou plusieurs services physiques, le routage, l’équilibrage de charge, la transformation et la médiation entre différents types de messages de requête et normes.

Bien que simple en surface, le concept de virtualisation est extrêmement puissant. Il offre la possibilité d’abstraire complètement les consommateurs de services de toute connaissance directe du service physique. Par exemple, via un service virtuel, un client .NET utilisant une implémentation Microsoft d’un protocole de messagerie fiable avec SOAP sur http pourrait consommer un ancien service XML simple exposé via la série IBM WebSphere MQ à partir d’une application mainframe. Le client .NET croirait qu’il s’agissait d’une communication avec un service http prenant en charge son protocole de messagerie fiable, tandis que l’application mainframe croirait qu’elle était interrogée par une autre application native de la série MQ.

Les services virtuels offrent un large éventail de fonctionnalités:

• Ils peuvent utiliser des technologies de transformation XML pour permettre aux consommateurs de continuer à utiliser une ancienne version d’un service qui n’existe plus en transformant les messages de demande et de réponse entre l’ancienne version et la nouvelle version qui a été déployée.
• Ils peuvent sélectionner des opérations spécifiques de plusieurs services différents et les combiner en un seul WSDL fonctionnel pour une classe spécifique d’application consommatrice.
• Ils peuvent fournir différentes exigences de stratégie pour différentes classes d’utilisateurs (p. ex. utilisateurs internes avec un ensemble de stratégies, et une autre implémentation du service qui applique un ensemble de stratégies différent pour les consommateurs externes).
• Ils peuvent fournir des ponts de transport pour les services et les consommateurs sur des transports incompatibles (par exemple http et JMS). * Ils peuvent servir de médiateur entre différentes mises en œuvre de normes ou même des versions de normes.
• Ils peuvent servir de médiateur entre différents styles de messagerie – RSS, SOAP, REST, POX (XML ancien).
• Ils peuvent fournir un routage puissant basé sur le contenu ou le contexte pour fournir des capacités avancées d’équilibrage de charge et de haute disponibilité.

L’essentiel avec les services virtuels est qu’ils sont nécessaires pour tout routage ou autre service Web avancé, et deviendront rapidement un élément essentiel de toute SOA d’entreprise.

Gouverner

Avec 5 étapes sur 7 terminées, l’enterprise SOA est à peu près prête à fonctionner. Vous disposez désormais de services gérés sécurisés, accessibles à un large public de manière fiable, équilibrée en charge et facilement détectables.

L’étape suivante consiste à lier toutes les capacités délivrées au cours des 5 premières étapes avec un cadre de gouvernance. La gouvernance est un travail surutilisé et très mal utilisé, alors examinons brièvement une définition de la gouvernance. De nouveau de Wikipedia:

Le terme gouvernance traite des processus et des systèmes par lesquels une organisation ou une société fonctionne. Souvent, un gouvernement est établi pour administrer ces processus et systèmes.

Le point clé à retenir de cette définition est que la gouvernance concerne les processus et les systèmes. Dans le cas de la gouvernance SOA, nous discutons des processus organisationnels tels qu’un comité de révision de l’architecture et des systèmes tels que les technologies de registre, de sécurité et de gestion discutées dans ce blog.

La gouvernance pour SOA est souvent divisée en deux parties distinctes, la gouvernance au moment de la conception et la gouvernance au moment de l’exécution. Au moment de la conception, les organisations veulent contrôler (gouverner) les types de services qui peuvent être publiés, qui peut les publier, quels types de schéma et de messages ces services peuvent accepter, et une foule d’autres règles sur les services. Au moment de l’exécution, les organisations doivent assurer la sécurité, la fiabilité et les performances de leurs services, et doivent s’assurer que les services sont conformes aux politiques d’entreprise définies. La gouvernance au moment de la conception est intéressante et contribue à garantir une SOA organisée et bien conçue, mais elle devient insignifiante par rapport au contrôle actif de la SOA au moment de l’exécution.

Le Service Manager d’Akana est la plate-forme de gouvernance à l’exécution leader du secteur, offrant une solution complète pour la sécurité, la surveillance, la gestion, la médiation et le registre. La gouvernance au moment de l’exécution fournit essentiellement un cadre unique pour contrôler et surveiller l’application des différentes étapes à la SOA décrites dans ce document. Il fournit une solution globale unique assurant la supervision du registre des services, de la sécurité, de la gestion et de la médiation. Une bonne solution de gouvernance au moment de l’exécution se manifestera comme une forme d’atelier fournissant des outils à tous les participants actifs d’une SOA.

• Développeur de services: outils pour publier, catégoriser, définir des métadonnées, télécharger  » agent « , virtualiser, versionner, choisir une stratégie, choisir la visibilité/les droits d’accès, participer à la planification des capacités et au workflow d’accès
• Service Consommateur : Outils pour faciliter la découverte, la sélection et le workflow d’accès aux services
• Personnel des opérations : Outils pour surveiller les performances des services, résoudre les problèmes, surveiller les dépendances, services de version, virtualisation, gestion des proxy
• Personnel de sécurité : Outils pour la gestion des stratégies, le reporting des stratégies, la vérification de la conformité, l’audit de sécurité
• Architecte d’entreprise: Outils pour la surveillance des applications, la gestion des relations, la validation et la définition des politiques de conception, la gestion des versions de service, l’affectation du service au proxy, la virtualisation des services
• Gestion informatique d’entreprise : Gestion des métriques de réutilisation, métriques de réutilisation des services, statistiques SOA

Intégration SOA avec ESB

En revenant sur les résultats des 6 dernières étapes vers une SOA, nous nous demandons ce qu’il peut y avoir d’autre. À ce jour, nous disposons d’un ensemble de services publiés dans un registre, sécurisés, gérés, fiables et faiblement couplés, le tout enveloppé dans une solution de gouvernance de conception et d’exécution solide.

La dernière étape pour certaines entreprises consiste à déployer une ou plusieurs implémentations de Bus de services d’entreprise (ESB) pour intégrer des services dans des services composites ou orchestrés de niveau supérieur. Ces ESB seront souvent livrés dans le cadre d’une suite d’applications plus large, telle que les applications Oracle eBusiness ou SAP. Certains ESB spécialisés peuvent être utilisés pour créer des services composites complexes et s’étendront au domaine de la gestion des processus métier (BPM).

Lectures connexes : En savoir plus sur les Solutions d’intégration d’Akana.

Le bus de service d’entreprise (ESB) est un concept de plus en plus populaire. Conçu à l’origine comme l’évolution à la fois du middleware orienté message et des solutions EAI (enterprise application integration), l’ESB signifie des choses très différentes selon les organisations. Au fur et à mesure que les analystes, les fournisseurs et les clients acceptent l’idée d’un ESB, il semble qu’un ESB encapsule 3 concepts fonctionnels: des adaptateurs tirés d’un outil EAI pour assurer la connectivité avec les applications héritées, des services de messagerie tirés d’une plate-forme middleware orientée message pour assurer une livraison fiable et une orchestration des processus pour créer des applications agiles.

Le consensus parmi les analystes est que la plupart des organisations se retrouveront avec plusieurs plates-formes ESB de plusieurs fournisseurs, fournissant des services dans leur propre contexte. Dans cet environnement, il est essentiel que les ESB utilisent une infrastructure SOA centrale pour assurer une conformité cohérente avec les politiques de sécurité et de messagerie pour les services qu’ils exposent et consomment.

Les produits Gestionnaire de services et Directeur de réseau d’Akana se combinent pour fournir une solution complète de gouvernance et de médiation entre plusieurs instances ESB dans une entreprise.

Maintenant que vous en savez plus sur ce que représente la SOA et les étapes clés de la SOA, consultez Akana en action !

Commencer l’essai