Obtention d'un proxy pour un autre composant de service

Un composant SCA peut appeler le service proposé par un autre composant SCA. Le service que fournit un composant est constitué de toutes ses méthodes publiques. SCA pour PHP propose deux méthodes pour que les composants s'appellent les uns les autres : soit localement (i.e., via le même exécutable PHP, et avec la même pile), ou bien à distance, via un service Web.

Afin qu'un composant en appelle un autre, le composant d'appel a besoin d'un proxy jusqu'au composant appelé. Ce proxy est généralement fourni sous forme de variable dans le composant appelant, même si les proxy peuvent être obtenu via la fonction SCA::getService()(). Quand un composant est construit, les proxy sont constitués pour toute variable d'instance qui fait référence à un autre composant, et ces proxy sont injectés dans les variables. Les proxy sont toujours utilisé, que le composant soit distant ou locale, afin de propose une interface d'appel identique, quelque soit la localisation des composants. Les proxy savent comment localiser un composant, et leur passer les appels.

Les variables d'instance qui sont destinées à contenir les proxy sont identifiées par deux annotations PHPDocumentor : @reference et @binding. Ces deux annotations sont rangées dans la section de documentation d'une classe, tel que le montre le code ci-dessous.

L'annotation @reference pour une variable d'instance indique que la variable doit être initialisée avec un proxy de composant.

L'annotation @binding prend deux formes : @binding.php et @binding.soap. Elles indiquent que le proxy est soit local, soit un service Web distant, respectivement. Pour les deux @binding.php et @binding.soap, l'annotation indique l'URI cible.

A ce moment, avec la méthode de spécification des dépendances via les annotations, le seul moyen de modifier la cible d'une référence est de modifier l'annotation dans le composant.

Dans notre exemple, la variable $exchange_rate est initialisée avec un proxy vers le composant ExchangeRate, à chaque fois qu'une instance de ConvertedStockQuote est construite.

Pour @binding.php, l'URI identifie la localisation du script qui contient l'implémentation du composant. Le composant sera appelé localement. Le service fournit est un jeu de méthodes publiques dans le composant. L'URI doit être un simple chemin, absolu ou relatif. Le composant sera chargé avec une fonction include de PHP, après avoir vérifié que le composant n'est pas chargé, avec class_exists(). Si l'URI est relative, elle est résolue relativement au composant qui contient l'annotation. Notez que cela est différent du comportement habituel de PHP, où les scripts cherchent les fichiers dans l'include_path. Ceci est nécessaire pour fournir une indépendance de localisation dans les références.

Si ce service ExchangeRate était distant, et qu'il était appelé comme un service Web, seule la ligne @binding aurait changé. Au lieu de donner la localisation d'une classe PHP, il faudrait donner la localisation d'un fichier WSDL, décrivant un service Web. Dans notre exemple de composant, ceci est illustré par la seconde référence :

Le composant StockQuote sera appelé comme un service Web. Dans ce cas, l'URI du WSDL peut être un simple chemin, ou utiliser un gestionnaire de flux PHP, et commencer, par exemple, avec file:// ou http://. Dans l'événement où c'est un simple chemin de fichiers, il peut être absolu ou relatif, et dans le cas d'un chemin relatif, il sera résolu relativement au fichier qui contient l'annotation. Notez que c'est le même comportement que pour @binding.php, et que c'est différent du comportement habituel de PHP.