Mise en cache des services Web

Le moteur de services Web de WebSphere Application Server fournit un support de mise en cache, ce qui signifie qu'une requête de service Web peut être mise en cache et que la réponse mémorisée peut être renvoyée en lieu et place d'un traitement subséquent. Cependant, ce support de mise en cache repose sur une approche en "tout ou rien", tant pour la requête que pour la réponse.

Dans HCL Commerce, avec les opérations représentées par des commandes et le service de composition de JSP utilisé pour composer les résultats, les fonctions Dynacache des commandes cachables et la mise en cache des fragments JSP peuvent aussi servir comme moyen de mettre en cache des parties de la requête et de la réponse.

La mise en cache d'une commande invoquée par un service Web ne diffère pas de celle d'une commande invoquée par une demande URL. En fait, si la commande a déjà été configurée pour être mise en cache, l'infrastructure de services Web pourra en profiter. De même, les étapes nécessaires à la mise en cache de pages JSP ou de fragments JSP pour des services Web sont les mêmes que pour des demandes URL.

Pour les réponses JSP, considérons l'exemple suivant :


<ShowCatalog xmlns="http://www.openapplications.org/oagis/9" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.openapplications.org/oagis/9 ../../BODs/Developer/ShowCatalog.xsd" 
  languageCode="en-US" 
  versionID="normalizedString" 
  releaseID="normalizedString" 
  systemEnvironmentCode="Production">
  <jsp:include flush="true" page="ApplicationArea.jsp"/>
  <DataArea>
    <Show recordSetTotal="2" 
      recordSetStartNumber="2" 
      recordSetCompleteIndicator="false" 
      recordSetReferenceId="normalizedString" 
      recordSetCount="2">
      <UserArea/>
      </OriginalApplicationArea>
    </Show>
  <jsp:include flush="true" page="Show/Catalog.jsp"/>
  </DataArea>
</ShowCatalog>

Dans cet exemple, deux pages JSP distinctes sont incluses dans la réponse : ApplicationArea.jsp, qui peut être réutilisée dans d'autres réponses de service Web, et Show/Catalog.jsp.

Show/Catalog.jsp contient trois blocs XML, chacun représenté par un fragment JSP :


<Catalog>
  <jsp:include flush="true" page="CatalogHeader.jsp"/>
  <jsp:include flush="true" page="ClassificationScheme.jsp"/>
  <jsp:include flush="true" page="CatalogLine.jsp"/>
</Catalog>

Tous les fragments JSP pourraient être cachables, ou bien seulement certains d'entre eux ou aucun. Pour ceux qui le sont, il est possible de définir une stratégie afin de mettre en cache le contenu, de sorte qu'au prochain rendu d'un fragment JSP, la version utilisée soit celle qui est stockée en cache. Voici un exemple d'une telle stratégie :


<cache-entry>
  <class>servlet</class>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/CatalogHeader.jsp</name>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/CatalogLine.jsp</name>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/ClassificationScheme.jsp</name>
  <property name="save-attributes">false</property>

  <cache-id>
    <component id="catalogId" type="parameter">
      <required>true</required>
    </component>
  </cache-id>
        
  <dependency-id>catalogId
    <component id="catalogId" type="parameter">
      <required>true</required>
    </component>
   </dependency-id>
</cache-entry>

Dans cette définition de stratégie, les trois fragments sont cachables sur la base du paramètre catalogId figurant dans la demande. Ce catalogId est soit contenu dans la demande de service initiale, soit retourné par la commande exécutée consécutivement à la demande de service.

Dans l'exemple précédent, à la première exécution de la réponse du service avec le catalogId 123, chaque JSP est également exécuté. Parallèlement, les trois fragments sont stockés en cache, de sorte qu'à la prochaine demande incluant les mêmes fragments JSP pour le catalogId 123, les fragments ne sont pas à nouveau exécutés ; ce sont les versions mises en cache qui sont renvoyées à la place.