Architecture SOA et service WCF

Présentation au sujet: "Architecture SOA et service WCF"— Transcription de la présentation:

1 Architecture SOA et service WCF
Architecture d’application Hugo St-Louis

2 Plan Historique Architecture SOA Service WCF Conclusion

3 Orientation composant
3/31/2017 Orienté objet Polymorphisme Encapsulation Classes & héritage 1980 Orientation composant Basée sur les interfaces Chargement dynamique Notion de métadonnées 1990 Evolution des applications sur un modèle distribué OBJET : au niveau langage COMPOSANT : exposition via IDL, assemblage, pb de gestion des versions et d’adhérence aux plate-formes SERVICE : impact de l’architecture distribuée, couplage faible, forte exposition aux métiers de l’entreprise Orientation Service Basée sur les message Schema & Contrat Liaisons via des règles 2000 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

4 Les applications distribués
Une application distribuée est une application dont tous les éléments qui la composent (classes, persistance, logique métier) sont distants géographiquement et communiquent entre eux via des réseaux locaux d’entreprise ou par Internet en utilisant le protocole IP. L’utilisateur final n’a pas conscience de la nature distribuée de l’applicatif car il utilise une interface – Web ou autre –, dont le but est de fédérer tous les éléments distants pour atteindre l’objectif de l’application tout en masquant tous les mécanismes d’accès.

5 Technologies pour applications distribuées
Le principe même des applications distribuées n’est pas nouveau. Beaucoup de technologies et de protocoles, souvent incompatibles entre eux ont été mis en œuvre pour permettre aux composants d’une application distribuée, de communiquer entre eux.

6 Technologies pour applications distribuées
COM (Component Object Model) : technologie de communication inter application propre à l’environnement Windows. Cette technologie ne permet pas de construire à proprement parler des applications distribuées mais sert d’interface pour faire communiquer des applications sur une même machine. (les différents logiciels de la suite bureautique Microsoft Office par exemple). DCOM (Distributed Component Object Model) : version Distribuée de COM. Corba:  Common Object Request Broker Architecture, est une architecture logicielle, pour le développement de composants et d’Object Request Broker ou ORB. Ces composants, qui sont assemblés afin de construire des applications complètes, peuvent être écrits dans des langages de programmation distincts, être exécutés dans des processus séparés, voire être déployés sur des machines distinctes. .Net Remoting : technologie de communication inter application incluse dans le Framework .Net 2.0, basée sur un modèle client/serveur permettant la communication et la transmission d’objets entre les applications.

7 Technologies pour applications distribuées
- RMI : équivalent Java du .Net Remoting

8 Termes que vous avez peut-être déjà entendu parlé
- Services Web : technologie permettant de faire communiquer des composants entre eux, indépendamment de la plateforme sur laquelle ils sont hébergés, en utilisant un protocole de communication et un format de fichier unique et standardisé basé sur du XML. Contrairement aux technologies évoquées précédemment, grâce à la nature standardisée des échanges, il devient tout à fait possible de faire communiquer des modules hébergés sous Windows avec d’autres hébergés sous Linux ou Unix. C’est cette interopérabilité associée à une relative facilité de mise en oeuvre, qui fait que les services web sont aujourd’hui une des technologies les plus utilisées, pour construire des applications distribuées. Middleware: est un logiciel tiers qui crée un réseau d'échange d'informations entre différentes applications informatiques. Le réseau est mis en œuvre par l'utilisation d'une même technique d'échange d'informations dans toutes les applications impliquées1 à l'aide de composants logiciels.

9 La naissance du SOA Malgré le fait que des technologies comme DCOM, RMI ou .Net Remoting permettent de transporter les objets et donc de dépasser les frontières de la machine grâce au réseau, on s’est souvent heurté à des problèmes de compatibilité entre plateformes, d’où le besoin d’une standardisation et la mise en commun des protocoles (SOAP, XML, …). De là est née la notion d’architecture orientée services (SOA).

10 Les 4 grands principes du SOA
La définition du service est explicite : Un service est une classe exposée à travers les réseaux. Le but de ce service est de fournir une prestation bien définie (exemple : fournir la date et l’heure dans un pays donné). Les détails d’un service (la manière dont il doit être appelé, les paramètres à spécifier…) sont contenus dans un document standardisé, qui fait office de contrat entre le client et le serveur. Les services sont autonomes : Un service se doit d’être totalement autonome. On doit pouvoir le remplacer ou le déplacer sans que cela affecte d’autres services. Un service implémente ses propres composants et ses propres méthodes d’accès aux données, il ne doit dépendre d’aucun élément externe.

11 Les 4 grands principes du SOA
Les clients et les services ne partagent que des contrats : On a vu dans le premier principe du SOA, que les services exposent des contrats pour exposer aux clients leurs fonctionnalités et comment les utiliser. Cette interface est la seule chose que le serveur partage avec le client. Comme en programmation orientée objet, le client n’a pas a connaitre comment procède le service pour arriver à ses fins. En aucun cas, le service et le client ne doivent partager du code. La compatibilité est basée sur les règles : L’accès à un service devrait être sécurisé, en utilisant un nom d’utilisateur et un mot de passe par exemple.

12 Éléments du SOA Il n'existe pas à proprement parler de spécifications officielles d'une architecture SOA, néanmoins les principales notions fédératrices que l'on retrouve dans une telle architecture sont les suivantes : La notion de service, c'est-à-dire une fonction encapsulée dans un composant que l'on peut interroger à l'aide d'une requête composée d'un ou plusieurs paramètres et fournissant une ou plusieurs réponses. Idéalement chaque service doit être indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité.

13 Éléments du SOA La description du service, consistant à décrire les paramètres d'entrée du service et le format et le type des données retournées. Le principal format de description de services est WSDL (Web Services Description Language), normalisé par le W3C. La publication (en anglais advertising) et la découverte (discovery) des services. La publication consiste à publier dans un registre (en anglais registry ou repository) les services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal Description Discovery and Integration), normalisé par l'OASIS. L'invocation, représentant la connexion et l'interaction du client avec le service. Le principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access Protocol).

14 Standards de l’architecture
Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité SOAP W3C Simple Object Access Protocol WSDL W3C Web Services Description Language UDDI Microsoft, IBM, HP Universal Description Discovery and Integration Transporte Décrit le contrat Spec pour Repository/Registry Les trois piliers des Services Web

15 WCF SOA est une architecture
Ce n’est pas un ou des produits Par conséquent, Microsoft se devait de donner son interprétation de la solution. Ils ont donc créé WCF.

16 WCF WCF est une technologie qui permet de faciliter la mise en place des applications distribuées en servant de socle commun aux architectures orientées services (SOA : Service Oriented Architecture). WCF se veut être un modèle uniforme de distribution de services : - Faiblement couplé pour plus de souplesse ; - Adapté à toutes situations et besoins de communication : Disponibilité ; Interopérabilité ; Sécurité.

17 Les bases fondamentales de WCF
Première étape : définition du contrat. On définit les signatures des méthodes composant notre service WCF, et du format des données à échanger. Seconde étape : implémentation du contrat. On implémente les services. Troisième étape : configuration du service. On définit les endPoints, autrement dit les points d’accès au service. Quatrième étape : hébergement des services dans une application .NET.

18 Contrats Contrats de Service Contrats de Donnée
Définit les opérations, communications, comportements. Contrats de Donnée Définit les types de données et de paramètres. Contrats d’erreur (Fault) Définit les types d’erreur Contrats de Message Définit les formats de message

19 Contrat de services [ServiceContract] – Ensemble d’opérations
[OperationContract] – Méthode unique [ServiceContract] public interface IService { [OperationContract] string GetData(int value); } public class ConcreteService : IService public string GetData(int value) { ... } public string OtherMethod()

20 Contrat de données [DataContract] – Un type = un data contrat
[DataMember] – Membres du contrat [DataContract] public class CustomType { [DataMember] public bool MyFlag { get; set; } public string MyString { get; set; } }

21 Transfert de données Sur un réseau les données sont sérialisées.
Le Framework .Net contient déjà un attribut de sérialisation Si vous voulez utiliser des type de données pour les transféré, assurez-vous qu’elle soit sérialisable.

22 Contrat de données DataContract: céer spécifiquement pour WCF
Les attributs contiennent les propriétés nom et namespace DataMember: spécifie quelle propriété fera partie du contrat EmitDefaultValue, IsRequired, Name, Order properties

23 Contrat de données [DataContract(Name="Contact")] public class Person
{ [DataMember(IsRequired=true, Name="SurName")] public string LastName; public string FirstName; //Not included in contract }

24 Erreurs SOAP Trois types d’exceptions possibles:
Erreur de Communication Erreur inattendue du service Erreur contextuelle du service Les exceptions .NET sont spécifique à cette technologie Toutes les exceptions sur le réseaux seront du type SOAP Faults

25 Erreurs Pour WCF, les SOAP faults sont des objets de type FaultException Les services doivent émettre des FaultExceptions et non des Exceptions

26 Contrats d’erreur Spécifie le type des Exceptions, émis par une opération [ServiceContract] public interface IEmployeeService { [OperationContract] [FaultContract(typeof(FaultException))] public void AddEmployee(Employee e); }

27 Code du serveur Toujours émettre des Exceptions de type Fault Exceptions public class EmployeeService { public void AddEmployee(Employee e) ... throw new FaultException (errorMsg); }

28 Code du client EmployeeServiceProxy proxy = new EmployeeServiceProxy(); try { ... proxy.AddEmployee(emp); } catch(FaultException e) //Will catch all other types of Fault exceptions...

29 Exceptions durant le développement
<system.serviceModel> <services> <service name = "EmployeeService" behaviorConfiguration = "Debugging"> ... </service> </services> <behaviors> <serviceBehaviors> <behavior name = "Debugging"> <serviceDebug includeExceptionDetailInFaults = "true"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel>

30 Points de terminaison (end points)
WCF repose sur trois éléments : Address Où se trouve le service ? adresse à laquelle le client doit se connecter pour utiliser le service. Binding Comment parler au service ? protocole à utiliser par le client pour communiquer avec le service.

31 Adresse Combinaison du transport, nom du server, port & path
Le transport est défini par le type de binding Examples net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe net.msmq://localhost/private/MyService net.msmq://localhost/MyService

32 Binding Transport Formats d’encodage des messages
HTTP TCP MSMQ Formats d’encodage des messages Plain text Binary Message Transmission Optimization Mechanism (MTOM) Communication Sécurisées No security Transport security Message security Authenticating and authorizing callers

33 Adresse et binding La configuration du fichier de configuration sera couverte plus en détail dans le cours de « Composants et Services »

34 Hébergements possibles
IIS HTTP seulement WAS (Windows Activation Service) Utilisable avec n’importe quel transport Vista and Windows Server 2008 Self hosting Utilisable avec n’importe quel transport Hébergée dans Console, WinForms, …

35 Un peu d’algo? SI Vous avez des questions ALORS SINON Posez-les
Exécuter l’exercice

36 Exercice Allons comprendre dans Visual Studio maintenant 