Composition sémantique de services et gestions des méta-données

Projet de synthèse bibliographique
–
partie 2
Ibrahima SALL
Rankin BATTAL
Meng GUO
Khalid MERNISSI
Elo PELOVAS

Projet «
ANR SEMEUSE
»

Développement d’une plateforme de bus
sémantique

INRIA, INSA, LIP6, INT, …

Thales, France Télécom, EBM Websourcing
2

Croissance exponentielle des écosystèmes de
services

Intégrer des informations
sémantiques
sur
les services

Objectif

Relier
dynamiquement
les services pour répondre
aux besoins de l’utilisateur de façon
sécurisée
avec une
qualité de service
.
3

Infrastructure SOA,

Entreprise Service Bus

Modélisation de services

Contrat de base

Contrat étendu, SLA

WSDL

Gestion des annuaires de services

UDDI

Gestion des annuaires

RDF, SPARQL, OWL
4

Conclusions

Introduire des données sémantiques dans la
description des services

Mettre en place une ontologie au niveau des
annuaires de services

Composer ces services sémantiques en offrant
une qualité de service et une garantie de sécurité

Comment
5

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
6
URI, HTML, HTTP
WWW
RDF, RDF(S), OWL,
SPARQL
Semantic
Web
UDDI, WSDL, SOAP
Web Services
???
Semantic
Web Services
Dynamic
Static
(Stollberg, ICWS 05)
7
Semantic
Web Services =
Semantic
Web Technologie + Service Web
Technology
•
Implement
•
Deploy
•
Describe
and
publish
Prodiver
•
Localization
•
Connection
•
Invocation
Client
Services directory
(UDDI)
1
-
Publish(WSDL)
2
-
Search for WSDL
3
-
Link/Connect
8
Web Service standards
lack
of
semantic

What should S+WS and service ontologies
provide? (Partly) Automation of the
Usage
Process:

Publication
: Make available the description of the capability of a service

Discovery:
Locate different services suitable for a given task

Selection:
Choose the most appropriate services among the available ones

Composition:
Combine services to achieve a goal

Mediation:
Solve mismatches (data, protocol, process) among the combined

Execution:
Invoke services following programmatic conventions

Monitoring:
Control the execution process

Compensation:
Provide transactional support and undo or mitigate unwanted effects

Replacement:
Facilitate the substitution of services by equivalent ones
9
S
E
M
A
N
T
I
C
S
S
E
C
U
R
I
T
Y
T
R
A
N
S
A
C
T
I
O
N
S
A
D
M
I
N
I
S
T
R
A
T
I
O
N
Q
O
S
Business
Process
Discovery
Description
Exchange
Transport
10

Nonfunctional
information of Web Services
Accuracy
Robustness
Availability
Scalability
Financial
Security
Network
-
related
QoS
Transactional
Performance
Trust
Reliability
11

WSDL
does
not
handle

Semantic

QoS

SLA

Pricing

Solutions

SAWSDL

OWL
-
S

WSMO
12
13

From discovery to invocation, automation is
possible

Four different semantic descriptions

Information semantics

Functionnal semantics

Nonfunctionnal semantics

Behavioral semantics
14

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
15

Semantic
Annotations for WSDL

Annotate
syntactic
WSDL descriptions
with
pointers to the
semantic
concepts

Provide
a
common
ground
for SWS
Frameworks
(OWL
-
S, WSMO)

Compatible
with
WSDL1.1+, RDF, OWL

SAWSDL extensions
take
two
forms
:

modelReference

point to the
semantic
concepts

schemaMapping

specify
data transformation
between
messages
16

SAWSDL is a layer above WSDL that
connects it to the semantic technologies
Extented Web Service specification stack
17

Not a complete technology for automation

Need a service and domain ontologies

Ground for WSMO, OWL
-
S

Goal

Put them all together in a standard SWS
Framework
18

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
19

OWL
-
S is an OWL ontology to describe
Semantic WS

OWL
-
S aims to enable the following tasks:

automatic WS discovery

automatic WS invocation

automatic WS composition and interoperation

OWL
-
S does not aim to replace the WS
standards rather OWL
-
S attempts to provide a
semantic layer

OWL
-
S relies on WSDL for WS invocation
(Service
Grounding)

OWL
-
s expands UDDI for WS discovery
(OWL
-
S/UDDI
mapping)
20

The OWL
-
S ontology has 3 main parts:
21
•
Capability specification
•
General features of the Service
•
Quality of Service
•
Classification in Service
taxonomies
•
Control flow of the service
•
Black/Grey/Glass Box view
•
Protocol Specification
•
Abstract Messages
•
Mapping to WSDL
•
communication protocol (RPC, HTTP, …)
•
marshalling/serialization
•
transformation to and from XSD to OWL

tells “what the service does”

Service Profile description
includes:

description of the service and it's
provider

specification of the functionalities

attributes which provide additional
information, requirements
22

Describes how to interact with the service

Atomic and composite process

It can have 2 sorts of purpose:

generate and return new information based on information it is
given and the world state (inputs and outputs)

produce a change in the world (preconditions and effects)
23

tells “how does a client
access the service?”

maps inputs and outputs of
an atomic process to
concrete messages

uses WSDL as a
specification for messages
24

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
25

WSMO is an ontology and conceptual framework to
describe Web services and related aspects

These technologies will facilitate the automation of
discovering, interoperating, composing and
invoking WS over the Web

WSMO defines the modeling concepts for
describing semantic WS:
26

Represent a key
element in WSMO
–
describes the
behaviour
of WS and
the information they
consume and produce

Facilitates the
interoperation between
humans and WS
27

Semantic
description of
Web Services:
Properties:
•
Capability
(functional)
•
Interfaces
(usage)
•
description
of users'
desires
28

Special elements used to link heterogeneous components

Creates a mediation
-
orientated architecture providing an
infrastructure for handling heterogeneities

*ggMediators *ooMediators *wgMediators *wwMediators
29

Discovery

Provide formal representation of capabilities and goal

Conceptual model for service discover
y

Different approaches to web service discovery

Composition

Provide formal representation of capabilities and choreographies

Invocation

Support any type of WS invocation mechanism

Clear separation between WS description and implementation

Mediation and Interoperation

Mediators as a key conceptual element

Mediation mechanism not dictated

(Multiple) formal choreographies + mediation enable interoperation

Guaranteeing Security and Policies

No explicit policy and security specification yet

Proposed solution will interoperate with WS standards

The solutions are envisioned maintaining a strong relation with existing WS
standards
30
31
32

Aim at similar goals: providing a support for semantic WS
but
they rely on different logics

OWL
-
S is more mature in certain aspects:

choreography, specifications

WSMO provides a more complete conceptual model as it
addresses aspects:

goals, mediators
33
OWL
-
S
WSMO
Web Services
Infrastructure
Discovery
What it does
Profile
Web Services
(capability)
UDDI API
Choreography
How is done
Process Model
Orchestration +
choreography
BPEL4WS
Invocation
How to invoke
Grounding+
WSDL/SOAP
Grounding
WSDL/SOAP

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
34

Illustration

Planification de voyage en ligne
▪
Réservation de billets d’avions
▪
Location de véhicule pour la durée du séjour
▪
Calcul du prix total
35

Conversion de contexte
36

Architecture de médiation
37

Extraction de l’information sémantique
39

Vérification des concepts du domaine utilisé
40

Vérification des éléments du contexte utilisé
41

Conversion des données
42

SWS

SAWSDL

OWL
-
S

WSMO

Composition de service

Sécurité
43

La sécurité est au cœur des préoccupations des
entreprises pour garantir la cohérence et la
pérennité des systèmes.

Pour ce faire, la sécurité doit être prise en compte
dès la conception des services web et ceci à tous les
niveaux
:

Conception, spécification

Architecture

Développement

Déploiement

Exécution & exploitation
44

Les fonctions de sécurité disponibles qui
pourront s’appliquer à des services:

Authentification

Habilitation

Intégrité
(ou signature)

Imputabilité

Confidentialité
(ou chiffrement)
45

WS
-
Security est un standard pour sécuriser
des services web

Cette norme s’applique uniquement au
niveau des messages échangés et n’a aucun
impact sur le protocole et le transport choisis.

Tente de normaliser les échanges sécurisés
de messages

Tente de garantir l’interopérabilité entre
systèmes
46

Définition:
L'infrastructure de gestion de privilèges
fournit un cadre dans lequel il est possible
d'appliquer la politique d'autorisation d'accès
ou d'attribution de privilèges à des
applications ou à des ressources, en fonction
du rôle des utilisateurs ou de leur
appartenance à un groupe.

L’intégration sémantique de PMI dans les
systèmes de contrôle d’accès de Service Web
héterogène permet de l’interopérabilité entre
eux.

Elle comprend :

Une politique décrivant les privilèges des entités
considérées,

Une autorité de certification

Et une interface permettant d'appliquer ces privilèges aux
ressources.

Authentification

Chiffrement

Signature
49

L’authentification s’appuie sur la notion de token
(login,mot de passe)

Le niveau de confidentialité de ces données
échangées peut également être choisi

Les principaux tokens disponibles sont
:

User Name Token
: échange de couples login/mot de
passe

SAML Token
: échange de données d’authentification au
format XML SAML

X
509
Token
: échange de données d’authentification par
certificat (authentification forte)
50

Le chiffrement peut se faire via différents
algorithmes, symétriques ou asymétriques.

La norme WS
-
Security permet l’envoi de
métadonnées du client de web service au web
service cible afin de décrire la méthode de
chiffrement utilisée et permettre des échanges de
clé si besoin.

Les messages sont constitués de plusieurs parties
(header, message), chacune pouvant être chiffrée
ou non selon la configuration choisie.
51

L’objectif de la signature est de garantir
l’origine du message en échangeant un jeton
chiffré avec un secret partagé

Elle se fait via des certificats X
509
et peut être
appliquée sur des messages en clair ou
chiffrés selon la configuration choisie.
52

La mise en place de tout ou partie des
5
fonctions
citées précédemment doit être étudiée selon le
besoin de chaque contexte.

Trouver le meilleur compromis pour mitiger les
risques en combinant ces fonctions.

Contrôle d’accès aux services

Confidentialité des données échangées over HTTP

Confidentialité et intégrité pour des messages XML over
HTTP

Confidentialité et intégrité pour des messages SOAP
53

Comment contrôler les droits d’accès ?

Pas de standards existants pour le moment

Possibilité d’inclure des données sémantiques
relatives au droit d’accès

Implémenter une politique de sécurité propre
(ex:
utilisé la logique des OS)
54

Modélisation de services

WSDL + OWL
-
S

WSDL + WSMO

Gestion des annuaires

UDDI

Gestion des métadonnées

RDF, RDFS, SPARQL

Composition de services

QoS

Sécurité
55