Transcript Slide 1

Les Architectures Orientées Services :
Mise en oeuvre, Cas Pratiques et Nouvelles Perspectives
Stéphane Goudeau
[email protected]
Valérie Monfort
[email protected]
Assia Ait Ali Slimane, Muhamad Usman Bhatti
aaitalislimane, [email protected]
« It is not the strongest of the species
that survive, nor the most intelligent,
but the ones most responsive to
change …»
Charles Darwin
Plan général du cours
SOA, Service Web, spécification et urbanisation
Scénarios de mise en œuvre
Perspectives des Services Web et des SOA
TP1 Etude de cas : formalisation, spécification
.Net, Biztalk, Corba, Axis, J2EE
Démonstration de Biztalk
TP2 Exemple dirigé de mise en œuvre
TP3 Etude de cas : développement avec Biztalk
TP4 Démonstration de l’interopérabilité
Partie 1 : SOA, Services Web, Spécification et
Urbanisation
Partie 1 : Plan de la présentation
Introduction : Contexte économique
Intégration et Interopérabilité
Place du PLM dans un contexte d’intégration
et/ou d’Urbanisation
Les Architectures Orientées Services : solution à
l’Entreprise étendue
Retour d’expérience
Les perspectives
Les services Web, une solution pour l’intégration
et l’interopérabilité des SI : scénario de mise en
œuvre de l’entreprise étendue
Introduction Partie 1
Introduction
Contexte Industriel : vers l’Entreprise Etendue
Clients
Service Client
Partenaires
ERP
Chaine d’approvisionnement
Collaborateurs
HumaRessources Humaines
Services Financiers
Introduction
Le PLM une approche intégrée : Les grands processus et systèmes
Investissement immatériel : Innovation
Marketing
Make/Buy
Portefeuille Produits
Management de programme - Assurance qualité
Demande
CRM
Customer
Relationship
Management
Commandes
Project d’innovation (R&D)
Projets Plate-formes (famille)
PLM
PDM
Projets Variantes / évolutions
Modifications
(commerce)
Maintenance
Product Data Management
MRO
Master
Planning
Planning
& Mgt
Achats
Planning
Production
Pilotage
Production
Distribution
ERP
Enterprise Ressources Planning
+ MES Manufacturing Equipement System
Gestion des commandes - Contrôle de Gestion - Comptabilité
Investissement matériel
Installation
Commandes
Maintenance
& Repair
Operations
CRM
Customer
Exploitation
Relationship
Management
(SAV)
Introduction
Les dimensions «Supply Chain»
Demande
Commandes
CRM
(Commerce)
Commandes
Master
Commandes
Planning
Master
Planning
Planning
Planning
& Mgt
Production
Achats
Pilotage
Production
Distribution
Management de programme - Assurance
qualité
Gestion des commandes - Contrôle de Gestion - Comptabilité
Project d’innovation
Installation
PLM
Commandes
Exploitation
(R&D)
Projets Plate-formes
(famille)
Supply Chain
Management
Projets Variantes / évolutions
SCM
SSM Strategic Sourcing Management
ILS Integrated
Logistics Support Maintenance
Modifications
CPC Collaborative Product Commerce
Planning
Planning
& Mgt
Production
Achats
MRO
Pilotage
Production
Distribution
ERP
Gestion des commandes - Contrôle de Gestion - Comptabilité
Installation
Demande
Marketing
Make/Buy
Portefeuille
Produits
Gestion des commandes - Contrôle de Gestion - Comptabilité
Installation
Marketing
Make/Buy
Portefeuille
Produits
Marketing
Make/Buy
Portefeuille
Produits
Management de programme - Assurance
qualité
Project d’innovation
(R&D)
Projets Plate-formes
(famille)
Projets Variantes / évolutions
Commandes
Maintenance
Management de programme
- Assurance
Modifications
qualité
Project d’innovation
(R&D)
Projets Plate-formes
Planning
(famille)Planning
Master
Pilotage
Commandes
& Mgt / évolutions
Distribution
Projets Variantes
Planning
Production
Production
Achats
Maintenance
Exploitation
Modifications
Demande
Commerce Chain
Design Chain
CRM
Exploitation
(SAV)
Manufacturing Chain
Service Chain
Introduction
Que de paramètres à gérer !!!!!!!
Intégration
Technologies
Progiciels
Processus
métier
Partenaires
ROI
Socle
technique
Clients
Référentiels
Données
Interopérabilité
Introduction
Opérations
Temps réel
Agilité
Intégration entre
applications
SI au service de la
stratégie de l’entreprise
Interopérabilité
Résilience
Sécurité
Accès
multiples
Vue consolidée
des données
Entreprise virtuelle
Chaîne de valeurs
Intégration et Interopérabilité
Intégration et Interopérabilité
Relever les défis du SI …
C’est composer notamment avec deux options :
Intégrer :
L’entreprise assume elle-même les fonctions dont elle a
besoin (fabrication, distribution, support, …)
Interopérer :
L’entreprise s’appuie sur des prestations externes et
consomme des services
Intégration et Interopérabilité
La quête de l’Interopérabilité
E-Mail
Web
Services Web XML
Le mouvement
vers des
systèmes de
plus en plus
communicants
reflète le besoin
des entreprises
PC
POP3, IMAP
PC
HTML / HTTP
PC
Connecter
les personnes
aux personnes
Site Web
Connecter
les personnes
aux applications
Système
XML / SOAP
Système
Connecter
les services aux services
Intégration et interopérabilité
Enterprise Application Integration
Étendre le périmètre restreint d’une application
à celui de l’entreprise, en la connectant aux
autres applications pour qu’elle puisse
échanger des informations :
Maximiser la réutilisation et la cohérence
Cette approche est névralgique pour une
entreprise désireuse d’offrir une vision intégrée
de ses clients, fournisseurs, partenaires,
employés … :
Privilégier la vision intra mais aussi inter entreprises
Intégration et interopérabilité
Les différents modèles d’intégration
L’unification par le partage des données
La réutilisation des traitements fondée sur
des connections points à point mettant en
œuvre des serveurs d’applications
L’intégration par l’échange de messages
fondée sur l’utilisation de MOM (MiddleWare
Orienté Message ou de « Message Broker »
La connexion des applications à des
serveurs d’intégration
Les services Web
Intégration et interopérabilité
Connexion en point à point : Les serveurs
d’application
Accounting
E-Commerce
Web Server
Order
Management
Sales Force
Automation
CRM
ERP
Logistics
Intégration et interopérabilité
Bus applicatif : Message Oriented Middleware
ou Message Broker
Accounting
E-Commerce
Web Server
Order
Management
Message Oriented Middleware
et Message Broker
Sales Force
Automation
CRM
ERP
Logistics
Intégration et interopérabilité
Bus applicatif : Serveurs
d’intégration
Accounting
E-Commerce
Web Server
Order
Management
Sales Force
Automation
CRM
ERP
Logistics
Intégration et Interopérabilité
Intégration, Interopérabilité et PLM
France
CITI
Enovia
VPM
Catia V4
Windchill
Enovia
LCA
Catia V5
Windchill
Windchill
SAP
Electronic
Workbench
ARTEMIS
Software
Workbench
Allemagne
SAP
…
…
Architectures Orientées Services
Web Services, l’interopérabilité sans adhérence !
Permet à des systèmes hétérogènes
d’interopérer
A travers les langages, les plateformes, les applications
D’ordinateur à ordinateur
A l’intérieur ou à l’extérieur d’un firewall
Fondé sur des standards internet
XML, SOAP, WSDL, UDDI
Technologie universellement adoptée
Consensus des acteurs clés
Intégration et Interopérabilité
Web Services, l’interopérabilité sans adhérence !
WSDLUDDI
Le serveur
peut décrit
être utilisé
le
pour localiser
les
Web services
service
Web
WSDL
Votre Entité
Serveur UDDI
Intégration et Interopérabilité
Web Services, l’interopérabilité sans adhérence !
Votre Entité
Systèmes internes
Autres Systèmes
Intégration et Interopérabilité
Apports des Web Services
Universalité
Modularité
UPnP, P2P, B2C, A2A, B2B, BPA, Grid …
Préserve l’existant
Standards
W3C, OASIS, IETF
Large adoption de l’industrie
Base de données, serveur d’intégration, outils de dev..
Interopérabilité: WS-I
Couplage faible
Approche par message, interface, contrat, policy
Plus forte granularité, orienté métier
Annuaire de service, déploiement
Virtualisation
Indépendant de la localisation
Indépendant de l’implémentation (langage, OS, middleware…)
Indépendant de la topologie (protocole réseau, pattern d’échange, route…)
Intégration et Interopérabilité
Synthèse
De plus en plus d’entreprises se trouvent
dans un contexte d’entreprise étendue
nécessitant de communiquer entre SI
distants
Le PLM est basé sur une vue métier et
technique reposant sur des technologies
d’intégration
Les services Web apparaissent aujourd’hui
comme le moyen le plus abouti pour faire
interopérer des SI distants
Place du PLM dans un contexte
d’intégration et/ou d’Urbanisation
Intégration et Urbanisation
Principaux processus pour urbaniser un SI
stratégie
Urbanisation Road Map
PAS de
Méthodologie
BIG BANG !!!!!
Cartographie
Projets d’EAI et customisation de progiciels
SI urbanisé
Intégration et Urbanisation
Niveau d'Urbanisation
Démarche itérative et incrémentale
Basée sur les invariants de l’entreprise,
cette vue est souvent une cible à atteindre Système urbanisé Architecture
logicielle
en se basant sur la cartographie, état actuel
* Ilots autonomes
Architecture
technique
Cible
n Etapes
(*)gestionnaire de flux
Serveur Datawharehouse
Hubpour
lesdonnées
1 ère Etape
Grandpublic
Systèmes
enrégion
Système
EDI fournisseur ServeursWEBisolépour
descontraintesdesécurité
Serveur client
Temps
Intégration et Urbanisation
Impact de Model Driven Architecture
Démarche pilotée par les modèles
PIM (Platform Independent Model)
PSM (Platform Specific Model)
PlatformIndependent
Model
CORBA
Model
CORBA
Map PSM to application
interfaces, code, GUI
descriptors, SQL
queries, etc.
Java/EJB XML/SOAP
Model
Model
.NET
Java/EJB XML/SOAP C#/.NET
Intégration et Urbanisation
Les niveaux d’architectures
Données métier
Process
abstraction
Métier
Domaine métier
Fonctions et Services métier
Données
spécifique
Organisationnel
Flux
Fonctions et Services
Données Techniques
implémentable
Technique
Workflows
COTs, Progiciels, …
Serveurs, Matériel …
Intégration et Urbanisation
Vision modulaire : Structure de la cartographie
Découpage en 5 domaines
Customer Facing Channel Partners
Develop Product / Service
Customers
Suppliers
Enterprise
1. Develop
Product /
Service
2. Generate
Demand
Generate Demand
Fulfill Demand
Plan & Manage the Enterprise
Collaboration
5. Collaboration
3. Fulfill
Demand
Entités externes :
4. Plan &
Manage
Enterprise
Customers and Suppliers
Logistics and Financial Service Providers
Channel Partners
Logistics
Providers
Financial
Providers
Intégration et Urbanisation
Cartographie d’entreprise : granularité 1/500000
Intégration et Urbanisation
Cartographie d’entreprise : granularité 1/1000000
Intégration et Urbanisation
Projection de la cartographie sur le SI global
Call
Center
Fulfillment
Private /
Public
Network
Legacy
systems
Securities
Middleware
Bank
Terminal
Datamining
Telefon
Merchant
Private /
Public
Network
POS
Enterprise
Customer
Kiosk
Intégration et Urbanisation
My Module Map
Module Map Supplier Tier 1
Complete
shared
Partial
shared
Partial
shared
Module Map Supplier Tier 2
Module Map Logistics
Vue Chaîne logistique
Intégration et Urbanisation
Synthèse
Urbaniser un Système d’information requiert une
gestion du changement
La gestion du changement utilise un certain
nombre d’outils comme la cartographie
Le PLM, qu’il soit considéré ou non dans un
contexte d’urbanisation, vise à améliorer le cycle
de développement du produit
Il intègre un certain nombre de progiciels
Maîtriser son Système d’information au travers
de la cartographie est l’outil indispensable de la
gestion de données techniques
Architectures Orientées Services
Architectures Orientées Services
Many in the technology industry believe SOAs will
overcome interoperability and inflexibility barriers
needed to finally fulfill a promise IT has been making for
decades.
« Les échos de
l’industrie »
A Service-Oriented Architecture (SOA) framework can
enable financial companies to achieve their business
goals by providing a service-based platform to integrate
new and existing applications and systems…
Service-Oriented Architecture (SOA) is the next wave of
application development
Architectures Orientées Services
“a set of independently running services
Services…
loosely
bound to each other via event-driven
messages.”
“SOA is the aggregation of components
satisfying a business driver.”
Faiblement couplé…
“A service architecture consists of three
primary components…the service
provider…the service requestor...the service
agency provides registration and discovery
servicesMessages…
”
“Service-oriented architecture (SOA) is a
client/server software design approach in
which an application
consists of software
Interfaces…
services and software service consumers
(also known as clients or service
requesters). SOA differs from the more
general client/server model in its definitive
emphasis on loose coupling between
software components, and in its use of
Architectures Orientées Services
Réduction du time-to-market
“…promotes
reuse
within the enterprise,
et
du
TCO
decreasing time-to-market and system TCO.”
“… primary intentions are business-level
software modularity and rapid, nonintrusive
reuse of business software in new runtime
contexts.”
Réutilisation…
SOA brings these benefits to enterprise IT:
Incremental development and deployment of
business software
Reuse of business components in multiple
business experiences
Diminution des coûts…
Low-cost assembly of some new business
processes
Clarity of application topology
“Reworking existing brittle, high-cost IT
infrastructures into flexible, Service oriented
architectures
promises
substantial long-term
Agilité
du SI…
cost savings and revenue opportunities
through increased business agility.”
Architectures Orientées Services
La Croisée des Chemins…
ERP
EDI
Contrôle
EAI
Web services et
SOA
Un juste et attendu
milieu
entre agilité et
maîtrise du SI
Processus formels
Web services
& SOA
Email
Site Web
Flexibilité
Source: AT Kearney and the Stencil Group
Le cercle va s’étendre avec
l ’émergence des Web
services techniques
Architectures Orientées Services
client
Architecture
Orientée
Application
SOA
Fournisseur
Composant
d’Architecture
Composant
d’Architecture
Architectures Orientées Services
Services internes et externes
Externe
SOA
Interne
Interne
SOA
SOA
Processus Partagés
Entreprise A
Entreprise B
Architectures Orientées
Services
Anatomie d’un Service
Service
Policy
Unité d’activité métier
Apporte de la valeur au consommateur
Communique par message
Peut utiliser d’autres services
Principes de base:
Les services sont autonomes
Les frontières de communication sont explicites
Couplage faible: partage les schémas/contrats pas les classes
Compatibilité entre services basée sur les
méta-données (policy)
Schéma
Contrat
Architectures Orientées Services : Service Web
Architectures Orientées Services
Un service n’est pas un composant
Évolution naturelle et certaine
Service
Fonction  Composant  Service
Les services gèrent messages,
données et composants
Les données privées sont totalement
encapsulées par le service
Les messages sont le seul moyen
d’échanges entre services
Composants
Fonctions
Private
Data
Les services permettent
des relations faiblement
couplées; les composants
des relations fortement
couplées
Architectures Orientées Services
Service Web et XML
Les Web Services sont basés sur des extensions
de la norme XML, langage de bannières
permettant d’écrire des contenus organisés de
manière hiérarchique.
La communication s ’effectue grâce aux
protocoles standard d’Internet : HTTP, SMTP,
FTP …(principalement HTTP)
Architectures Orientées Services
Un Service Web est basé sur l’utilisation de plusieurs standards
Service
Registry
Service Description
Find
Publish
UDDI
WSDL
Service
Service
Requestor
Bind
SOAP, XML
Service
Provider
Architectures Orientées Services
Mode Opératoire
Architectures Orientées Services
Mode Opératoire
Architectures Orientées Services
SOAP : Principes de base
SOAP est un protocole d ’échange
d’informations basé sur XML, les messages
SOAP peuvent être envoyés par HTTP, FTP,
SMTP ...
Il permet aux applications de communiquer dans
un environnement distribué.
A la différence de CORBA et Java RMI, la norme
SOAP ne cherche qu’à standardiser la syntaxe
des messages. Elle ne spécifie donc pas du tout
l ’architecture des clients et des serveurs. SOAP
serait plus à rapprocher d ’IIOP.
De plus SOAP n’est pas spécialement orienté
objet.
Architectures Orientées Services
Structure d’un message SOAP
SOAP est une norme centrée sur le
format des messages
Architectures Orientées Services
Structure d’un message SOAP
L’enveloppe permet de préciser la version.
L’entête permet de préciser la manière dont le
message sera traité par les différents nœud XML
qui le recevrons (attribut actor)
Le corps permet de faire passer les messages
au nœud destinataire.
Architectures Orientées Services
Exemple de message SOAP
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:doubleAnIntegerResponse
xmlns:ns1="urn:MySoapServices"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:int">246</return>
</ns1:doubleAnIntegerResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Architectures Orientées Services
Exemple de message SOAP
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Architectures Orientées Services
Principes de base du WSDL
WSDL est un standard de description de Web
Services basé sur XML.
Langage de description des interfaces des Web
Services.
Comparable à l’IDL de CORBA
Il permet de spécifier le format des messages, les
protocoles qui doivent être utilisés et la
localisation des différentes machines qui mettent
en œuvre le Web Service.
Message: définition de la structure de messages
à l ’aide de XSD (XML Schema Definition).
Architectures Orientées Services
Principes de base du WSDL
Operation : ensemble de message envoyé dans
un flux de messages.Exemple une opération
question réponse met en œuvre deux messages.
PortType : ensemble de flux de message
correspondant à un type de service. Il est défini
de façon abstraite sans référence au mode de
transport, ni à la manière de coder les données.
Binding : Précise le transport et le codage des
données pour un PortType particulier.
Port : Précise l’adresse sur le réseau de la
destination et le Binding qui lui correspond.
Service : Ensemble de destinations liées.
Architectures Orientées Services
Principes de base du WSDL
WSDL ne précise pas comment on peut décrire
des services mettant en œuvre des flux
complexes.
WSDL ne permet de décrire les détail
d ’implémentation des services.
WSDL ne décrit pas comment ces descriptions
de services doivent être échangées.
Architectures Orientées Services
Structure du WSDL
Architectures Orientées Services
Exemple de code WSDL : Message
<message name="quoteRequest">
<part name="body" element="quote-schemans:stockName"/>
</message>
<message name="quoteResponse">
<part name="body" element="quote-schemans:stockPrice"/>
</message>
Architectures Orientées Services
Exemple de code WSDL : PortType
<portType name="quotePortType">
<operation name="getQuote">
<input message="quote-wsdl-ns:quoteRequest"/>
<output message="quote-wsdl-ns:quoteResponse"/>
</operation>
</portType>
Architectures Orientées Services
Exemple de code WSDL : Binding
<binding name="quoteBinding"
type="quote-wsd-ns:quotePortType">
<operation name="getQuote">
<soap:operation
soapAction="http://example.com/stockQuoteAction"/>
<input>
<soap:body part="body" use="literal"/>
</input>
<output>
<soap:body part="body" use="literal"/>
</output>
</operation>
</binding>
Architectures Orientées Services
Exemple de code WSDL : Service
<service name="stockService">
<port name="stockPort"
binding= "quote-wsdl-ns:quoteBinding">
<soap:address
location="http://example.com/quotes/"/>
</port>
</service>
Architectures Orientées Services
Exemple de code WSDL
<tModel xmlns="urn:uddi-org:api"
tModelKey="UUID:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<name>microsoft-com:creditcheck</name>
<description xml:lang="en">
Check credit limits
</description>
<overviewDoc>
<overviewURL>
http://schema.com/creditcheck.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634"
keyName="Consumer credit gathering or reporting
services" keyValue="84.14.16.01.00"/>
<keyedReference
tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
keyName="types" keyValue="wsdlSpec"/>
</categoryBag>
</tModel>
Architectures Orientées Services
Exemple de
code WSDL
<definitions>
<message name="checkStocks">
<part name="check" element="tio:checkStocks" />
</message>
<message name="sellStocks">
<part name="order" element="tio:sellStocks" />
</message>
<portType name="stockBuyer">
<operation name="checkStocks">
<input message="tns:checkStocks" />
<output message="tns:checkStocksOut" />
</operation>
<operation name="sellStocks">
<input message="tns:sellStocks" />
<output message="tns:sellConfirmation" />
</operation>
</portType>
</definitions>
Architectures Orientées Services
UDDI
UDDI est un standard qui décrit comment on peut créer
des annuaires de Web Services.
Ce type de structure permet à une entreprise de publier
et de décrire les Web Services qu’elle met en ligne.
Un annuaire UDDI référence les Web Services soit par
type de service (page jaunes) soit par nom de société
(pages blanches). Et pour chaque Web Service proposé,
le catalogue doit indiquer le protocole d ’accès qui
permet de s ’y connecter.
Les tModels qui décrivent le comportement d’un Web
Service particulier. Ils comprennent : Le nom du service,
Une clé unique, Une référence vers la description WSDL
(qui n’est pas contenue dans le catalogue), Un ensemble
d’éléments de catégorisation.
Architectures Orientées Services : Contrat de
service et processus
Architectures Orientées Services
Échanges entre Services
Routage et intermédiaires
Requête/Réponse
Publication (Fire & forget)
Monologue
Dialogue
Conversation
Document
Service
A
Document
B
Service
Architectures Orientées Services
Schémas & Contrats
Process
Conception
Service
Document
A
Quels services, Rôles
Messages: format, séquences
Actions possibles à chaque étape
Traitements des erreurs: métier
ou technique
DocumentDocument
C-1
C-2
Contrats
Document
B
C-1 ou
C-2
Service
Process
Déploiement et Exécution:
Adresse
Requêtes par jour, disponibilité
Protocoles de transport
Encodage, Authentification,
Encryption et signature
69
Architectures Orientées Services
Rôle des processus
Processus
Métiers
Description des données
Architecture
d’Information
Clients et Agents
Architecture
Technique
Architectures Orientées Services
Orchestration des processus
Service de Processus
Service
Commercial
Service de
Porcessus
Service
Client
Service
Métier
Finance
Service
Métier
Service
Métier
Production
Service
Métier StocK
71
Architectures Orientées Services
Administration des services
•Disponibilité, Versioning, Monitoring, Déploiement
•Routage dynamique des requêtes et des réponses
•Audit, log
•Usage, facturation…
•Sécurité: authentification, autorisation, cryptage, signature

Intrusion

Attack

Timestamp

Statistics

Performance
Monitoring
Transform service,
request

Prioritization
Physical
Connection
 Switch
Service
 Switch
Implementation
Connector
XML
Firewall
Security
Logging
Access
Control

Identity

Authentication

Billing

Encryption

Royalties

Access control
Accounting
SLA
State
Mngmt

State

Recovery

Queuing
Transform
Service
Implementations
Aggregate
Composite
Aggregate or
Composite
services
Route
Other
Web
Services
Copyright CBDI Forum
Architectures Orientées Services
Synthèse
Les architectures SOA permettent aux applications de
communiquer avec les différentes ressources (données,
infrastructure, processus) par l’échange de messages
entre interfaces réseaux
L’une des principales caractéristiques des SOA est la
définition d’ interfaces stables et cohérentes offertes sur
des implémentations volatiles
Les SOA permettent aux entreprises de redonner la
priorité au métier par rapport au technique en offrant le
contrôle d’une collection de services d’infrastructure, de
processus
Grâce à ce contrôles le SI peut :
Optimiser
Orchestrer
Ouvrir de nouveaux points d’accès
Evoluer rapidement
PAUSE
Partie 2 : Scénario de mise en œuvre de
l’entreprise étendue
Scénario de mise en oeuvre
Cartographie du fabriquant de voiture
Customer Facing Channel Partners
Customers
Enterprise
1. Develop
Product /
Service
Suppliers
2. Generate
Demand
5. Collaboration
3. Fulfill
Demand
Logistics
Providers
Financial
Providers
4. Plan &
Manage
Enterprise
Workshop
Scénario de mise en oeuvre
Customer Facing Channel Partners
Customers
Enterprise
1. Develop Product / Service
Suppliers
2. Generate Demand
5. Collaboration
3. Fulfill Demand
4. Plan & Manage Enterprise
Level 1
3. Fulfill Demand
Logistics Providers
Financial Service Providers
Workshop
Scénario de mise en oeuvre
Customer Facing Channel Partners
Customers
Enterprise
Suppliers
2. Generate Demand
1. Develop Product / Service
2.1. Partner Relationship Mgmt.
1.1. Develop Product / Service
2.2. Marketing
2.3. Sales
5. Collaboration
5.1. Strategic Collaboration
5.2. Planning Collaboration
3. Fulfill Demand
4. Plan & Manage Enterprise
3.1. Provide Service
3.2. Advanced Planning
5.3. Operational Collaboration
4.1. Financial Management
3.3. Procurement
Level 2
4.2. Project Management
3. Fulfill Demand
3.3 Procurement
4.3. Human Resources
3.5. Logistics
3.4. Produce Product
Logistics Providers
4.4. Property and Advisory
Financial Service Providers
Workshop
Scénario de mise en oeuvre
Customer Facing Channel Partners
Customers
Enterprise
Suppliers
2. Generate Demand
1. Develop Product / Service
5. Collaboration
3. Fulfill Demand
3.1. Provide Service
3.2. Advanced
Planning
3.3. Procurement
4. Plan &
Manage
Enterprise
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
Level 3
3. Fulfill Demand
3.3 Procurement
3.3.2 Purchasing
3.4. Produce
Product
3.3.3 Receiving of Indirect / Capital Goods and Services
3.5. Logistics
Logistics Providers
Financial Service Providers
Workshop
Scénario de mise en oeuvre
Customer Facing Channel Partners
Customers
Enterprise
Suppliers
2. Generate Demand
1. Develop Product / Service
5. Collaboration
3. Fulfill Demand
4. Plan &
Manage
Enterprise
3.1. Provide Service
3.2. Advanced
Planning
3.3. Procurement
3.3.1 Sourcing and Supplier Contract Management
3.3.2 Purchasing
Request Resources
Manage
Requisition
Approva
Processl
Create
Purchase
Requisitions
Acquire/Purchase
Choose or
Default
Supplier for
Goods
Level 4
3. Fulfill Demand
3.3 Procurement
3.3.2 Purchasing
- Request
Resources
- Create
Purchase
Requisitions
Perform
Encumbrance
Check
Create
Auction Bids
Resources
Manage
Purchase
Item
Catalog
Manage
RFI/RFQ/
RFP
process
Verify/
Negotiate
Price
Purchase
Indirect
Materials
Purchase
Outside
Vendor
Services
Manage
Automatic
Replenishment
Manage
Purchasing
Methods
Consolidate
Approved
Requisitions
by Supplier
Purchase
Capital
Goods
Manage
Open to
Buy/Blanket
POs
Create
Purchase
Orders
Purchase
Direct
Materials &
Supplies
Track Open
POs
Approve
& Validate
Contract
Payments
Manage Suppliers
3.4. Produce
Product
Manage
Supplier
Relationships
Track
Supplier
Commitments
Maintain
Supplier
Catalog
Manage
Buyer
Performance
Request Resources
Create
Purchase
Requisitions
Provide Supplier
Self-Help
3.3.3 Receiving of Indirect / Capital Goods and Services
3.5. Logistics
Logistics Providers
Financial Service Providers
Workshop
Scénario de mise en oeuvre
Processus intra entreprise
Customer Facing Channel Partners
Customers
Suppliers
Enterprise
1. Develop
Product /
Service
2. Generate
Demand
5. Collaboration
3. Fulfill
Demand
Logistics
Providers
Financial
Providers
4. Plan &
Manage
Enterprise
Workshop
Scénario de mise en oeuvre
Refund payment
Buyer Org
Seller Org
Remittance Advice & Payment (electronic)
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Human Resources
Invoice (&
Image)
Data Store
Financial Management
Electronic Funds
Processing
Approver(s)
Employee
data
Employee
data
Invoice Details
Approvals,
rejections
Approval notifications
Credit Memo
Accounts Receivable
General Ledger
Capital Asset
Management
Accounts Payable
Credit memo
Invoice (Original)/Debit Memo
Expense Reimbursement
Request
Invoices (Match
Exception or
Out of
Tolerance)
B3.2 Process 3-Way Match
(PO, Receipt, Invoice)
Invoice
Expense Report
start
Notification
(rejected)
B3.5 Reject/Dispute Invoice
Invoices (Match
Exception or
Out of
Tolerance)
Out of Tolerance
Notification
Employee
B3.4 Invoice Approval
Invoice (Non PO
type (e.g. card,
direct order, etc))
Cash Disbursement
Needs
Receipted
Invoices
Billing Inquiry and Response
Negotiation
B3.6 Contact Supplier &
Discuss Dispute/Rejection
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Remittance Advice & Payment (hardcopy)
Invoices (approved)
B3.7 Pending Invoices
Invoices
(cleared)
B3.8 Remit Payment at
Settlement Period
Dunning Letter
Payment Inquiry/Invoice Status Response
B3.9 Respond to Payment
Inquiry
Tax Liability
Receipt
Notice
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Project Accounting
Initial Prepayment
Vendor update
acknowledgement
(approved, denied)
Procurement
B3.15 Update Vendor
Master (including set-up
customers as vendors for
refunds)
Accepted
profile
changes
Agreement/Contract
(negotiated terms, etc)
Receiving
AP Clerk POV
PO Change
(out of tolerance
accepted)
Vendor
changes
Vendor
profile
data
Advisory
B3.13 Receive Vendor
Profile Changes
B3.16 Perform Prepayments
Manage Tax Compliance
B3.12 Authorize/Reject
Payment (by line item)
statement
B3.11 Match Summary
Statement to card receipts/
invoices
statement
B3.10 Receive and review
Summary Statement (card
based programs only)
Requester or
Buyer
(whoever owns txn)
Business Intelligence
Vendor Master
Data Store
Agreement
Data Store
Supplier Performance Data,
Requester/Buyer
Performance Data,
Financial Performance
Data,
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Vendor
initiated
billing
profile
changes
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Prepayment
Buyer’s
Financial Services
Provider
Example KPI’s:
% Match (2-way)
% Match (3-way)
Invoice aging
Card based receipts/invoices
Logistics and Distribution
Warehouse
Management
B3.14 Authorize
Vendor Profile Changes
Remittance
Deposit
Invoice Status Response
Project Management
Remittance Advice & Payment Release (electronic)
Purchasing
Supplier
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Invoices (w/in
Tolerance Match)
Invoices
(blocked Invoice (w/in pending
Receipted
Tolerance Match)receipt)
Invoices
B3.3 2-Way Match
(Receipt, Invoice)
PO info
Invoices
(disputed, rejected)
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Payment (expense reimbursement)
Project Related Invoice Line Items
Receipt Info
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Notification
(accepted,
rejected)
Capital Goods Line Item Details
Treasury
Time & Expense
Management
Invoice (service based)
B3.1 Receive, Process, &
File Invoice
Invoice,
Payment JEs
Employee Data
Store
Business Intelligence
Bank
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Fax
Phone
Snail Mail
E-Mail
EDI VAN
MarketPlace Exchange
Monthly Summary Invoice (card based programs only)
Payment (to bank)
Chargeback (Summary Invoice errors)
Key
Core Function/
Module
Related
Function/Module
Logical
Data Store
Process
Interface
Data Flow
B2B Data Flow
Collaborative
B2B Data Flow
Product
overlay
Acronyms: AP: Accounts Payable, JEs: Journal Entries
PO: Purchase Order, KPI: Key Performance Indicator
Buyer Org Perspective: Requisition to Payment
B3. Invoice to Payment (AP)
Preconditions: A purchase order has been created and sent to the Seller Organization.
A supplier invoice usually triggers the Invoice to Payment process. In process step B3.1, a supplier submits an invoice to the buyer organization, usually after they’ve picked, packed, and shipped product to the buyer (although prepayments sometimes occur). The invoice is reviewed for accuracy and entered into a payables system for matching purposes. This can also trigger the flow of information to Capital Asset management tracking for depreciation
purposes, Project Accounting for project financials tracking, Tax for compliance reporting, and the General Ledger to account for liability owed. In process step B3.2, the buying organization’s Accounts Payable group/person then can
perform a 3-way match between the original PO, the materials Receipt, and the Invoice. Process step B3.3 illustrates how some alternative purchasing models can be accommodated, such as direct orders, employee expense report
submission (which requires payment to the employee) or procurement card (like a credit card) based purchases, where a the requisition and PO is entirely bypassed. Process B3.4 allows for these alternative 3-way matching scenarios
, as the invoice is approved and verified before payment is made to the vendor. In the event of match exception or out of tolerance scenarios (where amount invoiced is considerably different than expected), Accounts Payable notifies
the requester of over tolerance (which could trigger a PO change) or rejects (disputes) the invoice (B3.5). In process step B3.6, Accounts Payable (or the Buyer) contacts the Supplier to resolve the rejected invoice. If matching and
tolerance proceeds as planned, in process step B3.7 the invoice could be held in a pending state until a settlement period has been reached, optimizing working capital. Payment is then remitted to the supplier either electronically (via
a banking institution) or manually via a cheque-run (step B3.8). The invoice to payment process asserts a tight audit trail, which enables AP to know everything about the invoice and payment, supporting the ability to investigate and
respond to supplier payment issues (process B3.9). As mentioned above with the non-PO purchasing models, process steps B3.10 - B3.12 provide further details around procurement card purchasing verification and payment
processing since it evokes a different payment model - to the bank as opposed to the supplier (since payment has already been made). Finally, in steps B3.13 - B3.15 related vendor data maintenance processes are performed, which
play an important role in ensuring correct and proper payment to suppliers, as well as avoiding late charges resulting from incorrect payments (locations, addresses, bank acct #s, etc).
Flux d’Avis de paiement
Refund
cheque
or EFT
Scénario de mise en oeuvre
Enchaînement de Use
Cases
Scénario de mise en oeuvre
Modélisation fonctionnelle et organisationnelle
avec UML
Le responsable
commercial
élabore le devis à
partir de la
proposition du
concessionnaire
Transformer
Proposition
Compléter le
devis
Le responsable
du Bureau
d'Etude estime le
prix de la voiture
et complète le
devis
Le devis est retourné
au concessionnaire
via le service
commercial de
l'entreprise et est
soumis au client
Soumettre le
devis
refuser
valider
Le devis est
retourné à
l'entreprise qui va
le transfromer en
commande
Retourner le
devis
Le concessionnaire
propose au client de
refaire une
proposition en
modifiant sa requête
Refaire
Proposition
non
oui
Scénario de mise en oeuvre
Expression des processus extra entreprise
Customer Facing Channel Partners
Customers
Suppliers
Enterprise
1. Develop
Product /
Service
2. Generate
Demand
5. Collaboration
3. Fulfill
Demand
Logistics
Providers
4. Plan &
Manage
Enterprise
Financial
Providers
Workshop
Scénario de mise en oeuvre
Expression des processus extra entreprise
Customer Facing Channel Partners
Customers
Suppliers
Enterprise
1. Develop
Product /
Service
2. Generate
Demand
5. Collaboration
3. Fulfill
Demand
Logistics
Providers
Customer Facing Channel Partners
Customers
Suppliers
Enterprise
1. Develop
Product /
Service
2. Generate
2.3.3.1.1
Demand
Process Order
5. Collaboration
4. Plan &
Manage
Enterprise
Financial
Providers
3. Fulfill
3.5.1
Order
Fulfillment
Demand
3.5.2.3.1
Shipping
Logistics
Providers
4. Plan &
Manage
Enterprise
Financial
Providers
Scénario de mise en oeuvre
My Module Map
Module Map Supplier Tier 1
Complete
shared
Partial
shared
Partial
shared
Module Map Supplier Tier 2
Module Map Logistics
Vue Chaîne logistique
Scénario de mise en oeuvre
Ford : Chaîne logistique
coordination
Chaîne logistique
System Supplier
RHENUS
Transport & Logistic
Services:
transport, logistic, assembly and coordination
Chaîne logistique
Supplier Tier 2
Transport & Logistic
Chaîne logistique
Supplier Tier 3
Partage
Chaîne logistique Supplier Tier 4
Scénario de mise en oeuvre
Transformation Biztalk Server
Scénario de mise en oeuvre
Orchestration Biztalk Server
Scénario de mise en oeuvre
Gestion Devis
Web Services .NET
Validation Devis
ASP.NET
Atelier Fabrication Châssis
Web Service WebSphere
Base
1
2
Application Web
ASP.NET
Atelier Fabrication Roues
Web Service WebSphere
1
Concessionnaire A
Concessionnaire B
Gestion Devis
Application Web
ASP.NET
Commercial
Orchestration
des processus
métier
Biztalk Server
Bureau d’étude
Atelier Assemblage
Web Service WebSphere
Fournisseurs
Base
Scénario de mise en oeuvre
Gestion Commandes
Web Services .NET
Atelier Fabrication Châssis
Web Service WebSphere
Validation Devis
ASP.NET
3
5
Application Web
ASP.NET
Atelier Assemblage
Web Service WebSphere
4
6
3
Concessionnaire A
Concessionnaire B
Gestion
Commandes
Application Web
ASP.NET
Commercial
Orchestration
des processus
métier
Biztalk Server
Bureau d’étude
Atelier Fabrication Roues
Web Service WebSphere
5
Fournisseurs
Scénario de mise en oeuvre
Windows Server 2003
Validation Devis
Gestion Devis
ASP.NET
Web Services
.NET
ASP.NET
Atelier Fabrication Châssis
Web Service WebSphere
Base
Windows Server 2003
ASP.NET
Application Web
ASP.NET
Atelier Fabrication Roues
Web Service WebSphere
Windows Server 2003
ASP.NET
Concessionnaire A
Concessionnaire B
Orchestration
Gestion Devis
des processus
Application Web
ASP.NET Windows métier
XP
Biztalk Server
Windows Bureau
XP d’étude
Tablet PC Edition
Commercial
Atelier Assemblage
Web Service WebSphere
Fournisseurs
Base
Scénario de mise en oeuvre
Gestion Devis
Web Services .NET
Validation Devis
ASP.NET
Windows Server 2003
SQL Server
Atelier Fabrication Châssis
Web Service WebSphere
Base
WebSphere Application Server
Windows Server 2003
Application Web
ASP.NET
Concessionnaire A
Concessionnaire B
WebSphere Application Server
Windows Server 2003
Orchestration
Gestion Devis
Windows
Server
2003
des processus
Application
Web
métier
ASP.NET SQL Server
Biztalk Server
Commercial
Atelier Fabrication Roues
Web Service WebSphere
Atelier Assemblage
Web Service WebSphere
WebSphere Application Server
Windows Server 2003
Bureau d’étude
Fournisseurs
Base
Démonstration
Retour d’expérience
Retour d’expérience
Ford : Projet eSmart
(electronic Synchronous
Material Replenishment
Trigger)
Retour d’expérience
Ford : Projet eAVS
(electronic Automatic
Vehicle Scheduling)
Retour d’expérience
Begin
While
LoopForeever
Continue
Ford : Exemple de
workflow
Receive
AITBOD80
Check for Logistics
Channel
Decision
End
Check for Supplier
Channel
Send AITBOD80
To Database
Decision
RuleDoesLogisticsChannelExist
RuleDoesChannelExist
Else
Else
Send AITBOD80
To Logistics
OR
Send AITBOD80
To Supplier
OR
AND
End
Retour d’expérience
Ford : diagramme d’orchestration Biztalk associé
Retour d’expérience
Projet UGINE
EDI,
XML
EDI, XML
Flat files
EDI,
Files
IBM Mainframe
EDI, Files, XML
IWAY
flat file
VSAM
SQL DS
VSE
VM
IWAY
EAI
SAP
FI
A Déterminer
3270TR
CICSTR
VSE
VSE
HIS
BAPI
IDOC
TCP/IP
CO
SD
FTP
MM
WIN NT / SQL
AS/400
Flat files
Secure FTP: PELI NT
Windows 2000
MS SQL 2000
Rénovation du système d’information
Maintient de la cohérence entre l’ancien SI
(Mainframe) et le nouveau SI
#75 interfaces
Retour d’expérience
SAP
CICS, FTP,
DB2,
VSAM
CLUSTER BIZTALK
(Messaging, HIS, WS)
(Messaging + Orchestration)
Groupe Biztalk
Monitoring
iDOC, BAPI, FTP
CONNECTEURS
Network Load Balancing
Projet UGINE
VM/VSE
EDI, GED…
CLUSTER SQL
SAN
SERVEUR
MOM
Partie 3 : Perspectives
Perspectives
Stratégie de l’industrie des
Web Services
Implementations
Products,
Customer Successes
XML
Web Services
Connects Systems
Interoperability
Industry Support
Infrastructure
XML
Unlocks Data
Advance the Protocols
Perspectives
WS-I
WS I
Web Services
Interoperability
Organization
Initiative de l’industrie
Consortium pour l’interopérabilité des Web services
Profile
Regroupement de spécification à un niveau de version
définit avec des conventions pour les faire marcher
ensemble
WS-I Basic Profile (SOAP 1.1, WSDL 1.1, …)
Démonstrateur
Plusieurs implémentations
Respect des standards et l’interopérabilité
Test et outils
Outils pour tester le respect des standards
Documentation et livre blanc
Perspectives
Web Services Architecture
Connected Applications
Mobile
Secure
Management
Reliable
Messaging
XML
Transports
EAI
B2B
Grid
Business
Process
…
Transacted
Metadata
Devices
P2P
Perspectives
Messaging
SOAP
URI
WS-Addressing
Perspectives
Messaging et WS-Addressing
WS-Addressing fournit les mécanismes pour
adresser les ressources
En véhiculant ces adresses dans les messages
En adressant les messages vers ces ressources
Les mécanismes d’adressage sont
indépendants du protocole de transport
Les ressources ne sont pas soumises à des
contraintes
Elles peuvent être construites, nommées, adressées
d’une façon arbitraire
Perspectives
Méta-données
WS-Metadata
Exchange
WS-Policy
Assertions
WS-Policy
Attachment
WS-Policy
WSDL
Perspectives
Méta-données et WS-Policy
WS-Policy
Mécanisme pour déclarer les besoins et les
capacités des services
Technique (sécurité, fiabilité, …)
Business (qualité de service, coût, …)
Perspectives
Sécurité
WS-Security
WS-Trust
WS-Secure
Conversation
WS-Security
Policy
Perspectives
Sécurité
WS-Security
Encryptions et signature des messages SOAP
Garantit la confidentialité et l’intégrité
Authentification par échange de preuve de sécurité
Indépendant du modèle de sécurité sous-jacent
Login/Password, Certificat X509, ticket kerberos, SAML, …
WS-SecurityPolicy
Définit les contraintes de sécurité pour accéder à un service
WS-Trust
Gestion et définition de relation de confiance entre entité
Fédération
WS-SecureConversation
Définit comment établir un contexte de sécurité entre deux
services pour des échanges de plusieurs messages dans ce
même contexte (handshake ssl)
Perspectives
Sécurité
1) Demande jeton de
sécurité K (Kerberos ticket)
Security Token
Service X
2) Renvoie jeton K
3) Invoque service web
avec jeton K
Client
6) Invoque service web B avec
jeton C et signature digitale
Policy
Service Web A
Policy
Service Web B
Policy
5) Renvoie jeton C
4) Demande jeton C
(certificat X.509 )
Security Token
Policy Service Y
Perspectives
Coordination Distribuée
WS-ReliableMessaging
WS-Atomic
WS-Business
WS-Security
WS-Trust
Transaction
Activity
WS-Secure
WS-Security
Conversation
Policy
WS-Coordination
Perspectives
Technologies de coordination
Garantie de livraison « Reliable Messaging »
2 entités (source, destination), asynchrone
Respect de l’ordre, unicité de l’échange
Transaction atomique
Entités multiples, changement d’état (tout ou rien) synchrone
Two Phase Commit :
Phase 1: Préparation à l’accord
Phase 2: Validation ou interruption
Transaction Longue
Entités multiples, cohérence de l’ état au terme de la transaction,
asynchrone
Deux Phases :
Phase 1 : Annulation/Validation
Phase 2 : Close/Compensation
A tout moment : Sortie/Erreur
Perspectives
Services et transaction
Les messages déclenchent un service
Le service change l’état de ses données privées
Le service génère un message en sortie
Atomic Transaction (ACID)
Données
privées
Transaction
Logique métier
Perspectives
Transactions distribuées
Enjeux des transactions distribuées
Performance et autonomie
Transactions longues (Business-Operations)
Service
client
Service
commande
Transaction T1
Transaction T2
Transaction T5
Transaction T4
Service
production
Transaction T3
Perspectives
Transactions
WS-Transaction
Atomic
Business Activity
WS-Coordination
Création et communication de contexte
Perspectives
Synthèse
Sécurité, transactions, garantie de livraison
Framework WS-* modulaire et composable
Protocoles indépendants les uns des autres
Protocoles indépendants de la couche de
transport
Indépendant de la plate-forme
Basé sur des standards
L’interopérabilité entre fournisseurs est
indispensable
Large support de l’industrie
Conclusion
Conclusion
Evolution de
Orienté fonctionnalités
Conçu pour durer
Cycle de développement
long
Centrée sur les coûts
Plus de connections =
plus de coûts
Une plate-forme
Silos applicatifs
Couplage fort
Orienté Object
Implémentation connue
Vers…
Orienté processus
Conçu pour changer
Dév et déploiement
interactif
Centrée sur la valeur
Plus de connections =
plus de valeur
Toute Plate-forme
Orchestration de Srces
Couplage faible
Orienté message
Abstraction
Ressources
Roger session : SOA definition
http://www.objectwatch.com/issue_45.htm
The architect journal: Contenant l’article “Understanding SOA” de CBDI Forum
http://www.thearchitectjournal.com
Indigo: article sur les principes d’une approche service
http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx
Sessions du symposium architecte joué pendant le PDC (conférence développeurs)
http://microsoft.sitestream.com/PDC2003/Default.htm
Track architecture et infrastructure puis:
ARCSYM1 - Architecture Symposium: Envisioning the Service-Oriented Enterprise
ARCSYM2 - Architecture Symposium: Information Architecture in the Service-Oriented Enterprise
ARCSYM3 - Architecture Symposium: Solution Architecture in the Service-Oriented Enterprise
Web Services Orchestration, Management, and Security - Can They Play Together?
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032241878&Culture=en-US
Realizing Service-Oriented Architecture
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032240293&Culture=en-US
Microsoft pattern & practices
http://www.microsoft.com/practices
Shadowfax project
http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=9c29a963-594e-4e7a-9c45-576198df8058
Patterns and Practices Live - Shadowfax Reference Application
Merci de votre attention
Questions?