Migration von JMS und JMS-Prozessbindings

JMS und JMS-Prozessbindings können zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition hat dieser Bindingtyp Clients die Kommunikation mit einem BPEL-Prozess oder anderen Servicetyp durch Senden einer Nachricht an ein MDB ermöglicht. Beachten Sie, dass dieser Bindingtyp für Prozesse mit langer Laufzeit nicht optional war und immer ausgewählt war. Tatsächlich war dieser Bindingtyp der einzige Bindingtyp, der für Request-Response-Schnittstellen von Prozessen mit langer Laufzeit zulässig war. Bei andere Servicetypen würde eine MDB generiert werden, die den entsprechenden Service aufruft.

Der vom JMS Binding verwendete JNDI-Name war eine Kombination aus BPEL-Name, Zielnamensbereich sowie 'Gültig an'-Zeitmarke.

In WebSphere Studio Application Developer Integration Edition gab es die folgenden Optionen zur Auswahl, wenn JMS Binding als Implementiertyp für einen BPEL-Prozess ausgewählt wurde:
  • JNDI Verbindungsfactory - Standard ist jms/BPECF (dies ist der JNDI-Name der Verbindungsfactory-Warteschlange des Geschäftsprozesscontainers
  • JNDI-Zielwarteschlange - Standard ist jms/BPEIntQueue (dies ist der JNDI-Name der internen Warteschlange des Geschäftsprozesscontainers)
  • JNDI Provider URL: Vom Server bereitgestellt oder benutzerdefiniert - Sie müssen eine Adresse eingeben. Standard ist iiop://localhost:2809
Es gibt fünf Optionen für die Migration des WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding. Die Clienttypen, die auf den Service zugreifen, bestimmen, welche der unten aufgelisteten Migrationsoptionen durchgeführt werden:
Anmerkung: Wenn die manuellen Migrationsschritte abgeschlossen sind, muss der Client ebenso zum neuen Programmiermodell migriert werden. Weitere Informationen finden Sie im entsprechenden Thema für die folgenden Client-Typen:
Tabelle 1. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
WSIF Client, der JMS-Prozess-Binding verwendet Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client
Generischer Geschäftsprozess-Choreographer EJB API Migration des generischen Geschäftsprozess-Choreographer EJB API Client
Migration des Unternehmens durch generische Geschäftsprozess-Choreographer-Nachrichtenübertragungs-API Migration des generischen Geschäftsprozess-Choreographer Messaging API Client
Ein weiterer BPEL-Prozess im gleichen Modul N/V: BPEL-Komponenten mithilfe des Assembly-Editor verbinden
Ein weiterer BPEL-Prozess in einem anderen Modul N/V: Einen 'Import mit SCA-Binding' im Referenzmodul erstellen, und dessen Binding mit dem Verweis auf 'Export mit SCA-Binding', das Sie weiter unten in Option 1 erstellt haben, konfigurieren
Wenn der Geschäftsprozess einen Verweis an sich selbst außerhalb seines Moduls übergibt (über einen Serviceverweis), müssen Sie immer der untenstehenden Option 1 folgen (Sie können jederzeit mehr als eine dieser Optionen durchführen), um einen Export mit SCA-Binding für den Geschäftsprozess durchzuführen. Es kann nur ein Geschäftsprozess pro Modul seinen Serviceverweis außerhalb des Moduls übergeben, da sein Export als der Standardexport des Moduls markiert sein muss. Dies geschieht durch Angabe von "true" für das Attribut namens "default" eines Exports, wie in:
Standardendpunktverweis
Sie müssen den Export dieses Geschäftsprozesses manuell als Standard markieren, indem Sie mit der rechten Maustaste auf den Export in der Ansicht 'Geschäftsintegration' klicken und 'Öffnen mit' sowie 'Texteditor' auswählen.
Zugehörige Tasks
Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client
Migration des generischen Geschäftsprozess-Choreographer EJB API Client
Migration des JMS Client

Feedback
(C) Copyright IBM Corporation 2005, 2006. Alle Rechte vorbehalten.