WebSphere optimalizované místní adaptéry - WebSphere Optimized Local Adapters - Wikipedia

IBM WebSphere Optimized Local Adapters (OLA nebo WOLA) je funkční složkou IBM je WebSphere Application Server pro z / OS , který poskytuje účinný mechanismus mezipaměti pro volání jak příchozí do WAS z / OS, tak odchozí z z / OS. Protože se vyhýbá režii jiných komunikačních mechanismů, je schopen vysoké výměny zpráv. WOLA je rozšíření stávajícího mechanismu výměny mezi paměťmi systému WAS z / OS, přičemž WOLA poskytuje externí rozhraní, takže adresní prostory z / OS mimo server WAS z / OS se mohou účastnit výměn mezi paměťmi. WOLA podporuje připojení mezi serverem WAS z / OS a jedním nebo více z následujících: CICS, IMS, Batch, UNIX Systems Services a ALCS. WOLA byla poprvé zpřístupněna ve WAS z / OS verze 7, Fixpack 4 (7.0.0.4). Funkční vylepšení se objevila v následujících opravných balíčcích, jak je popsáno v tomto článku.

Dějiny

WebSphere Optimized Local Adapters for WAS z / OS (WOLA nebo OLA ve zkratce) má svůj původ ve snaze poskytnout efektivní příchozí volací mechanismus; to znamená od mimo the Java EE prostředí do něj vykonávat aktiva Java EE. Tento požadavek byl zvláště výrazný v systému z / OS, kde tradiční dávkové zpracování hledalo využití rostoucí základny programovacích prostředků založených na technologii Java EE a EJB.

Existovala i další příchozí řešení, například:

Zatímco každý měl své silné stránky; každý měl také své zvláštní nedostatky: režii a latenci; obtížnost konstrukce; nebo nedostatky v modelu zabezpečení nebo šíření transakce.

Toto byl původní návrhový bod optimalizovaných místních adaptérů. Architekti řešení rozšířili návrh o obousměrné vyvolání: příchozí do WAS z / OS z externího adresního prostoru a odchozí z WAS do externího adresního prostoru.

Technická nadace

Architekti tohoto řešení se rozhodli využít existující prvek designu WAS z / OS s názvem „local communications“, mechanismus mezipaměti používaný serverem WebSphere Application Server pro z / OS od dnů V4.x, který optimalizoval provoz IIOP mezi aplikacemi servery na stejném LPAR. OLA je v podstatě externalizací existujícího mechanismu křížové paměti, takže adresní prostory mimo WAS z / OS se mohou připojit a vyměňovat si zprávy ve sdíleném paměťovém prostoru.

Programy externího adresového prostoru přistupují k rozhraní OLA pomocí sady dodávaných API. Programy Java spuštěné v systému WAS z / OS přistupují k rozhraní OLA prostřednictvím implementace zabalené jako standardní adaptér prostředků JCA.

Aktuální podpora

Aktuálně podporovaná externí adresní prostory podporované pro WAS z / OS OLA jsou:

Programovací jazyky podporované v externích adresových prostorech jsou:

Java je programovací jazyk používaný pro přístup k OLA WAS z / OS z kontejnerů Java EE systému WAS z / OS.

Historie aktualizací funkcí

Podpora nových funkcí IBM WebSphere Optimized Adapters byla aktualizována při vydání nových verzí nebo opravných balíčků. Tato funkce byla poprvé zpřístupněna na úrovni FixPack 4 verze WAS z / OS verze 7, vydání 0 (7.0.0.4).

Funkční aktualizace, část 1
Funkční aktualizace, část 3

7.0.0.4

WOLA byla představena s balíčkem Fixpack 4 k produktu WAS z / OS verze 7, vydání 0. Výsledkem aplikace údržby byl nový adresář v souborovém systému produktu, který poskytoval moduly WOLA, sdílené objekty, adaptér prostředků JCA a knihovny vývojových tříd. Prostřednictvím skriptu prostředí (olaInstall.sh) byly vytvořeny nezbytné symbolické odkazy systému UNIX z běhového prostředí na souborový systém pro instalaci produktu.

Podporovaná funkce nabízená ve verzi 7.0.0.4 byla:

  • Podpora pro CICS, Batch, USS a ALCS
  • Jednofázové potvrzení pro odchozí WAS do CICS (2PC do CICS TS 4.1 poskytované s 7.0.0.12)
  • Dvoufázové potvrzení pro příchozí CICS do WAS
  • Nativní API
  • Adaptér zdroje JCA

7.0.0.12

Fixpack 12 na WAS z / OS verze 7, vydání 0 poskytl dvě aktualizace podpory WOLA:

  • Podpora WOLA a IMS
  • Dvoufázové zpracování transakcí potvrzení z WAS odchozí do CICS TS 4.1

8.0.0.0

Pokračující podpora produktu WebSphere Application Server pro z / OS verze 8, vydání 0 pro místní adaptéry WebSphere Optimized. WOLA byla dodána začleněna do produktu, což znamenalo, že spuštění olaInstall.sh již nebylo nutné k vytváření symbolických odkazů UNIX na soubory produktu. Kromě toho byly poskytnuty následující aktualizace funkcí:

  • Podpora více segmentů velkých zpráv (větší než 32 kB) pro práci s IMS
  • Podpora klasifikace příchozích transakcí volání WOLA odděleně od volání IIOP
  • Identifikace v záznamu SMF 120,9 pro volání WOLA spíše jako WOLA než IIOP
  • Identifikace selhání zdroje a alternativní převzetí služeb při selhání JNDI

Failover zdrojů a Failback

Tato funkce poskytuje prostředky k detekci ztráty datového zdroje připojeného k továrně připojení JCA a k automatickému přepnutí na definované alternativní JNDI. Detekce obnovení primárních datových zdrojů a navrácení služeb po obnovení je také prvkem tohoto funkčního návrhu. Návrh převzetí služeb při selhání prostředku je k dispozici na serveru WebSphere Application Server verze 8 napříč všemi platformami pro JDBC a JCA. WAS z / OS verze 8 poskytuje podporu převzetí služeb při selhání prostředků WOLA jako součást obecné podpory převzetí služeb při selhání prostředků JCA. K vyvolání převzetí služeb při selhání dojde, když dojde k konfigurovatelnému prahovému počtu selhání getConnection (). Po vyvolání převzetí služeb při selhání jsou všechny nové požadavky getConnection () směrovány do fondu připojení alternativní továrny připojení. K navrácení služeb dojde, když WAS z / OS určí, že se nezdařený primární zdroj dat vrátil. Nové požadavky getConnection () jsou zpracovávány proti továrně primárního připojení.

Běžný vzor použití pro tuto funkci je odchozí do CICS, kde je cílová oblast CICS směrovací oblastí. Tato funkce převzetí služeb při selhání poskytuje schopnost architektury více směrovacích oblastí, takže ztráta jakékoli jednotlivé směrovací oblasti neovlivní celkovou dostupnost CICS celkově.

Bylo přidáno několik vlastních vlastností fondu připojení k podpoře tohoto mechanismu převzetí služeb při selhání a mechanismu navrácení služeb po obnovení:

  • Prahová hodnota selhání - počet po sobě jdoucích selhání getConnection (), které musí nastat před vyvoláním automatického převzetí služeb při selhání
  • alternateResourceJNDIName - název JNDI továrny na alternativní připojení, který se má použít, pokud je vyvoláno automatické převzetí služeb při selhání
  • resourceAvailabilityTestRetryInterval - interval v sekundách, který WAS používá k testování návratu primárního zdroje

Poznámka: pro tuto funkci existují další vlastní vlastnosti fondu připojení. Vyhledejte řetězec „cdat_dsfailover“ v informačním centru WAS z / OS a získáte úplný seznam.

8.0.0.1 / 8.5.0.0

Poznámka: WAS z / OS 8.5.0.0 poskytuje podporu WOLA funkčně shodnou s 8.0.0.1

Balíček Fixpack 1 na server WebSphere Application Server pro z / OS verze 8 poskytl následující funkční aktualizace pro WOLA:

  • 64bitové volané nativní API pro programy C / C ++ pracující v 64bitovém režimu
  • SMF 120 podtyp 10 záznamů pro WOLA odchozí volání z WAS (SMF 120 podtyp 9 zachycuje informace o příchozím hovoru)
  • Work Distribution - schopnost zaokrouhlovat odchozí hovory napříč několika externími registracemi se stejným názvem
  • Podpora proxy pro vzdálený přístup - má dvě formy: příchozí a odchozí

64bitové volané nativní moduly API

Před 8.0.0.1 byly nativní moduly API dodávány pouze v 31bitovém volatelném formátu. Tyto moduly měly čtyřmístnou předponu BBOA * spojenou s každým názvem modulu.

S 8.0.0.1 jsou k dispozici jak 31bitové, tak 64bitové volané moduly API. 31bitové moduly zachovávají čtyřmístnou předponu BBOA * pro každý název modulu. 64bitové moduly nesou pro každý název modulu čtyřmístnou předponu BBGA *.

Počet API zůstává stejný jako dříve: 13 specifických API. Použití je stejné jako dříve.

Hledání v InfoCenter: cdat_olaapis

SMF 120,10 pro odchozí hovory WOLA

Ve WAS z / OS V7 byla podpora WOLA pro SMF omezena na příchozí pouze hovory. Příchozí volání WOLA do cílových EJB v kontejneru WAS z / OS byla identifikována jako volání IIOP a zachycena SMF jako volání IIOP, nerozeznatelná od jakéhokoli jiného volání IIOP. K zachycení informací o příchozím volání byl použit normální záznam WAS z / OS SMF 120 podtypu 9 (nebo 120,9 ve zkratkové notaci).

U WAS z / OS 8.0.0.0 byla upravena funkce záznamu a snímání SMF 120.9, aby bylo možné identifikovat příchozí volání WOLA odděleně od příchozích volání IIOP.

S WAS z / OS 8.0.0.1 byl vytvořen záznam SMF 120.10, který zachycuje informace o odchozí volání z WAS z / OS. Záznam SMF 120.10 má osm sekcí:

  • Informační část serveru neutrální na platformě
  • Informační sekce serveru z / OS
  • Sekce s informacemi o odchozích požadavcích
  • Specifická část typu WOLA Outbound Request
  • Sekce kontextu transakce odchozího požadavku
  • Sekce kontextu zabezpečení odchozího požadavku
  • Oddíl požadavku na odchozí požadavek CICS
  • Sekce specifická pro odchozí požadavek OTMA

Pro každý odchozí požadavek je vytvořen jeden záznam.

Hledání v InfoCenter: rtrb_SMFsubtype10

Distribuce práce

Tato funkční aktualizace poskytuje možnost distribuovat odchozí volání mezi více externích adresních prostorů registrovaných na daném serveru WAS z / OS pomocí stejného registračního názvu. Běžným vzorem použití by bylo více oblastí CICS s nasazenou stejnou cílovou programovou službou bez státní příslušnosti. Byla vytvořena nová proměnná prostředí, která označuje požadovaný typ distribuce práce. Následující ukazuje použití této funkce:

OLA Work Distribution.jpg

Hledání v InfoCenter: cdat_olacustprop

Podpora proxy: Příchozí a odchozí

Mezipaměťová povaha komunikace WOLA znamená, že server WAS z / OS a externí adresový prostor musí být na stejné logické části z / OS (LPAR). WAS z / OS 8.0.0.1 poskytuje funkci proxy, která umožňuje oddělené umístění volajících WOLA a cílů WOLA. To zahrnuje umístění v instancích operačního systému jiných než z / OS. Tato funkce má dva formáty: podpora proxy pro odchozí volání a podpora proxy pro příchozí hovory.

Podpora proxy pro odchozí hovory

To poskytuje mechanismus, kterým mohou aplikace Java používat dodávaný adaptér prostředků WOLA JCA pro přístup k cílovému adresnímu prostoru na vzdáleném systému z / OS. Příkladem vzorce použití by byl vývoj nebo test navrhované aplikace. Přístup k mezipaměťovému připojení WOLA v cílovém systému z / OS zajišťuje dodávaná aplikace proxy WOLA nainstalovaná na serveru WAS z / OS povoleném pro WOLA. Následující obrázek ilustruje topologii:

OLA Proxy odchozí volání.jpg

Tok sítě z aplikace do systému WAS z / OS probíhá prostřednictvím IIOP. Továrna připojení WOLA je informována o tomto toku IIOP k proxy prostřednictvím několika nových uživatelských vlastností do fondu připojení. Aplikace proxy ve WAS z / OS přijme hovor a předá jej přes skutečné připojení WOLA mezi paměťmi k pojmenované cílové službě.

Tato topologie má ve srovnání s odchozím voláním WOLA na stejném LPAR z / OS omezení: globální transakce vyžadující dvoufázové potvrzení nelze šířit přes připojení IIOP k proxy WOLA a identitu uživatele ve vlákně WAS nelze uplatnit do cílová služba v systému z / OS.

Podpora proxy pro příchozí hovory

To poskytuje mechanismus, kterým mohou aplikace jiné než Java v externím adresovém prostoru provádět příchozí volání do cílového EJB s povoleným WOLA ve vzdálené instanci WAS, a to buď na jiné LPAR z / OS nebo distribuované platformě WAS. Ke zpracování počátečního volání WOLA napříč paměťmi a jeho předání pojmenovanému cílovému EJB ve vzdálené instanci WAS je vyžadována stejná dodaná aplikace proxy WOLA nainstalovaná v místní instanci WAS z / OS. Následující obrázek ilustruje topologii:

OLA Proxy Inbound Calls.jpg

Cílová EJB s povolenou WOLA neví, že se proxy používá. Příchozí tok přichází jako volání IIOP, stejně jako v případě, že byla použita křížová paměť WOLA na stejném LPAR. Volající program musí označit, že tok bude používat službu proxy. To se provádí parametrem na BBOA1INV (nebo BBOA1SRQ) 2 pro parametr requesttype. To řekne místní aplikaci proxy, aby považovala požadovanou službu, která je zadána jako název JNDI cílového EJB, za požadavek na vyvolání EJB pomocí IIOP. To vyžaduje, aby místní a vzdálené instance WAS měly mezery federovaných jmen nebo fungovaly jako jedna buňka, aby vyhledávání JNDI proběhlo úspěšně.

8.0.0.3 a 8.0.0.4 / 8.5.0.1

Ve verzi 8.0.0.3 (a 8.5.0.1) je součástí produktu IBM Integration Designer for BPEL Processes podpora WOLA.

V 8.0.0.4 (a 8.5.0.1) byla podpora aktualizována, aby zahrnovala kontextové tvrzení transakcí RRS z oblastí závislých na IMS do WAS over WOLA:

  • Aplikace v IMS používají nastavit příznak „transakce podporována“ na registru API
  • Cílové prostředí WAS má nastavenou a povolenou proměnnou prostředí ola_rrs_context_propagate = 1
  • IMS Control Region musí běžet s RRS = Y

8.0.0.5 (a 8.5.0.2)

Fixpack 8.0.0.5 / 8.5.0.2 poskytl dvě funkční vylepšení: (1) RRS transakční kontextové tvrzení z WAS do IMS přes WOLA / OTMA a (2) vylepšená podpora pro kanály a kontejnery CICS.

Transakce IMS:

  • IMS Control Region musí běžet s RRS = Y
  • Cílové prostředí WAS má nastavenou a povolenou proměnnou prostředí ola_rrs_context_propagate_otma = 1

Pro vylepšenou podporu pro kanály a kontejnery CICS byla před verzí 8.0.0.5 / 8.5.0.2 podpora kanálů a kontejnerů CICS omezena na jeden kanál s pevným názvem pro požadavek i odpověď a jeden kontejner typu BIT nebo CHAR. S 8.0.0.5 / 8.5.0.2:

  • Odesílejte a přijímejte jeden nebo více kontejnerů z cílového programu CICS
  • Název kanálu nastavíte pomocí metody setLinkTaskChanID ()
  • Typ kanálu nastavujete pomocí metody setLinkTaskChanType ()
  • Názvy jednotlivých kontejnerů požadavků se nastavují přidáním dat do MappedRecord pomocí metody put ().
  • Klíče MappedRecord odpovídají názvům kontejnerů CICS a odpovídající hodnota se použije k vyplnění kontejneru v CICS.
  • Názvy kontejneru odpovědí budou z kanálu extrahovány po dokončení požadavku CICS a naplněny do nového MappedRecord, který je vrácen klientovi.

Součásti

Optimalizované místní adaptéry lze rozdělit do následujících komponent:

  • Moduly rozhraní - poskytovat programový přístup k rozhraní OLA a API OLA
  • CICS Ukončení uživatele související s úkolem, propojení serveru úloh a řízení transakcí - poskytuje zjednodušený mechanismus pro podporu odchozích volání do programových aktiv v CICS.
  • JCA Zdrojový adaptér - poskytuje rozhraní mezi prostředím Java a externím prostředím
  • Podpora vývojových nástrojů - poskytuje podpůrné třídy pro vývoj aplikací podporujících OLA
  • Vzorky - sada vzorků C / C ++, COBOL a Java, které ilustrují použití programovacího modelu

Přehled podpory CICS

Optimalizované místní adaptéry jsou v CICS implementovány jako uživatelský výstup související s úkolem (TRUE). To je to, co poskytuje základní připojení z křížové paměti CICS k adresnímu prostoru WAS z / OS.

Kromě toho je pro volání z WAS do CICS poskytována úloha Link Server (BBO $) a Link Invocation Task (BBO #). Úloha serveru BBO $ / BBO # chrání specifika programování před programy CICS. Volání OLA z WAS je zpracováno těmito zadanými úkoly a pojmenovaný program CICS je vyvolán standardem EXEC CICS LINK volání. Pojmenovaný program CICS zůstává nezměněn a neví, že hovor přišel z WAS pomocí OLA. Cílový program v CICS musí být možné vyvolat voláním LINK. Oba COMMAREA[je zapotřebí objasnění ] a Kanály / Kontejnery je podporován.

WOLA-Link-Server.jpg

Transakce BBOC je také dodávána, aby poskytla sadu řídicích příkazů k provádění věcí, jako je ruční spuštění TRUE (pokud není v PLTPI), zastavení TRUE, spuštění a zastavení Linkového serveru a dalších řídicích a řídících funkcí.

Datová sada knihovny modulu OLA programovacího rozhraní musí být zřetězena s příkazem DFHRPL DD oblasti CICS.

Následující obrázek shrnuje podporu WOLA CICS pro šíření transakcí a prosazování zabezpečení:

CICS-TX-Sec.jpg

Přehled podpory IMS

Optimalizované místní adaptéry jsou implementovány jako externí subsystém pro IMS. Použití je podporováno pro programy pro zpracování zpráv (MPP), programy pro dávkové zpracování zpráv (BMP), IMS Fast Path (IFP) a Batch DL / I aplikace.

Hovory z IMS do WAS využívají zařízení pro připojení externího subsystému (ESAF). Toto je stejné rozhraní, jaké používají jiné subsystémy, jako je DB2 nebo MQ.

Hovory z WAS do oblasti závislé na IMS lze provádět pomocí OTMA nebo přímo (tj. Program v IMS používá OLA API k „hostování služby“, jak je popsáno níže). OTMA poskytuje transparentnost OLA aplikacím IMS za cenu určité režie. Použití rozhraní OLA API v aplikaci IMS snižuje režii, což vede k lepšímu výkonu a propustnosti.

WOLA-IMS-Overview.jpg

Programovací rozhraní API pro IMS jsou stejná formát a syntaxe jak bylo původně představeno. Byly však aktualizovány, aby si byly vědomy IMS, pokud tam běží, a aby používaly ESAF.

Dále musí být soubor ola.rar, který implementuje adaptér prostředků JCA pro WAS, ten, který je dodáván s balíčkem Fixpack 7.0.0.12 nebo novějším, aby mohl být použit s IMS. Parametry metody byly aktualizovány pro podporu IMS a tato aktualizace je WAS zpřístupněna přeinstalováním souboru ola.rar, který je dodáván s 7.0.0.12.

Následující obrázek shrnuje podporu WOLA IMS pro šíření transakcí a prosazování zabezpečení:

IMS-TX-Sec3.jpg

Úvahy o programování

Příchozí do WAS z / OS

Externí adresový prostor přistupuje k mechanismu OLA prostřednictvím dodaných modulů rozhraní a dokumentovaných API. V současné době existuje 13 API. Jsou kategorizovány níže.

Programy Java spuštěné v prostředí WAS z / OS, které chtějí být cílem vyvolání zvenčí, musí implementovat rozhraní OLA v fazole relace bez státní příslušnosti pomocí souborů třídy OLA dodaných v podpoře vývojových nástrojů.

Odchozí z WAS z / OS

Program Java, který si přeje zahájit odchozí volání OLA, může být implementován buď jako servlet nebo EJB. Programy Java kódují dodaný adaptér prostředků JCA (ola.rar) pomocí souborů třídy dodaných v podpoře vývojových nástrojů.

Externí adresní prostory, které jsou cílem odchozího hovoru, musí být ve stavu připraveném přijmout hovor. Existují dva základní modely:

  • Pokud je prostorem externích adres CICS, pak má uživatel možnost použít zadanou úlohu serveru Link, aby fungovala jako přijímající agent jménem existujících aktiv programu CICS. Úkol serveru Link Server (ve výchozím nastavení BBO $) přijme volání a vydá PROVEDENÍ CICS LINK programu pojmenovaného naactionSpecImpl.setServiceName (). Nejsou nutné žádné změny stávajícího programu CICS za předpokladu, že podporuje buď COMMAREA, nebo Channels / Containers.
  • Pokud je externí adresou IMS, lze hovor uskutečnit pomocí rozhraní IMS OTMA (což neznamená žádnou změnu vaší aplikace IMS) nebo přímo pomocí OLA (což znamená použití OLA API v programu IMS k „hostování služby“ ).
  • Pokud je externí adresový prostor něco jiného než CICS nebo IMS, musí program „hostovat službu“ pomocí jednoho z dodaných API. Tím se program dostane do stavu připraveného přijmout hovor z programu Java ve WAS z / OS. Když je hovor přijat, může potom zpracovat požadavek a poskytnout odpověď zpět do programu Java ve WAS z / OS

Synchronní a asynchronní operace

API podporují oba režimy. Synchronní poskytuje jednodušší programovací model, protože řízení programu se nevrací volajícímu programu, dokud není přijata odpověď. Asynchronous poskytuje architektovi příležitost zpracovat další práci, aniž by musel čekat na odpověď vracející se z dlouho běžícího cílového procesu.

Modulární design

Je možné navrhnout programové artefakty specifické pro OLA, které budou sloužit jako „mosty“ mezi rozhraním OLA a existujícími aktivy. To slouží k minimalizaci dopadu na stávající programovací prostředky a omezuje míru „uzamčení platformy“.

  • Odchozí do CICS - použijte poskytnutou implementaci Link Serveru; žádné změny vašich programů CICS vůbec.
  • Příchozí do WAS - vytvořte EJB, který převezme volání OLA, poté se otočí a zavolá zadaný EJB. Pokud je cílový EJB ve stejném JVM, pak může být vysoce efektivní. Pokud je cílový EJB ve stejné buňce na stejném LPAR, použije se dříve uvedená funkce „místní komunikace“.

API

Existuje 13 API rozdělených do následujících kategorií:

  • Obecné nastavení a Teardown - BBOA1REG (registrace) a BBOA1URG (zrušení registrace)
  • Příchozí základní - BBOA1INV (vyvolat s automatickou odezvou)
  • Příchozí pokročilé - BBOA1CNG (získat připojení), BBOA1SRQ (odeslat požadavek), BBOA1RCL (získat délku odpovědi), BBOA1GET (získat data zprávy), BBOA1CNR (uvolnit připojení)
  • Odchozí základní - BBOA1SRV (hostitel služby), BBOA1SRP (odeslat odpověď)
  • Odchozí pokročilé - BBOA1RCA (příjem při připojení libovolném), BBOA1RCS (příjem při konkrétním připojení), BBOA1GET (získání údajů o zprávě), BBOA1SRP (odeslání odpovědi) a BBOA1SRX (odeslání výjimky)

InfoCenter má úplný seznam všech, seznamy parametrů a návratový kód (RC) a kódy příčiny (RSN). Hledat na cdat_olaapis.

Ilustrace společných vzorů API

Běžný příchozí Model využití API by byl:

Jednoduchý

V tomto případě se rozhraní BBOA1REG API používá k registraci do skupiny démonů WebSphere Application Server pro z / OS (krátký název buňky) a k vyvolání cílového EJB se použije více vyvolání BBOA1INV. BBOA1INV je synchronní takže řízení programu je drženo, dokud EJB nevrátí odpověď. Toto API je užitečné, když volající program předem zná velikost zprávy s odpovědí. Pokud je velikost zprávy odpovědi v době volání neznámá, pak by byly vhodnější primitivnější API (BBOA1SRQ (požadavek na odeslání), BBOA1RCL (délka odpovědi), BBOA1GET (data zprávy)).

Když volající program zjistí, že dokončil svou práci, použije BBOA1URG k odhlášení ze skupiny Daemon.

Pokud má cílový program Java delší interval odezvy než asynchronní model je pravděpodobně lepší. Následující obrázek ukazuje, jak by se asynchronní volání uskutečnilo pomocí takzvaného primitivní API: BBOA1SRQ se sadou parametrů async = 1:

OLA Pokročilejší příchozí API.jpg

Jak ukazuje obrázek, asynchronní režim umožňuje programu, který není Java, získat kontrolu a provádět další zpracování. To znamená kontrolu odpovědi v určitém budoucím bodě. K tomuto účelu se používá BBOA1RCL. V tomto příkladu je vydán BBOA1RCL synchronně (parametr async = 0). Pokud je k dispozici odpověď, BBOA1RCL poskytne délku a návrat řízení programu do programu. Pokud není k dispozici žádná odpověď, BBOA1RCL drží ovládání programu, dokud není k dispozici jedna. BBOA1RCL s async = 1 vrátí x'FFFFFFFF ', pokud není k dispozici žádná odpověď; ovládání programu je okamžitě vráceno.

Další ilustrace pro odchozí lze najít v dokumentu WP101490 na webu IBM Techdocs.

Poznámka: Odchozí z WAS do CICS by ne vyžadují kódování API. V takovém případě by toto zpracování provedly transakce se serverem poskytnutým BBO $ / BBO #. Tyto transakce propojovacího serveru „hostují službu“ pomocí interních konstruktů podobných API BBOA1SRV. Odchozí do dávkového programu by vyžadovalo použití rozhraní API k „hostování služby“.

Transakčnost

Optimalizované místní adaptéry podporují zpracování dvoufázového potvrzení (2PC) z příchozích CICS do WAS.

S příchodem údržby 7.0.0.12 podporují adaptéry Optimized Local také dvoufázové odchozí potvrzení z WAS do CICS. Před 7.0.0.12 byla transakční podpora z WAS do CICS omezena na „synchronizaci při návratu“.

Pro IMS byla v balíčku oprav 8.0.0.4 a 8.5.0.1 poskytována podpora pro transakční tvrzení příchozí do WAS z oblastí závislých na IMS. Transakční tvrzení odchozí z WAS do IMS přes WOLA / OTMA poskytované v balíčku oprav 8.0.0.5.

Transakční šíření není podporováno příchozí ani odchozí do dávkového, USS nebo Airlines Line Control.

Bezpečnostní

Optimalizované místní adaptéry jsou schopné prosadit identitu za následujících okolností:

  • WAS -> CICS: Identitu ve vlákně WAS použitém k volání rozhraní WOLA API lze použít k prosazení identity do CICS. K tomu je nutné použít odkazový server WOLA CICS a spustit jej s parametrem SEC = Y a oblast CICS musí běžet s SEC = YES a ID, pod kterým běží úloha odkazového serveru, musí mít oprávnění SURROGAT SAF pro zahájení transakcí jménem šířeného ID uživatele. Další podrobnosti najdete v IBM InfoCenter.
  • WAS -> Batch, USS nebo ALCS: neprovádí se žádný pokus o prosazení identity. Cílový proces běží pod identitou použitou při jeho spuštění.
  • CICS -> WAS: CICS může uplatnit své ID regionu nebo ID uživatele aplikace
  • Batch, USS or ALCS: The external process will try to assert its identity into WAS z / OS.

Omezení

Optimalizované místní adaptéry WAS z / OS lze použít pouze v rámci daného LPAR. Jedná se o mechanismus křížové paměti a nemůže procházet mezi LPAR nebo mimo stroj.

externí odkazy