CZ381198A3

CZ381198A3 - Zajišťování komunikačních spojů v počítačové síti

Info

Publication number: CZ381198A3
Application number: CZ983811A
Authority: CZ
Inventors: Peter David Niblett; Karen Louise Randell
Original assignee: International Business Machines Corporation
Priority date: 1996-05-24
Filing date: 1997-05-19
Publication date: 1999-10-13
Also published as: KR20000010691A; US6336135B1; DE69731318D1; DE69731318T2; CN1219257A; HUP9902190A2; WO1997045798A1; GB2313524A; CN1117333C; PL329935A1; KR100275403B1; MY123071A; EP0978056A1; GB9610898D0; EP0978056B1; ES2227692T3; JP3578221B2; JPH11510632A; HUP9902190A3

Description

Oblast techniky

Vynález se týká vzájemného propojování datových komunikací a prostředků zpracovávajících data v síti a zejména zajišťování spojů mezi různými komunikačními prostředími.

Dosavadní stav techniky si mohly vyměňovat mohou být vzájemně

Počítačovou síť může tvořit libovolné množství počítačů, které jsou schopné vzájemné výměny informací. Počítače mohou být uspořádány v libovolné konfiguraci a mohou být umístěny ve stejné místnosti, nebo v různých zemích, pokud existuje způsob jejich vzájemného propojení {například pomocí telefonních linek nebo jiných komunikačních systémů) tak, aby informace. Stejně jako počítače propojeny, čímž tvoří síť, stejně tak mohou být vzájemně propojeny také sítě pomocí nástrojů nazvaných mosty a brány. Tyto nástroje umožňují počítači v jedné síti výměnu informací s počítačem v jiné síti. Internet je síť sítí, která nemá jednoho majitele ani regulátora a obsáhuje velké a malé, veřejné a soukromé sítě, ve které je jakýkoli připojený počítač, na kterém běží programové vybavení s internetovým protokolem s řídícími prvky zabezpečení, schopný výměny informací s libovolným jiným počítačem, který je také připojen k Internetu. Toto složené seskupení sítí,

76 328

J ····

φφ ·· · »· ··*· které souhlasí se vzájemným propojením, není založeno na jednom přenosovém médiu (dvousměrná komunikace muže například nastat satelitními spoji, optickými páteřním vedením, telefonním vedením, dráty kabelové televize a místními rádiovými spoji).

Internetová služba www je schopnost získávat informace z rozlehlých územních oblastí, která nabízí přístup k obrovskému množství informací, ke kterým lze přistupovat sítí, a která může nabídnout levnou komunikaci mezi Internetem propojenými počítači. Informace o www lze nalézt v publikaci „Spinning the Web, Andrew Ford (International Thomson Publishing, London 1995) a v publikaci „The World Wide Web Unleashed, John December a Neil Randall (SAMS Publishing, Indianapolis 1994). Použití www prudce narůstá kvůli kombinaci flexibility, přenositelnosti a snadnosti použití spojené se schopnostmi prezentace interaktivních multimédií. WWW umožňuje libovolnému počítači připojenému do Internetu, který má příslušnou softwarovou a hardwarovou konfiguraci, získat libovolný dokument, který byl zpřístupněn kdekoli na Internetu. Dokumenty, které je možné získat na www, obsahují dokumenty s „hymermédii - t j. dokumenty, které mohou být textové, nebo mohou mít formu jiného média, jako jsou zvuky a obrázky, a které obsahuji odkazy („hyperodkazy) na jiné dokumenty. Formát textových dokumentů na www je standardně formát HTML (jazyk Hypertext Markup Language), takže dokument vytvořený v jednom operačním systému a hardwarové platformě mohl být čten uživatelem na libovolné jiné platformě, která má www prohlížeč (viz. níže). Obrázky mohou být uloženy v oddělených grafických souborech , například ve standardním formátu GIF nebo JPEG, a může se na ně odkazovat v HTML textu, takže uživatel je vyzván k získání zadaných souborů

9« • 9 99 s obrázky stejně jako HTML textu.

Uživatel získává tyto informace pomocí www „prohlížeče nebo „www klienta, což se software instalovaný na počítači uživatele, který má schopnosti získávání a doručování dokumentů z www serveru Internetem. Momentálně dostupné www prohlížeče jsou například WebExplorer od IBM Corporation a Mosaic od NCSA. Tyto prohlížeče obsahují adresáře a prohledávací nástroje a rozumí formátu HTML a jiným standardním formátům a mohou správně zobrazovat nebo posílat na výstup soubory v těchto formátech. Uživatelské rozhraní těchto www prohlížečů je grafické rozhraní ve smyslu „ukaž a klepni {tj. položky lze volit přesunutím kurzoru po obrazovce a klepnutím na tlačítko myši). Www je strukturováno jako stránky nebo soubory, přičemž každá z nich má jednoznačný univerzální lokátor zdroje (URL). URL udává jak server, tak konkrétní soubor nebo stránku na tomto počítači. Uživatel může buďto zadat konkrétní URL, nebo skočit z jednoho URL na odkazované URL pomocí „hyperodkazů, to znamená, že slovo nebo symbol na stránce může být spojeno s jiným URL a lze jej zvolit, například klepnutím myši na příslušné místo, což způsobí, že prohlížeč získá a zobrazí požadovanou stránku. Na jednom serveru může být mnoho stránek a přidružené stránky, na které ukazují odkazy, mohou být umístěny na jiných serverech. Pokud URL začíná na „http:, pak to znamená, že soubor obsahuje hyperodkazy.

Pokud uživatel označí URL stránky v systému“ www serverů pomocí www prohlížeče, je tomuto serveru poslán jednorázový požadavek, přičemž server provede akci specifickou pro danou stránku. V mnoha případech server reaguje na požadavek získáním požadované stránky ,z databáze uložených stránek a vysláním HTML stránky zpět Internetem www klientovi, který •••'.A·

O acv.

jí zobrazí uživateli. Tato akce je prováděna v rozsahu jedné dvoubodové synchronní relace. To znamená, že prohlížeč pošle svůj požadavek a pak čeká na odezvu předtím,' než pokračuje dále ve zpracovávání nebo zahajování jiných požadavků. Říká se, že prohlížeč je „blokován nebo také „pozastaven v době, kdy čeká na odezvu na požadavek. V některých případech povede požadavek prohlížeče k tomu, že se na serveru spustí aplikace, která generuje HTML, ale opět jednorázový požadavek prohlížeče požaduje odezvu v rámci existující synchronní komunikační relace, protože prohlížeč nepočítá se současně probíhajícími komunikačními relacemi a mezi požadavky nejsou udržovány žádné informace o stavu aplikace. Selhání přístupu ke stránce požadované prohlížečem může být signalizováno uživateli pomocí chybové zprávy zobrazené na terminálu uživatele, pokud však server pouze pomalu reaguje, pak zůstává prohlížeč „pozastaven po nekonečně dlouhou dobu. Ve skutečnosti může uživatel zrušit pokus o komunikaci, pokud je pro něj zpoždění nepřijatelné. Www prohlížeče neobsahují schopnost automatického opakování požadavku.

Moderní podniky vyžadují schopnosti komunikace s jinými odděleními v podniku a s jinými podniky jako například se zákazníky nebo dodavateli, kteří mohou být v jiné zemi. Internetová www služba může nabídnut částečnou odpověď na takový požadavek, přičemž zajistí nákladově výkodné komunikační médium pro komunikaci uvnitř společnosti, avšak model internetové www služby s jednorázovým požadavkem a absence možnosti několika současných požadavků prohlížeče může představovat vážná omezení, v případě že požadované informace nejsou dostupné v přijatelném časovém období. Pro systém odesílatele je často nepřípustné být v pozastaveném stavu nekonečně dlouho a je nepřípustné pro úspěch

• *

kritických obchodních aplikací, aby závisely na tom, zda aplikace na serveru odpoví na požadavek včas. Internetová služba www nenabízí schopnosti zajištěné dodávky zpráv, což je požadavek mnoha kritických obchodních aplikací {to znamená, že aplikace potřebuje vědět, že zpráva, kterou poslala, nebude po cestě do cíle ztracena a že bude poslána pouze jednou). Obchodní aplikace mohou také obsahovat komunikaci používající mnoho dvojic požadavek-odezva a nedostatek informací o kontextu přenášených mezi požadavky www prohlížeče má za následek neschopnost přiřadit k sobě požadavky, které jsou součástí stejné obchodní aplikace.

Alternativní komunikační model k synchronnímu časově závislému modelu „požadavku a čekání na odezvu je model asynchronních zpráv. Program, který pošle zprávu přijímajícímu programu nemusí být blokován čekáním na odezvu od přijímače a může tudíž dále běžet a odesilatel a příjemce spolu nejsou synchronizováni. Asynchronní posílání zpráv mezi programy typicky používá fronty zpráv jako mezilehlý ukládací prostor, do kterého jsou umísťovány zprávy poté co jsou poslány prvním programem, a ze kterého mohou být získány přijímajícím programem, jakmile připraven. Mezi programy není žádné vyhrazené logické spojení. Po umístění zprávy do fronty může posílající program pokračovat v provádění jiných úloh, které mohou představovat také posílání zpráv jiným programům v síti. V oboru je známo zavádění systémů s asynchronním posíláním zpráv, které podporují komunikaci mezi programy heterogenními sítěmi a které chrání aplikační programy (které jsou napsány pro konkrétní prostředí svého operačního systému) před složitostí sítě a před nutností udržovat a prohledávat fronty se zprávami.

4*

Takovéto systémy s posíláním zpráv jsou důležité pro mnoho komerčních společností, které potřebují dosáhnout účinné komunikace mezi svými různými obchodními aplikačními programy, ale jejichž prostředky pro zpracovávání dat obsahují více neslučitelných prostředí operačních systémů a hardwaru.

Řazení zpráv do front a komerčně známé produkty pro řazení zpráv do front jsou popsány v „Messaging and Queing Using the MQI, B. Blakeley, H. Harris & R. Lewis, McGrawHill, 1994, a v následujících publikacích dostupných u společnosti IBM Corporation: „An introduction to Messaging and Queuing (číslo IBM dokumentu GC33-0805-00) a „MQSeries - Message Queue Interface Technical Reference (číslo IBM dokumentu SC33-0850-01). IBM a MQSeries jsou obchodní značky IBM Corporation. Programové produkty MQSeries od IBM pro zpracovávání zpráv nabízí transakční podporu pro zpracovávání zpráv, synchronizaci zpráv v logických jednotkách práce podle protokolu zpráv, která zajišťuje právě jedno doručení zprávy i v případě selhání systému nebo komunikace. Produkty MQSeries zajišťují zabezpečené doručování tím, že neodstraní definitivně zprávu z úložného média v systému odesilatele, dokud není potvrzeno její bezpečné uložení v systému přijímající aplikace s použitím složitých funkcí obnovy. Před potvrzením přenosu zprávy po schválení úspěšného uložení je ponecháváno „v nejistotě jak odstranění zprávy z úložného prostoru odesílajícího systému, tak i vložení do úložného prostoru přijímajícího systému a je možné obě akce v případě selhání navrátit atomicky do původního stavu. Tento protokol pro přenos zpráv a s ním spojené pojetí transakcí a schopnosti obnovy jsou popsány v mezinárodní patentové přihlášce WO 95/10805 a US patentu 5465328, které jsou zde zahrnuty odkazem.

* · 4 · 44

4 4 4«4< 4

4 4 4 ·

4444444 44 44

Je žádoucí přenést výhody asynchronního (offline, nespřaženého) zpracování do výpočetních prostředků, které jsou upraveny k synchronní komunikaci, jako jsou klientské systémy internetové www služby a obecně umožnit vzájemnou komunikaci mezi prostředky založenými na asynchronním modelu komunikace a prostředky založenými na synchronním modelu, přednostně bez vyžadování zásadních změn v existujících synchronních prostředcích. Je také žádoucí zjednodušit sledování průběhu asynchronních zpráv od synchronně připojeného klientského systému.

Kromě toho, že společnosti připojují své výpočetní prostředky do Internetu, zjišťují, že internetové standardy (internetový protokol, použití HTML, atd.) jsou s výhodou implementovány v „intranetu”, to znamená v počítačové síti v daném závodě, přičemž tato síť dodržuje standardy Internetu. Program prohlížeče je nyní dostupný pro použití v intranetech.

Výše uvedené požadavky jsou příkladem požadavků mnoha uživatelů prostředků zpracovávájících data na schopnost vzájemné komunikace mezi jejich rozdílnými prostředky bez ohledu na to, zda jsou uzpůsobeny pro různá prostředí nebo založeny na rozdílných komunikačních modelech nebo architekturách. Po aplikačních programech, které jsou napsané pro různé operační systémy, nebo založené na různých komunikačních modelech a vzorech, stejně jako počítačích a jiných komunikačních systémech používajících různé komunikační protokoly, formáty dat, jazyky nebo režimy komunikace se stále více požaduje bezchybná komunikace a to bez znalostí uživatelů o složitosti komunikace. Tento vynález napravuje jisté základní zjevné neslučitelnosti mezi

Φ

prostředky, po kterých je vyžadována vzájemná komunikace, přičemž zajišťují spojení mezi různými prostředky.

Podstata vynálezu

Podle prvního hlediska vynálezu je navržen datový komunikační server v komunikační síti, kde server má funkce pro podporu synchronní komunikace mezi serverem a klientem v síti a kde server také usnadňuje podporu asynchronní komunikace s programy {jako jsou aplikační programy) na serveru nebo na jiném systému v síti, přičemž server obsahuje:

prostředky, reagující na požadavek od klienta v synchronní komunikační relaci mezi klientem a serverem, kvůli poslání požadavku (který souvisí s požadavkem klienta) programu na serveru nebo na jiném systému v síti jako asynchronní komunikace;

prostředky, reagující na potvrzení odezvy na asynchronní komunikaci pro přiřazení odezvy k požadavku od klienta, aby se tím umožnilo poslání odezvy klientovi;

prostředky pro generování předběžné odpovědi před přijetím odpovědi na asynchronní komunikaci; a prostředky pro poslání alespoň předběžné odpovědi uvedenému klientovi v synchronní komunikační relaci.

Systém podle tohoto vynálezu má tudíž prostředky pro posílání alespoň předběžné odpovědi klientu v synchronní komunikační relaci i v případě, že zatím nebyla přijata žádná odpověď na asynchronní požadavek.

Druhé hledisko vynálezu zajišťuje způsob komunikace mezi programy mezi klientským programem a programem na serveru nebo na jiném systému v síti používajícím schopnosti serveru jak bylo popsánu výše.

Vynález umožňuje procesu v systému klienta komunikovat s asynchronně komunikujícím programem i v případě, že klientský proces vyžaduje vyhrazenou synchronní komunikační relaci ke komunikaci mezi programy. Program na serveru nebo jiném systému v síti může být aplikační program uzpůsobený k přijímání a posílání asynchronních zpráv bez vyhrazené komunikační relace. Také předběžné odpovědi, které jsou posílány klientovi v počáteční synchronní relaci nabízejí prostředky k potvrzení toho, že server přijal požadavek. Pokud je server částí sítě serverů zajišťujících zaručené doručování zpráv mezi sebou, ale synchronně připojený klient nepodporuje zaručené doručování pro komunikační spoj mezi klientem a připojeným serverem, pak může být velice žádoucí zajistit sledování toho, zda požadavek úspěšně dosáhl serveru, to znamená sledování komunikace nezaručeným spojem komunikační cesty.

„Předběžné odpovědi jsou přednostně posílány pouze tehdy, pokud není k dispozici „úplná odpověď k poslání klientovi během předem určeného časového období (např. do doby definované systémovým administrátorem). To znamená, že pokud od asynchronně komunikujícího aplikačního programu nebyla přijata odpověď po vypršení předem nastavené časové prodlevy, takže server ještě není schopen nabídnout požadovanou úplnou odpověď, pak je proces na serverů přepnut tak, aby poslal předběžnou odpověď klientovi. Předběžná odpověď přednostně obsahuje pro server jednoznačný identifikátor relace přiřazený serverem.

Vkládání identifikátoru relace do předběžných odpovědí

«4

4 4 ·

4 4 4

4 4

44 klientovi umožňuje klientovi (nebo koncovému uživateli pracujícímu na klientovi), který ještě nepřijal očekávanou úplnou odpověď od aplikačního programu nebo “jiného asynchronně komunikujícího programu před vypršením časového limitu, kontaktovat server později znovu a pomocí identifikátoru relace zjistit, zda je odezva spojená s tímto identifikátorem relace ještě dostupná. Klient, který obdržel předběžnou odpověď, je tudíž schopen pokračovat v dalších úlohách, které má zpracovávat, a někdy později znovu zahájit komunikaci se serverem pomocí identifikátoru relace. To zamezuje problému, který by jinak vyvstal, a to že synchronně připojený proces klienta musí buďto zůstat zablokovaný (po neurčené časové období) a čekat na odezvu, nebo zrušit aplikaci pokud odezva není dostatečně rychle dostupná.

Podle upřednostňovaného provedení tohoto vynálezu zjednodušuje komunikace poslaná klientovi jako odezva na vypršení časovače rozhodování procesu nebo uživatele klienta, zda má synchronně připojený proces klienta zůstat zastavený (t j. udržování současné relace), nebo zda se má relace ukončit. Pokud je relace ukončena, proces klienta může zopakovat předchozí komunikaci pomocí identifikátoru relace; identifikátor, který byl poslán klientskému systému může být zahrnut v následujícím požadavku poslaném serveru tak, aby byl server schopen identifikovat jakékoli dostupné odpovědi na předešlé požadavky, které měly stejný identifikátor relace. Po vypršení časového limitu je tudíž klientu, který požaduje vyhrazené komunikační relace, umožněno se rozhodnout, zda bude udržovat synchronní spojení se serverem, nebo jej změnit vlastně na asynchronní komunikaci se serverem pomocí připojených synchronních relací, nebo prostě natrvalo ukončit komunikaci. Klient je

• · · • · t · · to « ♦ to « to toto • to tudíž vybaven ještě jinými volbami, než zůstat nekonečně dlouho zastaven nebo ukončit aplikaci.

Stejně jako umožnění klientovi znovu zahájit předchozí komunikaci, přidání identifikátoru relace klientovi pro konkrétní komunikaci usnadňuje klientovi přiřazení mnoha dvojic požadavek-odpověď z komunikace, i v případě že je proces komunikace na klientovi založen na modelu jednoho požadavku a odezvy. Také to napomáhá při určování problému možného selhání spojení mezi klientem a serverem zatímco klient čeká na odpověď. Také to umožňuje procesu klienta nebo uživateli prokládat komunikaci s několika různými aplikacemi zajištěním prostředků k jejich rozlišení a umožňuje více než jednomu uživateli přistupovat ve stejný okamžik ke stejné aplikaci. Identifikátory relace mohou být automaticky ukládány klientem po přijetí předběžné odpovědi pro následující použití jak je popsáno výše.

Pojmy „klient” a „server se ve výše uvedeném textu používají pouze k rozlišení rolí představovaných v komunikaci, tj . klient vydá požadavek a server podnikne akci jako odezvu na požadavek. Libovolný počítač, který provádí akci na vyžádání jiného počítače, je server. Pojem „klient-server se často používá na poli zpracování dat pro prostředí, ve kterém klient (např. pracovní stanice) pouze zajišťuje funkce komunikace s koncovým uživatelem zatímco server (např. sálový počítač) zajišťuje datový úložný prostor a přístup a provádí komplexní zpracování. Tento vynález je použitelný v těchto prostředích „klient-server ale také v prostředích „peer-to-peer, ve kterých se nerozlišuje mezi funkcemi nabízenými jednotlivými komunikujícími systémy. Vynález je zejména hodnotný v situacích, kdy počítačový program v prvním systému je

specificky přizpůsobený k synchronní komunikaci a je pro něj žádoucí komunikovat s aplikačním programem přizpůsobeným ~k asynchronní komunikaci mezi programy, který běží na jiném systému, jako například tam, kde je pro www prohlížeč žádoucí komunikace s asynchronním aplikačním programem prostřednictvím systému řadícího zprávy do fronty.

Podle upřednostňovaného provedení vynálezu, pokud server přijme odpověď na svůj asynchronní požadavek před vypršením předem nastaveného časového období, pak vloží informace ze získané odpovědi do své odpovědi klientovi, kterou posílá během synchronní relace. Tak může být tudíž asynchronní povaha komunikace s aplikačním programem klientovi skryta pokud odpověď od aplikačního programu je k dispozici dostatečně rychle, s klientem, kterému je poslána úplná odpověď během synchronní relace.

Alternativní uspořádání vynálezu zamezuje zablokování procesu klienta navrácením předběžného potvrzení klientovi o požadavku klienta bez čekání na vypršení časovače. Potvrzení o přijetí obsahuje identifikátor relace (např. jednoznačné referenční číslo) přiřazené procesem na serveru. V tomto případě může klient pokračovat v jiných úlohách jakmile obdrží toto potvrzení, aniž by byl zastaven a čekal na úplnou odpověď nebo na vypršení časovače. Jakmile je odpověď následně přijata od aplikačního programu, je umístěna do úložného prostoru na serveru a podržena tak dlouho, dokud klient nezahájí další komunikaci se serverem, která ponese přiřazený identifikátor relace. Server porovná identifikátor relace uložené odpovědi a nového požadavku a pak pošle uloženou odpověď klientovi.

Je také v rozsahu tohoto vynálezu vytvořit závislost

mt

Ht· • Φ φφ φ φ φ φ

φφ φ· • φ φ · φ φφφ * φφ Φ Φ Φ

Φ Φ Φ ·· ΦΦ typu odpovědi na požadavek klienta na povaze požadavku. Některé požadavky, jako například objednávka zboží, mohou vyžadovat okamžité potvrzení přijetí s přiřazeným číslem objednávky, což minimalizuje dobu, po kterou je proces klienta zastaven. Jiné požadavky, jako například dotaz na zůstatek na účtu nemusí vyžadovat potvrzení přijetí požadavku před poskytnutím požadovaných informací, protože tyto informace jsou vyžadovány pokud jsou dostupné rychle; v tomto případě je pro klienta vhodné počkat po jistou dobu na úplnou odpověď. Takové určení toho, zda se mají posílat okamžitá potvrzení, či ne, je přednostně implementováno vybavením koncového uživatele prostředky pro udání potřeby potvrzení, jako například zajištění volitelného pole nebo parametru ve formuláři s požadavkem a prostředky k vyplnění a reagování na tyto položky v tomto poli.

Identifikátory relace jsou přednostně přiřazeny k požadavkům od klienta procesem na serveru, který vloží identifikátor relace do příslušného asynchronního požadavku, který posílá aplikačnímu programu. Asynchronní požadavek serveru tudíž obsahuje informace z počátečního požadavku klienta a přiřazený identifikátor. Jakmile server následně přijme odpověď od aplikačního programu, která obsahuje tento identifikátor relace, server přiřadí tuto odpověď k požadavku klienta a pošle klientovi odpověď, která obsahuje identifikátor relace. Zde je třeba si povšimnout, že server může přiřadit identifikátor relace pro komunikaci s procesem klienta, který sám od sebe nepodpdruje více současných relací. Výměna identifikátoru relace a použití schopností úložného prostoru klienta k ukládání navrácených identifikátorů relace umožňuje použití těchto identifikátorů k rozlišení mezi současně probíhajícími relacemi. Klient může prokládat komunikaci komunikací s mnoha různými ·« 00 0 0 0 · ·· 0 • · ·

0 0 •0 000» • ··<·

00 • · · 0 0 0 00

0 0 « 0

0 «

00 aplikacemi, protože má prostředky k jejich rozlišení a server muže snadno přiřazovat odpovědi na asynchronní zprávy k odpovídajícím požadavkům. Toto opatření pro současné nebo paralelní zpracování aplikací může značně zvýšit účinnost obchodování.

Vynález umožňuje, aby komunikační prostředky, které jsou navrženy pro synchronní komunikaci s jedním požadavkem, komunikovaly s prostředky, které využívají asynchronní komunikaci.

U systému a způsobu podle vynálezu je upřednostňována podpora řazení komunikace mezi klientem a aplikačním programem. To lze implementovat pomocí informací o stavu relace (jako je například číslo pořadí udávající pozici komunikace v aktuální konverzaci), které je přidáváno do zpráv, které posílá aplikační program zpět klientovi. Aplikace, která vyžaduje další vstup od klienta, tuto skutečnost uvede v informacích o stavu relace v odpovědích, přičemž tyto informace jsou buďto zjistitelné pro server, nebo pro klienta, nebo pro oba. Pomocí informací o identifikátoru relace a o stavu relace je možné jednak identifikovat k sobě patřící dvojice požadavek-odezva konkrétní aplikace, která může obsahovat několik úspěšných komunikací uživatele a zajistit správné po sobě jdoucí řazení komunikace v relaci.

Identifikátory relace jsou přednostně obsaženy jak v komunikaci, která je posílána klientovi po vypršení časovače, tak v odpovědích, které jsou posílány klientovi aplikací, které očekává další komunikaci s klientem. Podle jednoho provedení se na serveru zjišťuje, zda se má do odpovědi zahrnout údaj o identifikátoru relace, přičemž

proces zjišťování přednostně reaguje na údaje o stavu relace poslané komunikujícím aplikačním programem a reaguje na vypršení časového limitu. Pokud není ^—ód klienta očekáván žádný další vstup {tj. od koncového uživatele ani procesu na klientovi), pak server uvolní všechny prostředky pro danou relaci po odeslání odpovědi klientovi a není vyžadován žádný identifikátor relace.

Tento proces zjišťování může být žádoucí při hledání možných problémů spojených s relacemi, které jsou udržovány po delší časové období, než je nutné. Za prvé udržování relací spotřebovává prostředky serveru. Za druhé vrácení údajů o identifikátoru v poslední komunikaci z posloupnosti požadavek-odpověď by mohla obsahovat identifikátor zůstávající v úložném prostoru v klientovi po nekonečně dlouhou dobu. To by mohlo být narušení bezpečnosti stejně jako využití prostředků klienta. Pokud jsou informace o identifikátorech vždy vraceny klientovi (tj. výše uvedený proces zjišťování není implementován), pak jsou výše uvedené problémy řešeny odstraněním informací o stavu z klienta po uplynutí příslušného časového období.

Upřednostňované provedení vynálezu nabízí systém sdělující data, ve kterém má v sobě server nainstalován program internetového www serveru a klient má na sobě nainstalován program www prohlížeče pro posílání požadavků internetem připojeným serverům. Server má také funkce pro podporu asynchronní sdělování zpráv mezi aplikačními programy. Jakmile server přijme požadavky na HTML od terminálu WWW klienta (v synchronní komunikační relaci), které vyžadují komunikaci s aplikačním programem, který je navržen pro asynchronní komunikaci, proces na serveru přepošle požadavek aplikačnímu programu jako zprávu poslanou • * » 1 .· do vstupní fronty aplikačního programu. Pokud aplikační program nemůže interpretovat HTML, pak proces na serveru také převede přijatý HTML požadavek do “formátu zprávy rozpoznatelného aplikačním programem a pak přepošle převedenou zprávu. Jako odezva na přijetí zprávy s odpovědí od aplikačního programu před vypršením předem stanoveného časového limitu převede proces na serveru zprávu ve formě odpovědi zpět do HTML (pokud je to nezbytné) a pošle vytvořené HTML stránky jako odpověď terminálu klienta. Z pohledu www klienta, pokud je odpověď k dispozici před vypršením časového limitu, pak je tato součástí původní synchronní komunikační relace.

Server obsahuje prostředky pro vkládání údajů o identifikátoru relace do HTML stránek, které jsou vkládány do odpovědí posílaných uvedenému klientovi. Server přednostně obsahuje také prostředky, které reagují na údaje o stavu relace obsažené v odpovědi aplikačního programu na asynchronní požadavek, kvůli vložení do HTML stránek jednoho nebo více HTML formulářů k vyplnění koncovým uživatelem, přičemž tyto formuláře v sobě obsahují identifikátor relace. Údaje o stavu relace mohou být také obsaženy v HTML stránkách.

Server reaguje na vypršení časového limitu před přijetím zprávy s odpovědí od aplikačního programu posláním komunikace (tj . HTML stránky) www terminálu klienta. Tato komunikace obsahuje identifikátor relace á přednostně identifikátor stavu relace. Komunikace poslaná zpět klientovi končí svou synchronní HTTP relaci a www klient není již zastaven, ale klientova dále probíhající komunikační „relace s bránou stále logicky existuje tím, že jsou udržovány informace, které umožňují opětovné zahájení

	- 17 -	·· ·· • « · » • t · ΐ · · • fl · • fl ·flfl ·	« fl* · ·· e · · · fl · · * • · » · · · 1 fl ·«♦♦··· • fl · · · ····««« fl* · ·
komunikace mezi www	klientem a programem brány. Koncový
uživatel může určit,	zda se má, či	nemá,	opět vstoupit do
zastaveného stavu pb	další časové	období	á spustit nová

synchronní relace. Identifikátor relace a údaje o stavu jsou uloženy ve vyrovnávací paměti www klienta soužitím schopnosti www klientů zachycovat www stránky ve vyrovnávací paměti. Www klient může používat tyto informace zachycené ve vyrovnávací paměti k opětovnému zahajování předchozích komunikací - k pozdějšímu ověření, zda není na serveru aplikačnímu programu dostupná zpráva s odpovědí. Vložením identifikátoru relace a údajů o stavu relace do po sobě následujících požadavků na server, které jsou spojeny s původní relací, umožňuje klient serveru rozlišovat mezi různými relacemi a mezi různými požadavky, které jsou částí stejné aplikace.

Výše popsané provedení vynálezu nabízí převod z formátu zprávy HTML do formátu zprávy jiného než HTML podle známých technik. Tam, kde je vyvolávaná aplikace schopna interpretovat HTML, není samozřejmě převod nutný.

Tento vynález tudíž v upřednostňovaném provedení nabízí spojení mezi synchronním prostředím www a asynchronním prostředím systémů pracujících se zprávami. Vynález je stejně použitelný při použití programu prohlížeče ke komunikaci s aplikačními programy pomocí serveru v intranetu.

Přehled obrázků na výkresech

Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na ··’'⁵''xvhř’ ·':- '· ·'? ě- ··

ΒΒ • Β · * · · » · · * • Β Β •5 Β ΒΒ Β Β

* · · 9 * · ♦·

ΒΒΒ 9 « kterých představuje obr, schematické znázornění komunikace mezi klientem a servery Internetem;

obr. 2 schematické znázornění komunikace mezi programy pomocí asynchronního posílání zpráv a řazení do front;

obr. 3 program brány instalovaný na serveru pro komunikaci mezi synchronně spojeným www prohlížečem a aplikačním programem uzpůsobeným k asynchronní komunikaci podle provedení tohoto vynálezu;

obr. 4 vzájemná komunikace mezi bránou, prohlížečem a aplikačními programy podle druhého provedení vynálezu; a obr. 5 blokové schéma zobrazující prováděné činnosti zejména programem brány na serveru jakmile je z programu www prohlížeče poslán požadavek, podle provedení tohoto vynálezu.

Příklady provedení vynálezu

Tento vynález může být implementován v mhoha systémech zpracovávajících data a v komunikačních systémech, ve kterých jsou vyžadována spojení mezi různými prostředími. Vynález není omezen na konkrétní počítačový hardware, ani operační systém, ani na konkrétní typy komunikačních spojů a může být implementován buďto jako hardwarová součást, nebo ·· ·♦ ► 4 « « » · ·· ·*« · · • · « • · *· jako softwarová součást, nebo jako kombinace hardwarové a softwarové části.

Upřednostňované provedení tohoto vynálezu obsahuje softwarově implementovanou součást serveru, která zajišťuje spojení mezi prostředím s asynchronním posíláním zpráv a prostředím s řazením do front a synchronním prostředím www.

Jak je zobrazeno na obrázku 1 a popsáno výše, jsou koncoví uživatelé Internetu vybaveni počítači 10, které mají přístup k Internetu a které mají na sobě nainstalován program 20 www prohlížeče. Www server 30 obsahuje počítačový systém (na tomto systému může být například běžet operační systém Windows NT nebo operační systém UNIX, nebo se může jednat o počítač IBM PS/2 Model 80, na kterém běží operační systém OS/2, nebo systém sálového počítače podporující operační systém MVS od IBM) připojený k Internetu a na něm běží program 40 www serveru (jako například IBM Internet Connection Server). OS/2, MVS a PS/2 jsou obchodní značky společnosti IBM Corporation. Program www serveru obsluhuje HTTP (HyperText Transfer Protocol) požadavky od www prohlížečů, analyzuje je buďto jako požadavky na statickou HTML stránku, nebo na spustitelný program a odpovídá buďto posláním dostupné HTML stránky (která se např. nachází na úložném médiu) www prohlížeči, nebo vyvoláním programu 50, který poběží na www serveru nebo na jiném systému a vygeneruje HTML. Programy jsou vyvolávány www serverem pomocí společného rozhraní brány, CGI 60, nebo jiného rozhraní implementovaného www serverem (většina www serverů podporuje dvě rozhraní, přičemž jedno z nich je CGI)

Obrázek 2 je zjednodušené schematické znázornění komunikace mezi programy pomocí asynchronního posílání zpráv a řazení do front za řízení sítě programů pro správu front jako jsou programy MQSeries od IBM. Správce fronty je systémová služba, která zajišťuje schopnosti řazení zpráv do front používané aplikacemi. Jak je zobrazeno na obrázku 2, první aplikační program 100 v systému 110 vydá příkaz k předání zprávy do řízení programu 120 místního správce front a k jejímu sdělení správci 130 front, který běží na vzdáleném systému 160, do fronty 140. Obsluhující aplikační program 150 následně převezme zprávu z fronty 140 jakmile je připraven jí zpracovat. Obchodní aplikace mohou být například převod bankovních fondů nebo systém rezervací míst v letadle. Fronty se zprávami jsou pojmenované objekty, ve kterých se hromadí zprávy a ze kterých jsou později odstraňovány.

Za údržbu určité fronty je zodpovědný jeden ze správců front. Fronta zpráv není pouze zásobník: při přidávání zpráv jsou tyto přidávány do fronty na konec a při odebírání zpráv z fronty jsou normálně odstraňovány zepředu. Fyzická reprezentace front zpráv závisí na prostředí, ale může to být vyrovnávací paměť, nebo vyrovnávací paměti v hlavním úložném prostoru, soubor nebo soubory na disku nebo jiném trvalém úložném zařízení, nebo oba způsoby. Za fyzickou správu front zpráv je plně zodpovědný program správce front a tyto podrobnosti nejsou aplikačním programům viditelné. Pro aplikace představují frontu zpráv prostě jako „černou skříň, ve které se hromadí zprávy. Aplikace mají přístup do front zpráv pomocí API volání pro řazení¹ do fronty ke komunikaci se správcem front, který je instalován na stejném systému jako aplikace {tj. lokální správce front).

Aplikační programy jsou připraveny ke komunikaci s určitými pojmenovanými front zpráv, přičemž posílají

'···.' í? A

• · φ· ·· φ · · · • ♦ *· * ··· · φ « * • Φ φφ zprávy do určitých cílových front, ze kterých aplikační programy mohou číst. Umístění těchto front nemusí být aplikacím posílajícím zprávy viditelné;· každá aplikace komunikuje pouze se svým místním správcem front a je to síť vzájemně propojených správců front, která je zodpovědná za přesun zpráv do požadovaných front. Každý správce fronty udržuje lokální směrovací tabulky pro nalezení ostatních správců front v síti. Tímto způsobem software pro řazení zpráv do front podporující aplikace velmi zjednodušuje složitost, která se vyžaduje od aplikačních programů tím, že se odstraní jejich potřeba implementovat své vlastní složité řízení komunikace.

Tento vynález nabízí přístup k takové síti vzájemně propojených správců front uživatelům, kteří nemají na svém lokálním systému instalován žádný program pro správu front. Vynález také zajišťuje prostředí pro vývoj složitých, spolehlivých www aplikací, které mohou využívat služeb existujících aplikacím zprostředkujících programů jako jsou například produkty MQSeries od IBM.

Spojová součást, která je v programu implementována, je navržena k instalaci na www serveru k tomu, aby posílala a přijímala zprávy jménem synchronně připojených uživatelů.. Tato spojová součást, dále označovaná jako program brány, je vyvolávána požadavky od www prohlížeče jak bylo popsáno výše. Program brány používá rozhraní s www serverem, například standardní CGI (společné rozhraní brány). Program brány umožňuje správu více současně připojených uživatelů a jejich stavu, jak bude popsáno níže, a spravuje rozdíly mezi synchronním HTTP a asynchronními zprávami, přičemž zajišťuje synchronně připojenému www prohlížeči informace o průběhu asynchronních zpráv, které vyšle jménem prohlížeče. Program

fe * fe· «· fe * fe ·

brány také spravuje spojeni mezi systémy pro zaručené doručování zpráv a nezaručenou HTTP komunikací. Přestože muže být vyžadován převod dat (jako například z ASCII do EBCDIC), protože různé architektury a hardwarové platformy mají různou reprezentaci a parametry dat, je tento převod v oboru znám a není nutné jej implementovat programem brány, protože známé programové produkty pro posílání zpráv převod umí provést. Program brány také nemusí zajišťovat komplexní schopnosti zabezpečení, protože tyto schopnosti jsou implementovány ve známých programech posílajících zprávy a ve www serverech (jako jsou servery Secure Internet Servers od IBM).

Obrázek 3 zobrazuje program 200 brány, který tvoří rozhraní mezi programem 210 správce front zpráv a programem 220 www serveru instalovaným na počítačovém systému . 230. Může se použít program brány, jak je ukázáno v tomto příkladu, k tomu, aby tvořil rozhraní mezi www serverem a aplikačním programem 240 pro řazení zpráv do front, který může běžet na jiném stroji, než na serveru 230. V tomto případě se na serveru nevyžaduje žádný aplikační software. Systém, na kterém běží aplikace pro řazení zpráv do front, může být připojen k serveru Internetem nebo jinou komunikační sítí. Aplikační program v tomto příkladu je schopen interpretovat data ve formě HTML od www prohlížeče 250 a generovat HTML stránky jako odpověď.

Podobné použití programu brány ve spojení se složkou 260 aplikace pro převod formátu instalovanou na www serveru je zobrazeno na obrázku 4. Složka pro převod formátu slouží k převodu mezi HTML požadavky www prohlížeče a odezvami a vnitřní strukturou zpráv aplikačního programu 270,, který není schopen interpretovat HTML. Tato převodní složka 260

..•Ϋ'^-‘V : •/ ' .íoíf'

fc fcfc • » · * fc · **• fcfcfc fc • fc · fcfc fcfc tudíž umožňuje použití programu 200' podle tohoto vynálezu s existujícími aplikacemi pro řazení zpráv do front. Součást serveru může také koordinovat požadavky na několik cílových aplikací a odpovědi www prohlížeči v jedné pracovní jednotce. Převod HTML je v oboru dobře znám a tudíž zde nebude dále popisován.

Nyní bude popsán program brány a komunikační tok mezi www prohlížečem a asynchronním aplikačním programem s odkazem na obrázek 5. Jedna nebo více aplikačních vstupních front, je definována pro každý aplikační program pro řazení zpráv do front, který je spojený s programem brány. Tato aplikace a její vstupní fronty mohou být umístěny na počítači s www serverem nebo na libovolném počítači připojeném pro komunikaci se serverem pomocí podpory zprostředkujícího softwaru pro řazení zpráv do front. Brána má frontu s odpověďmi umístěnou na serveru a spravovanou lokálním programem pro správu front, pro zprávy posílané aplikačními programy.

Uživatel komunikuje s programem brány pomocí požadavku 300 GET nebo POST z formulářů ve formátu HTML, který udává název aplikace pro řazení zpráv do front nebo služby, kterou si přejí použít. V upřednostňovaném provedení tohoto vynálezu název obsahuje název aplikační fronty, ale v alternativním provedení je tento odvozen programem brány od názvu aplikace.

Příklad příkazu, kterým uživatel vyvolá aplikaci je následuj ící:

Určení systému pro řazení zpráv do front:

X- - νΧΧ'ΝΧ:· -' - . 4/¾ ·Η*ί4·

	·♦ · « · · - 24 - : : ·· ··· ·	«* · · ♦ · · * Φ · · · ·· _ · Φ * ·♦· · * • * · · *
Cinput type=input;	name=QMName;	size=48; max
length=48>
a aplikace:
cinput type=input;	name=QName;	size=48; max
length=48>
<input type=submit;	value=Klepněte	sem a spustí se

aplikace>

</form>

Název QName se vyžaduje k určení cíle pro generovanou asynchronní zprávu a je normálně určen samotnou aplikací. Název QMName je volitelný. Pokud je uveden, používá se spolu s QName k určení cíle zprávy. Pokud není zadán, použije se prázdný název. Je možné aplikovat normální pravidla pro rozlišování názvů systému pro posílání zpráv. Do formuláře s požadavkem lze přidat další pole obsahující formátovací data, která mají charakter specifický pro danou aplikaci. Tato pole jsou předána aplikaci ve zprávě poslané bránou.

První komunikace uživatele s aplikačním programem („vstupní bod aplikace) přichází typicky ze statické www stránky ve formátu HTML. Uživatel dereferencuje dané URL nebo pošle 300 HTML formulář, který komunikuje s programem brány. Počáteční požadavek HTML neobsahuje žádný vložený identifikátor relace. Poté co uživatel poprvé projde tímto vstupním bodem (tj. pošle se požadavek na HTML, který nepatří k již existující relaci) a spustí aplikaci, program brány sestrojí relaci 340, označenou identifikátorem relace, který je v bráně jedinečný a představuje kombinaci aplikace požadované uživatelem a instance požadavku. Identifikátory relace se mohou generovat s dostatečnou nahodilostí nebo s použitím jednoznačné identifikace serveru tak, aby se zajistila jednoznačnost pro celou síť, ale to není ·· · 9 · * · » · · *· • · ♦·» · · ·

• 9 · · * správu front se zprávami od IBM) mají schopnosti

- 25 podstatné. Existující programy pro (jako například programy MQSeries generovat jedinečné identifikátory a program brány podle upřednostňovaného provedení těchto schopností využívá.

Brána přidává 350 údaje o identifikátoru relace do tabulky relace (implementované jako položky ve frontě se zprávami, která je například držena v křížově zpracovávané sdílené paměti serveru, na kterém běží operační systém OS/2 nebo AIX, nebo zapsané na diskovém úložném prostoru) spolu s údaji o klientském systému nebo s údaji o totožnosti uživatele. ΟΞ/2 a AIX jsou obchodní značky společnosti IBM Corporation. Tato tabulka se dále používá k přiřazování identifikátorů relací k požadavkům uživatelů k odezvám aplikačních programů, jek bude popsáno níže. Není zajištěn jiný způsob spouštění aplikace kromě průchodu vstupním bodem aplikace výše popsaným způsobem. Komunikace uživatele se nemůže týkat více než jedné relace.

Poté co program brány přiřadí identifikátor relace komunikaci uživatele, vloží 360 zprávu do vstupní fronty definované aplikačním programem, spustí 370 časovač a zahájí 370 proces přijímání zprávy s odpovědí od aplikačního programu. Přijímání odpovědí bude popsáno níže. Zpráva obsahuje stavové informace ve formě pořadového čísla udávajícího pozici této komunikace v rámci celkové komunikace mezi klientským procesem posílajícím požadavky a aplikačním programem a obsahuje identifikaci uživatelského klientského systému a také vstupní data poslaná www prohlížečem. Tato data jsou předána aplikaci v příslušné znakové sadě a kódové stránce (s konverzí provedenou procesem na serveru odděleným od samotného programu brány, jak bylo uvedeno výše) . Cíl zprávy může být dlouhodobě

»· ♦ *· · 4 • · * ·* ** běžící aplikace řadící zprávy do fronty nebo se její příchod může použít ke spuštění aplikace pro řazení zpráv do fronty. Jak bylo popsáno výše, vynález se může implementovat pro použití s aplikacemi, které jsou „navrženy pro www (tj . které rozumí HTML stránkám a generují HTML stránky) a s aplikacemi, které vyžadují HTML převod. Následující popis provedení vynálezu se týká příkladu vzájemné komunikace s aplikací navrženou pro www.

Aplikace řadící zprávy do fronty by měla odpovídat na přijaté zprávy posláním HTML stránky do fronty s odpověďmi programu brány. Jak bylo výše popsáno, program brány již vyvolal proces pro převzetí těchto odpovědí ze své fronty po jejich přijetí. To se implementuje s použitím známé schopnosti mezilehlého programu pro řazení zpráv do front, kdy příkaz k získání zpráv z fronty může volitelně obsahovat příkaz k čekání po udanou dobu pokud není odpověď okamžitě dostupná při prvním pokusu operace Get (získání). V produktech správců front MQSeries od IBM je tato schopnost vyvolána jako parametr API příkazu pro získání zprávy „MQGET_Wait, jak je popsáno ve výše uvedené publikaci „MQSeries - Message Queue Interface Technical Reference (IBM číslo dokumentu SC33-0850-01). Program brány tudíž pošle zprávu a vyvolá 370 příkaz k získání zprávy s odpovědí, přičemž nechá program pro správu front řídit současnou operaci Get Message pro získání zprávy, která získá 420 HTML zprávu z fronty s odpověďmi a pošle jí bráně. Program brány pak vyšle 420 prohlížeči HTML stránku obsahující současný identifikátor relace jako skryté pole v HTML.

V případě že vyprší časový limit operace získání zprávy předtím, než program brány obdrží zprávu s odpovědí, pak se

získání zprávy vrátí a program brány odešle 390, 400 prohlížeči zprávu s předběžnou odezvou. Tato předběžná zpráva ukončuje synchronní relaci, ale protože obsahuje identifikátor relace, muže být později „opětovně spuštěna (bude vlastně spuštěna úplně nová relace, ale protože s sebou nese komunikaci mezi stejným prohlížečem a programy brány a obsahuje stejný identifikátor relace, můžeme se na ní dívat jako na opětovné spuštění původní relace). Pokud je synchronní relace mezi www prohlížečem a programem www serveru připojeným prostřednictvím brány jinak přerušena před přijetím odpovědi, zruší brána jakékoli operace získání zpráv v nejistém stavu. Všechny zprávy s odpověďmi, které jsou umístěny do fronty s odpověďmi programu brány po vypršení nebo jiném přerušení relace tam zůstanou dokud www prohlížeč znovu nenaváže komunikaci s bránou kvůli vyhledání příslušné zprávy s odpovědí. Po přijetí takového následného požadavku www prohlížeče vyvolá program brány znovu operaci pro získání zprávy (s intervalem čekání).

U všech zpráv, které jsou poslány klientům v relaci není potřeba, aby obsahovaly identifikátor relace, identifikátor je však přidán kdykoli se očekává další komunikace klienta. To je obecně případ, kdy je poslána 400 komunikace po vypršení časového limitu a předtím, než je dostupná odpověď aplikace nebo pokud je přijata odpověď aplikace a vložené informace o stavu relace potvrzují očekávání další komunikace klienta. Program brány obecně aktualizuje 420 svou tabulku s relacemi s informacemi o stavu relací pro příslušnou relaci po přijetí odpovědi od aplikačního programu. Pokud však aplikace nepožaduje další komunikaci s uživatelem nebo s procesem v klientském systému (což udávají informace o stavu relace, nebo jejich nepřítomnost v odpovědích od aplikačního programu), uvolní

't

0« ·

0 · ·

0 · • 0 * • V · »· »000

0 ····

Β 0 * · · ·· • •0 · · · ·

0» ·«

420 program brány všechny prostředky specifické pro relaci poté co pošle stránku prohlížeči.

Jakmile aktuální aplikační program „očekává nebo vyžaduje další komunikaci s klientem (tj. očekává interakci klienta se současným aplikačním programem nebo jiným aplikačním programem předtím, než celá aplikace skončí), uvede tuto skutečnost pomocí příznaku ve svých odpovědích serveru. Také obsahuje další HTML formuláře v HTML stránce, která je posílána klientu s identifikátorem relace vloženým v každém z dynamiky vytvářených HTML formulářů.

Www prohlížeč má schopnosti ukládání stránek 410 do vyrovnávací paměti a proto je schopen ukládat vložené identifikátory relace a to umožňuje obyčejnému uživateli mít otevřenu více než jednu relaci. Tyto relace mohou být vnořené, nebo se mohou vzájemně překrývat. Poté co je formulář obsahující identifikátor relace následně doplněn 300 do prohlížeče, poputuje identifikátor relace zpět do programu brány na serveru tak, aby mohl program brány přiřadit 320, 330 následně přijatý formulář ke správné relaci. Identifikátor relace se používá k odlišení požadavku od jiných požadavků jiných uživatelů a jiných požadavků od stejného uživatele, ale pro jiné aplikace. Proces, který je částí programu brány, prohledá 320 tabulku relace na shodu položek v tabulce s identifikátorem relace a shodu informací o stavu relace přijatého požadavku. Pokud relace a informace o stavu neodpovídají existující komunikaci s aplikací, pak program brány pošle 360 stavové informace a vstupní data jako zprávu do vstupní fronty aplikace jak bylo popsáno Pokud je však při porovnávání informací o relaci informací přijatého požadavku s položkami vyse, a stavových v tabulce relací nalezena shoda, musí se jednat o opětovný

. -I ^·· W^!ti -J. . ' , f . ... * I. ..

·· ·· « 0 0 ·

0 ·

0 > ·

0 0

000·

0*

0 • 00 «000

0 0 • 0·

0 0 ·

0 0 ·· pokus dřívějšího požadavku a tudíž může být již k dispozici odpověď. Aplikaci by tudíž neměla být poslána nová zpráva, protože příslušný správce front nebosprávci front zodpovídají za to, že zajistí právě jednu zabezpečenou dodávku předtím vyslané zprávy; program brány vyvolá 370 operaci pro získání (Get) s čekáním, která ověří, zda ve frontě s odpověďmi není očekávaná zpráva s odpovědí.

Přiřazení identifikátoru relace uživatelské komunikaci, který je pak vrácen prohlížeči a v něm uložen, tudíž řeší mnoho technických problémů. Za prvé umožňuje více než jednomu uživateli přistupovat ke stejné aplikaci nebo službě současně, přičemž brána je schopná rozlišovat odpovědi, které přijímá. Za druhé zajišťuje, že je přenášen dostatek informací o kontextu mezi za sebou následujícími požadavky vydávanými jednotlivými uživateli jednotlivým aplikacím serveru kvůli přiřazení množství dvojic požadavek-odpověď déle probíhající komunikaci s aplikací. Za třetí umožňuje uživateli prokládat komunikaci s několika různými aplikacemi, protože je zajištěn mechanismus k rozlišování mezi nimi. Za čtvrté umožňuje uživateli přerušit aplikaci v libovolném stavu, případně bez poslání jakéhokoli upozornění serveru nebo programu brány a bere v úvahu možnost selhání spojení mezi uživatelem a serverem.

Stejně jako přidávání identifikátoru relace budou dynamicky vytvářené HTML obsahovat pořadové číslo udávající pozici komunikace v rámci aktuální relace. To se vrátí programu brány při dalším požadavku prohlížeče a program brány jej porovná 320 s očekávanou hodnotou. Tento mechanismus, udržování kontextu dat a kontextu stavu spuštění s použitím identifikátorů relace v tabulce a pořadových čísel v tabulce, umožňuje provádění posloupností

44 >4

4 4 4 ··

4 · ··

4 44« 4 · • 4 4 4

I 4 *

4444 sobě vzájemně závislé rozlišovat mezi mnoha jedním z následujících

- 30 požadavků od klienta, které jsou na obsluhující aplikace je schopna zprávami v jedné relaci.

Relace může být ukončena způsobů:

Aplikace na serveru udává ve své zprávě s odpovědí, že není vyžadován žádný další vstup uživatele a brána odpoví uvolněním 420 prostředků specifických pro danou relaci.

HTML stránka obsahující formulář je poslána uživateli do administrátorem stanoveného časového období, není však vyplněna. Brána pošle zprávu o ukončení obsluhující aplikaci, která očekávala odpověď- od uživatele (přičemž zamezí nadbytečné údržbě nedokončenou obsluhující aplikací).

Uživatel se rozhodne přerušit aplikaci pomocí dialogu s programem brány, protože aplikace neodpovídá na zprávy během přijatelné doby. Program brány se pokusí získat poslanou zprávu. Pokud se to nepodaří, pošle zprávu o zrušení obsluhujícími aplikačnímu programu.

Ukončení relace umožňuje programu brány a obsluhujícím aplikacím uvolnit všechny prostředky specifické pro danou relaci, které měly přidělené. Identifikátor relace bude odmítnut (tj . nespustí další komunikaci kromě upozornění o odmítnutí) pokud je poslán programu brány, buďto uživatelem, nebo obsluhující aplikací po ukončení relace. Důležité je všimnout si, že vypršení serverem nastavitelného časového období udává období po které by měl být proces klienta udržován zastavený, avšak neukončuje automaticky relaci. Tudíž po takovém časovém limitu program brány stále udržuje

07,

·· · · • · ·· • a · * ·

4 ·

44

4 a · · • 4 4444 ·*· ♦··· zprávy na obrazovce týkající se vypršení časovače), odpověď prohlížeči vyvolaná časovačem podle upřednostňovaného vynálezu však udává, zda byl požadavek přijat cílovým počítačem a zda aplikace požadavek přečetla, nebo nepřečetla. Jsou známy programy pro správu front se zprávami, které zajišťují oznámení potvrzení po příchodu a potvrzení po doručení. Program brány podle předcházejícího provedení je uzpůsoben k použití dostupných oznamovacích schopností, aby mohl sestrojit své upozornění o vypršení časového limitu tak, aby upozornění obsahovalo veškeré dostupné informace o průběhu komunikace pro danou relaci.

Je v rozsahu tohoto vynálezu implementovat předběžnou odpověď jako mezilehlé potvrzení přijetí požadavku od klientského systému bránou. Toto potvrzení ukončí přítomnou synchronní relaci, bude však obsahovat identifikátor relace a tak umožní klientovi později opět zahájit komunikaci. Přestože klientský proces nebude v tomto případě pozastaven, aby očekával odezvu od asynchronně dotázaného programu, zůstává možnost prodlev mezi požadavkem a potvrzením přijetí kvůli problémům s komunikačními spoji samotných komunikačních systémů. Doba vypršení časového limitu klienta zde může být použita k automatizaci doby, kdy by měl být požadavek klienta přerušen v případě, že není přijato žádné potvrzení, ale pro jisté aplikace je určení doby, kdy se má rozhodnout o přerušení požadavku klienta, ponecháno na koncovém uživateli, jak je známo uživatelům existujícího softwaru www prohlížečů.

Je také v rozsahu tohoto vynálezu zajistit proces v programu brány, který reaguje na přijatý „typ požadavku od klientského systému k určení, zda je požadována okamžitá předběžná odpověď, nebo zda se má použít nastavené přerušení

* » • * · • · * · « · ···· » Β· ·· · · • · • · *

·»· ·*»· ·· ·· « · ·· ♦ ·· · · • · * ·· ·· nebo časový limit kvůli zajištění úplné odezvy během tohoto limitu v případě že je dostupná. Podle jednoho konkrétního provedení tohoto vynálezu má program brány nastavitelnou hodnotu časového limitu, kterou používá standardně. Tato hodnota je udržována v konfiguračním souboru na serveru, kde je instalován program brány a může být nastavena při instalaci programu brány a následně upravena administrátorem systému. Volitelný parametr může být vložen do HTML formulářů s požadavky {podobně jako parametry QName a QMName), který překryje tuto standardní hodnotu. S použitím výše uvedených příkladů při návrhu HTML formuláře, který má posílat objednávku zboží a který vyžaduje rychlou odpověď s potvrzením požadavku, bude ve formuláři s požadavkem zakódována nízká hodnota časového limitu; zatímco pokud se požadují informace o zůstatku na bankovním účtu, kde se nepožaduje žádné takové rychlé potvrzení, bude zakódována vyšší hodnota (pravděpodobně hodnota odpovídající nej delšímu časovému období, které budou uživatelé schopni tolerovat).

Protokoly pro přenos zpráv pro zajištění zabezpečené dodávky zpráv jsou popsány v mezinárodní patentové přihlášce WO 95/10805 a v patentové přihlášce UK číslo publikace GB 2311443, které jsou zde zahrnuty odkazem. Přestože základní podpora sítě typicky zabezpečuje spolehlivou dodávku paketů mezi počítači, zabezpečenou dodávku není obvykle schopné zajistit nespolehlivé médium. Aby se zajistilo právě jedno poslání dat a aby se komunikace opět spustila a správně se obnovila po závažném selhání počítače nebo sítě, vyžaduje se více než základní podpora sítě pro dodávku paketů. Oba partneři v zajištěné dodávce si zejména f

musí zapamatovat, která data byla úspěšně přenesena a „zajištěna. Zajištění je proces zapsání dat na úložné médium jako je disk a zabezpečení obnovitelnosti i informace o identifikaci relace a stavové informace.

Jsou známy programy pro správu front se zprávami, které mají schopnost zajistit, aby zprávy od programu brány byly doručeny do vstupní fronty aplikace a aby byly odpovědi vraceny programu brány (viz. níže). Programy pro správu front se zprávami však nemohou zajistit funkčnost komunikačních spojů v dané době, ani to, aby se aplikace sama spustila a zpracovala požadavky od prohlížeče. Program pro správu front nemůže rovněž zajistit zabezpečenou dodávku www prohlížeči, . který se připojuje do sítě správců front, jak bylo popsáno, reaguje program brány na přicházející požadavky www prohlížeče tím, že vkládá zprávu do vstupní fronty aplikace na serveru. Poté co je zpráva poprvé umístěna do fronty, spustí 370 program brány odpočítávací časovač a čeká na odpověď od aplikace na serveru. Pokud časovač vyprší .před přijetím odpovědi od aplikačního programu, vytvoří 390 program brány HTML stránku, aby upozornil 400 uživatele na vypršení.

Program brány je tudíž nastaven tak, aby posílal svou odpověď prohlížeči v případě, že nedostane odpověď od aplikace před vypršením administrátorem definovaného časového období. Nastavení maximální časové prodlevy před přerušením klienta bude záviset na příslušné aplikaci (vhodné zpoždění může být 10 sekund nebo 1 sekunda) . Hlavní účel této odpovědi je poskytnout uživateli nebo komunikujícímu procesu v systému klienta informace, které umožní zjistit, zda se má udržovat stav čekání aktuální komunikační relace na odezvu, nebo zda se má ukončit relace (ale udržovat informace týkající se relace) a pokračovat dalšími pracovními položkami. Tato odpověď klientovi může být prostě výzva koncovému uživateli (například vyvolání • 9

v případě selhání hardwaru. Zajištění obnovy prostředků v systému řazení zpráv do fronty je popsáno podrobně na stránkách 209 až 217 v knize „Messaging and Queuing Usíng the MQI, B. Blakeley, H. Harris & R. Lewis, McGraw-Hill, 1994 .

Obchodní aplikace může obsahovat několik obsluhujících aplikací, jejichž aktivity je zapotřebí zkoordinovat transakčním způsobem. tento problém je řešen programem správce front se zprávami na serveru. Program brány posílá zprávu jednomu - řídícímu aplikačnímu programu pro řazení zpráv do front, který ji pak v případě potřeby rozloží na oddělené požadavky na jednotlivé obsluhující aplikace. Tyto zprávy mohou být posílány a rekombinovány transakčním řízením programem pro správu řazení zpráv do front. Programy obsluhující zprávy, které mají schopnosti zajišťující takovéto transakční řízení jsou v oboru známy (například programy obsluhující zprávy MQSeries od IBM).

Návrh programu brány umožňuje přidání dalších obsluhujících aplikací, které zdolají zvýšené požadavky t j. řešení podle upřednostňovaného provedení vynálezu je stupňovatelné. To je dosaženo tím, že program brány obsahuje identifikátor relace v části deskriptoru zprávy jednotlivých asynchronních zpráv. (Deskriptor zpráv obsahuje informace definující vlastnosti zprávy a používá jej služba pro řazení zpráv do fronty k rozhodnutí o tom jak se má zpráva zpracovat. Samotné zprávy obsahují dvě samostatné části část s aplikačními daty a část se záhlavím zprávy obsahující informace deskriptoru zprávy, které jsou vzhledem k aplikačním datům pomocné.) To umožňuje současný běh několika obsluhujících aplikačních programů pracujících na jedné pracovní frontě. Pokud aplikace potřebuje sama udržet

fl * • · • · flfl fl fl · ·

flfl ·· « · fl · flfl·· informace o kontextu mezi za sebou následujícími interakcemi, může získat zprávy, u kterých se shodují jejich identifikátory relace. Pokud neudržuje informace o kontextu, pak mohou instance obsluhující aplikace získat a zpracovat první zprávu, kterou naleznou.

Vynález podle upřednostňovaného provedení tudíž zjednodušuje spojení internetové www služby se systémem pro zpracovávání zpráv pro obecné účely, aniž by bylo zapotřebí modifikace existujících www prohlížečů, vynález však není omezen na tuto implementaci. Vynález se může implementovat tak, aby zajistil spojení mezi dvěma systémy zpracovávajícími data, kde počítačový program nainstalovaný na jednom systému vyžaduje synchronní komunikaci, zatímco program ve druhém systému vyžaduje asynchronní formu komunikace. Vynález podle upřednostňované implementace ve spojení se softwarem pro zpracovávání zpráv jako například produkty MQSeries od IBM také zajišťuje most do sítí, které nepodporují internetový protokol (IP), protože MQSeries podporuje komunikační protokoly TCP/IP, APPC a NetBIOS. Vynález tudíž usnadňuje komunikaci mezi aplikacemi v IP a nelP sítích.

Výše popsané upřednostňované provedení obsahuje odděleně instalovatelný program brány ve spojení se systémem zpracovávajícím zprávy. Alternativní provedení implementuje bránu jako vnitřní součást programu pro správu front. Tabulka s identifikátory relací a tabulka se stavy relací může být výhodně implementována jako fronta zpráv řízená správcem front. Mohou být použity identifikátory MessageID a CorelID, které jsou již implementovány ve správcích front MQSeries jako vhodné informace pro vyhledávání ve frontě. Je však nutné vzít na vědomí, že aktualizace položek

.««2g£UttteflfeMiÍÍ<>% -.

« · *· φ φ φ · · ·· .

• * · · φφ φ * » * · ♦ φ « · φ ♦ · φ ·· « · · « φ ♦»····· * φ · φ · φφ* • Φ Φφφφ φφφ φφφφ *· φφ zadržovaných ve správcem front řízené frontě vyžaduje kroky odstranění položek z fronty, úpravy a pak nahrazení ve frontě, protože není zajištěna úprava položek v době, kdy se nacházejí ve frontě řízené správcem fronty. Aktualizace položky v tabulce udržované ve sdílené paměti může vyžadovat prosté přepsání předchozí položky. Protože je výhodné používat schopností programu pro správu front se zprávami u operace „čekání na událost (tj. odpověď) nebo vypršení časového limitu, je tato funkce typicky zajištěna v operačních systémech podporujících více vláken, přičemž program pro správu front se zprávami může v praxi provádět používání funkcí na nižší úrovni z operačního systému. Alternativní provedení mohou používat spuštění programu brány kdykoli je nová zpráva s odpovědí poprvé umístěna do fronty s odpověďmi, ale nejedná se upřednostňovanou implementaci, protože spouštění není žádoucí není-li přítomna žádná živá relace s klientským systémem. Další alternativní provedení tohoto vynálezu mohou implementovat periodické prohledávání fronty s odpověďmi na nové zprávy s odpověďmi místo vyvolávání operace „získat s čekáním.

Ve výše uvedeném upřednostňovaném provedení jsou identifikátory relace automaticky ukládány do vyrovnávacího úložného prostoru www prohlížeče (jako vložená pole v HTML stránkách). Identifikátory relace by však eventuelně mohly být zobrazeny koncovému uživateli na obrazovce zobrazovacího zařízení a po uživateli se může vyžadovat vložení identifikátoru relace při vytváření následného souvisejícího požadavku. V provedeních, ve je kterých předběžná odpověď klientskému systému po vypršení časového limitu pouze zobrazena uživateli bez automatického vložení do budoucích požadavků, je to koncový uživatel, který rozhoduje, zda se má aktuální relace udržovat, nebo zda se má ukončit a

99 • 99 9 ·

»

9 *9 ·· identifikátor uložit pro následující opakované pokusy požadavku. Výše popsané provedení z příkladu má také schopnosti zahrnovat identifikátory relací a informace o stavu relací pouze jistých komunikací vracených zpět prohlížeči, avšak alternativa, která je zřejmě v rozsahu tohoto vynálezu, obsahuje vkládání alespoň informací o identifikátoru relace do všech odpovědí.

Znakem výše popsaného upřednostňovaného vynálezu je údržba stavových dat programem brány; alternativní provedení tohoto vynálezu ponechává řešení všech problémů s pořadím na aplikačních programech, takže program brány není žádným způsobem zapojen do udržování informací o stavu relace.

Zastupuj e:

Dr. Petr Kalenský v.r.

Ύ',í , <·>. ÁT Μ ί K A N CPI. Λ Ř

KALENSKÝ

A PARTNER!

' ¹ Z' , 1 ' . I·, k.r? ! 9 ' . : :·.: ui,'i [.i

iVÁ

JUDr. Petr Kalenský advokát

120 00 Praha 2, Hálkova 2

• to		• ·	•	4 ·» ··
•
•	•	to	to	• to ·
v	to	to to	•	• to to · « to
•	•	•	to	• * *
• ·		• •to»

PATENTOVÉ NÁROKY

Claims

PATENTOVÉ NÁROKY

1. Datový komunikační server pro komunikační síť, kde synchronní komunikace mezi kde server také usnadňuje server má schopnosti podpory serverem a klientem v síti a podporu asynchronní komunikace s programy na serveru nebo v jiném systému v síti, přičemž server obsahuje:

prostředky . reagující na požadavek od klienta v synchronní komunikační relaci mezi klientem a serverem pro posílání požadavku programu na serveru nebo na jiném systému v síti jako asynchronní komunikace;

prostředky pro spouštění časovače odezvou na požadavek od klienta,·;

prostředky citlivé na přijetí odpovědi na asynchronní komunikaci pro přiřazení odpovědi k požadavku od klienta, aby se umožnilo poslat klientovi odpověď;

prostředky pro generaci předběžné odpovědi před přijetím odpovědi na asynchronní komunikaci, přičemž předběžná odpověď obsahuje identifikátor relace přiřazený serverem; a prostředky pro posílání předběžné odpovědi klientovi v synchronní komunikační relaci pokud předem nastavené časové období vyprší před přijetím odpovědi na asynchronní požadavek.
2. Datový komunikační systém podle nároku 1,

27 76 328 * · · · • · · *

9 9 9

9 · 9 ·*· Φ · 9 9 9

9 999·· ► * »*····· » Φ ·*Φ ··· Φ·*« 99 ·· obsahující prostředky pro posílání odpovědi klientovi v synchronní relaci, přičemž prostředky pro posílání odpovědi jsou citlivé na přijetí odpovědi na asynchronní požadavek před vypršením předem nastaveného časového období, aby vložily informace z přijaté odpovědi do odpovědi klientovi, které je posílána v synchronní relaci.
3. Datový komunikační systém podle nároku 1, obsahující proces na serveru pro přiřazování identifikátoru relace požadavku klienta a vkládající identifikátor relace do asynchronního požadavku, který posílá programu, přičemž server obsahuje prostředky citlivé na přijetí odpovědi na asynchronní požadavek od programu, která obsahuje identifikátor relace, pro použití identifikátoru relace k přiřazení odpovědi programu k požadavku od klienta a pro vložení identifikátoru relace do odpovědi, která je poslána klientovi.
4. Datový komunikační systém podle nároku 3, obsahující prostředky citlivé na informace o stavu relace vkládané do odpovědi programu na asynchronní požadavek pro vložení informací o stavu relace do odpovědi posílané klientovi.
5. Datový komunikační systém podle nároku 3, kde server má v sobě nainstalovaný software internetového www serveru pro odpovídání na požadavky od programu www prohlížeče nainstalovaného na klientovi, přičemž server obsahuje prostředky pro vkládání informací o identifikátoru relace do HTML stránek, které jsou vkládány do odpovědí posílaných klientovi.
6. Datový komunikační systém podle nároku 5, kde

.....

φφφφ φφ · φ φφφφ • · φ φ · φ · ·· • φ φ · · φφφφφφ· • * · · φ φφφ φφ φφφφ φφφ ···· φφ · φ server obsahuje prostředky citlivé na informace o stavu relace obsažené v odezvě programu na asynchronní požadavek pro vkládání do HTML stránek jednoho nebo více HTML formulářů pro vyplnění koncovým uživatelem, přičemž formuláře mají v sobě vložený identifikátor relace.
7. Datový komunikační systém podle nároku 5 nebo 6, kde server obsahuje prostředky citlivé na informace o stavu relace vkládané do odpovědi programu na asynchronní požadavek, pro vkládání informací o stavu relace do HTML stránek posílaných klientovi.
8. Datový komunikační systém podle nároku 5 nebo 6, obsahující prostředky pro převod HTML dat požadavku klienta do formátu interpretovatelného programem a pro převod informací obsažených v odpovědi programu do HTML pro vložení do odpovědi klientovi.
9- Datový komunikační systém podle nároku 1, kde server implementuje záznam potvrzování po příchodu (COA) a záznam potvrzování po doručení (COD) a je citlivý na přijetí záznamu COA nebo COD před vypršením předem nastaveného časového období pro vložení záznamu COA nebo COD do komunikace poslané klientovi po vypršení předem nastaveného časového období.
10. Datový komunikační systém podle nároku 1, kde server obsahuje prostředky citlivé na identifikaci stavu relace, která je vkládána do odpovědi programu na asynchronní požadavek pro zjištění toho, zda se mají vkládat informace o identifikaci relace do odpovědi klientovi.
11. Datový komunikační systém podle nároku 4, kde

+OT -vi «4 « 4 • · 4 • · · 4 •9 ···· «·4· ···· prostředky pro vkládání informací o stavu relace do odpovědi klientovi obsahují prostředky pro zjištění toho, zda se mají vložit informace o stavu relace, v závislosti na stavu relace.
12. Datový komunikační systém podle nároku 1, obsahující prostředky citlivé na požadavek klienta pro t . zjištění, zda se má poslat potvrzení o přijetí klientovi jako předběžná odpověď, nebo zda má být spuštěn časovač.
13. Způsob datové komunikace mezi prvním počítačovým programem v prvním systému v komunikační síti a třetím počítačovým programem přístupným prostřednictvím druhého počítačového programu ve druhém systému v síti, obsahující kroky:

poslání prvního požadavku od prvního programu do druhého systému v synchronní komunikační relaci;

odezvou na přijetí druhým systémem synchronního požadavku od prvního programu, poslání požadavku třetímu programu jako asynchronní komunikace, přičemž asynchronní požadavek obsahuje identifikátor relace přiřazený druhým programem ve druhém systému;

po přijetí druhým systémem komunikaci, přiřazení odpovědi programu s použitím identifikátoru poslání odpovědi prvnímu programu;

odpovědi na k požadavku relace, aby asynchronní od prvního se umožnilo poslání odpovědi prvnímu procesu v synchronní komunikační relaci, kde odpověď poslaná prvnímu procesu obsahuje předběžnou odpověď obsahující identifikátor relace ý v .';·,?. .·' ,;'./

PU sířg -HP

4» 44 44

4 4 4 4 4

4 4 « 4·

4 4 4444 4

4 4 4 4 pokud není přijata žádná odpověď na asynchronní komunikaci před vypršením předem nastaveného časového období.