Modèles de programmation d'appels

Ce modèle de programmation permet d'envoyer des messages sortants depuis une application IMS pour demander des services ou des données à des beans gérés par message (MDB), des composants EJB (Enterprise JavaBeans) ou des services Web, et éventuellement de recevoir des données de réponse.

Dans les modèles de programmation d'appel IMS, IMS agit comme client pour interagir avec les données ou la logique métier qui résident dans un bean MDB, un composant EJB ou un service Web. Les applications IMS invoquent les applications Java™ externes en émettant des demandes sous forme de messages sortants. A l'inverse, dans WebSphere Application Server, ces messages en provenance des applications IMS sont perçus comme des messages entrants.

Différents modèles de programmation peuvent être employés, selon qu'une réponse de l'application Java externe est attendue ou non par l'application IMS demanderesse, et selon que cette réponse est attendue dans la même transaction ou dans une autre.

Appel synchrone

Une demande d'appel synchrone est ainsi nommée parce que la réponse de l'application Java externe ou du service Web est supposée parvenir à la même application IMS dans la même transaction.

Lorsqu'une application IMS émet une demande synchrone en utilisant l'appel IMS DL/I ICAL, un tube de transaction (tpipe) OTMA est utilisé pour stocker la demande. L'application IMS dans la région dépendante reste planifiée et attend la réponse. Une fois que l'application externe a extrait le message de demande du tpipe, celui-ci est en état d'attente jusqu'à ce qu'une réponse soit renvoyée par l'application externe.

Dans le cas d'une application MDB (bean géré par message), vous pouvez tirer parti de la spécification J2EE Connector Architecture 1.5 et des multiples outils proposés dans les différents environnements de développement intégré (IDE) Rational ou WebSphere. L'adaptateur IMS TM Resource Adapter écoute les messages en provenance d'IMS Connect et gère la corrélation entre les demandes et leurs réponses.

Dans le cas d'une application non-MDB, il revient à celle-ci d'interroger périodiquement IMS Connect pour savoir si des demandes sont en attente dans la file de stockage temporaire. L'application doit aussi gérer le jeton de corrélation qui lui est passé comme propriété de la classe IMSInteractionSpec.

La présence de la demande sortante et de la réponse dans la même instance de transaction a pour principal avantage de permettre à la logique d'émission de la demande et à la logique de traitement de la réponse d'être contenues dans la même application IMS. Cette approche impose cependant à l'application IMS d'attendre la réponse ; les régions dépendantes sont donc bloquées pendant cette attente.

Appel asynchrone

Une demande d'appel asynchrone est ainsi nommée parce qu'elle n'attend pas de réponse ou, tout au moins, elle n'en attend pas dans la même transaction.

Lorsque l'application IMS émet une demande asynchrone en utilisant l'appel ISRT ALPCB, un tube de transaction (tpipe) OTMA ou une destination alternative (codée dans une routine d'exit) sont utilisés pour stocker la demande. Une fois que l'application externe a extrait le message de demande de la file de stockage temporaire, l'application IMS n'est plus planifiée dans la région dépendante IMS et cette dernière est ainsi libérée.

Si une réponse est attendue, le message de réponse revient sous la forme d'une nouvelle demande de transaction IMS, avec les données de sortie, destinée à la même application IMS ou à une autre application, selon la façon dont est conçue votre application.

Le principal avantage d'un renvoi asynchrone de la réponse est qu'il évite de bloquer les régions dépendantes et ainsi de verrouiller trop longtemps des ressources IMS. En revanche, cette approche exige que, si une réponse doit être traitée, l'application IMS doit être conçue de manière à pouvoir gérer la sortie dans une instance distincte de transaction. Il revient aussi à l'application de corréler la réponse et la demande.


Vos commentaires