Génération de code sortant WOLA (WebSphere Optimized Local Adapters)

Les adaptateurs WOLA peuvent être utilisés pour appeler des applications s'exécutant dans un espace d'adresses externe sous z/OS. Pour des performances optimales, ces applications doivent s'exécuter en local, sous la même image de z/OS. Les adaptateurs WOLA supportent également l'appel d'applications sous z/OS depuis une application s'exécutant sur un serveur WebSphere Application Server réparti. Cela s'appelle le mode distant, ou développeur.

Pourquoi et quand exécuter cette tâche

Important : Les beans J2C sont formellement pris en charge et testés sur les serveurs WebSphere Application Server. Leur utilisation dans d'autres environnements Java™ devrait être possible, mais les tests effectués à ce titre n'ont pas été très poussés. Si un problème se présente au niveau du code généré et que ce problème peut être isolé en tant que tel au sein d'un environnement WebSphere Application Server, le support sera assuré.

Voici les manières dont vous pouvez appeler des applications sortantes dans WebSphere Application Server avec WebSphere Optimized Local Adapters.

Appel d'applications Batch/UNIX System Services

Les adaptateurs WOLA peuvent être utilisés pour appeler des applications batch et USS sous z/OS ayant été modifiées pour utiliser l'une des API de serveur WOLA.

Pourquoi et quand exécuter cette tâche

Les API receive request (BBOA1RCV) et host service (BBOA1SRV) WOLA permettent de rendre n'importe quelle application disponible pour les applications Java s'exécutant dans WebSphere Application Server, qui peuvent alors l'appeler avec des méthodes de style JCA. Pour plus d'informations sur l'utilisation de ces API, voir API des adaptateurs locaux optimisés pour z/OS.

Les applications s'exécutant sous z/OS dans CICS, IMS, USS ou en batch peuvent toutes utiliser les API WOLA pour s'établir comme serveurs WOLA et accepter les demandes de WebSphere Application Server.

Appel d'applications CICS existantes

Les adaptateurs WOLA peuvent être utilisés pour des appels sortants en conjonction avec le serveur de liaison CICS WebSphere Optimized Local Adapter.

Pourquoi et quand exécuter cette tâche

Le serveur de liaison WOLA est une application qui peut être lancée dans une région CICS et fonctionne comme serveur ou comme proxy pour les appels aux programmes CICS existants. Dans ce cas, l'application WebSphere Application Server appelle les programmes CICS non modifiés existants via une liaison EXEC CICS LINK avec soit une zone de communication (COMMAREA), soit un canal et un conteneur pour transmettre les données et obtenir la réponse.

Le mécanisme par défaut utilisé par WOLA pour transmettre un message à un programme CICS est la zone COMMAREA. Vous pouvez spécifier qu'un conteneur CICS délivre le message de demande et qu'un autre soit utilisé pour la réponse, à l'aide des propriétés de fabrique de connexions. Pour un conteneur de demande/réponse unique, vous définissez l'enregistrement de demande comme IndexedRecord contenant une seule entrée. Vous pouvez également spécifier que WOLA délivre plusieurs messages dans plusieurs conteneurs pour le nom de canal que vous fournissez, en utilisant des méthodes setter ou en indiquant que vous le demandez dans la fabrique de connexions. Pour des enregistrements multiples, vous fournissez un MappedRecord à WOLA pour l'appel sortant à CICS. Pour plus d'informations sur la prise en charge des canaux et des conteneurs CICS dans WOLA, voir Transactions WebSphere Application Server BBOC, BBO$, BBO#.

Procédure

Pour générer une implémentation prenant en charge des conteneurs CICS :

  1. Sur la page Importation de données, pour le nom de fichier du copybook COBOL, spécifiez le canal CICS WOLA COBOL vers Java.
  2. Pour le nom du canal CICS à utiliser, spécifiez un nom de conteneur de demande et de réponse.
  3. Facultatif : Vous pouvez ajouter plusieurs noms de conteneur et les associer au même canal. En faisant cela, vous fournissez un mappage (copybook) séparé pour chaque conteneur. Cette méthode est utile si vous utilisez un MappedRecord pour transmettre plusieurs conteneurs et obtenir plusieurs conteneurs en retour de l'application CICS.

Que faire ensuite

Pour des informations sur les propriétés de fabrique de connexions WOLA liées au serveur de liaison CICS WOLA, voir Considérations sur la fabrique de connexions pour les adaptateurs locaux optimisés. Pour plus de détails sur l'utilisation de WOLA avec les applications CICS, voir (Facultatif) Utiliser l'environnement CICS.

Appel d'applications IMS existantes

La troisième manière dont des appels sortants peuvent être effectués via WOLA est pour l'appel de transactions IMS existantes.

Pourquoi et quand exécuter cette tâche

La troisième manière dont des appels sortants peuvent être effectués via WOLA est pour l'appel de transactions IMS existantes. Pour cela, WOLA utilise l'interface appelable OTMA IMS. Une méthode setter dans la spécification de connexion et la fabrique de connexions WOLA indique qu'OTMA est utilisé. Les applications WebSphere Application Server doivent sélectionner un nom de serveur et un ID de groupe OTMA et elles doivent mettre leurs messages sous forme de messages IMS puis appeler l'adaptateur de ressources WOLA en sélectionnant OTMA comme protocole sous-jacent.

Formats de message pris en charge pour WOLA via OTMA

WOLA via OTMA prend en charge les messages multi-segments IMS.

Pourquoi et quand exécuter cette tâche

Les données de message de demande IMS pour WOLA via OTMA doivent être mises sous la forme IMS standard suivante : LLZZ ou LLLLZZ plus l'ID de transaction IMS (8 caractères) plus les données de message IMS.

Les données de message de réponse IMS de l'appel WOLA via OTMA peuvent être renvoyées sous la forme LLZZ plus les données de réponse ou LLLLZZ plus les données de réponse. Il vous est recommandé de passer en revue les options de configuration de WOLA via OTMA pour indiquer que vous utiliserez la forme LLZZ ou la forme LLLLZZ, et la prise en charge WOLA des messages de demande et de réponse ; ces paramètres peuvent être définis avec des méthodes setter dans la spécification de connexion ou avec des propriétés dans la fabrique de connexions.

Lorsque vous utilisez l'Importateur de données du plan de travail, inspectez le copybook COBOL ou la structure PL/I, voyez le format utilisé pour les messages de demande IMS (LLZZ ou LLLLZZ) et sélectionnez l'indicateur associé dans la fabrique de connexions WOLA (ou utilisez la méthode setter appropriée) qui correspond à ce format. Pour des détails sur les formats de message, voir Appel de transactions IMS existantes avec les adaptateurs locaux optimisés via OTMA. Pour des détails sur WOLA via OTMA, voir (Facultatif) Utiliser l'environnement IMS.

Propagation et assertion de données d'identification de sécurité depuis une adresse externe

WOLA prend en charge la propagation et l'assertion de données d'identification de sécurité d'un espace d'adresses externe au conteneur de bean Java WebSphere Application Server.

Pourquoi et quand exécuter cette tâche

Le fonctionnement varie selon le type de l'environnement externe (batch, CICS ou IMS). Pour les appels de WebSphere Application Server dans un environnement batch, les données d'identification de l'utilisateur ne sont pas propagées et le travail batch s'exécute toujours sous l'ID utilisateur de batch. Pour CICS et IMS, WOLA prend en charge la propagation et l'assertion de l'identité de l'utilisateur, mais vous devez utiliser le serveur de liaison CICS WOLA pour CICS et la prise en charge de WOLA via OTMA pour IMS. Pour plus d'informations sur cette implémentation, voir Sécurisation des adaptateurs locaux optimisés.

WOLA prend également en charge les transactions globales à validation en deux phases dans les deux sens entre WebSphere Application Server et CICS, et WebSphere Application Server et IMS. Pour plus d'informations sur WOLA et les transactions globales, voir Appel d'un bean enterprise depuis un espace d'adresses externe dans une transaction démarrée par un client.

Pour des informations sur WebSphere Application Server et les transactions globales IMS, voir Appel de transactions IMS existantes avec les adaptateurs locaux optimisés via OTMA.

Exécution d'applications WOLA depuis un serveur d'applications connecté à distance

En exécutant WOLA en mode développement ou distant, vous pouvez vous connecter à distance à un serveur WebSphere Application Server fonctionnant sur un autre système z/OS ou un serveur d'applications fonctionnant sur un système non-z/OS réparti.

Pourquoi et quand exécuter cette tâche

WOLA est une technologie locale et ses principaux bénéfices viennent de l'exécution de WebSphere Application Server z/OS au même endroit que vos applications existantes dans l'environnement CICS, IMS ou batch. Toutefois, vous pouvez utiliser l'adaptateur de ressources WOLA dans un serveur WebSphere Application Server se connectant à distance qui fonctionne sur un autre système z/OS ou sur un serveur d'applications fonctionnant sur un système non-z/OS réparti. Pour cela, vous devez exécuter WOLA en mode développement ou distant, et avoir installé l'application proxy WOLA dans le serveur WebSphere Application Server z/OS auquel se connecter pour accéder aux ressources z/OS. Le serveur WebSphere Application Server z/OS où s'exécute l'application proxy doit se trouver au même endroit que les applications z/OS visées en retour dans CICS, IMS ou en batch.

Avec le mode distant, vous pouvez utiliser le plan de travail et WebSphere Application Server, et déployer ou redéployer votre application sans avoir à effectuer de modifications dans le serveur WebSphere Application Server z/OS où s'exécute le proxy WOLA. Le recours à cette méthode peut être nécessaire pour le développement et le test de mises à jour d'application. Pour plus d'informations sur l'utilisation de WOLA en mode développement ou distant, voir Déploiement des adaptateurs locaux optimisés en mode développement

Génération d'une application d'appel sortant WOLA : exemples d'étapes

En imaginant un scénario où une application, s'exécutant dans un environnement quelconque, effectue un appel dans un espace d'adresses externe, voici les étapes et un exemple de code pour transférer les données d'un côté à l'autre pour la demande puis dans l'autre sens pour la réponse.

Procédure

  1. Sélectionnez Fichier > Nouveau > Autre > J2C.
  2. Cliquez sur WebSphere Optimized Local Adapter (IBM:2), puis sur Suivant.
  3. Sur la page Importation de connecteur, dans la zone Projet de connecteur, acceptez la valeur par défaut ola ; dans la zone Serveur cible, sélectionnez la version de WebSphere Application Server à utiliser, puis cliquez sur Suivant.
  4. Dans la page Style de l'adaptateur, sélectionnez Sortant, puis cliquez sur Suivant.
  5. Dans la boîte de dialogue Propriétés de connexion, entrez le nom JNDI pour la fabrique de connexions qui sera utilisée pour les appels sortants WOLA, puis cliquez sur Suivant.
  6. Sous Propriétés de sortie du bean Java J2C, entrez un nom de projet existant ou nouveau, un package et un nom d'implémentation d'interface à créer pour l'appel sortant, puis cliquez sur Suivant.
    1. Sur la page Projet Java, le nom entré pour le projet sur la page Nouveau bean Java J2C est affiché dans la zone Nom. Vérifiez qu'il est correct. Si le nom du projet n'est pas affiché, entrez-le dans la zone Nom.
    2. Dans la zone Nom, entrez un nom pour le projet Java. Pour modifier la valeur par défaut de l'Emplacement du projet, cliquez sur le bouton Parcourir pour sélectionner un nouvel emplacement.
    3. Dans la zone Environnement d'exécution cible, sélectionnez la version de WebSphere Application Server dans laquelle vous souhaitez déployer le projet. Cette sélection affecte les paramètres de compilation et d'exécution en modifiant les entrées de chemin de classe du projet.
      Remarque : Si vous spécifiez un nouveau nom de projet EAR, le projet est créé à l'emplacement par défaut avec le numéro de version Java EE le plus bas compatible avec la version du projet créé. Pour spécifier une autre version ou un autre emplacement pour l'application d'entreprise, utilisez l'assistant Nouveau projet d'application d'entreprise.
    4. Acceptez la version de module Java par défaut ou sélectionnez une version différente dans la liste. Si vous créez des applications entrantes J2C, vous devez sélectionner Java 3.0.
      Important : Si vous sélectionnez Java 3.0, l'assistant Java 3.0 crée par défaut une interface locale. Pour créer une interface distante, créez-la manuellement en ajoutant l'annotation @Remote(class= interface.java) au bean J2C.
    5. Dans la zone Configuration, acceptez la configuration par défaut ou cliquez sur Modifier et changez les facettes du projet.
    6. Pour ajouter le projet Java à un projet EAR, sélectionnez Ajouter le projet à un projet EAR.
    7. Choisissez le projet EAR auquel vous souhaitez ajouter le module Java ou entrez le nom d'un nouveau projet EAR dans la zone Nom du projet EAR, puis cliquez sur Suivant.
    8. Sur la page Module Java, dans la zone Dossier source, acceptez la valeur par défaut ejbModule ou entrez un autre nom de dossier source pour le projet Java, puis cliquez sur Suivant.
    9. Sur la page Configurer les paramètres du module Java, effectuez les opérations suivantes :
      1. Pour conserver les classes d'interface client pour les beans enterprise dans un fichier JAR de client Java séparé, cliquez sur Créer un module JAR de client Java pour les interfaces et classes clientes. Ce fichier JAR de client Java est ajouté à l'application d'entreprise en tant que fichier JAR utilitaire de projet.
      2. Dans la zone Nom, acceptez le nom par défaut du module JAR de client ou tapez un nom différent.
      3. Dans la zone URI du fichier JAR client, acceptez le nom par défaut du fichier JAR de client ou tapez un nom différent.
    10. Cliquez sur Terminer.
  7. Sur la page Propriétés de sortie du bean Java J2C,
    1. dans la zone Nom du projet Java, vérifiez que le nom de projet est correct ou entrez le nom de projet correct.
    2. dans la zone Nom du package, entrez le nom de votre package.
    3. dans la zone Nom Java de la session sans état, entrez le nom Java de votre session sans état.
    puis cliquez sur Suivant.
  8. Sur la page Méthodes Java, cliquez sur Ajouter pour créer une méthode Java.
  9. Sur la page Méthode EJB, dans la zone nom, entrez un nom pour la méthode Java.
    1. dans la zone Type d'entrée, cliquez sur Parcourir pour trouver une entrée ou sur Nouveau pour en créer une nouvelle.
      1. Sur la page Importation de données, dans la zone Choisir le mappage, sélectionnez COBOL vers Java.
      2. dans la zone Fichier COBOL, cliquez sur Parcourir et sélectionnez votre fichier COBOL, puis cliquez sur Suivant.
      3. Sur la page Importateur, sélectionnez z/OS dans la zone Plateforme, IBM-1047 dans la zone Page de codes, et la structure de données à utiliser dans la zone Structures de données, puis cliquez sur Suivant.
    2. Sur la page Sauvegarde des propriétés, assurez-vous que les valeurs pour la classe auxiliaire soient affichées, puis cliquez sur Terminer.
  10. Sur la page Méthodes Java, dans la zone Nom du service, entrez le nom du service WOLA cible. Il s'agit du nom que l'application de l'espace d'adresses externe doit avoir utilisé avec une API Receive Request ou Host Service WOLA. Si vous utilisez le serveur de liaison CICS WOLA, il s'agit du nom qui devra correspondre au nom de service ou au paramètre SVC de fourniture. Si vous utilisez WOLA via OTMA, il s'agit du nom de la transaction cible IMS. Cliquez sur Terminer.

Résultats

Exemple de classe Java

Voici un exemple d'implementation d'appel externe WOLA générée, créé avec le nom zCUSTCPY_Out. Il a été configuré pour utiliser le nom JNDI eis/ola et le nom de service cible ZCUSTGET. Ce code a été généré pour inclure une classe auxiliaire de liaison de données créée à partir d'un copybook COBOL avec une définition de niveau 01 nommée CUSTOMER.

   package com.ibm.rad.ola.test;
   import javax.resource.ResourceException;
   import javax.resource.cci.Connection;
   import javax.resource.cci.Interaction;
   import javax.resource.cci.ConnectionFactory;
   import javax.resource.cci.ConnectionSpec;
   import javax.resource.cci.InteractionSpec;
   import javax.resource.cci.Record;
   import javax.resource.cci.ResourceAdapterMetaData;
   
   
   /**
    * @j2c.connectionFactory jndi-name="eis/ola"
    * @j2c.connectionSpec class="com.ibm.websphere.ola.ConnectionSpecImpl"
    * @generated
    */
   public class ZCICSCustGetImpl implements com.ibm.rad.ola.test.ZCICSCustGet {
   
   	private ConnectionSpec typeLevelConnectionSpec;
   	private InteractionSpec invokedInteractionSpec;
   	private InteractionSpec interactionSpec;
   	private ConnectionSpec connectionSpec;
   	private Connection connection;
   	private ConnectionFactory connectionFactory;
   
   	/**
   	 * @j2c.interactionSpec class="com.ibm.websphere.ola.InteractionSpecImpl"
   	 * @j2c.interactionSpec-property name="serviceName" value="ZCUSTGET"
   	 * @generated
   	 */
   	public com.ibm.rad.ola.test.CUSTOMER zCUSTCPY_Out(
   			com.ibm.rad.ola.test.CUSTOMER arg)
   			throws javax.resource.ResourceException {
   				ConnectionSpec cs = getConnectionSpec();
   				InteractionSpec is = interactionSpec;
   				try {
   					if (cs == null) {
   						cs = getTypeLevelConnectionSpec();
   					}
   					if (is == null) {
   						is = new com.ibm.websphere.ola.InteractionSpecImpl();
   						((com.ibm.websphere.ola.InteractionSpecImpl) is)
   								.setServiceName("ZCUSTGET");
   					}
   				} catch (Exception e) {
   					throw new ResourceException(e.getMessage());
   				}
   				com.ibm.rad.ola.test.CUSTOMER output = new
					com.ibm.rad.ola.test.CUSTOMER();
   				invoke(cs, is, arg, output);
   				return output;
   			}
	
	< ... d'autres méthodes de génération suivent... >   

Pour utiliser cette classe, une application doit simplement créer un enregistrement CUSTOMER à transmettre en entrée et recevoir en sortie, puis créer une instance de zCUSTCPY_Out() pour effectuer l'appel externe via l'adaptateur de ressources WOLA à l'application cible.

Lors de l'installion de l'application utilisant ces outils, veillez à installer l'adaptateur de ressources WOLA et à créer une fabrique de connexions ayant le nom spécifié pour le nom JNDI (dans l'exemple, le nom JNDI est eis/ola). Vous devez également fournir le nom du registre WOLA dans la fabrique de connexions. Si vous utilisez WOLA via OTMA, fournissez le nom de serveur et le nom de groupe OTMA IMS dans la fabrique de connexions. Pour des informations sur les propriétés de fabrique de connexions WOLA liées au support WOLA via OTMA, voir Considérations sur la fabrique de connexions pour les adaptateurs locaux optimisés.


Commentaires