R´ealisation

!"#&% '()"(*+,+-% .)/01)//2332-% ^{'()"(*+,+-%/)/%}.)/01)//2332-% 4*05*2(%62-0#% 7/,2(.802% 7/,2(.802% 79"3+92/,81)/% -,#."'/01%23"' -,#."'-4 5*%23"' !"#$%&"*'67"8)#"*9' 4*05*2(-% (+83*-81)/% :)62% ;+,5)62%<% :)62% ;+,5)62%=%

Figure 3.6: Illustration d’un service abstrait et de ses impl´ementations

3.2.4 R´ealisation

Dans cette partie nous d´ecrivons les modalit´es de r´ealisation de l’´ecosyst`eme et de ses divers ´el´ements.

3.2.4.1 Propri´et´es de l’´ecosyt`eme

Les propri´et´es de l’´ecosyst`eme sont exprim´ees `a travers deux types d’ontologies de r´ef´erence partag´ees par les membres de l’´ecosyst`eme. Uschold et Gr¨uninger [142] d´efinissent une ontologie comme l’ensemble de connaissances partag´ees d’un domaine donn´e. Selon [56], une ontologie est une sp´ecification explicite d’une conceptualisa-tion. Nous retenons qu’une ontologie est une mod´elisation formelle et structur´ee. Elle fournit une repr´esentation hi´erarchique des diff´erents ´el´ements symbolisant les constituants d’un domaine donn´e et les relations entre ces ´el´ements. La descrip-tion d’une ontologie est accessible `a travers le web et consitue un mod`ele informatif compr´ehensible autant par l’Homme que par la machine. D’o`u la possibilit´e d’au-tomatiser le traitement d’une ontologie. Les principaux ´el´ements d’une onotlogie d´ecrite en logique descriptive sont : (i) les concepts, (ii) les relations et les (iii) ins-tances. Un concept repr´esente un objet, un terme ou une notion comme par exemple un v´ehicule, une personne, une facture etc. Une relation ou rˆole est une association

binaire entre deux concepts. Elle est exprim´ee par un pr´edicat logique. Parmi les relations usuelles nous retenons les relations suivantes : isA, partOf, hasPart, clo-seTo, over, under, contain, connectedTo. Une instance ou extension de concept est une valeur attribu´ee `a un concept donn´e. Par exemple, Pierre est une instance du concept Personne. Les ontologies servent `a annoter les propri´et´es de l’´ecosyst`eme et celles des services abstraits. Parmi les ontologies de r´ef´erence indispensables `a la description de l’´ecosyst`eme et de ses propri´et´es nous retenons deux types majeurs : – L’ontologie des propri´et´es fonctionnelles. Elle contient un ensemble de concepts et de relations associ´ees mod´elisant les fonctionnalit´es requises et couvertes par les services abstraits. Cette mˆeme ontologie ou une ontologie rattach´ee d´ecrits les concepts et les relations associ´ees mod´elisant les ensembles d’entr´ees-sorties des services abstraits d´ecrits dans l’´ecosyst`eme.

– L’ontologie des propri´et´es non fonctionnelles significatives aux membres de l’´ecosyst`eme. Des ´el´ements de cette ontologie sont associ´es aux propri´et´es non fonctionnelles des services abstraits.

3.2.4.2 Ressources de l’´ecosyt`eme

Deux aspects concernant les ressources sont `a ´etudier. D’abord les services abs-traits uniformisant les fonctionnalit´es m´etiers et ensuite les services membres (ou services fournis) concr´etisant le savoir-faire des entreprises membres.

Services Abstraits Pr´ec´edement, dans la section 3.2.3.3, nous avons d´efini un service abstrait comme une interface qui se rapporte `a une fonctionnalit´e donn´ee et poss´edant un ensemble de propri´et´es rattach´ees. Nous proposons de rajouter des annotations s´emantiques aux divers ´el´ements de l’interface d’un service abs-trait afin d’augmenter la pr´ecision de la description. En effet, pour une activit´e fonctionnelle donn´ee, automatis´ee ou non, l’interface du service abstrait est un ensemble de donn´ees structur´ees ou semi-structur´ees contenant des informations d´ecrivant les op´erations n´ecessaires pour accomplir cette activit´e. Chaque op´eration poss`ede un ensemble de param`etres en entr´ee et fournit un ensemble de param`etres en sortie. Afin de d´ecrire s´emantiquement ces param`etres, nous rattachons `a cha-cun une annotation s´emantique vis-`a-vis d’une ontologie de r´ef´erence d´ecrite dans l’´ecosyst`eme. Les restrictions et les contraintes de r´ealisation sont exprim´ees sur les concepts des ontologies de r´ef´erence. Particuli`erement, les restrictions peuvent ˆetre

exprim´ees lors de la d´efinition des param`etres d’entr´ee - sortie `a travers l’´el´ement XML < xs : restriction >.

Les services abstraits sont d´efinis par les membres de l’´ecosyst`eme apr`es la mise place du consensus global (section 3.2.3.1). L’uniformisation des interfaces de description des fonctionnalit´es fournies dans l’´ecosyst`eme permet de faciliter la d´ecouverte du point de vue de l’utilisateur. En effet, une partie du proces-sus de d´ecouverte est accomplie par le fournisseur du service dans la mesure o`u il impl´emente directement ou indirectement l’interface d’une description com-mun´ement adopt´ee par les membres de l’´ecosyst`eme. L’impl´ementation directe consiste `a fournir un service ayant une interface identique `a un service abstrait propos´e dans l’´ecosyst`eme ; tandis que l’impl´ementation indirecte consiste `a four-nir les correspondances entre l’interface du service propos´e et un service abstrait ´equivalent.

Services Membres Concr`etement, comme ´evoqu´e dans la section 3.2.2, les ser-vices membres sont class´es en deux cat´egories : des serser-vices encapsulant une activit´e automatis´ee et d’autres encapsulant une activit´e n´ecessitant une intervention hu-maine.

Les ´el´ements de la premi`ere cat´egorie sont r´ealis´es par des services web ayant une interface WSDL. Si une description WSDL5 contient plusieurs op´erations cor-respondant `a des activit´es fonctionnelles diff´erentes, chaque ensemble d’op´erations rattach´es `a une fonctionnalit´e donn´ee sera mod´elis´e par un service abstrait dans l’´ecosyst`eme de DyCoSe. Par exemple les services S1 3, S2 1 et S3 5, constituant des impl´ementations respectives des services abstraits A1, A2et A3, peuvent ˆetre d´ecrits dans un mˆeme fichier WSDL. Les ´el´ements de la deuxi`eme cat´egorie sont r´ealis´es ´egalement par des services web (WSDL) proposant des op´erations o`u les entr´ees et les sorties sont d´efinies mais le traitement sera accompli par une personne et non pas par la machine. La sp´ecification WS-HumanTask [44], aborde la d´efinition des acti-vit´es “humaines” (service-enabled human tasks), non accomplies par la machine et leurs associe des propri´et´es et un ensemble d’op´erations. WS-HumanTask propose un protocole de coordination afin de g´erer la dur´ee de vie des activit´es humaines de fa¸con uniforme garantissant l’interop´erabilit´e entre elles et avec d’autres services web.

3.2.4.3 Base de connaissances de l’´ecosyt`eme

La base de connaissances de l’´ecosyst`eme, comme d´ecrite auparavant, contient les diff´erents ´el´ements r´ealisant l’´ecosyst`eme. Elle regroupe l’ensemble des fichiers d´ecrivant les ontologies n´ecessaires `a la d´efinition du consensus global et des services abstraits. L’ensemble des propri´et´es d´efinissant le consenus global est recens´e dans un fichier semi-structur´e. Ce fichier contient aussi la liste des services abstraits dis-ponibles ainsi que les adresses (URL/URI) respectives de leurs interfaces associ´ees. La base de connaissances pourrait comprendre, si les membres de l’´ecosyst`eme le souhaitent, un historique des applications cr´e´ees et ex´ecut´ees, contenu dans un fi-chier semi-structur´e pointant vers le journal d’ex´ecution de chaque application. La base de connaissances de l’´ecosyst`eme contient aussi un fichier listant les entreprises membres `a travers leurs pairs. En effet, comme discut´e dans la section 3.2.3, une entreprise est mod´elis´ee par un ou plusieurs pairs, tel que chaque pair est un point d’entr´ee accessible aux membres de l’´ecosyst`eme (adresse URL/URI d’une interface). Concr`etement, la base de connaissances de l’´ecosyst`eme est r´epartie sur le r´eseau de membres. Les d´etails de cette r´epartition sont discut´es dans la section 3.3.3.1, apr`es la description de la r´eorganisation du r´eseau de membres en un r´eseau virtuel hi´erarchique.