Transcript Architecture SOA et POO

SOMMAIRE
Architecture SOA
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
Définition
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 OleJohan 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 soustypage (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).