Interopérabilité entre des événements de portlets JSR 286 et des portlets coopératifs JSR 168

Par nature, les portlets coopératifs sont similaires à des événements de portlets JSR 286. Les deux concepts décrivent des modèles de communication de publication/abonnement basés sur les informations publiées et reçues par des portlets, puis propagées via des liaisons.

Comme les concepts sont assez identiques, le portail supporte l'échange de données entre des portlets coopératifs JSR 168 et des portlets JSR 286 supportant des événements. Par conséquent, vous pouvez étendre une configuration existante avec des portlets coopératifs JSR 168 avec de nouveaux portlets JSR 286, puis faire progressivement migrer des portlets coopératifs individuels vers la nouvelle API sans perdre de possibilités de communication.

Le tableau suivant répertorie les similitudes :

Tableau 1. Similitudes entre des événements et des portlets coopératifs
Aspect de similitude	Cooperative portlets	Evénements JSR 286
Déclaration d'événement	dans un descripteur de déploiement WSDL	comme élément de `portlet.xml`
Envoi de données	comme conséquence d'un traitement, par exemple en définissant un attribut de demande déclaré comme propriété de sortie	à l'aide de l'appel d'API de portlet `setEvent()` sur une action ou une réponse d'événement
Réception de données	comme action du portlet avec des propriétés d'entrée, par exemple des paramètres de demande	en utilisant le rappel `processEvent()` d'API de portlet

Ecriture de portlets interopérables

Dans les deux modèles, les portlets déclarent leur entrées et sorties externes pour les mettre en correspondance en vue de la communication. Les sorties et les entrées sont mises en correspondance en fonction d'un nom qualifié XML associé à un espace de nom XML pour le rendre unique. Pour les portlets JSR 286, les informations de correspondance se distinguent par le nom d'événement, alors que pour les portlets coopératifs, la correspondance se fait selon le type de données XML déclaré ou référencé dans le langage WSDL. Par ailleurs, les entrées et les sorties véhiculent des données possédant un type de données de langage Java spécifique.

Par conséquent, il est possible de connecter une action de portlet coopératif à un événement de traitement JSR 286 si ces deux conditions sont remplies :

Le nom du type XML de la propriété de sortie de l'action correspond au nom ou à un alias de l'événement de traitement.
Le type Java de la propriété de sortie est identique à celui de la charge de l'événement de traitement.

Vous pouvez connecter un événement de publication JSR 286 à une action de portlet coopératif si ces deux conditions sont remplies :

Le nom ou un alias de l'événement de publication correspond au nom du type XML de la propriété d'entrée de l'action.
Le type Java de le charge de l'événement de publication est identique à celui de la propriété d'entrée.

Ces règles ont aussi les implications suivantes :

Un événement JSR 286 sans type Java associé (sans déclaration <value-type>) ne peut pas être connecté à un portlet coopératif.
Les types de données échangées doivent être des types primitifs ou sérialisables Java et JAXB (comme JSR 286 l'exige) et déployés dans un chargeur de classe partagé (car les portlets coopératifs ne supportent pas la conversion de paramètres entre chargeurs de classe).

Exemple de migration de descripteurs de déploiement

Le langage WSDL du portlet coopératif suivant déclare une action de portlet OrdersForMonth qui prend un nom de mois comme entrée et génère un ID de commande et un ID de client comme sorties.

   <definitions name="OrderDetail_Service"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  targetNamespace="http://www.ibm.com/wps/c2a/examples/shipping"
  xmlns:shipping="http://www.ibm.com/wps/c2a/examples/shipping"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
  <xsd:schema targetNamespace="http://www.ibm.com/wps/c2a/examples/shipping">
    <xsd:simpleType name="MonthType">
      <xsd:restriction base="xsd:string"/>

    </xsd:simpleType>
    <xsd:simpleType name="OrderIDType">

      <xsd:restriction base="xsd:string"/>

    </xsd:simpleType>
    <xsd:simpleType name="CustomerIDType">

      <xsd:restriction base="xsd:string"/>

    </xsd:simpleType>
  </xsd:schema>
</types>
<message name="OrderMonthRequest">
  <part name="order_month" type="shipping:MonthType"/>
</message>
<message name="OrderMonthResponse">
  <part name="order_Id" type="shipping:OrderIDType"/>
  <part name="customer_Id" type="shipping:CustomerIDType"/>
</message>
<portType name="OrderMonth_Service">
  <operation name="order_Month">
     <input message="shipping:OrderMonthRequest"/>
     <output message="shipping:OrderMonthResponse"/>
  </operation>
</portType>

<binding name="OrderMonthBinding" type="shipping:OrderMonth_Service">
  <portlet:binding/>
  <operation name="order_Month">
    <portlet:action name="OrdersForMonth" type="standard"/>
    <input>
      <portlet:param name="month" partname="order_month" class="java.lang.String"/>
    </input>
    <output>
      <portlet:param name="orderId" partname="order_Id"/>
      <portlet:param name="customerId" partname="customer_Id"/>
    </output>
  </operation>
</binding>
</definitions>

Le portlet conteneur peut être converti en portlet JSR 286 montrant le même comportement externe. Chaque action avec une propriété d'entrée devient un événement de traitement pouvant être envoyé au portlet. Chaque propriété de sortie d'une action devient un événement de publication pouvant être émis par le portlet. Le comportement de connexion peut être conservé en déclarant un alias pour chaque événement portant le même nom que le type de données WSDL du paramètre d'entrée ou de sortie correspondant : par exemple, l'événement customerId.published déclare un alias shipping:CustomerIDType pour être connecté à un événement de traitement ou une action de portlet acceptant un ID de client comme entrée.

<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
xmlns:shipping="http://www.ibm.com/wps/c2a/examples/shipping"
version="1.0"> 
<portlet ...>
...
   <supported-processing-event>
      <qname>shipping:OrdersForMonth</qname> 
   </supported-processing-event>
   <supported-publishing-event>
      <qname>shipping:orderId.published</qname>
   </supported-publishing-event>
   <supported-publishing-event>
      <qname>shipping:customerId.published</qname>
   </supported-publishing-event>
</portlet>
<event-definition>
  <qname>shipping:OrdersForMonth</qname> 
  <alias>shipping:MonthType</name>
  <value-type>java.lang.String</value-type>
</event-definition>
<event-definition>
  <qname>shipping:orderId.published</qname> 
  <alias>shipping:OrderIDType</name>
  <value-type>java.lang.String</value-type>
</event-definition>
<event-definition>
  <qname>shipping:customerId.published</qname> 
  <alias>shipping:CustomerIDType</name>
  <value-type>java.lang.String</value-type>
</event-definition>
</portet-app>

Remarque :

Le fait que les propriétés du portlet coopératif utilisent java.lang.String comme type de données et que les événements correspondants doivent être déclarés avec <value-type>java.lang.String dépend uniquement de l'attribut class="java.lang.String" de l'élément <portlet:param>WSDL. Si aucun attribut classe n'existe, java.lang.String est aussi utilisé comme valeur par défaut. Les déclarations de type XML dans le langage WSDL ne sont pas utilisées pour déterminer le type Java d'une propriété.
La déclaration des actions du portlet coopératif n'autorise pas plusieurs paramètres d'entrée. Les actions ou les événements qui demandent plusieurs entrées doivent à la place être déclarés avec une seule propriété d'entrée composée ou charge d'événement regroupant toutes les données requises.