Représentation externe du COTS

Le COTS, dans notre étude, n’est qu’une boite noire qui offre des services ou, par fois, demande des services s’il en a besoin.

Un COTS n’est connu que par son interface, qui diffère d’un COTS à un autre. Tous nos COTS sont reliés à l’unité d’orientation (OR), cette dernière doit s’adapter avec chaque interface du COTS. Ce la signifier qu’il faut un connecteur adéquat pour chaque COTS. D’autre part, l’ajout d’un nouveau COTS nécessite un nouveau connecteur adéquat, et une adaptation de l’unité d’orientation pour ce nouveau COTS. Cet inconvénient dégrade considérablement notre solution, surtout du point de vu de la dynamique du système. Pour cela nous avons pensé à unifier toutes les interfaces des COTS. L’approche optée par les interfaces WSDL été la plus proche a notre cas, donc nos l’avons adopté sans trop réfléchi. De plus, cette architecture a un intérêt à la génération du code WSDL, qui sert comme enveloppe du COTS, puisqu’elle est proche de la technologie des services WEB, d’une part. D’autre part, les interfaces prennent le même modèle, c'est-à-dire les même fonctions à publier.

Le code suivant représenté l’interface du COTS en WSDL : <? xml version="1.0"?> <definitions name="Offre_service" targetNamespace="urn: serveur_orchestration " xmlns:typens="urn: serveur_orchestration " xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <!—Declaration de parametre de message --> <types>

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:serveur_orchestration"> <xsd:element name="Nom_cervice" type="xsd: string "/> <xsd:complexType name="Param">

<xsd:element name="Nom_param" type="xsd: string "/> <xsd:element name="Type_param" type="xsd: string "/>

<xsd:element name="Valeur_param" type="xsd:string"/> </xsd:complexType>

<xsd:complexType name="Table_param">

<xsd:element name="Set_param" WSDL:arrayType="xsd: Param[]"/>

</xsd:complexType>

<xsd:Type name="Reponse_pret" type="xsd:boolean"/> </types>

<!—assemblage de parametre, pour notre cas nous avons un seul parametre -->

<message name="demande_service">

<part name="Nom_cervice" type="xsd: Nom_cervice "/> <part name="Param" type="xsd: Table_param"/> </message>

<message name="reponse_service">

</message>

<!—décrire l’operation demande_pret" --> <portType name="Offre_service_port"> <operation name="Offre_service_op">

<input message="typens: demande_service "/> <output message="typens: reponse_service "/> </operation>

</portType>

<!-- Spécifie la liaison d’un <porttype> à aux protocole (SOAP, http GET/POST -->

<binding name="Offre_service_bind" type="typens: Offre_service_port ">

<soap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/> <operation name=" Offre_service_op ">

<input> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding>

<service name=" Offre_service">

<port name=" Offre_service_op " binding="typens: Offre_service_Bind">

<soap:address location="http:// Local_COTS.com "/> < !—URL comme exemple -- > </port>

</service> </definitions>

Dans cette interface nous voyons que le service offert par un COTS est devenu un paramètre de la fonction Offre_service. Donc pour appeler un service de COTS, on doit faire référence à l’URL du COTS mais pas au service lui-même.

nous avons choisi d’utiliser un tableau de trois champs pour représenter les paramètres nécessaires pour l’appel d’un service. Il va de même pour la réponse (Figure 28).

Figure 28 le tableau de paramètre utiliser par une interface WSDL

Maintenant, nous pouvons rédiger le style de notre COTS comme suite :

„ Le port offre_service prend la forme suivante

Type Type_demande_service is view( Nom_Service : string

Param : Sequence (view(nom : string; type: string; valeur : string))) Donc le port sera

In_P_demande_service is port with Connections

In: connection[Type_demande_service];

Protocol

Via In receive.

Le COTS prend le style composant/connecteur suivant

COTS_component is style extending ( component ) where Cammen

Ports

-- !pour les besoin des autres demandeur.

port_OR_COTS_Fournisseur_demande_service : in_P_demande_service

port_OR_COTS_Fournisseur_reponse_service : out_P_reponse_service

-- !pour les besoins du COTS.

port_COTS_OR_demande_service :

out_P_demande_service

port_COTS_OR_reponse_service :

in_P_reponse_service -- !pour les notifications

port_OR_UC_notification :

constraints

exists(port_OR_COTS_Fournisseur_demande_service); --! Les

deux ports (fournisseur)sont nécessaire, si

exists(port_OR_COTS_Fournisseur_reponse_service);

-- !est passif non le COTS, mais les deux autre s’ils n’existent pas , on dit que le COTS est autonome

every sequence {true*.<via

port_OR_COTS_Fournisseur_demande_service resive any>. (not<via port_OR_COTS_Fournisseur_reponse_service send any >)*.<via port_OR_COTS_Fournisseur_demande_service resive any >.true*} –-!

Il ne faut pas avoir une réponse avant une demande de service

leads to state{false})

forall(p |p in type P_demande_service;

implies

{via p resive D : Type_demande_service > and

D~ ID_repondeur_service != e.name} –-! il faut recevoir les requêtes

qui lui sont adressé

leads to state{false})