ARCHITECTURE SOA ET POO

.

RÉALISER PAR:

NAWFEL ELABED AMIN CHEBBI

SOMMAIRE

Architecture SOADéfinitionLes conceptsLe service WOA (Web Oriented Architecture)Les protocoles et les normesTechnologies basées sur les principes de SOA

Architecture POODéfinitionLes principesLe typage et le polymorphismeLa 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).