Migration von EJB und EJB-Prozessbindings

EJB und EJB-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 Aufruf eines EJB ermöglicht. Beachten Sie, dass dieser Bindingtyp für Mikroprozesse nicht optional war – er wurde immer ausgewählt, wenn das generierte EJB intern von den anderen Bindingtypen verwendet wurde.

Der JNDI-Name des generierten EJB wurde automatisch als eine Kombination aus BPEL-Name, Zielnamensbereich sowie 'Gültig ab'-Zeitmarke generiert. Die folgenden Attribute können beispielsweise durch Überprüfung der BPEL-Prozesseigenschaften im BPEL Editor auf den Registerkarten 'Beschreibung' und 'Serverinhalt' gefunden werden:

Tabelle 1. Generierter Namensbereich
Prozessname MyService
Zielnamensbereich http://www.example.com/process87787141/
Gültig ab Jan 01 2003 02:03:04

Der generierte Namensbereich für dieses Beispiel lautet daraufhin com/example/www/process87787141/MyService20030101T020304.

In WebSphere Studio Application Developer Integration Edition gab es keine Optionen zur Auswahl, wenn EJB-Binding als Implementierungstyp ausgewählt wurde.

Es gibt vier Optionen für die Migration des WebSphere Studio Application Developer Integration Edition-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 2. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
EJB Client, der die generierte Session-Bean aufruft. Ein solcher Client ruft eine EJB-Methode auf, die der aufzurufenden BPEL-Operation entspricht Migration des EJB Client
WSIF Client, der das EJB Prozessbinding verwendet Migration des EJB-Prozessbinding-Client
Generischer Geschäftsprozess-Choreographer EJB API Migration des generischen Geschäftsprozess-Choreographer EJB API Client
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 EJB Client
Migration des EJB-Prozessbinding-Client
Migration des generischen Geschäftsprozess-Choreographer EJB API Client
Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client

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