Introduction lArchitecture Oriente Service
Modules SAR O2/SAR O3 SI3 Revu par F. Baude, M2 MIAGE NTDP, 2008
(essentiellement simplification, raccourcissements, + quelques details)
(c) 2007, Occello Audrey, SAR
-1-
Plan du cours
A quels besoins rpond le SOA ? Pourquoi les solutions actuelles sont insuffisantes ? Quels sont les principes de base du SOA ? Quels sont les lments cl dune architecture oriente services ? Quel est le cycle de vie dun service ? Quelles mthodes et outils permettent de mettre en oeuvre une architecture oriente services ?
(c) 2007, Occello Audrey, SAR
-3-
A quels besoins rpond le SOA ? Pourquoi les solutions actuelles sont insuffisantes ?
(c) 2007, Occello Audrey, SAR
-4-
Problmatique de lintgration en entreprise
La cration d'applications dans l'entreprise est trs souvent pilote par des besoins trs court terme Dveloppement d'une application sous tel dlai avec telles fonctionnalits Modlisation et dveloppement dirig par les choix/contraintes techniques Pas de discussion entre maitrise d'ouvrage (MOA) et maitrise d'oeuvre (MOE) Dcalage entre besoins mtier et leur ralisation (constituants informatiques) Pas de place pour la prise en compte de l'volution des besoins fonctionnels au niveau de l'application (c) 2007, Occello Audrey, SAR -6-
Problmatique de lintgration en entreprise
Le dcoupage prsentation/traitement/base de donnes de l'architecture 3-tiers facilite le travail de la MOE mais favorise le cloisonnement en silos applicatifs indpendants (blocs monolithiques) Certaines fonctions sont redondantes : une version pour chaque application
Pas de mutualisation des dveloppements entre projets et peu de rutilisation possible (c) 2007, Occello Audrey, SAR -7-
Problmatique de lintgration en entreprise
Entreprises dcoupes en dpartements fonctionnels y compris le SI Processus mtiers de + en + inter-dpartementaux Les processus franchissent les fontires de l'entreprise qui doit pouvoir prendre en compte les activits et processus des partenaires pour tre reactive
Cots considrables dans la gestion des flux entre dpartements et dans lintgration de leurs SI (c) 2007, Occello Audrey, SAR -8-
Hier : plat de spaghettis
Dveloppements coteux Interconnexions redondantes (point point) Grande complexit Maintenance difficile (c) 2007, Occello Audrey, SAR -9-
Vers toujours plus d'abstraction
Procdures Modules Modles orients objets
Packages Encapsulation
Design pattern ...
(c) 2007, Occello Audrey, SAR - 10 -
Limites de la programmation oriente Objet
Structure et architecture de lapplication peu visibles Interactions entre objets enfouies dans le code volution / modification difficile Recherche des bouts de code impliqus source derreur Gestion de la consistance dun changement dlicate
(c) 2007, Occello Audrey, SAR
- 11 -
Objets et encapsulation
Granularit encore trop fine Mal adapte la programmation grande chelle Couplage fort Rend difficile la rutilisation Accrot la complexit des Systmes OO
(c) 2007, Occello Audrey, SAR
- 12 -
Encore plus de structuration avec les composants logiciels
Analogie avec les composants lectroniques, legos, puzzles
(c) 2007, Occello Audrey, SAR
- 13 -
Un Composant : Quest-ce que cest ?
Dfinition usuelle
Une unit regroupant les fonctionnalits concernant une mme ide Un module logiciel autonome pouvant tre install sur diffrentes plates-formes qui exporte des attributs et des mthodes qui peut tre configur (dploiement semi automatique) capable de sauto-dcrire tre des briques de base configurables pour permettre la construction dune application par composition - 14 -
Intrt
(c) 2007, Occello Audrey, SAR
Structure dun composant
Interactions avec un composant
ce qui est fourni par le composant ce qui est utilis par le composant modes de communication proprits (attributs publics) connexions cycle de vie (arret, redemarrage, ...) contraintes techniques (transaction, persistance, scurit, ...)
Configuration du composant
Interface de configuration
(c) 2007, Occello Audrey, SAR
Interfaces fournies
- 15 -
Interfaces requises
Re-configuration dynamique
Consommer: payer, selectionner, prendre Gerer: ouvrir, remplir, mettreMonnaie Rparer: ouvrirCapot, fermerCapot Facturer: encaisser, rendreMonnaie
Distributeur de boissons
Facturation version 1
Facturer: encaisser, rendreMonnaie
Just in time binding Permet de modifier l'application chaud sans modification du code en manipulant les assemblages (c) 2007, Occello Audrey, SAR
Facturation version 2
Facturer: encaisser, rendreMonnaie
- 16 -
Les composants dans la nature
La modlisation des composants logiciels est intgre UML 2.0 Spcification : Composants CORBA (CCM) Spring (JEE beans for Web apps) Fractal (Etendu pour le rparti, voir GridComponentModel Equipe I3S/INRIA OASIS) SCA (Service component Architecture) => utilis pour SOA (voir OSOA Tuscany, HydraSCA, IBMWebSphere pack for SOA, etc) Plates-formes d'xecution OpenCCM (GridCCM, Equipe PARIS IRISA Rennes) Julia (Fractal), ProActive (GCM) Sofa (Fractal) ... Occello Audrey, SAR (c) 2007, - 17 -
Convergence Composants / Services
Exposer les interfaces offertes par les composants selon une technologie au choix; Par exemple Services web, avec binding SOAP Interface Java avec binding RMI ou JMS Principe suivi par la norme SCA : Service Component Architecture Notion de Composite Service
(c) 2007, Occello Audrey, SAR
Convergence Composants / Services : Exemple
From : (c) 2007, Occello Audrey, SAR
Demain : Architecture urbanise
Lurbanisation informatique dfinit l'organisation dun SI limage dune ville
dcouper le SI en modules autonomes (zone, quartier, lot, bloc) localiser les zones dchange dinformations (routes, ponts, tunels) qui permettent de dcoupler les diffrents modules
Objectif : faire voluer le SI au mme rythme que la stratgie et l'organisation des mtiers de l'entreprise
legacy services portail
...
Canal d'change donnes processus
NonInterruptible Receive Invoke Invoke Reply Invoke Reply Fault
partenaires
... - 20 -
(c) 2007, Occello Audrey, SAR
Quels sont les principes de base du SOA ?
(c) 2007, Occello Audrey, SAR
- 21 -
Principes fondamentaux de larchitecture SOA
Il nexiste pas une recette pour garantir le succs de la mise en place dune SOA mais des principes respecter : Discussion entre mtier et IT Utilisation des use case mtier Utilisation de standards Pas de remise en cause de lexistant lors dvolutions technologiques Dcouplage entre fournisseur et consommateur de services Indpendance des ressources vis vis de ceux qui les utilisent
(c) 2007, Occello Audrey, SAR - 22 -
Quest ce quun Service (au sens SOA) ?
Partage les caractristiques suivantes dun objet
Modulaire (ensemble de fonctionnalits qui font sens)
Partage les caractristiques suivantes dun composant
Boite noire (sparation interface/implmentation) Indpendant de la localisation Neutralit vis--vis des protocoles de transport
Correspond un primtre fonctionnel que lon souhaite exposer des consommateurs Est faiblement coupl (indpendant des autres services) Expose un petit nombre doprations offrant un traitement de bout en bout Sans tat (c) 2007, Occello Audrey, SAR - 23 -
4 proprits du service retenir
Un Service est Autonome et sans tat (en gnral, [Link] WSRF) Un Service expose un Contrat
in out
Conditions Gnrales de Vente Rglement Intrieur Vos droits/Vos devoirs
Les Frontires entre services sont Explicites
Les services communiquent par messages
(c) 2007, Occello Audrey, SAR
- 24 -
Exemple de couplage fort : Gestion de prts
Entits
LoanAgent LoanApproval Account Loan SMSGateway
calculateRisk
checkCredit
createLoan sendConfirmation
LoanAgent est li LoanApproval et Loan LoanApproval est li Account Loan est li SMSGateway (c) 2007, Occello Audrey, SAR - 25 -
Gestion de prts en couplage faible
Services
LoanProcess CheckAccount Balance Calculate LoanRisk CreateLoan Notify ViaSMS
Quest ce que LoanProcess ? Un processus mtier ! Il permet dorchestrer les services => couplage lche (c) 2007, Occello Audrey, SAR - 26 -
Business Process Management (BPM)
But : Donner l'Entreprise les moyens de grer ses processus mtiers de manire informatise (modlisation, simulation, excution et audit)
Optimisation, adaptation aux besoins en temps rel
Un processus est compos de sous processus, de dcisions (Business rules) et dactivits Un sous processus a son propre but, entres et sorties Les activits
correspondent aux parties du processus mtier qui nincluent pas de dcision et sont associes des rles Sont ralises par des systmes ou des humains
Des mesures (KPI pour Key Performance Indicators) permettent de capturer les performances du processus Un processus est le rsultat dune orchestration de service Le processus est lui-mme accessible en tant que service
(c) 2007, Occello Audrey, SAR
- 27 -
BPM par lexemple
(c) 2007, Occello Audrey, SAR
- 28 -
Les couches SOA
ag e
* *
Ces diffrents modes de couplage sont ncessaires et dpendent du niveau dans larchitecture
Co au up ni lag ve e au fa l o i bl e gi qu e
(c) 2007, Occello Audrey, SAR
Ex :
Co au up ou n lag vi a ive e si u au fa on n i v te i b l S C ea c e A u hn i lo q gi ue qu e :
Co up l
fo rt
- 29 -
e-store : Couches
AccountController Default SignOut Presentation Layer My Account Edit Account Create Account SignIn Search Category Items Item Details Shopping Cart Help Error CartController
Check out
Order Billing
Order Shipping
Order Process
Business Logic Layer
Account
Profile
Product
Item
Inventory
Cart
OrderInsert
OrderRead
Data Access Layer
IAccount
IProfile
IProduct
IItem
IInventory
IOrder
(c) 2007, Occello Audrey, SAR
- 30 -
e-store : Domaines
Default SignOut Presentation Layer My Account Edit Account Create Account SignIn Search Category Items Item Details Shopping Cart Help Error
Check out
Order Billing
Order Shipping
Order Process
Business Logic Layer
Account
Profile
Product
Item
Inventory
Cart
OrderInsert
OrderRead
1.0 1.1 1.2
Data Access Layer IAccount IProfile
1.0 2.0 3.5
IProduct IItem
10.0 11.2 11.5
IInventory
5.1 5.2 5.3
IOrder
1.0 6.0 7.0
Customer
Catalog
Inventory
Shopping
Billing
(c) 2007, Occello Audrey, SAR
- 31 -
e-store : Domaines
Presentation Layer
Business Logic Layer
Data Access Layer
Customer
Catalog
Inventory
Shopping
Billing
(c) 2007, Occello Audrey, SAR
- 32 -
e-store : Services
Presentation Layer
Business Logic Layer
Service Layer
Manage Customer
Show Catalog
Make Inventory
Shop
Bill
Data Access Layer
(c) 2007, Occello Audrey, SAR
- 33 -
Bnfices mtier
Amliorer lagilit et la flexibilit du mtier Faciliter la gestion des processus mtier Offrir la capacit casser les barrires organisationnelles (silos) Rduire en temps le cycle de dveloppement des produits Amliorer le retour sur investissement Accrotre les opportunits de revenu
(c) 2007, Occello Audrey, SAR - 34 -
Bnfices techniques
Rduire la complexit de la solution Construire les services une seule fois et les utiliser frquemment Garantir une intgration standardise et le support de clients htrognes Faciliter la maintenabilit
(c) 2007, Occello Audrey, SAR - 35 -
Quels sont les lments cl dune architecture oriente services ?
(c) 2007, Occello Audrey, SAR
- 36 -
Points cls de larchitecture
1.a Search for service
Service consumer
1.b Return contract 2.a Create a process instance
Repository
Contract
Mediation layer/Service bus
2.d Send request 2.c Retrieve service end-point
2.b Execute process
Service provider
Business service orchestrator
Business process description
Registry
(c) 2007, Occello Audrey, SAR
- 37 -
Standards de larchitecture
Les standards sont un lment cl dune SOA, ils assurent linteroprabilit
SOAP
W3C
WSDL
W3C
UDDI
Microsoft, IBM, HP
BPEL
Oasis
Simple Object Access Protocol Transporte
Web Services Description Language Dcrit le contrat
Universal Description Discovery and Integration Spec pour Repository/Registry
Business Process Execution Language Dcrit les processus mtier
Les trois piliers des Services Web
(c) 2007, Occello Audrey, SAR
- 38 -
SOA et web services
Attention ne pas confondre les 2 !
SOA est un ensemble de concepts : Une SOA peut se mettre en uvre sans Web Services Les WS sont de lordre de la technologie : On peut utiliser les Web Services sans faire de SOA
Les WS constituent la meilleure solution standardise disponible
Un service mtier = un webservice (c) 2007, Occello Audrey, SAR - 39 -
Le langage BPEL
Standard de lOASIS Norme permettant de dcrire des processus en XML Propose les fonctions basiques dun langage de programmation:
sequence, flow, loop, switch
Identification des Instances de Process Gestion des transactions longue dure (scope, compensation) Gestion des fautes (c) 2007, Occello Audrey, SAR - 40 -
BPEL le chef dorchestre
(c) 2007, Occello Audrey, SAR
- 41 -
BPEL par lexemple
<PartnerLink> references to the services participating in the process flow <invoke> a credit rating service synchronously
PartnerLink
<faultHandlers> catch and manage exceptions when customer has a bad credit history
flow PartnerLink
<flow> initiates asynchronous loan processors in parallel of execution
PartnerLink
<receive> asynchronous callbacks from longrunning loan processors <switch> to the lowest loan offer
[Link]
(c) 2007, Occello Audrey, SAR
- 42 -
Quelques dtails sur le langage BPEL
Transparents 52 -> 67 de
[Link]
(c) 2007, Occello Audrey, SAR
Cest le point dentre vers un service => invocation indirecte du service au travers du bus Ce point dentre doit tre normalis mais on ne sait pas qui fournit le service et comment il le fournit (implmentation). Infrastructure qui optimise les changes entre consommateurs et fournisseurs de services. Il peut prendre en charge : Routage transformation des donnes transactions, scurit, qualit de service, Ex: voir [Link] Le but dun ESB est de permettre de communiquer de manire simple et standardise entre des applications htrognes (c) 2007, Occello Audrey, SAR - 44 -
ESB : couche de mdiation
Quelques manires dimplmenter un ESB
Intergiciels de type MOM (Message Oriented Middleware) Intergiciels de type Bus (CORBA par exemple) Intergiciels de type EAI (Message Broker avec connecteurs propritaires lis au moteur dintgration) Routeurs Web services tel que WebSphere Web Services Gateway Selon le type dimplmentation retenu, lESB assurera plus ou moins de services : le choix dpend des besoins LESB nest pas obligatoire : mais il est fortement recommand pour viter le couplage entre fournisseur et consommateur (c) 2007, Occello Audrey, SAR - 45 -
Exemples darchitecture techniques se basant ou pas sur un ESB
Avec ESB Sans ESB
Plusieurs connecteurs Orchestration importante Transactions consquentes
(c) 2007, Occello Audrey, SAR
Communications inities par les applications seront donc homognes Pas dorchestration, parce que pas dintermdiaire: invocations de services directement pilotes par le code Peu de transactions, ou alors les grer - 46 la main
Intgration applicative via un bus JBI
Dans cet exemple, hormis le BPEL process, tous les autres lments applicatifs sont des services externes au bus. Mais, par ex. un lment pourrait tre un autre BPEL process ou un composant EJB,
ou autre, dploy DANS le bus, et vu comme un service interne. (c) 2007, Occello Audrey, SAR
Specification JBI pour ESB (ouvert)
BC et SE peuvent se rajouter (et senregistrer) sur le bus dynamiquement (c) 2007, Occello Audrey, SAR
Quel est le cycle de vie dun service ?
(c) 2007, Occello Audrey, SAR
- 49 -
Dcoupage du cycle de vie dun service
4 grandes phases :
Identification Spcification Dveloppement Gestion
1 aspect tranversal : la gouvernance
Les architectures orientes service impliquent une vision globale La gouvernance permet de casser les silos de lentreprise - 50 -
(c) 2007, Occello Audrey, SAR
Cycle de vie des services (activits de gouvernance)
Service Identified Search for Existing Implementation
yes
exists?
Service Owner Approval Service reusability Commission Candidate Consumers Identified
Service Identification
Service Specification Created Provider Interfaces Documented Service/Process Workflow Created
no
Service Specification Review
Service Specification
Develop Components Integrate & Test Create Deployment Unit Acceptance Test Code in repository
Service Development
Plan New Version Decommis sion Service Deprec ate Service
Certify Service
Service in registry
Service in use
Monitor service
Service Management
(c) 2007, Occello Audrey, SAR
- 53 -
Rles associs au cycle de vie des services
Id if t en n o i t ic a
Analyste mtier
Dfinit les processus mtiers et les KPI associes Identification des services mtier Optimise les processus via la simulation
Architecte cif Sp Dfinit les services pour les use
cases Modlise les services
on i t i ca
Intgrateur pe p o l ve Assemble les services D
nt e m
e v D Implmente les services
pe p lo
nt e m
Dveloppeur
on i t es
Gestionnaire
Publie les services Gre le cycle de vie des services Contrle la qualit de service
(c) 2007, Occello Audrey, SAR
- 54 -
Zoom sur la phase didentification
Un des problmes centraux pour mettre en uvre une SOA La granularit des services est fondamentale Or succs SOA = % de rutilisation des services viter une granularit trop fine qui entrane :
beaucoup dinteractions des problmes de performance dtermine en grande partie la rutilisabilit des services
On recommande des services gros grain
attention une granularit trop paisse un service qui fait trop de chose, risque de ne pas tre rutilisable
Trouver le juste milieu (c) 2007, Occello Audrey, SAR - 55 -
2 mthodes didentification des services
Une premire phase d'indentification doit tre effectue sur l'ensemble du SI dans le cadre de son urbanisation en s'appuyant sur la cartographie des domaines mtiers de l'entreprise et sur le code existant Approche incrmentale : une phase d'identification est ncessaire au dmarrage de chaque nouveau projet SOA en s'appuyant sur les processus et services rpertoris prcdemment Approche Bottom-up :
On part des briques informatiques, on rassemble les bouts (abstraction) Ralise gnralement par la MOE Plus adquat pour rutiliser lexistant non SOA-is
Approche Top-down :
On part des interactions mtier pour aboutir aux interactions techniques Ralise gnralement par la MOA Plus adquat pour dmarrer un nouveau projet
(c) 2007, Occello Audrey, SAR
- 56 -
Approche Outside in
Dans la pratique on utilise rarement une seule approche Pour obtenir une granularit pertinente des services, il est ncessaire de concilier les 2
Faire lanalyse Top-down sans se proccuper de lexistant Faire lanalyse Buttom-up en ne considrant que lexistant Comparer les services remonts avec ceux dduits des processus Faire les compromis ncessaires pour rutiliser le maximum de code
(c) 2007, Occello Audrey, SAR
- 64 -
Zoom sur la phase de spcification
Les services identifis ne doivent pas tre tous publis :
Chaque service a un cot et un risque Il faut viter la prolifration des services
Candidate Candidate Services Services
Le Service Litmus Test d'IBM aide trouver les bons services exposer
Business Alignment Composability Externalized Service Description Redundancy Elimination
SLT
Services Services (exposed) (exposed)
(c) 2007, Occello Audrey, SAR
- 65 -
Quelques critres d' exposabilit
Le potentiel d'un service est d'autant plus important qu'il :
permet d'automatiser un processus mtier critique est rutilisable par plusieurs domaines mtiers remplace une application dsuette supporte des besoins non fonctionnels (scurit, logging, monitoring, ...)
Les services non exposs
(c) 2007, Occello Audrey, SAR
- 66 -
Location de vhicules : services exposs
[Link] Vehicle
1.1 Reserve Vehicle
1.2 Check-out Vehicle
1.3 Check-in Vehicle
1.1.1
Check Rates
1.1.2
Make Reservation
1.2.1
Locate Reservation
1.2.2
Modify Reservation
1.2.3
Create Rental Agreement
1.2.4
Sign-out Vehicle from Lot
1.3.1
Locate Rental Agreement
1.3.2
Process Return Information
1.3.3
Process Payment
1.3.4
Return Vehicle to Lot
[Link]
Confirm Rental Information
[Link]
Get Customer Information
[Link]
Get Payment Information
[Link]
Confirm Reservation
[Link]
Create Reservation
[Link]
Get Location (Pick-up/drop-off)
[Link]
Get Date / time (Pick-up/drop-off)
[Link]
Choose Vehicle
[Link]
Get Options Information
[Link]
Check Vehicle Availability
[Link]
Offer Rates For Selection
(c) 2007, Occello Audrey, SAR
- 67 -
Exemple : quels sont les services exposables ?
A basic calculator for performing simple arithmetic operations (+, -, *, /) A printing application, shared by multiple applications, running in multiple environments A credit card authorization application A Database lookup that returns application-specific data A composite database lookup for customer information, searching across multiple databases (c) 2007, Occello Audrey, SAR - 68 -
Quelles mthodes et outils permettent de mettre en oeuvre une architecture oriente services ?
(c) 2007, Occello Audrey, SAR
- 69 -
Mthodes de conception des services
SOMA (IBM) SODA (De Gamma) Praxeme (Unilog Management et Orchestra Networks) + toutes les formations proposes par les diteurs tels que Softeam (SEA), DreamSoft, etc sur leur savoir-faire Autant doffres que de mthodes diffrentes : de quoi sy perdre !
(c) 2007, Occello Audrey, SAR - 70 -
Modeleurs de processus
Outils de modlisation des processus mtier
IBM WebSphere Business Modeler Bull Bonita De Gamma BPM MEGA Aris Corporate Modeler WinDesign Power AMC Popkin System Architecture - 71 -
(c) 2007, Occello Audrey, SAR
Moteurs dexcution de processus
Plate-forme dintgration IBM Websphere Process Server BEA Weblogic Integrator/Acqualogic Microsoft Biztalk De Gamma Workflow Oracle BPEL PM Bull Orchestra SAP Netweaver Apache ODE ESB IBM Websphere ESB Celtix hosted on ObjectWeb/IONA Technologies OpenESB ([Link]) Mule ([Link]) Sonic ESB EBM Web Sourcing Distributed Petals Bus (on OW2)
(c) 2007, Occello Audrey, SAR
- 72 -
Contrleurs/moniteurs
BAM (Business Activity Monitoring)
IBM WebSphere Business Monitor Oracle BAM Systar Business Bridge BMC Service Impact Manager
Composants de scurit
Oracle Web Service Manager Oblix
(c) 2007, Occello Audrey, SAR
- 73 -
Exemple: Gamme d'outils IBM couvrant le cycle de vie complet
Business Analyst
Service Architect
WebSphere Business Modeler
Service Specification
Rational Software Architect
BPEL KPIs
WebSphere Integration Developer Service Development WebSphere Service Repository & Registry
Service Registrar
WSDL
Developer
Integration Developer
Rational Application Developer
Business Analyst
Server Administrator
Governance Manager
Performance Manager
WebSphere Business Monitor
WebSphere Process Server WebSphere ESB
Service execution & Management (c) 2007, Occello Audrey, SAR
WebSphere Business Services Fabric
- 74 -
Conclusions
(c) 2007, Occello Audrey, SAR
- 75 -
Du dj vu ?
SOA est une volution des plate-forme passes, tout en prservant les caractristiques russies des architectures traditionnelles Contractualisation des services
Design by Contract (Meyer)
Dcouplage Interface/Implmentation, interoprabilit, transparence des communications,
Middlewares la CORBA
Dcouplage fournisseur/comsommateur
Message Oriented Middleware (MOM)
Orchestration des services
Travaux autour des workflows, langages de coordination
SOA est une volution plutt quune rvolution (c) 2007, Occello Audrey, SAR - 76 -
Chronique dune volution
Assembleur Langages machine
objets Langages procduraux
* *
*
services
composants
services
01011 10100 11000 01011
Niveaux dabstraction grandissant (c) 2007, Occello Audrey, SAR - 77 -
Synthse
Depuis
Orient fonctionnalits Conu pour durer Cycle de dveloppement long
Vers
Orient processus Conu pour changer Dveloppement et dploiement interactif
Silos applicatifs Couplage fort Orient Objet
Orchestration de Services Couplage faible Orient message
(c) 2007, Occello Audrey, SAR
- 78 -
Avantages et inconvnients
Architecture adaptative Rutilisation du code Utilisation de standards Productivit accrue
Manque de maturit des standards Lenteur dexcution Difficile effectivement implmenter Encore peu de chose sur la contractualisation
(c) 2007, Occello Audrey, SAR - 79 -
Quelques rfrences ...
Urbanisation et BPM - Yves Caseau, DSI Bouygues Tlcom, Edition Dunod SOA la sauce IBM
[Link]
SOA la sauce Orchestra
[Link]
CBM appliqu au scnario Rent-a-car
[Link] tml - 82 -
(c) 2007, Occello Audrey, SAR
Quelques rfrences ...
Composants
CCM spec [Link] Fractal spec (GCM spec: [Link]) [Link] Service Component Architecture (SCA)
[Link]
OpenCCM [Link] Sofa [Link] [Link] (c) 2007, Occello Audrey, SAR - 83 -
