View
108
Download
1
Category
Preview:
Citation preview
1Fujitsu Computer Systems
Un survol des Technologies e-Business / e-Gouvernement
Partie 4
Jacques DurandFujitsu Computer Systems
2Fujitsu Computer Systems
4. Les Architectures e-Business
- Modèles de déploiement des Services Web- Profils WS-I
Jacques DurandFujitsu Computer Systems
3Fujitsu Computer Systems
Aspects Importants du Déploiement Web Services [pour e-Bus / e-Gov]
- Interopérabilité: Web Services Interoperability (WS-I) Profils
- Gestion du déploiement: Adaptée au mode de déploiement des Services
4
Modèles de Déploiement des Services Web
• Plusieurs façons de déployer / publier un service Web (WS)
• Affecte la gestion du WS– Gestion des changements (interface du WS, location du
WS)– Ajout d’utilisateurs, intégration coté’ applications…
• Quelques paramètres d’ un déploiement:– Exposition de l’interface du Service (fichier WSDL): interne?
Externe?– Protocole Web utilisé (SOAP? REST?)– A quel profil WS-I se conformer?
5
Questions préliminaires (1):• Qu’ y a-t-il derrière mon Service?
?WebService
• Un “vrai” service? (exécute une fonction précise, “délocalisée”)
• conversion de monnaie• évaluation de police d’ assurance • gestion de panier eCommerce
• Une adresse où poster un document métier?
•Bons de Commandes, Factures…
• Un interface Web a une application conventionnelle?
• visibilité de stock / inventaire• modules de gestion, ERP
6
• Qui / quel est l’utilisateur du WS (“Clients”)?
WS
Une passerelle
Un navigateur Web
Un processus métierinterne?
?
?
Un “EnterpriseServiceBus” (ESB)
?
Questions préliminaires (2):
7
3 Modèles de Déploiement de WS
• Le modèle Publication Web
• Le modèle Interface d’Application Business Distante (IABD)
• Le modèle Passerelle-Cliente
8
Le modèle Publication Web• Service Web = resource Web
– comme les pages Web et documents accessibles par tous.• Les services ne sont pas liés a des processus métier
spécifiques d’ une filière– Plutôt “hosted” (outsourced) et gères comme des entités
individuelles• Large accès public
– Cherche a maximiser le nombre d’utilisateurs, facilite l’ acces• E.g. WS publies par Amazon, eBay, Google• Protocoles: comme pour les autres resources Web,
préférence pour REST• L’interface du service: sa définition est diffusée
publiquement – connue des utilisateurs – cependant, l’ingterface joue un role surtout documentaire si
REST est utilise’ (WSDL doc non processe’)
9
eCommerce cart
CRM
WebService
Storage
WebService
WebService
WebService
BusinessProcess
ClientApplication
BusinessApplication
Utilisateurs publics (nombreux)
HTTPProxy
(reverseProxy)
Services hotes, SaaS
Scheduling
SOAP
REST
SOAP
REST
Modèle Publication Web
10
PublicationWeb
InterfaceApp Businessdistante
Passerelle-cliente
Format Document
Qualité’ de comm (Sécurité’, Fiabilité’…)
Nombre de Services
Nombre d’utilisateurs( clients)
Type d’échangeB2B
XML (+ multi-media)
Elémentaire / comm(HTTP/S)
Tolérance a desProtocoles autres
Couteuse
Conçus pour grandnombre
Suppose’ restermodeste
Invocation de Fonction(Transfer Doc possible)
Non (SOAP ou REST)
Mode Déploiement
Requis
Gestion de Changement des interfaces
11
Modèle Interface d’Application Business Distante
• Service Web = Interface d’ une application métier. – Rend possible l’ accès distant.
• Le service est lié a un processus métier spécifique.– Liens avec les processus d’ entreprise ou de l’ administration:
accès contrôle’, mise en opération délicate.• Accès restreint
– Uniquement partenaires business (sécurité’, autorisation, authentification)
• E.g. WS qui servent d’ interface a des gestionnaires d’ inventaire, des modules ERP.
• Protocoles:, préférence pour SOAP, et les modules de qualité’ de service de la communication associes
– sécurité’, fiabilité du message• L’interface du service: sa définition est diffusée de facon
restreinte – connue des partenaires seulement – Interface est nécessaire coté client – e.g. utilise’ pour générer
du code source coté client.
12
InventoryVisibility
SCM
WebService
Pricing
WebService
WebService
ClientApplication
CustomerBusinessProcess
ClientApplication
SmallSupplier
Applications from Trusted Business Partners
SecurityAuthorizationReliability
Enterprise B
usiness Applications
Qual. Of Svce
QoS
QoS
SOAP
SOAP
Modèle Interface pour Application Business Distante
HTTPProxy
(reverseProxy)
Manufacturing Company
13
Interface BusinessAppl. Distante
Complete
CouteuseRisque eleve’
Requis
Mode Déploiement
Format Document
Qualité’ de comm (Sécurité’, Fiabilité’…)
Nombre de Services
Nombre d’utilisateurs( clients)
Type d’échangeB2B
Tolérance a desProtocoles autres
Gestion de Changement des interfaces
Elémentaire (HTTP/S)
Couteuse
Conçu pour Grand nombre
Suppose’ restermodeste
Invoc. de Fcn(Doc possible)
Non
XML (+ multi-media)
XML (+ EDI, multi-media)
Supposé resterLimité (partenaires)
Supposé restermodeste
Invocation de Fonction(Transfer Doc possible)
Non
PublicationWeb
14
Modèle Passerelle-Cliente• Service Web = Une ressource interne quelconque.
– Souvent Interface de module Applicatif business, mais interne.• Le service est lié a un processus métier spécifique.
– Ou bien une fonction utilisée par un processus métier, en interne, ou interface a des fins d’ intégration internes avec des systèmes existant (ERP, CRM, PLM…) .
• Accès externe par médiation uniquement – Service déployé en interne, accès externe direct impossible.
Accès indirect par un “médiateur” ou passerelle de messagerie.• Protocoles: Le découplage entre communication externe
et interne par passerelle B2B, autorise variete’ cote’ B2B:
– AS2, ebMS2,3. SOAP-based (ebMS3) facilite la conversion du message sous forme d’ invocation WS.
– sécurité’, fiabilité du message• L’interface du service: sa définition n’est PAS diffusée
aux partenaires – La passerelle est le client réel des WS internes.
15
WebService
WS
WS
ClientApplication
BusinessProcess
ClientApplicationClientApplication
Business Users
HTTPProxy
(reverseProxy)
InternallyDeployedServices
eB/eGGateway
eB/eGGateway
DMZ
Business Document Publish / subscribe
Modèle Passerelle-Cliente
SOAPebXMLAS2RNIF…
The actualWS client
WS
QoS
16
Passerelle-cliente
XML et autres
CompleteOption centralisée
Facilitee,Peu de risques
Grand nombre
Nombreuxpossible
Doc. metiers: +++Invoc. de Fcn : +
Oui
Requis
Format Document
Qualité’ de comm (Sécurité’, Fiabilité’…)
Nombre de Services
Nombre d’utilisateurs( clients)
Type d’échangeB2B
Tolérance a desProtocoles autres
Gestion de Changement des interfaces
InterfaceApp Businessdistante
Mode Déploiement PublicationWeb
Elémentaire (HTTP/S)
Couteuse
Conçu pour Grand nombre
Suppose’ restermodeste
Invoc de Fcn (Doc possible)
Non
XML (+ multi-media)
Complete
CouteuseRisque eleve’
Conçu pour Petit nombre
Suppose’ restermodeste
Non
Invoc. de Fcn(Doc possible)
XML (+ multi-media)
17
Les Passerelles e-Business
• Tendance: multi-standard• Rôle: découplage messagerie / intégration avec
applications, sécurité’/ autorisation, validation de docs, etc.
• SeeBeyond eXchange Integrator (Java CAPS) – supporte AS2, ebMS2, RosettaNet (RNIF)
• Hermes/CECID (Open Source), – supporte AS2 et ebMS2
• BusinessConnect/TIBCO: – AS2, ebMS2 et +
• SonicCollaborationServer/SonicSoftware:– ebMS2 et +
18
2 Exemples d’ Architectures Passerelles
• General Motors– ebMS2 cote’ B2B– Conversion ebMS2 invocation de services Internes.– Passerelle: traite la securite’ generale
• Health Care Dental, Canada– ebMS2 cote’ B2B– Passerelle: fonctions de routage, d’ autorisation– ebMS2 en Interne
19
J2EE application
ERP
SCM
Business Process(e.g. BPEL)
WebServiceB2B
gateway
.NET application
ESBWeb
Service
WebService
RegistryRepository
WebService
Architecture Orientées-Service(Service-Oriented Architectures, SOA)-“Agile” : changements facile a gerer- conversion de messages en un format normalise’ sur le BUS (assume une partie des fonctions de la passerelle “cliente”)
20
Les échanges orientés-document• Service ou pas Service ?• A supposer “Service”, autre question cruciale:
Service externe ou Service interne?
WebService
WebService
WebService
WebService
WebService
WS clients =User apps
WS client =Gateway
JMSMQ
WS internesWS externes
DocumentsOver ebMS,AS2
21
Echanges orientés document• Grand nombre potentiel de types de documents,
e.g schemas XML. Même pour un seul Document Métier:– Evolution de ces documents (versions successives, e.g.
Bon de Commande V1, V1.1, V1.2.– Personnalisation: chaque entreprise a sa variante de
Bon de Commande.
Difficulté à maitriser dans les interfaces Service Web (fichiers WSDL).– Types de doc: associes étroitement à l’ interface WS.– A Eviter absolument: faire face aux deux a la fois:
• l’ instabilité / l’ évolution de l’ interface WSDL• la diffusion du WSDL a un nombre important de partenaires
22
Risques d’ une exposition externe des Service Web orientés-document
• 1- Impact d’ une évolution des documents.
• problèmes logistiques de transition des partenaires eB/eG. (tous ne peuvent migrer en même temps sur le nouveau Service.)
• 1 opération du WS = 1 seul document au plus en input (pas plusieurs variantes). – Donc, difficulté d’associer les deux variantes d’ un
document type, à la même opération impact sérieux sur la définition d’interface.
Operation AWeb ServiceOperation B
Operation C
23
Risques d’ une exposition externe des Service Web orientés-document
• 2- Gestion des erreurs.
• Le document XML est validé automatiquement par la pile Web services– vérification automatique de “types”: une bonne chose dans les
langages de programmation ou dans Remote procedure Calls, mais inappropriée pour les documents business !
• Non conformité au schéma XML message rejeté par la couche basse du protocole. Or, de telles erreurs:– (1) souvent ne sont pas fatales au niveau business, (e.g.
différente version d’ un même document, avec conversion possible).
– (2) en majorité’ devraient être traitées a un niveau “business” comme les erreurs “sémantiques” de contenu business. (et non comme un problème de couche communication)
24
Risques d’une exposition externe des Service Web orientés-document
• 3- Pré-traitement souvent nécessaire
• Sécurité commune aux Services: éviter de la gérer au niveau de chaque service !– La centraliser au niveau passerelle (pas HTTP proxy )– Laisser la partie spécifique a chaque WS (e.g. autorisation d’ accès)
• Coté Réception: Routage interne souvent nécessaire– doit être flexible: La destination finale du document demande une visibilité
préalable.– Passerelle: Un Web service intermédiaire? Mais le document XML doit
souvent être transmis tel-quel, avec son contexte message (non-transforme’)
– Contrôler la validation (éviter validation aveugle par la pile Web services)– Le concept de passerelle, ou d’ intermédiaire s’impose pur les
prétraitements – et ce ne doit pas être un Service.
25
En Conclusion
• Gestion des systèmes en production: doit faire partie d’un cahier des charges COMPLET qui va au delà des aspects fonctionnels et infrastructure (interface définition & Protocol):– Identifier le type de Service, perspectives d’
évolution de leur nombre, de leurs définitions, – Gestion des changements? Transition a un
nouveau service? A une nouvelle version? Impact sur utilisateurs?
– L’existant doit être pris en compte: intégration avec back-office , problèmes de transition.
Copyright © 2005-2006 by The Web Services Interoperability Organization (WS-I). All Rights Reserved 26
WS technology involves several standards (from OASIS, W3C, IETF…)
Many Interoperability issues in WS arise from
Different Interpretations of these Standards by Product Vendors
Different Integration Approaches
Need for…
The WS-I Approach
SO
AP
UD
DI
PROFILE
HT
TP
XM
L
STANDARDS
Copyright © 2005-2006 by The Web Services Interoperability Organization (WS-I). All Rights Reserved 27
SOAP 1.1 WSDL 1.1 UDDI 2.0 XML Schema XML 1.0 (Second Edition) HTTP 1.1 SSL 3.0
WS-I Profiles
+• Restrictions,• Integration Guidance• Best Practices
Basic Profile 1.1=
More than 200 interoperability issues resolved
Copyright © 2005-2006 by The Web Services Interoperability Organization (WS-I). All Rights Reserved 28
WS-Addressing SOAP 1.1 WSDL 1.1 UDDI 2.0 XML Schema XML 1.0 HTTP 1.1 SSL 3.0
WS-I Profiles
Basic Profile 1.1, 1.2
• WS-S 1.1• SAML
Basic SecurityProfile 1.1
• WS-ReliableMessaging1.1• WS-SecureConv
ReliableSecureProfile 1.0
Copyright © 2005-2006 by The Web Services Interoperability Organization (WS-I). All Rights Reserved 29
An open industry effort
advance Web services interoperability across platforms, applications and programming languages
Broad participation
150+ users, software vendors, consultants, industry orgs, etc.
Establish best practices for achieving interoperability
Based on existing and broadly supported standards
Cooperate with SDOs (standards development orgs)
On the Consumer side of standards
WS-I Organization
www.ws-i.org
Recommended