Les processus métier changent/évoluent Les systèmes monolithiques détiennent les processus Les processus doivent être séparés des fonctionnalités.

Présentation au sujet: "Les processus métier changent/évoluent Les systèmes monolithiques détiennent les processus Les processus doivent être séparés des fonctionnalités."— Transcription de la présentation:

1

2

3

4 Les processus métier changent/évoluent Les systèmes monolithiques détiennent les processus Les processus doivent être séparés des fonctionnalités L’existant ne peut pas être rebâti Nécessite une approche de l’intégration standardisée L’IT n’est pas un paysage homogène Interopérabilité doit être la priorité N° 1

5 Identité&Accès Interaction Messaging *-bilities (Scalability, Availability, Secureability, Manageability, …) Modèle de programmation + Outils Données Workflow

6 Business Model What  Capabilities How  Business Processes Technology Model Service Interface Orchestration Engine Service Implementation Service Host Service Model Service Contract OrchestrationService Management SLASLE

7 PolymorphismeEncapsulation Classes & héritage Basée sur les message Schema & Contrat Liaisons via des règles 1980 2000 Basée sur les interfaces Chargement dynamique Notion de métadonnées 1990 Orienté objet Orientation Service Orientation composant

8 S : La notion de service Un point d’accès qui réagit à un message S : La notion de service Un point d’accès qui réagit à un message O : On prend un peu de recul avec l’orientation service Un paradigme d’architecture qui s’appuis sur des piliers O : On prend un peu de recul avec l’orientation service Un paradigme d’architecture qui s’appuis sur des piliers En plus il nous faut un socle technologique robuste et évolutif pour la mise en œuvre A : On capitalise sur une architecture orientée service Toute architecture qui adhère aux piliers de l’orientation service A : On capitalise sur une architecture orientée service Toute architecture qui adhère aux piliers de l’orientation service

9 Les services sont autonomes Les frontières sont explicites La compatibilité des services repose sur des règles (politiques) Les services partagent des schémas et contrats Communication par messages

10 Autonomie ≠ Indépendance La topologie d’un système évolue dans le temps A la différence de l’orientation objet, les services ne partagent pas de comportement Les services savent (et surtout doivent) gérer les “pannes”

11 Les services interagissent en échangeant des messages Tout message échangé doit traverser des “frontières” et cela a un coût L’orientation service formalise des interactions explicites et intentionnelles

12 Les services exposent des schémas définissant les structures de données et des contrats exposant les opérations disponibles Contrats et schéma peuvent évoluer (versions) indépendamment dans le temps

13 Une règle contient les pré-requis de communication nécessaires aux interactions entre les services Les “capacités” et les “besoins” des services sont exposés de façons explicites et normalisées (à la différence des objets/classes) Une règle peut contenir plusieurs assertions

14 Une architecture guidée par les besoins métier

15 15 WPF WCF WF ATLAS … WPF WCF WF ATLAS …

16 Interopérabilité avec d’autres plateformes ASMX TransactionPerformance Enterprise Services Protocoles WS-* WSE Programmation orientée Message System.Messaging Extensibilité Mode binaire.NET Remoting

17

18 Endpoint

19 CBA CBA A BCAdresseOù? ContratQuoi?« Binding »Comment? Endpoint CBA Adresse : où est exposé le service Binding : lien entre le contrat et ce qui exposé : le protocole de transport Contrat : explicitement le service expose ses méthodes

20 CBA CBA A BC Adresse Où? Contrat Quoi? « Binding » Comment? Endpoint CBA Quelles sont mes attentes sur l’environnement d’exécution (ex: contexte)

21 CBA CBA GetMetadata WSDL

22 Une initiative du groupe Pattern & practises Des assistants dans Visual Studio 2005 pour définir les caractéristiques d’un service et son implémentation : Sécurité, déploiement, contexte Patterns de conception des services Des exemples d’implémentation Utilise le GAT (Guidance Automation Toolkit) Utilisation des tests unitaires Intégration avec Enterprise Library Patterns WCF La version finale du Service BAT Un guide complet de prise en mains Un tutorial complet (HOL) en 10 étapes sur un scénario réaliste Un exemple de conception, en 17 itérations Modifiable Intégré à VS 2005

23 Comprend: Plate-forme de base RéseauSANClusteringVirtualisationSécurité Identité et Accès MiddlewareDéploiement Audit, monitoring, instrumentation Management

24 Appréhender la SOA en terme d’aptitudes (capabilities) et de cycles de vie…

25 Logging Service Monitoring

26 Comment peut-il rendre ma vie plus facile? Possibilité de déterminer l’usage Peak usage times Max calls per time (sec, min, etc.) Par consommateur Troubleshooting Accès aux messages SOAP, SLA, métriques, utilisateurs Non-Repudiation Prouver qui a fait quoi, quand et comment

27 Comment peut-il rendre ma vie plus facile? Information sur le réel usage des services Max calls per time (sec, min, etc.) Utilisation pour les tests cases Store and forward messages intéressants Messages en échec SLAs en échec Aide à l’automatisation des tests Evolutivité, disponibilité, résilience

28 Comment peut-il rendre ma vie plus facile? Tests unitaires Rejouer les messages qui sont connus pour avoir posé des problèmes Analyse des performances des services Temps passé dans le service Temps réseau Nombre de consommateurs Nombre de d’appels par sec/min Ne pas avoir à bâtir son propre mécanisme de logging

29

30 Impliquer les fonctionnels au plus tôt afin de résoudre de réels problèmes métier Collecter les indicateurs qui permettront de mesurer l’atteinte des objectifs métiers Communiquer sur l’atteinte de ces objectifs Masquer la complexité Facilite l’utilisation par les projets Minimise l’impact sur les consommateurs en cas d’évolution Cycle de vie Capitalisation Mise à jour des bonnes pratiques Mise à disposition de ces bonnes pratiques

31

32

33 Sans comprendre comment la SOA impactera le Business, il y a le risque de “sur-architecture” ou de mettre en place les mauvaises aptitudes (capabilities) Mettre en place les bons éléments pour supporter les “capabilities” qui sont pertinentes pour votre entreprise

34

35

36 SOI Architecture Center http://msdn.microsoft.com/architecture/soi http://msdn.microsoft.com/architecture/soi Microsoft Architecture Centre http://msdn.microsoft.com/architecture http://msdn.microsoft.com/architecture Architect Journal http://www.architecturejournal.net http://www.architecturejournal.net Patterns and Practices: Building Secure Web Services http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/thcmch12.asp http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/thcmch12.asp http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnnetsec/html/thcmch12.asp

37

38 S’informer - Un portail d’informations, des événements, une newsletter bimensuelle personnalisée Se former - Des webcasts, des articles techniques, des téléchargements, des forums pour échanger avec vos pairs Bénéficier de services - Des cursus de formations et de certifications, des offres de support technique Visual Studio 2005 + Abonnement MSDN Premium Abonnement TechNet Plus : Versions d’éval + 2 incidents support

39 © 2007 Microsoft France Votre potentiel, notre passion TM