3 M ETAMODELE DE COMPOSANTS A SERVICES
3.1 C OMPOSANTS A SERVICES PRIMITIFS
Dans notre approche, un composant à services primitif possède trois matérialisations, spécification, implémentation et instance, chacune correspondant à un niveau d abstraction différent associé à une phase du cycle de vie des composants : conception, développement et exécution.
3.1.1 S
PECIFICATIONTout d abord une spécification décrit un composant à services par ses ressources (interfaces et messages) offertes et requises (voir la Figure 51).
Figure 51. Spécification de composant à services
Contrairement aux approches à services, notre approche permet de définir des dépendances de
ressources à partir de la spécification d un composant à services Ces dépendances de niveau
spécification permettent la composition structurelle de spécifications (les spécifications sont composables) et augmentent la flexibilité de la composition (les implémentations des spécifications
sont substituables Ce niveau de dépendances n annule pas les dépendances spécifiées au niveau des
implémentations : une implémentation d une spécification dépend des ressources spécifiées dans la spécification et peut en addition dépendre d autres ressources dépendances propres à l implémentation
Les ressources requises peuvent être définies par des dépendances simples ou complexes (voir la Figure 51). Une dépendance simple est définie vers une seule ressource. Une dépendance complexe représente une dépendance vers un ensemble de ressources qui doivent être offertes par un même
fournisseur Les dépendances complexes permettent de gérer d une façon plus contrôlée la résolution
Une dépendance, simple ou complexe, possède des attributs de cardinalité qui permettent
d exprimer l optionalité et la multiplicité de la connexion et de filtrage qui permettent d exprimer les
propriétés nécessaires (contraintes) et préférables (préférences) que les fournisseurs des ressources requises doivent satisfaire. Les contraintes et les préférences de sélection sont exprimées dans notre langage de contraintes (présenté dans la section 4.1), qui vérifie la validité des expressions afin
d assurer la compatibilité entre clients et fournisseurs
Ensuite, une spécification établit les propriétés (intrinsèques) et les définitions de propriétés qui caractérisent un composant à services. Les définitions de propriétés (aussi appelées propriétés configurables) sont en général affectées lors de la phase de développement du composant, toutefois
elles peuvent être affectées à n importe quel moment du cycle de vie du composant
Enfin, une spécification définit les contraintes et les préférences (intrinsèques) qui caractérisent un composant à services. Celles-ci expriment respectivement les propriétés requises et préférables du composant, par exemple, une plate-forme particulière d exécution ou une propriété non-fonctionnelle requise. De manière plus formelle, nous définissons le concept de spécification de la façon suivante :
Une spécification est un 7-uplet S = <name, R, D, P, DP, CT, PF>, où : name est le nom symbolique de la spécification S
R = {r1, r2 rn} est l ensemble des ressources fournies de S, tel que chaque ressource ri est une interface ou un type de message D = {d1, d2 dn est l ensemble des dépendances de S, tel que
chaque dépendance di est un 5-uplet d = <id, target, cardinality, dCT, dPF>, où id est l identificateur de la dépendance d
target indique l objet destination une spécification ou une ressource de d : Type(target) = Specification | Resource
cardinality = <min, max> est la cardinalité de d, où
min est le nombre minimum de connexions requises, et max * est le nombre maximum de connexions autorisées, tel que
min max, et max peut être défini comme un nombre indéterminé dénoté par « n » dCT est l ensemble des contraintes de d, et
dPF est l ensemble des préférences de d
P = {p1, p2 pn} est l ensemble des propriétés de S, tel que chaque propriété pi est un 3-uplet p = <name, type, value>
DP = {dp1, dp2 dpn est l ensemble des définitions de propriétés de S, tel que
chaque définition de propriété dpi est un 3-uplet dp = <name, type, value>, où value est optionnel CT est l ensemble des contraintes de S, et
PF est l ensemble des préférences de S
Dans la pratique, une spécification est décrite dans un fichier de description XML en spécifiant ses ressources fournies et requises, ses propriétés et ses définitions de propriétés, ses contraintes et ses préférences. La Figure 52 présente un exemple de description XML (projeté sur Java) créée par notre environnement de développement (cf. Chapitre 7 section 1.2).
Pour illustrer le concept de spécification, nous reprenons les spécifications définies pour notre application de gestion multimédia : MediaManager, MediaServer et MediaPlayer. La spécification
MediaManager, illustrée dans la Figure 52 :
définit une ressource fournie à travers l interface MediaManagerService,
configure la propriété prédéfinie multiple (voir le Tableau 9),
définit des définitions de propriétés avec les attributs provider et freeware, et
spécifie des ressources requises par les dépendances ms et mp vers les spécifications
3.M
ETAMODELE DE COMPOSANTS A SERVICES<specification na me="MediaManager" interfaces="media.services.manager.MediaManagerService"> <property na me="multiple" va lue="false" />
<definition na me="provider" type="String" /> <definition na me="freeware" type="Boolean" />
<dependency s pecification="MediaServer" i d="ms" multiple="true" /> <dependency s pecification="MediaPlayer" i d="mp" multiple="false" /> </specification>
Figure 52. Spécification de composant à services Exemple MediaManager
En résumant, les ressources fournies et requises, les propriétés et les définitions de propriétés, les contraintes et les préférences définies par une spécification sont les caractéristiques de tout
composant à services qui l implémente
3.1.2 I
MPLEMENTATIONUne spécification peut être implantée par plusieurs implémentations en utilisant différentes technologies à services (Services Web, UPnP, DPWS, OSGi, iPOJO) et/ou différents algorithmes. Une
implémentation implémente une seule spécification (voir la Figure 53).
Figure 53. Implémentation de composant à services
La relation implements qui relie une implémentation et sa spécification est une relation de groupe : une spécification représente le type de ses implémentations. De ce fait, les caractéristiques définies par une spécification sont héritées par ses implémentations.
Une implémentation fournit et requiert ainsi, au moins, les ressources définies par sa spécification. Les dépendances définies par une spécification doivent être précisées par ses implémentations. Une dépendance peut être précisée en indiquant par exemple le nom de la variable ou de la méthode correspondante dans le code source, la cardinalité, les contraintes et les préférences additionnelles de sélection. Toutefois, les dépendances définies par une spécification contraignent les dépendances correspondantes de ses implémentations, par exemple, une dépendance obligatoire et
simple (cardinality=<1,1>) définie par une spécification ne peut pas être précisée comme optionnelle ou multiple par aucune de ses implémentations. Une implémentation possède également les propriétés, les contraintes et les préférences définies par sa spécification.
Selon la logique de groupes, les membres ont au moins les propriétés et les relations communes et
variables définies par son représentant mais peuvent en ajouter d autres Une implémentation peut
ainsi ajouter des ressources fournies, des dépendances de ressources, des propriétés et des définitions de propriétés pour ses instances, ainsi que des contraintes et des préférences. Grâce au mécanisme de
groupes la validité d une implémentation i e sa conformité et sa cohérence vis-à-vis de son spécification) peut être assurée statiquement (lors de sa compilation/packaging).
Nous définissons formellement le concept d implémentation comme suit :
Une implémentation est un 8-uplet I = <name, S, R, D, P, DP, CT, PF>, où : name est le nom symbolique de l implémentation )
S est la spécification de I
R = SR )R est l ensemble des ressources fournies de I, où SR est l ensemble des ressources fournies de S, et
IR = {r1, r2 rn}est l ensemble des ressources fournies définies par I D = SID )D est l ensemble des dépendances de I, où
SID = {d1, d2 dn est l ensemble des dépendances de S précisées par I : Soit SD l ensemble des dépendances de S
dSD, d = <id, target, cardinality, dCT, dPF> SID : id id d est l identificateur de la dépendance d target target d est la destination de d
cardinality = <min, max> est la cardinalité de d, où min min d max max d min max dCT est l ensemble des contraintes de d, dCT d dCT dPF est l ensemble des préférences de d, dPF d dPF
ID = {d1, d2 dn est l ensemble des dépendances définies par I, tel que chaque dépendance di est un 5-uplet d = <id, target, cardinality, dCT, dPF> P = SP SIP )P est l ensemble des propriétés de I, où
SP est l ensemble des propriétés de S
SIP = {p1, p2 pn}est l ensemble des définitions de propriétés de S configurées par I : Soit SDP l ensemble des définitions de propriétés de S
pSIP, dp SDP :name(p) = name(dp)type(p) = type(dp) IP = {p1, p2 pn} est l ensemble des propriétés définies par I, tel que
chaque propriété pi est un 3-uplet p = <name, type, value>
DP = {dp1, dp2 dpn}est l ensemble des définitions de propriétés de I, où
chaque propriété dpi est un 3-uplet dp = <name, type, value>, où value est optionnel CT = SCT )CT est l ensemble des contraintes de I, où
SCT est l ensemble des contraintes de S, et )CT est l ensemble des contraintes définies par I PF = SPF )PF est l ensemble des préférences de I, où
SPF est l ensemble des préférences de S, et )PF est l ensemble des préférences définies par I L implémentation ) est conforme à la spécification S : I S
La Figure 54 montre deux implémentations différentes de la spécification MediaManager
présentée précédemment : ACME-MediaManager et ADELE-MediaManager. Elles possèdent donc les caractéristiques définies par la spécification MediaManager l interface fournie MediaManagerService, les spécifications requises MediaServer et MediaPlayer, et les propriétés provider et freeware.
3.M
ETAMODELE DE COMPOSANTS A SERVICES<implementation na me="ADELE-MediaManager" s pecification="MediaManager"
i nterfaces="media.servi ces.MediaRecorderService" classname="adele.media.manager.ADELEMediaManager"> <property na me="instantiable" va lue="false" />
<property na me="provider" va lue="ADELE" /> <property na me="freeware" va lue="true" />
<property na me="recorder" type="Boolean" va lue="true" /> <property na me="version" type="String" value="1.0.0" /> <definition na me="language" type="String" />
<dependency s pecification="MediaServer" i d="ms">
<interface fi el d="mediaServers" name="mediaServerServices" /> <constraints>
<implementation fi l ter="(streaming=true)" /> </constraints>
</dependency>
<dependency s pecification="MediaPlayer" i d="mp">
<interface fi el d="audioPlayer" name="audioPlayerService" /> <interface fi el d="videoPlayer" name="videoRecorderServi ce" /> </dependency>
<dependency s pecification="MediaRecorder" i d="mr" multiple="false"> <interface fi el d="audioRecorder" name="audioRecorderService" /> <interface fi el d="videoRecorder" name="videoRecorderService" /> <constraints>
<implementation fi l ter="(&(audio=true)(video=true))" /> </constraints>
</dependency> </implementation>
Figure 54. Implémentation de composant à services Exemple ADELE-MediaManager
Limplémentation ADELE-MediaManager est un MediaManager « standard » mais en plus, il
fournit des fonctionnalités pour l enregistrement programmé de médias à travers l interface
MediaRecorderService, requiert un service d enregistrement via la dépendance mr vers la spécification
MediaRecorder, définit les propriétés recorder et version, et la définition de la propriété language. La Figure 54 présente aussi la description XML de cette implémentation.
En récapitulant, les ressources fournies et requises, les propriétés et les définitions de propriétés,
les contraintes et les préférences d une implémentation sont les caractéristiques de tout composant à services qui l instancie
3.1.3 I
NSTANCEUne implémentation peut avoir diverses instances. Une instance appartient à une seule implémentation (voir la Figure 55).
Figure 55. Instance de composant à services
De même que la relation entre une implémentation et sa spécification, la relation instantiates
entre une instance et son implémentation est une relation de groupe : une implémentation représente le type de ses instances. Ainsi, les caractéristiques d une implémentation et par transitivité celles de sa
spécification, sont héritées par ses instances (ressources fournisses et requises, propriétés, contraintes et préférences). Une instance ne peut pas définir de capacités, de dépendances ou de propriétés propres. Toutefois, elle peut ajouter des contraintes et des préférences de sélection sur les dépendances héritées de son implémentation.
Grâce au mécanisme de groupes la validité d une instance i e la conformité et la cohérence de sa déclaration vis-à-vis de son implémentation) peut être assurée statiquement (lors de sa compilation, son packaging ou son déploiement Nous définissons formellement le concept d instance de la façon
suivante :
Une instance est un 7-uplet Inst = <name, I, R, D, P, CT, PF>, où : name est le nom symbolique de l instance )nst
) est limplémentation de Inst
R est l ensemble des ressources fournies de )nst égal à l ensemble des ressources fournies de ) D = InstSD InstD est l ensemble des dépendances de Inst, tels que
InstSD = {d1, d2 dn} est l ensemble des dépendances de ) précisées par )nst : Soit ID l ensemble des dépendances de I,
d = <id, target, cardinality, dCT, dPF> InstSD, d ID, tel que id id d target target d cardinality = cardinalityd dCT d dCT
dPF d dPF
InstD = ID\InstSD est l ensemble des dépendances de ) non précisées par )nst P = IP )nstP est l ensemble des propriétés de Inst, où
IP est l ensemble des propriétés de )
)nstP est l ensemble des définitions de propriétés de I ou de la spécification S de I configurées par Inst : Soient IDP l ensemble des définitions de propriétés de I, et
SDP l ensemble des définitions de propriétés de S(I) et
pInstP, dp : dp IDPdp SDP name(p) = name(dp)p IP : name(p) = name(p) CT est l ensemble des contraintes de Inst, égal à l ensemble des contraintes de )
PF est l ensemble des préférences de Inst, égal à l ensemble des préférences de ) L instance )nst est conforme à l implémentation ) : Inst I, et donc
3.M
ETAMODELE DE COMPOSANTS A SERVICES3.1.4 P
ROPRIETES PREDEFINIESLes trois types de composants à services spécification, implémentation et instance disposent
d un ensemble de propriétés prédéfinies et configurables qui caractérisent leur nature En général ces
propriétés sont affectées lors de la création/définition des composants. Le Tableau 9 présente les propriétés prédéfinies propres à chaque type de composant ainsi que leur sémantique.
Propriété Sémantique S p é c if ic a ti on Im p lé m e n ta ti
on instantiable [true | false]
Cette propriété indique si le composant (étant un représentant de groupe) est instanciable ou non. La valeur par défaut est false pour les spécifications, et true pour les implémentations.
multiple [true | false]
Cette propriété indique si le composant (étant un représentant de groupe) peut être résolu par plusieurs membres ou non i e si plus d une résolution est autorisée). La valeur par défaut est true.
singleton [true | false]
Cette propriété indique si le composant (étant un représentant de groupe) peut avoir plus qu un seul membre ou non La valeur par défaut est false.
In s ta n c e shared [true | false]
Cette propriété indique si le composant peut être utilisé par plusieurs consommateurs simultanément ou non. La valeur par défaut est true. Note : les spécifications et les implémentations peuvent être utilisées par plusieurs consommateurs simultanément : elles sont toujours partageables.
Tableau 9. Propriétés prédéfinies des composants à services primitifs
Ces propriétés permettent de contrôler leur résolution (pour les spécifications et les implémentations) et leur composition avant et/ou durant leur exécution.