Architecture SOA et POO . réaliser par: nawfel elabed amin chebbi

sommaire Architecture SOA Architecture POO Définition Les concepts Le service WOA (Web Oriented Architecture) Les protocoles et les normes Technologies basées sur les principes de SOA Architecture POO Les principes Le typage et le polymorphisme La redéfinition

Architecture SOA Définition: L'architecture orientée services (calque de l'anglais Service Oriented Architecture, SOA) est une forme d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre des services (composants logiciels) : avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML), et des couplages externes « lâches » (par l'utilisation d'une couche d'interface interopérable, le plus souvent un service web WS-*). Ce terme est apparu au cours de la période 2000-20011 et concernait à l'origine essentiellement les problématiques d'interopérabilité syntaxique en relation avec les technologies d'informatique utilisées en entreprise. Cette conception a évolué pour désigner maintenant le sous-ensemble particulier d'architecture de médiation en fonction de la technologie disponible.

Les concepts: Une architecture orientée service se conforme à divers principes de gestion des services influençant directement le comportement intrinsèque d’une solution logicielle et le style de sa conception : L’encapsulation des services. Le faible couplage des services avec la maintenance d’une relation réduisant les dépendances. Le contrat de service adhérent à un accord de communication, collectivement défini avec un ou plusieurs documents de description. L’abstraction des services dissimulant la logique du service à l’extérieur. La réutilisation des services partageant la logique entre plusieurs services avec l’intention de promouvoir la réutilisation. La composition des services. L’autonomie des services. L’optimisation des services. La découverte des services depuis leur description extérieure.

Le service : Le service est un composant clef de l'Architecture Orientée Services. Il consiste en une fonction ou fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend d’aucun contexte ou service externe. Il est divisé en opérations qui constituent autant d'actions spécifiques que le service peut réaliser. On peut faire un parallèle entre opérations et services d'une part, et méthodes et classes dans le mode orienté objet d'autre part. Une architecture orientée services consiste essentiellement en une collection de services qui interagissent et communiquent entre eux. Cette communication peut consister en un simple retour de données ou en une activité (coordination de plusieurs services). Un service est une entité de traitement qui respecte les caractéristiques suivantes : Large Granularité (coarse-grained) : Les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion de composant technique. Interface : Un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent implémenter une interface commune.

Localisable : Avant d’appeler (bind, invoke) un service, il faudra le trouver (find). Instance unique : À la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps, un service est unique. Il correspond au design pattern Singleton. Couplage faible (loosely-coupled) : Les services sont connectés aux clients et autres services via des standards. Ces standards assurent le découplage, c'est-à-dire la réduction des dépendances. Ces standards sont des documents XML comme dans les web services. Synchrone ou Asynchrone. Une déclinaison du service est par exemple le service Web qui utilise WSDL (un meta langage XML) comme langage de description, un annuaire UDDI pour en permettre la localisation et un protocole de transport comme HTTP dans l'architecture REST et SOAP pour l'architecture SOA. Il existe une hiérarchie des services correspondant aux différentes couches techniques de l'architecture d'une solution : Les services de présentations ou de référencement vers les informations affichées et les formulaires de saisies de données. Les processus métiers composés de tâches décrites et faisant appel éventuellement à d’autres services. Les services de gestion et d’accès aux bases de données Les services d’intégration en charge de la messagerie ou l’échange de données tant à l’intérieur que vers l’extérieur comme la gestion des courriers électroniques

WOA (Web Oriented Architecture): Une autre possibilité pour mettre en place SOA au sein d'un SI consiste à utiliser le web comme unique support de service (et non un bus). Cette approche est rendue possible par le fait que le web contient d'ores et déjà les qualités nécessaires à une SOA (routage, sécurité...). Cependant, une telle architecture impose que tous les services soient exposés sur le web (ce qui signifie accessible depuis un URL), privilégiant ainsi les services web (rappelons que les services web ne sont pas le seul moyen d'exposer des services sur le web). L'avantage de cette conception est que le support des messages d'invocation de service (le web donc) est vraiment universel et ne nécessite aucune configuration, maintenance, évolution… Mais cette solution est actuellement assez dépréciée dans les situations où les performances sont un critère discriminant (cf. inconvénients des services web). Cette solution semble, en termes de pure architecture (considérations techniques mises à part), vraiment plus conforme aux principes de SOA7. A l'heure où ce paragraphe a été écrit (été 2008), WOA est encore jeune et sans véritable formalisme, elle suscite encore de nombreux débats. Ainsi il est nécessaire de prendre tout le recul nécessaire quant à la description présentement faite de WOA On peut mentionner Qworum, décrit plus loin, comme exemple de technologie WOA.

Les protocoles et les normes : Les architectures SOA se reposent principalement sur l’utilisation d’interface d’invocation (SOAP, Simple Object Access Protocol) et de vocabulaire de description de données (WSDL, Web Services Description Language et XML, eXtensible Markup Language) qui doivent être communs à l’ensemble des agents (fournisseurs de services et utilisateurs de services). Ce dispositif permet de réutiliser les applicatifs métiers, le but étant de permettre à l’entreprise de s’adapter rapidement à un nouveau contexte de marché. En termes d'interopérabilité, les architectures SOA reposent en partie sur les normes décrites à travers le WS-I. Parmi les différentes couches de normes et protocoles qui permettent de bâtir de telles architectures, on relève :la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui) avec : UDDI (Universal Description Discovery and Integration) normalisé par l'OASIS, la description des interfaces des services (quelles sont les données nécessaires à l'exécution du service, que fournit-il en retour, ...) avec : WSDL recommandé par le W3C,l'invocation (ou l'appel) du service (la requête transmise au service) avec : SOAP recommandé par le W3C,le format des données échangées avec : XML recommandé par le W3C, et enfin, le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont des recommandations RFC.

Une architecture SOA pourra être également complétée par : la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key Management Spécification, qui gère les infrastructures à clé publique ou PKI) l'orchestration (on parle également de chorégraphie) des services pour constituer des processus métier avec : BPEL4WS (Business Process Execution Language For Web Services) devenu WS-BPEL et qui est un dérivé à la fois de WSFL (Web Services Flow Language) d'IBM et de XLang de Microsoft qu'il a remplacé, devenant de fait le standard de l'orchestration des services web. On peut aussi citer WSCI (Web Services Choregraphy Interface). L'orchestration suppose l'existence d'un chef d'orchestre (WS-BPEL est un langage d'orchestration), tandis que la chorégraphie implique des interactions pair-à-pair. WS-CDL (Web Services Choregraphy Description Language) est un exemple, le plus récent, d'un tel langage. la gestion transactionnelle (gestion du protocole de validation à deux phases, two-phase commit, pour la mise à jour contrôlée de plusieurs bases de données réparties entre plusieurs fournisseurs de services : la transaction « attend » de recevoir l'acquittement (le commit) des différents serveurs sollicités et en cas de problème avec l'un d'eux, est en mesure de demander aux autres serveurs de « défaire » les mises à jour partielles effectuées afin de maintenir l'intégrité des données) : WS-Transaction d'IBM, XAML (Transaction Authority Markup Language) ou encore BTP (Business Transaction Protocol).

Technologies basées sur les principes de SOA : Service Component Architecture (SCA) est une technologie d'assemblage de composants dans laquelle on considère que tout composant peut exposer des services et que toute dépendance est un lien vers un autre service. Ainsi, créer une application devient un simple assemblage de services, et on peut très aisément publier notre application comme un service sous divers formats (JBI, WS, RMI...). Qworum est une plate-forme qui permet de construire des applications web en combinant des services accessibles par le réseau. Ces services sont interactifs : chaque service peut interagir avec l'utilisateur final par le biais de pages web. Chaque service peut également être composé d'autres services. Exemples : On peut citer la SNCF, qui a mis en place une architecture de type SOA pour son système de réservation (recherche d'horaire, demande de tarif, réservation...) qui prend en charge à la fois les terminaux des guichets des agences et gares, et les sollicitations de son site web de commande en ligne Voyages-sncf.com. Le Groupe Air France-KLM a lui aussi décidé en juillet 2008 de choisir une architecture orientée service pour son SI (architecture à base de web services, elle remplacera à terme l'architecture SOA « maison » qui est en place depuis les années 1990). L'entreprise opte pour cette architecture dans le but de « rendre son SI à la fois évolutif et réactif » 8.

Enfin, l'administration française se modernise également à travers la rénovation de l'infrastructure technique dans certains ministères, dont la Défense et les anciens combattants. Par exemple, l'équipe de projet du prochain système d'information ministériel des achats envisage de recourir à une architecture de services reposant sur un ESB. En effet, ce SI HA ministériel devra échanger avec de nombreux autres. Ainsi, la SOA lui permettra de s'intégrer dans un paysage contraint par un fort besoin d'interopérabilité.

Architecture POO Définition: La programmation orientée objet (POO), ou programmation par objet, est un paradigme de programmation informatique élaboré par les norvégiens Ole- Johan Dahl et Kristen Nygaard au début des années 60 et poursuivi par les travaux d'Alan Kay dans les années 1970. Il consiste en la définition et l'interaction de briques logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait communiquer avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; la communication entre les objets via leurs relations permet de réaliser les fonctionnalités attendues, de résoudre le ou les problèmes. Orthogonalement à la programmation par objet, afin de faciliter le processus d'élaboration d'un programme, existent des méthodologies de développement logiciel objet dont la plus connue est USDP (Unified Software Development Process). Il est possible de concevoir par objet une application informatique sans pour autant utiliser des outils dédiés. Il n'en demeure pas moins que ces derniers facilitent de beaucoup la conception, la maintenance, et la productivité. On en distingue plusieurs sortes : les langages de programmation (Java, C#, vala, Objective C, Eiffel, Python, Ruby, C++, Ada, PHP, Smalltalk, LOGO, AS3...) les outils de modélisation qui permettent de concevoir sous forme de schémas semi-formels la structure d'un programme (Objecteering, UMLDraw, Rhapsody, DBDesigner…) les bus distribués (DCOM, CORBA, RMI, Pyro...) les ateliers de génie logiciel ou AGL (Visual Studio pour des langages Dotnet, NetBeans pour le langage Java) Il existe actuellement deux catégories de langages à objets : les langages à classes et ceux à prototypes, que ceux-ci soient sous forme fonctionnelle (CLOS), impérative (C++, Java…) ou les deux (Python, OCaml…).

Les principes : La programmation orientée objet a été introduite par Alan Kay avec Small talk. Toutefois, ses principes n'ont été formalisés que pendant les années 1980 et, surtout, 1990. Par exemple le typage de second ordre, qui qualifie le typage de la programmation orienté objet (appelé Duck Typing par la communauté Ruby et Python), n'a été formulée qu'en 1995 par Cook. L'objet (attribut et méthodes) : Concrètement, un objet est une structure de données évaluées et cachées qui répond à un ensemble de messages. Cette structure de données définit son état tandis que l'ensemble des messages qu'il comprend décrit son comportement : Les données — ou champs — qui décrivent sa structure interne sont appelées ses attributs ; L'ensemble des messages forme ce que l'on appelle l'interface de l'objet ; c'est seulement au travers de celle-ci que les objets interagissent entre eux. La réponse à la réception d'un message par un objet est appelée une méthode (méthode de mise en œuvre du message) ; elle décrit quelle réponse doit être donnée au message.

Le typage et le polymorphisme : Dans la programmation par objet, chaque objet est typé. Le type définit la syntaxe (« Comment l'appeler ? ») et la sémantique (« Qu'est ce qu'il fait ? ») des messages auxquels peut répondre un objet. Il correspond donc, à peu de chose près, à l'interface de l'objet. Toutefois, la plupart des langages objets ne proposent que la définition syntaxique d'un type (C++, Java, C#, ...) et rares sont ceux qui fournissent aussi la possibilité de définir aussi sa sémantique (Eiffel avec sa conception par contrats). Un objet peut appartenir à plus d'un type : c'est le polymorphisme ; cela permet d'utiliser des objets de types différents là où est attendu un objet d'un certain type. Une façon de réaliser le polymorphisme est le sous-typage (appelé aussi héritage de type) : on raffine un type-père en un autre type (« le sous-type ») par des restrictions sur les valeurs possibles des attributs. Ainsi, les objets de ce sous-type sont conformes avec le type père. De ceci découle le principe de substitution de Liskov. Toutefois, le sous-typage est limité et ne permet pas de résoudre le problème des types récursifs (un message qui prend comme paramètre un objet du type de l'appelant). Pour résoudre ce problème, Cook définit en 1995 la sous-classification et le typage du second ordre qui régit la programmation orientée objet : le type est membre d'une famille polymorphique à point fixe de types (appelée classe). Les traits sont une façon de représenter explicitement les classes de types. (La représentation peut aussi être implicite comme avec Small talk, Ruby, etc.)

On distingue dans les langages objets deux mécanismes du typage : le typage dynamique : le type des objets est déterminé à l’exécution lors de la création desdits objets (Small talk, CLOS, Python, PHP…), le typage statique : le type des objets est vérifié à la compilation et est soit explicitement indiqué par le développeur lors de leur déclaration (C++, Java, C#, Pascal…), soit déterminé par le compilateur à partir du contexte (Scala, OCaml, Haskell…).

La redéfinition : La programmation objet permet à un objet de raffiner la mise en œuvre d'un message défini pour des objets d'un type parent, autrement dit de redéfinir la méthode associée au message : c'est le principe de redéfinition des messages (ou overriding en anglais). Pour réaliser alors la redéfinition, deux solutions existent : le typage du premier ordre associé à l'attachement dynamique (c'est le cas de C++, Java, C#, ...). Cette solution induit une faiblesse dans le typage et peut conduire à des erreurs. Les relations entre type sont définies par le sous-typage (théorie de Liskov) ; le typage du second ordre (duquel découlent naturellement le polymorphisme et l'appel de la bonne méthode en fonction du type exact de l'objet). Ceci est possible avec Small talk et Eiffel. Les relations entre types sont définies par la sous-classification (théorie F-Bound de Cook).