La politique de gestion SOA apporte une grande flexibilité technique et métier aux solutions SOA. A l’utilisation la politique SOA apporte un moyen rapide de changer les caractéristiques clés d’un service opérationnel, incluant les règles métiers comme les seuils d’approbation et le traçage des transactions (ou logs). Comment construire une architecture adaptée à sa politique d’entreprise ? Au cours du développement, la politique SOA contrôle les aspects clés de la manière dont vos services sont construits. Il nécessite une parfaite coordination entre les progiciels de gestion intégrés et autres produits d’infrastructure différents.
Même si certains produits sont estampillés «Gestion de la politique»,vous devrez préparer votre infrastructure pour la politique SOA, cette préparation ne doit pas commencer par l’évaluation des produits, mais par la compréhension des principales fonctions nécessaires à une gestion efficace et à la façon dont ils travaillent tous ensemble.
Alors vous serez en mesure d’évaluer la façon dont vos produits ( existants ou nouveaux ) – portant ou non la mention « Gestion de la politique » – vous apporteront l’environnement intégré dont vous avez besoin pour une politique SOA efficace.
Concevoir une architecture adaptée à vos processus de gestion
La plupart des organisations choisissent une approche progressive de la politique SOA, commençant par des domaines tels que la sécurité ou la gestion. Avant de concevoir la politique d’infrastructure SOA, assurez-vous de maitriser les process au seins des premiers services qui utiliseront la SOA, la maturité de ces processus, et l’appréhension générale du cycle de vie de la politique SOA.
Du fait de l’utilisation cordonnée impérative de plusieurs produits, la conception de l’architecture est le point de départ – surtout pour préparer le terrain de la construction incrémentale de l’infrastructure. La conception de l’architecture pour votre politique SOA se fait en trois étapes itératives :
- 1. L’architecture conceptuelle de la SOA
En concevant en premier lieu le fondement de la SOA pour votre organisation vous devez :
1) Vous assurez de comprendre et maîtriser la politique SOA.
2) Vous créez une base simple pour la description de la SOA pour la direction, les différents services, les services techniques de l’IT , mais également pour le reste du personnel concerné (c’est à dire tout le monde).
3) Construisez un vaste schéma de catégorisation pour comprendre où, comment, et dans quelle mesure différents produits s’intègrent et jouent un rôle dans votre infrastructure.
- 2. La logique de l’architecture SOA
S’appuyant sur votre architecture conceptuelle, il faut ajouter un niveau supplémentaire de détail qui définit les éléments majeurs de votre infrastructure pour la politique SOA. En développant l’architecture logique, vous commencerez à percevoir comment votre politique s’intègre dans votre organisation complète de la plate-forme SOA, par exemple, en évaluant comment un référentiel SOA peut être utilisé pour telle ou telle politique.
- 3. L’intégration avec la stratégie de plate-forme SOA
Avec une architecture logique déjà en place (ou une première ébauche), cartographiez les fonctions de la politique dans votre platforme pour définir comment la politique devrait s’intégrer avec les fonctions de messagerie et de management. Les produits concernés et leurs rôles varient en fonction du développement spécifique et progressif de la plate-forme et de l’infrastructure SOA.
Construire une politique efficace
Vous avez maintenant une architecture logique solide comme base pour votre politique, mais vous ne pouvez pas gérer mener votre activité avec une architecture logique.
En menant la réalisation physique de votre plate-forme SOA supportant votre politique, deux tâches essentielles préparent le terrain:Rechercher des fonctions de politique SOA dans des produits existants pour les mettre en valeur, optimiser leur utilisation et ainsi les mettre à profit.
- 1. Rechercher des fonctions de politique SOA dans des produits existants pour les mettre en valeur, optimiser leur utilisation et ainsi les mettre à profit.
L’infrastructure agit ici comme une extension d’une plate-forme SOA, et non comme une plate-forme indépendante. Les fonctions de la politique SOA sont identifiées dans votre architecture logique mais fournis par 3 types de produits :
1) Des logiciels d’infrastructure traditionnels,
2) des produits spécialisés de SOA,
3) et les produits conçus spécialement pour soutenir les politiques SOA ou plus généralement des politiques de management.
Pour développer votre infrastructure de politique SOA, identifiez par exemple, la façon dont votre application SOA, votre ESB(Enterprise Service Bus), mais aussi vos produits non-SOA pourraient fournir des fonctions définies par votre architecture logique.
- 2. Définissez votre stratégie pour la politique SOA de gestion des normes. Dans le cadre de la détection de politiques dans les produits existants, décidez comment utiliser les normes existantes de l’industrie.
Bien qu’elles ne couvrent qu’une petite partie de la totalité du champ d’application de la politique de gestion des SOA, certaines spécifications et standards fournissent d’importants aspects d’intégration entre les différentes parties de votre infrastructure SOA.
Néanmoins, nous sommes aux premiers jours des politiques SOA, et les normes ne sont pas encore largement adoptées, de sorte que votre planification doit être faite avec soins pour savoir quand et comment les utiliser.
Règles générales lors de l’examen de normes liées à une politique SOA :
Utiliser une norme si votre infrastructure SOA la supporte mais seulement après l’avoir testé avec soin.
- Toujours inclure une gestion reconnue des normes dans les critères de sélection de votre produit – à moins qu’elle ne soit pas applicable dans votre cas ou si vous avez spécialement opté contre.
- Ne pas rendre une norme obligatoire, sauf si le critère de sélection, en fonction de vos besoins, de votre stratégie, et de la maturité de vos spécifications fonctionnelles l’exigent, ou que vous avez expressément décidé de l’adopter.
- Tous les autres aspects étant égaux, acheter un produit qui prend en charge la norme en question et de manière générale, favoriser un produit fait pour la supporter.
- En utilisant (ou non) une norme, examiner attentivement la façon dont vous adapterez l’évolution de votre architecture et de la plate-forme si la norme venait à perdre (ou gagner) le support de l’industrie.
Une fois que vous avez défini une architecture logique, déterminez comment adapter vos produits avec les processus de l’architecture, et décidez de l’utilisation des spécifications de l’industrie et des normes, vous aurez la base technique dont vous avez besoin pour déterminer ce que les produits dont vous pourriez avoir besoin pour la politique SOA. Votre stratégie peut varier en fonction de votre agressivité dans l’adoption de la SOA, de votre calendrier pour l’utilisation de SOA et de l’implémentation des différents domaines de la politique, de votre infrastructure existante, et de vos plans pour l’évolution de votre plate-forme.
Utilisez ces conseils pour fournir une solide fondation à votre architecture à la fois pour faciliter la planification à court terme et à long terme, et pour l’évolution de votre politique de gestion.
Appsmetrix.com
Les architectures orientées services sont une évolution des architrectures distribuées basées sur le schéma classique des requetes et des réponses que se soient pour des applications syncrhones ou asynchrones. La logique des applications de gestion ou des fonctions indépendantes y sont modulaires et présentées comme des services avec une relation d’applications consommatrices ou clientes.
Microsoft a dévoilé les détails de sa future offre Business Intelligence et entrepôt de données (BI) et les communiqués de l’entrepôt de données, et les mots d’ordre sont libre service et évolutivité.