Kommunikation unter Verwendung von Connection-Interfaces

Die Connection-Interfaces stellen verschiedene Funktionen bereit, die bei der Kommunikation einer EJB mit einer EIS-Anwendung einzeln oder kombiniert verwendet werden können:

• Dialogbasierte Kommunikation (basiert auf den Interfaces EISConnection, EISOltpConnection und EISUpicConnection)

• Asynchrone Kommunikation (basiert auf dem Interface EISConnection und auf weiteren Methoden des Interfaces EISOltpConnection)

• Transaktionale Kommunikation

• Connection Groups

• Code-Konvertierung

Die folgenden Abschnitte enthalten Informationen zu diesen Themen. Beispiele der am meisten verbreiteten Kommunikations-Szenarien werden in der JavaDoc zu BeanConnect beschrieben.

Dialogbasierte Kommunikation

Die empfohlene Kommunikation zwischen einer EJB und einer EIS-Anwendung verwendet die Methoden des Interfaces EISConnectionOltpMessage. Über dieses Interface werden Objekte des Typs OltpMessage mit der EIS-Anwendung ausgetauscht. Das Objekt OltpMessage dient als Container für den Nachrichteninhalt, der sich aus einem oder mehreren OltpMessageRecord-Objekten und/oder aus einem oder mehreren
OltpMessagePart-Objekten zusammensetzt. Während ein OltpMessageRecord beliebig lang sein kann, darf die Länge eines OltpMessagePart 32767 Bytes nicht übersteigen.

Die Daten, die gesendet werden sollen, werden zwar zum Zeitpunkt des Aufrufs von sndOltpMessage() sofort an BeanConnect übergeben, aber noch nicht zur EIS-Anwendung transferiert. Das tatsächliche Senden einer Anforderung an die EIS-Anwendung geschieht, wenn die erste rcvOltpMessage()-Methode für diese Verbindung aufgerufen wird.

Am einfachsten lässt sich ein Dialog-Service in einer EIS-Anwendung mit der Methode call() aufrufen. Diese Methode ermöglicht eine RPC-ähnliche Kommunikation mit einer EIS-Anwendung.

Die folgenden Abschnitte geben einen Überblick über die Kommunikation zwischen einer EJB und einem UTM-/CICS-Programm mit Hilfe von OltpMessage-Objekten.

Die unten aufgelisteten Optionen stehen für den Datenaustausch zwischen einer EJB und einem UTM-/CICS-Programm mit OltpMessage-Objekten zur Verfügung:

• Auf OltpMessagePart-Objekten basierender Datenaustausch

• Auf OltpMessageRecord-Objekten basierender Datenaustausch

Weitere Beispiele für verbreitete Kommunikations-Szenarien sowie Code-Beispiele finden Sie in der JavaDoc zu BeanConnect.

Auf OltpMessagePart-Objekten basierender Datenaustausch bei UTM-Partnern

Mit MGET und MPUT kann ein UTM-Programm eine oder mehrere Nachrichtenteile senden oder empfangen. Die Nachrichtenteile dürfen dabei die Größe von 32 KB nicht überschreiten. Hier entsprechen die einzelnen MessagePart-Objekte genau den MGET- und MPUT-Aufrufen im UTM-Programm.

Der Datenaustausch läuft daher gemäß dem folgenden Schema ab:

EJB		UTM-Partneranwendung
create OLTP message ... addMessagePart(...) addMessagePart(...)
call(...)		MGET MGET
		MPUT MPUT MPUT
getMessageParts(...) read part 1 read part 2 read part 3

Bild 61: Auf OltpMessagePart-Objekten basierender Datenaustausch bei UTM-Partnern

Auf OltpMessagePart-Objekten basierender Datenaustausch bei CICS-Partnern

Mit RECEIVE und SEND kann ein CICS-Programm eine oder mehrere Nachrichtenteile senden oder empfangen. Die Nachrichtenteile dürfen dabei die Größe von 32 KB nicht überschreiten. Hier entsprechen die einzelnen MessagePart-Objekte genau den RECEIVE- und SEND-Aufrufen im CICS-Programm.

Der Datenaustausch läuft daher gemäß dem folgenden Schema ab:

EJB		CICS-Partneranwendung
create OLTP message ... addMessagePart(...) addMessagePart(...)
call(...)		RECEIVE                                        RECEIVE
		SEND SEND SEND
getMessageParts(...) read part 1 read part 2 read part 3

Bild 62: Auf OltpMessagePart-Objekten basierender Datenaustausch bei CICS-Partnern

Auf OltpMessageRecord-Objekten basierender Datenaustausch

Statt mehrerer MessagePart-Objekte können Sie innerhalb eines OltpMessage-Objekts auch OltpMessageRecord-Objekte versenden. Als Java-Programmierer können Sie in diesem Fall Nachrichten senden und empfangen, die größer als 32 KB sind, d.h. Sie müssen sie nicht in 32-KB-Pakete aufteilen.

EJB		UTM-Partneranwendung
create OLTP message ... addMessageRecord(...)
call(...)		MGET-Schleife bis zum Empfang aller Nachrichtenabschnitte
		MPUT MPUT MPUT
getMessageRecords(...) read record

Bild 63: Auf OltpMessageRecord-Objekten (OSI TP Protokoll) basierender Datenaustausch bei UTM-Partnern

EJB		CICS-Partneranwendung
create OLTP message ... addMessageRecord(...)
call(...)		RECEIVE-Schleife bis zum Empfang aller Nachrichtenabschnitte
		SEND SEND SEND
getMessageRecords(...) read record

Bild 64: Auf OltpMessageRecord-Objekten basierender Datenaustausch bei CICS-Partnern

Bei der Kommunikation mit einer UTM-Anwendung über das UPIC-Protokoll können Sie OltpMessageRecord-Objekte und OltpMessagePart-Objekte verwenden, wenn Sie mit unterschiedlichen Formatnamen arbeiten.

EJB		UTM-Partneranwendung
create OLTP message ... addMessageRecord("FORMAT1",...) addMessageRecord("FORMAT2",...)
call(...)
		MGET-Schleife bis zum Empfang aller Nachrichtenabschnitte mit KCRMF/kcrfn="FORMAT1" MGET-Schleife bis zum Empfang aller Nachrichtenabschnitte mit KCRMF/kcrfn="FORMAT2"
		MPUT mit KCFM/kcfn="*FORMATA" MPUT mit KCFM/kcfn="*FORMATA" MPUT mit KCFM/kcfn="*FORMATA" MPUT mit KCFM/kcfn="*FORMATB" MPUT mit KCFM/kcfn="*FORMATB"
getMessageRecords(...) read record 1 Alle Daten der drei MPUT-Aufrufe mit *FORMATA wurden empfangen. Formatname kann von OLTPMessageRecord mit getMapName() gelesen werden. read record 2 Alle Daten der zwei MPUT-Aufrufe mit *FORMATB wurden empfangen. Formatname kann von OLTPMessageRecord mit getMapName() gelesen werden.

Bild 65: Auf OltpMessageRecord-Objekten (UPIC-Protokoll) basierender Datenaustausch

Asynchrone Kommunikation

Ein Service wird als asynchron bezeichnet, wenn er keine Reply Message sendet.

Das Senden einer Asynchron-Nachricht muss explizit durch die EJB mit den Methoden snd() + flush(), sndLast() oder sndLastString() des Interfaces EISConnection ausgelöst werden, welche die Nachricht abschließen und den Sendezyklus initiieren.

Eine Asynchron-Nachricht kann entweder sofort oder aber verzögert an den EIS Partner übertragen werden. Für eine verzögertes Senden muss die EJB die Verzögerungszeit vor dem Aufruf der Methode snd() festlegen. Die Verzögerungszeit legen Sie mit der Methode setDelayTime() fest. Eine verzögerte Nachricht wird für die Dauer der Verzögerungszeit vom BeanConnect Proxy gespeichert. Nach Ablauf dieser Zeit wird die Nachricht an die EIS-Anwendung weitergeleitet.

i

Eine in einer Transaktion erzeugte asynchrone Nachricht wird nur dann gesendet, wenn die Transaktion erfolgreich beendet wird. Im Falle eines Rücksetzens der Transaktion wird die asynchrone Nachricht nicht gesendet. Eine außerhalb einer Transaktion erzeugte asynchrone Nachricht mit Zeitverzögerung 0 wird sofort gesendet.

Wenn Sie sicherstellen möchten, dass aktuell ein asynchroner Service angesprochen wird, können Sie dies mit der Methode getPartnerType() überprüfen. Oder Sie verwenden die Methode setDelayTime(0), die eine Exception auslöst, wenn unerwarteter Weise ein Dialog-Service angesprochen wird. Die Verwendung dieser Methoden ist allerdings mit einem gewissen Performance-Nachteil verbunden.

Beispiele für asynchrone Kommunikationen mit einem EIS Partner finden Sie in der JavaDoc zu BeanConnect.

Transaktionale Kommunikation

Während des Deployments einer Connection Factory muss die Property transactional eingestellt werden (siehe „transactional“ im Konfigurations-Properties für OSI TP / LU6.2 definieren ). Eine Connection Factory kann sowohl transaktionale als auch nicht-transaktionale Kommunikation unterstützen, sie kann aber auch auf nicht-transaktionale Kommunikation beschränkt sein:

• Wenn die Connection Factory transaktionale Kommunikation unterstützt, entscheidet die Laufzeitumgebung zu Beginn der Transaktion, ob für eine Conversation dieser Verbindung die Kommunikation transaktional ist oder nicht: Eine Conversation, die gestartet wird während eine Transaktion offen ist, wird immer in die Transaktion eingebunden.

  Eine Conversation, die beim Start der Transaktion bereits existierte, aber über die bis zu diesem Zeitpunkt noch keine Kommunikation erfolgte, wird ebenso in die Transaktion eingebunden. In diesen Fällen wird für die Kommunikation ein transaktionales Protokoll, in allen anderen Fällen ein nicht transaktionales Protokoll verwendet.
   

• Folgendes gilt, falls die Connection Factory keine transaktionale Kommunikation unterstützt: Für Verbindungen, die mit dieser Connection Factory erzeugt wurden, wird immer ein nicht-transaktionales Protokoll verwendet. Dabei spielt es keine Rolle, ob die Kommunikation inner- oder außerhalb der Application Server Transaktion stattfindet. Dies ermöglicht dem Deployer des Resource Adapters, einen EIS-Service ausdrücklich von einer Transaktion auszuschließen, die im Application Server aktiv sein könnte.

Den aktuellen Transaktionsstatus können Sie mit der Methode isInDistributedTransaction() des Interfaces EISOltpConnection abfragen.

Wenn ein transaktionales Protokoll für die Kommunikation verwendet wird, sind die Transaktionen im Application Server und im EIS Partner Teil einer einzigen, verteilten Transaktion, die als eine Einheit vor- oder zurückgesetzt wird. Bei transaktionaler Kommunikation darf sich eine Conversation nicht über mehr als eine Transaktion erstrecken. Eine Conversation kann jedoch mehr als einen Dialogschritt umfassen. Somit können innerhalb einer Transaktion mehrere snd()/rcv()-Paare mit der EIS Partner ausgetauscht werden.

i	Wenn eine EJB innerhalb einer transaktionalen EJB-Methode mehr als eine transaktionale Verbindung verwendet, sollten diese Verbindungen unbedingt in einer EISConnectionGroup vereinigt werden (siehe „Connection Groups"). Auf diese Weise lässt sich eine Ressourcenverknappung vermeiden.

Connection Groups

Das Konzept der Connection Groups ermöglicht einer EJB, gleichzeitig mehrere Nachrichten über mehr als eine Verbindung zu senden. Somit können gleichzeitig mehrere Dialog-Services einer oder mehrerer EIS Partneranwendungen verarbeitet werden, ohne dass es zu einer Zeitverzögerung kommt, wie sie durch die sequentielle Verarbeitung von RPC-ähnlichen Aufrufen verursacht wird.

Mit Hilfe einer EISConnectionGroup können Sie eine Verbindung mit einer anderen Verbindung verknüpfen. Die EISConnectionGroup erstellen sie mit Hilfe einer EISConnectionGroupFactory. Eine EISConnectionGroupFactory erhält man mit der Methode getEISConnectionGroupFactory() von einer ConnectionFactory.

Beispiel:

ConnectionFactory cf1 = (ConnectionFactory)ic.lookup(...);
ConnectionFactory cf2 = (ConnectionFactory)ic.lookup(...);
EISConnectionGroupFactory cgf = cf1.getEISConnectionGroupFactory();
EISConnectionGroup cg = cgf.getConnectionGroup();
con1 = (EISOltpConnection)cf1.getConnection(cg);
con2 = (EISOltpConnection)cf2.getConnection(cg);

Ein Code-Beispiel finden Sie im Beispiel 16 auf Code-Beispiele für Outbound-Kommunikation .

Das gleichzeitige Senden der Nachrichten auf allen Verbindungen einer ConnectionGroup wird durch den Aufruf der Methode execute() am EISConnectionGroup-Objekt ausgelöst. Verbindungen für transaktionale Kommunikation können mit Verbindungen für nicht-transaktionale Kommunikation verknüpft werden. Weitere Einzelheiten hierzu finden Sie in der JavaDoc zu BeanConnect.

Code-Konvertierung

Wann immer String- oder ByteContainer-Objekte verwendet werden, kann BeanConnect eine Code-Konvertierung durchführen. Die Methoden für das Einrichten der ordnungsgemäßen Umgebung für eine Code-Konvertierung sind in dem Interface net.fsc.beanta.encoding.EncodingDef enthalten. Dieses Interface wird durch die EISConnection-Interfaces von BeanConnect erweitert. Wenn die Code-Konvertierung zum Deployment-Zeitpunkt noch nicht mit der Konfigurations-Property encodingActive aktiviert wurde (siehe „encodingActive“ im Konfigurations-Properties für OSI TP / LU6.2 definieren ), können Sie die Code-Konvertierung über die Methode setEncodingActive() einschalten. Die für eine Code-Konvertierung benötigte Code-Tabelle wird während des Deployments beim Definieren der Konfigurations-Property encoding zugeordnet (siehe „encoding“ im Konfigurations-Properties für OSI TP / LU6.2 definieren ) oder über die Methode setEncoding() des Interfaces EISConnection. Weitere Einzelheiten zur Code-Konvertierung von Nachrichten und zur Bereitstellung eigener Konvertierungstabellen finden Sie in Zeichensatz-Konvertierung und Sprachunterstützung ) und in der JavaDoc des Packages net.fsc.beanta.encoding.