Soa Sca

SCA et SOA : exemple de mise en oeuvre au travers d'un tutorial
par Armel CHETA, B. Jc. BAKENEGHE, Alain FOKO, M. YACOUBOU, Salomon MAYENGUE et Stphanie YOUNA
Date de publication : 13 mars 2010 Dernire mise jour :
Le prsent article traite d'une mise en oeuvre simple de concepts SCA (Service Component Architecture) et SOA (Service Oriented Architecture) pour les dveloppements d'applications.
SCA et SOA : exemple de mise en oeuvre au travers d'un tutorial par Armel CHETA, B. Jc. BAKENEGHE, Alain FOKO, M. YACOUBOU, Salomon MAYENGUE et Stphanie YOUNA
I - Introduction aux concepts SCA et SOA................................................................................................................. 3 II - Quels sont les avantages lorsqu'on adopte SOA ?...............................................................................................3 II-1 - Avantages pour le dveloppeur.................................................................................................................... 3 II-2 - Avantages pour l'entreprise...........................................................................................................................3 III - Ecriture de composants SOA............................................................................................................................... 4 III-1 - Exemple de conception d'un petit Framework SOA.................................................................................... 4 III-1-1 - Les Data Transfert Object (DTO)........................................................................................................ 5 III-1-1-1 - Dfinition......................................................................................................................................5 III-1-1-2 - Diagramme de classe................................................................................................................. 5 III-1-2 - L'accs aux donnes (DAO)................................................................................................................6 III-1-2-1 - Dfinition......................................................................................................................................6 III-1-2-2 - Diagramme de classe................................................................................................................. 7 III-1-3 - Les services simples (SISV)................................................................................................................8 III-1-3-1 - Dfinition......................................................................................................................................8 III-1-3-2 - Diagramme de classe................................................................................................................. 9 III-1-4 - Les services composes (SVCO)......................................................................................................10 III-1-4-1 - Dfinition....................................................................................................................................10 III-1-4-2 - Diagramme de classe............................................................................................................... 11 III-1-5 - La gestion des exceptions................................................................................................................. 12 III-1-5-1 - Dfinition....................................................................................................................................12 III-1-5-2 - Diagramme de classe............................................................................................................... 13 III-2 - Exemple d'utilisation du Framework SOA dans un projet..........................................................................15 III-2-1 - Spcifications du projet......................................................................................................................15 III-2-2 - Les DTOs........................................................................................................................................... 16 III-2-2-1 - Diagramme de classe : module User et module Compte Bancaire.......................................... 16 III-2-2-2 - Exemple de code d'une classe DTO........................................................................................ 17 III-2-3 - La couche DAO................................................................................................................................. 17 III-2-3-1 - Diagramme de classe : module comptes bancaires................................................................. 17 III-2-3-2 - Exemple de code d'un Service Simple..................................................................................... 17 III-2-4 - La couche des Services Composs.................................................................................................. 17 III-2-4-1 - Diagramme de classe : module Compte Bancaire....................................................................17 III-2-4-2 - Exemple de code d'un Service Compos................................................................................. 18 III-2-5 - Exposition des services composs....................................................................................................18 IV - Infrastructure SCA pour l'assemblage de composants SOA..............................................................................18 V - Dbat : le mode SOA est-il toujours adapt et pertinent pour nos dveloppements ?........................................18 VI - Les tlchargements.......................................................................................................................................... 19
http://koossery-tech.developpez.com/tutoriels/soa/sca-et-soa-exemple-mise-oeuvre-travers-tutorial/
-2-
I - Introduction aux concepts SCA et SOA

SCA (Service Component Architecture) est un concept qui dfinit un ensemble de stratgies pour la mise en place d'applications base de composants afin d'adresser les problmatiques SOA (Service Oriented Architecture). Un des points fondamentaux dans SCA est qu'un service de niveau N se construit par orchestration (ou combinaison) de services de niveau N-1 ou N. Dans une application qui suit SCA on distingue 2 lments : les composants SOA qui fournissent et consomment des services, l'assemblage des composants SOA qui donne lieu une application mtier de haut niveau.
Dans cet article nous allons aborder tour tour : les avantages que peut tirer un projet ou une entreprise en adoptant SOA, l'criture de composants SOA : pour cela nous allons concevoirde faon progressive un exemple de framework SOA.
Nous allons brivement aborder l'assemblage de composants SOA puis la fin nous allons nous poser la question de savoir si le mode SOA est toujours pertinent et adapt pour toute situation.
II - Quels sont les avantages lorsqu'on adopte SOA ?

Les avantages SOA gnralement cits peuvent tre classs en 2 catgories : les avantages pour le dveloppeur. les avantages pour l'entreprise.
II-1 - Avantages pour le dveloppeur

Ci-dessous quelques avantages : Meilleure maintenance de l'application : en effet en cas de bug il suffit de localiser le service qui cause problme, de l'isoler, de le traiter et ensuite le rinjecter dans l'application. Meilleure volutivit par ajout de nouveaux services ou remplacement de services existants. Rutilisabilit de services : des services de base peuvent tre partags entre diffrentes applications. Le dveloppement de nouvelles applications peut alors tre fait par combinaison de services dj prouvs et du coup le risque de bug s'en trouve amoindri. Les quipes de dveloppements qui adoptent SOA sont souvent emmenes mettre en place un Centre d'Excellence en Architecture, ce qui lve le niveau de conception et de dveloppement des projets. Baigner dans un tel environnement ne peut qu'tre bnfique pour un dveloppeur.
II-2 - Avantages pour l'entreprise

Ci-dessous quelques avantages : Agilit et innovation permanente des offres : pour une entreprise qui doit sans cesser lancer de nouvelles offres sur le march, le dveloppement de ces dernires peut se faire en grande partie par utilisation de services dj existants. Cela a pour consquence de rduire le temps de sortie des offres car le temps des dveloppements est rduit. Possibilit d'aligner les services avec les mtiers : cela a pour avantage de faire travailler de faon rapproche les quipes mtiers avec les quipes techniques.
-3-
Mise en place d'un tableau de bord SOA permettant de recenser les services de base communs aux mtiers de l'entreprise et de rflchir sur la faon de les organiser de sorte les rutiliser efficacement. Il pourrait en rsulter la mise en place d'une politique de prvention pour ce qui concerne la prolifration de services parfois inutiles. Mise en place d'une gestion rigoureuse des modifications des services partags : cela suppose des mtriques de qualit et des tests de non rgression hautement prouvs. Mise en place de mtriques sur l'utilisation d'un service, ce qui peut aider valuer son cot. Enfin la SOA prpare l'entreprise pouvoir inter-communiquer avec ses partenaires via diffrents canaux : EAI, ESB, etc. Elle expose ses services ses partenaires qui les consomment.
Au-del des avantages immdiats ci-dessus cits, certaines entreprises peuvent encore aller plus loin en rflchissant sur une sorte de gouvernance SOA. La gouvernance SOA peut tre dfinie comme une rflexion que l'entreprise ayant adopte SOA mne afin de profiter pleinement de cette nouvelle architecture pas seulement du point de vue technologique, mais aussi des points de vue humain, processus, droits dcisionnels (qui est-ce qui par exemple dcide de faire voluer un service et quelles sont les prcautions prendre, qui est-ce qui dcide de la publication ou du retrait d'un service, etc.), gestion des objectifs, etc. La gouvernance SOA n'est pas dans le scope de cet article.
III - Ecriture de composants SOA

Nous allons concevoir un petit Framework SOA de faon progressive. Ensuite suivra une mise en oeuvre de ce framework au travers d'un exemple de code d'un projet SOA.
III-1 - Exemple de conception d'un petit Framework SOA

Nous allons partir d'une logique selon laquelle tout composant d'une application oriente services est construit par combinaison de plusieurs couches : la couche d'accs aux donnes (DAO pour Data Access Object), la couche des services simples (SISV pour Simple Service) et la couche des services composs (SVCO pour Service Compos).
Figure 1 : les diffrentes couches d'un composant En dehors des couches ci-dessus, notre logique voudrait qu'on ait aussi : les DTO (data transfert objet) pour vhiculer les donnes entre les composants. Les DTO interviennent aussi au sein des couches d'un composant. une ossature pour la gestion des exceptions.
Nous dveloppons les briques techniques de ce Framework dans la suite.
-4-
III-1-1 - Les Data Transfert Object (DTO) III-1-1-1 - Dfinition

Les donnes persistantes sont les informations contenues et gres dans les bases de donnes (MySQL, Oracle, SQL Server...) ou sur tout autre support (fichier Excel, XML...). Les DTO sont utiliss pour vhiculer les donnes travers les couches. Ils peuvent galement intervenir lors des changes de messages entre l'application et l'extrieur.
III-1-1-2 - Diagramme de classe
Figure 2 : diagramme de classe pour les DTO ITransferableObject : ITransferableObject Interface de base pour tous les objets qui permettent de vhiculer les donnes entre les couches d'un composant ou entre l'application et l'extrieur. CommonTransferableObject :
-5-
CommonTransferableObject Classe abstraite commune tous les Transferable Object (DTO, criteria) LazyLoadArrayList FilLazyLoadProperty() Credential()
Tableau contenant la liste des proprits devant tre charges par lazy-load. Charge en lazy-load les proprits dfinies dans le tableau LazyLoadArrayList. Retourne un objet Credential qui encapsule les donnes d'authentification d'un utilisateur.
AbstractDataTransfertObject : AbstractDataTransfertObject AbstractDataTransfertObject()
PropertyHasChanged()
Constructeur permettant de crer une nouvelle instance d'un objet transfrable sans tat. L'objet peut avoir les tats suivants : - IsNew = true pour spcifier que l'objet devra tre nouvellement cr dans le en base. - IsModified = true pour spcifier qu'il existe dj un tel objet en base et que le systme devra juste faire un update de cet objet existant avec les nouvelles donnes contenues dans le DTO. - IsDeleted = true pour spcifier qu'il existe dj un tel objet en base et que le systme devra le supprimer. Par dfaut un nouveau DTO est l'tat isNew. Si isModified=true alors ajoute la proprit concerne dans la liste des PropertiesModified.
III-1-2 - L'accs aux donnes (DAO) III-1-2-1 - Dfinition

La DAO (Data Access Object) est la couche o sont implmentes les oprations d'accs aux donnes. En gnral ces oprations concernent la recherche, la cration, la suppression ou la modification. Le Framework met en place des classes techniques pour grer la persistance dans les applications indpendamment du support de persistance (base de donnes, fichier xml, etc.). En gnral chaque module mtier a son propre DAO (Exemple : DocumentDAO, RevenuDAO, ...). Toutefois un mme DAO peut tre utilis par plusieurs modules mtiers. Pour accder aux donnes, la couche DAO peut s'appuyer sur un Framework de mapping objet relationnel (ORM) tel Hibernate ou un Data Mapper tel iBatis.
-6-
Figure 3 : Couche DAO IDataAccessObject : IDataAccessObject
Interface de base de toute DAO. IGeneriqueDAO :
-7-
IGeneriqueDAO
Insert( DTO ) Find( Criteria ) FindOne( DTO ) FindAll() Update( DTO )
SaveOrUpdateOrDelete( DTO )
Interface gnrique dfinissant les oprations de base (CRUD) d'accs aux donnes. Insre une DTO dans la source de donnes et retourne son identifiant technique. Recherche toutes les DTO dont les critres de recherche sont prciss dans un Criteria. Charge une DTO ainsi que toutes les proprits spcifies dans le tableau du lazyload Retourne toutes les DTO d'un type prsent dans la base de donnes. Met jour une DTO dans la source de donnes. Pour identifier la DTO, le framework s'appuie soit sur l'identifiant technique, soit sur la BK (BK pour Business Key). Insre, met jour ou supprime un DTO en fonction de son tat.
KTIbatisGenericDAOImpl : KTIbatisGenericDAOImpl Implmentation gnrique d'une DAO s'appuyant sur le data mappeur Ibatis pour l'accs aux donnes.
DAOController : DAOController Gre l'accs aux DAO : on y trouve la mthode get( String key ) permettant de retourner l'implmentation de la DAO dont la cl est passe en paramtre
III-1-3 - Les services simples (SISV) III-1-3-1 - Dfinition

Les services simples sont constitus de fonctionnalits mtiers basiques (atomiques). Ils forment une couche qui manipule directement la couche DAO. Cette couche est en gnral trs stable et est aussi souvent dsigne par 'couche des composants mtiers'. Nous allons dsigner les services simples par l'abrviation SISV.
-8-
Figure 4 : Couche SISV IBusinessService : ISimpleService Interface de base de tout service simple. IGeneriqueSISV : IGeneriqueSISV
Crer( DTO )
Charger( DTO ) Chercher( Criteria ) Enregistrer( DTO )
cre une DTO en base et retourne son identifiant technique. Retourne une DTO en chargeant toutes les proprits marques en lazy-load. Retourne une liste de DTO selon des critres prciss dans Criteria. Permet de faire des oprations sur des grappes d'objet. La mthode Enregistrer est invoque la racine de la grappe et tous les
-9-
objets de la grappe sont traits en fonction de leurs tats. SISVFinder : SISVFinder Il s'agit d'un finder pour l'accs aux SISV : on y trouve la mthode get(String key) permettant de retourner l'implmentation de la SISV dont la cl est passe en paramtre.
III-1-4 - Les services composes (SVCO) III-1-4-1 - Dfinition

C'est la couche des services de haut niveau. Ces services sont obtenus par combinaison des fonctionnalits offertes par la couche des services simples (SISV). Nous les dsignons aussi par services composs, en abrg SVCO. Exceptionnellement pour des composants pas complexes, un SVCO peut directement manipuler des DAO.
- 10 -
Figure 5 : Couche SVCO IServiceComposed : IServiceComposed Interface de base de tout service de haut niveau (SVCO). IGeneriqueSVCO : IGeneriqueSVCO
Crer( DTO )
Charger( DTO ) Chercher( Criteria ) Enregistrer( DTO )
cre une DTO en base et retourne son identifiant technique. Retourne une DTO en chargeant toutes les proprits marques en lazy-load. Retourne une liste de DTO selon des critres prciss dans Criteria. Permet de faire des oprations sur des grappes d'objet. la mthode Enregistrer est invoque la racine de la grappe et tous les
- 11 -
objets de la grappe sont traits en fonction de leurs tats. SVCOFinder : SVCOFinder Il s'agit d'un finder pour l'accs aux SVCO
III-1-5 - La gestion des exceptions III-1-5-1 - Dfinition

Le framework offre un socle technique permettant de grer les exceptions. Pour lever une exception dans une mthode, il suffit de dcorer ladite mthode avec l'attribut MethodAttribut. MethodAttribut prend en paramtre la cl du message d'erreur ainsi que les arguments du message d'erreur. Une methode peut lever une ou plusieurs exceptions.
[MethodAttribut("KTMICROFI_USERSVCOIMPL_CHARGER")] public UserDTO Charger(UserDTO userDTO) { userSISVImpl = ConcreteSISVImpl(userDTO); if (userSISVImpl.ValiderUserDTO(MODE.FINDONE.ToString(), userDTO)) { return userSISVImpl.Charger(userDTO); } return null; }
- 12 -
Figure 6 : Diagramme de classe de gestion des exceptions ExceptionAdvice : ExceptionAdvice Intercepteur des appels des mthodes. IExceptionHandler : IExceptionHandler Interface de base des classes charges de traiter les exceptions. HandlerException ( System.Exception, Object, MethodeInfo , Object[])
Mthode dans laquelle le traitement de l'exception est effectu. Elle prend comme paramtres : - System.Exception : reprsente l'exception leve.
- 13 -
- Object : Objet cible sur lequel la mthode est dfinie. - MethodeInfo : contient les mta-donnes ( nom de la mthode, type de retour,...) de la mthode en cours d'execution. - Object[] : tableau contenant les arguments de la mthode. DefaultKTExceptionHandler : DefaultKTExceptionHandler Une implmentation par dfaut de l'interface IExceptionHandler. IMethodMatcher : IMethodMatcher GetExceptionHandlerKey (MethodInfo, object[])
Retourne la cl du gestionnaire d'exception qui traitera l'exception lve : - MethodInfo : mta-donnes dcrivant la mthode dans laquelle l'exception a t lve. - Object[] : tableau contenant les arguments de la mthode.
DefaultKTMethodMatcher : DefaultKTMethodMatcher Une implmentation par dfaut de l'interface IMethodMatcher.
IKeyReader : IKeyReader ReadKey ( MethodInfo, object[])
Retourne la cl du message d'erreur pour l'exception traiter : - MethodInfo : mta-donnes dcrivant la mthode dans laquelle l'exception a t leve. - Object[] : tableau contenant les arguments de la mthode.
DefaultKTReader : DefaultKTReader Une implmentation par dfaut de l'interface IKeyReader.
IExternalExceptionBuilder : IExternalExceptionBuilder Permet de contruire une exception en fonction du mode d'exposition du service (SOAPexception pour les WebServices...)
DefaultKTExternalExceptionBuilder :
- 14 -
DefaultKTExternalExceptionBuilder Une implementation par dfaut de l'interface IExternalExceptionBuilder.
III-2 - Exemple d'utilisation du Framework SOA dans un projet III-2-1 - Spcifications du projet
Nous allons mettre en oeuvre le framework en codant un composant SOA dans le cadre d'un petit projet de gestion d'une mini banque de dtail : le projet MiniBank. L'application MiniBank doit : permettre un Agent de crer ou rechercher les comptes clients. permettre un Client de visualiser les historiques de toutes les oprations effectues sur son compte bancaire. permettre un client de payer ses achats e-commerce. La Mini-Bank exposera alors un service au site ecommerce que ce dernier pourra invoquer pour interroger le compte bancaire du client et effectuer des dbits correspondants au montant des achats.
Le projet MiniBank va comporter une partie front-end et une partie serveur. Nous allons coder le serveur en mode SOA. A premire vue on distingue le service des Comptes Bancaires : CompteBancaireService. Ce service devra fournir les fonctionnalits suivantes : fonctionnalit de cration d'un compte bancaire pour un client donn. On suppose qu'il n'existe qu'un seul type de compte bancaire et que la cration d'un compte bancaire se fait de pair avec la cration du client si ce dernier n'existe pas dans la liste des clients de la banque. fonctionnalit de recherches de comptes bancaires. fonctionnalit de visualisation de l'historique d'un compte bancaire. fonctionnalit consistant mouvementer le compte bancaire. Mouvementer un compte bancaire consiste le crditer ou le dbiter.
Dans la suite nous allons tour tour aborder : les DTO. les services simples (SISV) et les DAO que va utiliser notre CompteBancaireService.. l'exposition des fonctionnalits de CompteBancaireService.
- 15 -
III-2-2 - Les DTOs III-2-2-1 - Diagramme de classe : module User et module Compte Bancaire
Figure 7 : les DTO de la MiniBank Dans le schma ci-dessus, BK dsigne la business key : cela se traduira en base par une contrainte UNIQUE NOT NULL. PK dsigne l'identifiant technique : cela se traduira en base par PRIMARY KEY. FK dsigne l'identifiant de l'entit d'une association : cela se traduira en base par FOREIGN KEY. Lazy load signifie chargement la demande. Si lazy-load=false alors le chargement a lieu automatiquement et on utilise une jointure afin d'viter d'avoir N+1 requtes (avoid N+1 request).
AgentDTO est le DTO pour reprsenter un Agent. ClientDTO reprsente un Client. AgentDTO et ClientDTO tendent UserDTO : on a utilis la stratgie JOINDED-SUBCLASS. Pour cela au niveau de UserDTO on a mis toutes les proprits communes ClientDTO et AgentDTO ainsi que le discriminateur (ici c'est la proprit 'rle'). UserDTO va se traduire dans le code par une classe abstraite.
- 16 -
Entre ClientDTO et CompteDTO nous avons une relation bidirectionnelle de type 1<->n : 1 client a potentiellement plusieurs comptes bancaires et rciproquement un compte bancaire appartient 1 Client. Le ct matre de la relation bidirectionnelle ci-dessus est au niveau de CompteDTO et le ct esclave (dans certaines littratures technique on parle de ct mapped-By) est au niveau de ClientDTO.
III-2-2-2 - Exemple de code d'une classe DTO III-2-3 - La couche DAO III-2-3-1 - Diagramme de classe : module comptes bancaires
III-2-3-2 - Exemple de code d'un Service Simple III-2-4 - La couche des Services Composs III-2-4-1 - Diagramme de classe : module Compte Bancaire
- 17 -
III-2-4-2 - Exemple de code d'un Service Compos III-2-5 - Exposition des services composs IV - Infrastructure SCA pour l'assemblage de composants SOA
Une fois qu'on a fini de dvelopper nos services dans une technologie donne (Java, .NET, C++, etc.), il se pose naturellement les questions d'assemblage. L'assemblage peut tre vu comme une technique consistant dfinir d'une part comment un composant expose ses services pour consommation par d'autres applications priori dveloppes dans des technologies htrognes, et d'autre part comment un ensemble de services peuvent tre packags sous formes de composites. Le fait de mettre en place des composites permet de favoriser la rutilisation dans la mesure o on expose un groupe de composants comme un seul service. Il existe des spcifications SCA d'assemblage qui dcrivent comment lier les composants et les composites. Avec un assemblage SCA en place : Le dveloppeur dispose d'un point d'accs (on parle aussi d'interface) unique pour les services. L'accs un service est rendu possible par les mcanismes d'accs proposs par l'infrastructure SCA. Notons que les services peuvent tre implments dans n'importe quel langage. L'administrateur, par configuration de la plate-forme SCA, peut mettre en place une politique efficace pour scuriser l'accs aux services ou plus globalement configurer un ensemble de politiques pour des services.
Il existe un ensemble de plate-forme SCA open source. Parmi celles-ci, on peut citer notamment les plates-formes : Tuscany : http://tuscany.apache.org/ Fabric3 : http://www.fabric3.org/ SCOrWare : http://www.scorware.org/
Dans une publication ultrieure nous ferons un tutorial d'assemblage de composants l'aide de Tuscany.
V - Dbat : le mode SOA est-il toujours adapt et pertinent pour nos dveloppements ?
De nos jours de nombreuses entreprises ont adopt du mode SOA pour les dveloppements de leurs projets et plus largement pour leur SI. Cela a entran parfois de gros investissements car la mise en place d'une politique SOA a ncessit de profonds chamboulements. Une des questions qu'on peut lgitimement se poser est de savoir si les entreprises ont toujours un bon retour sur investissement. De notre point de vue, les entreprises qui sont confrontes une rude concurrence ncessitant qu'elles renouvellent sans cesse leurs offres ont certainement trouv leur compte dans la SOA du fait par exemple de l'agilit et de la rutilisation de services lors des dveloppements de nouvelles offres. Pour ce qui concerne les entreprisses qui n'ont pas besoin de systmatiquement remettre en cause leurs offres ou n'ont pas trop besoin d'agilit, elles ont surtout trouv dans la SOA un moyen de rendre leur systme d'information propre et lisible. En adoptant la SOA, elles se prparent inter-communiquer via des bus EAI ou ESB avec leurs partenaires avec une relative aisance technique.
- 18 -
En dernier lieu les entreprises qui ne sont pas confronts aux enjeux majeurs ci-dessus cits auront certainement plus de mal trouver le bien-fond d'une politique SOA... Ces dbats sur le retour sur investissement SOA ont parfois emmen certains gourous techniques dcrter la mort de SOA... Au-del du dbat sur la mort ou pas de SOA, certaines minences telles Rockford Lhotka (www.lhotka.net) ont mis il y'a quelques annes l'ide selon laquelle la SOA n'est pas quelque chose de nouveau car en ralit c'tait dj pratiqu de tout temps ! Par ailleurs il va l'encontre du principe de rutilisabilit chre SOA arguant que cella baisse les performances de l'application.
VI - Les tlchargements
Le projet Maven du framework que nous avons conu dans cet article est disponible ici en version .NET : ?? Le projet UML du serveur de la MiniBank est disponible ici : ??. Il a t fait en s'appuyant sur l'article UML suivant : Framework de modlisation d'un projet en langage UML Le projet Maven du serveur MiniBank est disponible ici en version .NET : ?? Koossery Technology est une entreprise spcialise dans les dveloppements de projets au forfait (.NET & Java J2ee) et dispose pour cela d'une cellule Architecture Technique & Outillages ainsi que d'une Usine Logicielle. Koossery Technology dispose aussi d'un Centre de Services pour les dveloppements GED base de Alfresco et workflow avancs base de jBoss jBPM. Tous nos remerciements au comit developpez.com
- 19 -

Soa Sca

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Soa Sca

Transféré par

Droits d'auteur :

Formats disponibles

SCA et SOA : exemple de mise en oeuvre au travers d'un tutorial

I - Introduction aux concepts SCA et SOA

II - Quels sont les avantages lorsqu'on adopte SOA ?

II-1 - Avantages pour le dveloppeur

II-2 - Avantages pour l'entreprise

III - Ecriture de composants SOA

III-1 - Exemple de conception d'un petit Framework SOA

Nous dveloppons les briques techniques de ce Framework dans la suite.

III-1-1 - Les Data Transfert Object (DTO) III-1-1-1 - Dfinition

III-1-1-2 - Diagramme de classe

AbstractDataTransfertObject : AbstractDataTransfertObject AbstractDataTransfertObject()

III-1-2 - L'accs aux donnes (DAO) III-1-2-1 - Dfinition

III-1-2-2 - Diagramme de classe

Figure 3 : Couche DAO IDataAccessObject : IDataAccessObject

Interface de base de toute DAO. IGeneriqueDAO :

Insert( DTO ) Find( Criteria ) FindOne( DTO ) FindAll() Update( DTO )

III-1-3 - Les services simples (SISV) III-1-3-1 - Dfinition

III-1-3-2 - Diagramme de classe

Charger( DTO ) Chercher( Criteria ) Enregistrer( DTO )

III-1-4 - Les services composes (SVCO) III-1-4-1 - Dfinition

III-1-4-2 - Diagramme de classe

Charger( DTO ) Chercher( Criteria ) Enregistrer( DTO )

III-1-5 - La gestion des exceptions III-1-5-1 - Dfinition

III-1-5-2 - Diagramme de classe

DefaultKTMethodMatcher : DefaultKTMethodMatcher Une implmentation par dfaut de l'interface IMethodMatcher.

IKeyReader : IKeyReader ReadKey ( MethodInfo, object[])

DefaultKTReader : DefaultKTReader Une implmentation par dfaut de l'interface IKeyReader.

DefaultKTExternalExceptionBuilder Une implementation par dfaut de l'interface IExternalExceptionBuilder.

Vous aimerez peut-être aussi