Beszerzési Ajánlások

Miniszterelnöki Hivatal Informatikai Koordinációs Iroda

Informatikai Tárcaközi Bizottság ajánlásai

Beszerzési Ajánlások

Az X/Open XPG4 (XPG3) specifikációi és a GOSIP4 kormányzati OSI profil alapján

7. sz. ajánlás

Budapest, 1994

2

INFORMATIKAI TÁRCAKÖZI BIZOTTSÁG

Beszerzési Ajánlások

3

A kiadványt készítette a Miniszterelnöki Hivatal Informatikai Koordinációs Iroda megbízásából az MTA KFKI és az MTA SZTAKI.

4

Az Informatikai Tárcaközi Bizottság beszerzéspolitikai állásfoglalása

A Magyar Köztársaság Kormányának 1039/1993. (V.21.) határozata a központi államigazgatási szervek informatikai fejlesztésének koordinálásáról 1. pontjában tárgyalja, hogy "az informatika területén az Európai Közösség elôírásaihoz igazodó kormányzati ajánlásokat kell kibocsátani...", amelyeknek többek között "...biztosítaniok kell a nyílt rendszer elv érvényesítését...". Ezzel összhangban és az 1993. szeptember 14-ei ülésen hozott határozatának megfelelôen az Informatikai Tárcaközi Bizottság a következô, fontossága miatt szó szerint idézett beszerzés-politikai állásfoglalást hozza nyilvánosságra: "A kormányzati informatikai beszerzéseknél a tendereztetôknek versenytárgyalási felhívásaikban célszerû hangsúlyozniok, hogy a nyílt rendszerek szabványaira épülô termékeket kívánnak alkalmazni, amelyek megfelelnek a GOSIP valamint az X/Open XPG specifikációinak. A beszerzôknek tisztázniok kell potenciális szállítóikkal, hogy termékeik jelenleg és szándékaik szerint a jövôben milyen mértékben felelnek meg az említett szabványoknak és specifikációknak, s elônyben kell részesíteniök azokat a szállítókat, amelyek komolyan elkötelezték magukat a nyílt rendszerek iránt. A GOSIP kormányzati profilt illetôen az Egyesült Királyságban elfogadott GOSIP4, az X/Open XPG-vel kapcsolatban pedig az XPG3 és XPG4 specifikációk az irányadóak." Az állásfoglalást támogató háttéranyagként az Informatikai Tárcaközi Bizottság kormányzati informatikai ajánlásai sorozatának 6. köteteként kiadta az X/Open specifikációknak megfelelô nyílt rendszerû termékek útmutatóját, amelyet évente kétszer az új védjegyezett termékek miatt frissített kiadásokban kíván megjelentetni. Ezen újabb 7. sz. ajánlás már az ajánlott terméklista rendszerezésének megfelelô beszerzési ajánlásokat tartalmazza egyrészt az X/Open XPG4 specifikációira, másrészt pedig a GOSIP 4 kormányzati OSI profilra alapozva.

5

Tartalomjegyzék

1 Bevezetô................................................................................................................................. 8 2 Az Ajánlások célja és alapfogalmak........................................................................ 8 3 Az Ajánlások felhasználóinak köre..........................................................................9 4 Az Ajánlások felépítése..........................................................................................10 5 A szabványosítás szerepe a kormányzati informatikai beszerzéspolitikában.......................11 6 Szabványok fogalma és típusai.............................................................................. 11 7 A szabványok alkalmazása a beszerzéspolitikában................................................12 8 A szabványosítási folyamat....................................................................................13 9 A szabványosítás és a nyílt rendszerek.................................................................. 15 10 Az X/Open XPG és a GOSIP szabványkör áttekintése......................................................17 11 Az X/OPEN és az XPG védjegyek ..................................................................... 17 12 Az X/Open és a nyílt rendszerek............................................................17 13 Az X/Open mûködése............................................................................ 18 14 Az XPG dokumentumok........................................................................ 21 15 XPG3..................................................................................................... 22 16 XPG4..................................................................................................... 24 17 GOSIP.................................................................................................................. 28 18 A GOSIP célja....................................................................................... 28 19 GOSIP szervezetek................................................................................ 29 20 EPHOS...................................................................................................29 21 Részletes XPG4 ajánlások..................................................................................................31 22 Operációs rendszer és nyelvek............................................................................. 31 23 Rendszerhívások és könyvtárak............................................................. 31 24 Parancsok és segédprogramok............................................................... 33 25 C nyelv................................................................................................... 36 26 COBOL nyelv........................................................................................ 37 27 Pascal nyelv........................................................................................... 37 28 FORTRAN nyelv................................................................................... 38 29 Ada nyelv............................................................................................... 39 30 Adatkezelés.......................................................................................................... 39 31 Indexszekvenciális adatelérési módszer (ISAM)................................... 39 32 Relációs adatbázis..................................................................................40 33 Felhasználói felület.............................................................................................. 42 34 Terminálcsatoló..................................................................................... 42 35 Grafikus felhasználói interfész...............................................................43 36 Általános együttmûködés..................................................................................... 45 37 Byte Stream File Transfer (BSFT).........................................................45 38 X.400 átjáró........................................................................................... 46 39 X.400 üzenetelérés.................................................................................48 40 Katalóguselérés...................................................................................... 50 41 Hálózati állományrendszer (NFS)..........................................................52 42 Transzport szolgáltatások (XTI)............................................................ 54 43 Együttmûködés nagyszámítógépekkel................................................................. 56 44 CPI-C..................................................................................................... 56 45 Együttmûködés PC-kkel.......................................................................................57 46 Bevezetés............................................................................................... 57 47 (PC)NFS Szerver................................................................................... 58 48 LMX Szerver......................................................................................... 59 49 Adathordozók.......................................................................................................60 50 Mágneses adathordozók.........................................................................60 51 Részletes GOSIP ajánlások................................................................................................ 63 52 Bevezetés............................................................................................................. 63 53 GOSIP dokumentumok.......................................................................... 63 54 GOSIP-architektúra és az alprofilok......................................................63 55 Alkalmazói profil................................................................................................. 65 56 Állománykezelés — a GOSIP szabvány FTAM fejezete szerint...........66 6

57 Üzenetkezelés — GOSIP MHS............................................................. 71 58 Katalógus szolgálatok — GOSIP DIR...................................................74 59 Virtuális terminál — GOSIP VT Forms................................................ 77 60 GOSIP transzport profil....................................................................................... 80 61 Lokális hálózatok................................................................................... 81 62 Nagykiterjedésû hálózatok.....................................................................82 63 Transzport protokollok.......................................................................... 83 64 Formátum profil................................................................................................... 83 65 Dokumentum csere (ODA).................................................................... 83 66 Elektronikus adatcsere (EDI).................................................................84 67 Karakter készletek..................................................................................85 68 Support profil....................................................................................................... 85 69 Elnevezés és címzés............................................................................... 85 70 Menedzsment......................................................................................... 86 71 Biztonság............................................................................................... 88 72 Tesztelés (vizsgálat) és hitelesítés........................................................................89 73 Konformancia tesztelés (vizsgálat)........................................................ 89 74 Az együttmûködési képesség tesztelése (együttmûködtetés vizsgálat).. 92 75 Harmonizálás......................................................................................... 94 76 A GOSIP használata.............................................................................................96 77 GOSIP a tervezésben és a beszerzésben................................................ 97 78 PICS használata a tervezésben...............................................................97 79 A hivatkozott szabványok és rövidítéseik.......................................................................... 99 80 Hivatkozások....................................................................................................................102 81 Rövidítések.......................................................................................................................103

7

1 BEVEZETÔ 2

AZ AJÁNLÁSOK CÉLJA ÉS ALAPFOGALMAK

A Beszerzési Ajánlások alapvetô célja, hogy ajánlásokat adjon a különbözô kormányzati intézmények informatikai termékeinek és szolgáltatásainak szabványokra alapozott beszerzési programjaihoz. A legfrissebb adatok szerint a kormányzati informatikai beszerzések az európai informatikai piac forgalmának mintegy 1/5 részét teszik ki. Ez az arány valószínûleg még jelentôsebb Kelet-Európában, beleértve Magyarországot is, ahol a gazdaság felvevôképessége az informatikai termékek iránt csökkent, viszont a közigazgatási, és ezen belül a kormányzati IT infrastruktúra modernizálási folyamatának idôszakát éljük. Ezért különös jelentôségû, hogy a kormányzati IT beszerzések szabályozottan, az ún. nyílt rendszerû szabványokra alapozottan történjenek, mert ez biztosítja leginkább a gyártófüggetlen, könnyen továbbfejleszthetô, költségtakarékos megoldásokat. Ezt a célt szolgálta az ismert kormányhatározatnak a nyílt rendszer elvvel foglalkozó része, az ebbôl következô kormányzati beszerzéspolitikai állásfoglalás, majd ezt követôen az elôzô 6. sz. és a jelen 7. sz ITB ajánlások. Mint ahogy az említett állásfoglalás hangsúlyozza, a kormányzati IT beszerzésekre az ITB az X/Open konzorcium által gondozott XPG3 és XPG4 specifikációkat valamint az Egyesült Királyságban a CCTA által kidolgozott GOSIP kormányzati OSI profil legfrissebb 4. változatának ajánlásait tekinti irányadónak. Ez logikusan következik abból, hogy a Magyar Kormány tagja a nyílt rendszerek elterjesztésében komoly szerepet játszó X/Open Felhasználói Tanácsának és a magyar kormányzati informatikában a CCTA célkitûzései és tapasztalatai kezdettôl fogva jelentôs szerepet kaptak. Alapvetô azonban az a tény, hogy az XPG specifikációk és a GOSIP kormányzati profil teljes mértékben lefedik a nyílt rendszerek filozófiáját meghatározó két kérdéskört — az alkalmazások hordozhatóságáét (portability) és a rendszerek együttmûködési képességéét (interoperability). Az alkalmazások hordozhatósága azt jelenti, hogy szabványos programozási felület készletre írt programok egyszerûen átvihetôk minden olyan rendszerre, amelyen ilyen felületet implementáltak. Ezt a hordozhatóságot, amely fôleg a stand-alone rendszerek nyíltságának követelménye, forráskód szinten szabványosított Alkalmazói Programozási Felületekkel (API) biztosítják. Az elosztott rendszerek nyíltságát meghatározó együttmûködési képesség teszi lehetôvé, hogy az alkalmazói folyamatok egymással kommunikációs kapcsolatban lévô számítógépes rendszereken együttmûködhessenek. Az együttmûködési képesség minimális követelményét, a rendszerek összekapcsolhatóságát (connectivity) szabványosított kommunikációs nyelv alkalmazásával valósítják meg, de teljesebb értelmezésben az együttmûködési képesség még megköveteli a szabványosított adatformátumokat és programozási felületeket is. A fogalmak közötti összefüggéseket az ábra szemlélteti.

8

Együttmûködési képesség

Alkalmazás

Hordozhatóság

Alkalmazás

Alkalmazói Programozási Felületek

Háló- Operációs rendszer zat Rendszer

Hordozhatóság

Háló- Operációs rendszer zat Rendszer

Összekapcsolhatóság

A nyílt rendszerek alapfogalmai Az X/Open XPG-jének eredeti specifikációi alapvetôen a hordozhatóság követelményeit biztosítják, de az XPG legutóbbi változatai, az XPG3 és fôleg az XPG4 már jelentôsen elmozdultak az együttmûködési képesség irányába is számos szabványosított API beillesztésével a specifikációkba. A különbözô kormányzatok által kidolgozott GOSIP-ok, köztük az EK GOSIP4, valamint az Európai Únió által gondozott EPHOS kézikönyv eddigi változatai viszont csak az együttmûködési képesség biztosítását célozták meg. Ezt fôleg OSI bázison az XPG-ktôl eltérôen nem termék, hanem szolgáltatások és protokollok ún. profilokba szervezett ajánlásaival valósítják meg. Ez a különbség magyarázza a Beszerzési Ajánlások két meghatározó része közötti felépítésbeni eltérést, viszont a nyílt rendszerek kormányzati beszerzéspolitikájának teljeskörû kezeléséhez mindkét szabványcsaládra szükség van. 3

AZ AJÁNLÁSOK FELHASZNÁLÓINAK KÖRE

A Beszerzési Ajánlások elsôsorban a kormányzati intézmények olyan informatikai szakemberei számára készültek, akik az intézmények mûködési stratégiájának leginkább megfelelô információ technológiai változatok kiválasztásáért felelôsek. Az anyagban található információkat és ajánlásokat az intézmények közvetlenül hasznosítják IT rendszereik beszerzésénél. Az ITB szándéka, hogy az Ajánlások az intelligens beszerzéspolitikát szolgálják, amelyben a megoldások sikere a megvalósítási változatok alapos tervezésén és értékelésén alapszik. Végül pedig az Ajánlások hasznosak lehetnek az IT termékek és szolgáltatások olyan szállítói számára is, akik maguk is más szolgáltatók eszközeinek vásárlóivá válhatnak. Hangsúlyozni kell, hogy a szabvány alapú Beszerzési Ajánlások egy átfogó kormányzati informatikai beszerzési kézikönyv szükséges tematikájának csak egyik, bár kétségtelen nagyjelentôségû témakörét tárgyalják. Az ITB-nek szándékában áll egy olyan átfogó beszerzési kézikönyv kiadását elôkészíteni, amely a kormányzati IT tendereztetés szabályozását, valamint a beszerzéspolitika jogi és szervezeti vonatkozásait is magába foglalja.

9

4

AZ AJÁNLÁSOK FELÉPÍTÉSE

Az anyag szerkezetileg négy fontosabb részre tagolódik. A bevezetést követi egy rövid összefoglaló a szabványok világáról, amely tárgyalja a szabványok szerepét a kormányzatok informatikai beszerzési politikájában. A következô 3. fejezet bevezetést nyújt az X/Open, az XPG-k és a GOSIP világába. A 4. és 5. fejezetek tartalmazzák a részletes XPG4 és GOSIP4 ajánlásokat. Az elôbbiben minden XPG4 komponensnél ezek ismertetése után utalás történik a más szabványokkal és az XPG3-mal való kapcsolatra, majd ezután következnek a tényleges ajánlások. Fontos tudni, hogy a komponensek tárgyalása teljes mértékben követi a 6. sz. ajánlás (Termék Útmutató) frissített változatának rendszerezését, ami a tájékozódást a két anyagban kölcsönösen megkönnyíti. A GOSIP-pal foglalkozó 5. fejezet részletesen ismerteti a GOSIP profiljait, kitér a tesztelésre és hitelesítésre, majd a GOSIP használatára. Befejezésül az érdemi anyagot a hivatkozott szabványok, irodalmi hivatkozások, valamint a rövidítések jegyzéke zárja.

10

5

A SZABVÁNYOSÍTÁS SZEREPE A KORMÁNYZATI INFORMATIKAI

BESZERZÉSPOLITIKÁBAN

6

SZABVÁNYOK FOGALMA ÉS TÍPUSAI A "szabvány" fogalmának ma már sokkal tágabb értelmezése van, mint néhány évvel ezelôtt. Mostanra szabványnak tekinthetünk bármilyen "házon belüli" megkötést, gyakorlati útmutatót éppúgy, mint a hagyományos nemzetközi szabványintézmények hivatalos kiadványait. Ez a tágabb értelmezés gyakran vezethet félreértésre. A szabványok két alapvetô típusát különböztetjük meg: a formális és az informális szabványokat. Az elôbbieket legális, vagy de jure szabványoknak is hívjuk, hiszen azok formálisan szabványkiadásra jogosult, akkreditált nemzeti vagy nemzetközi intézmények kiadványai. Jellemzô példa ilyen szabványokra a FORTRAN 77, vagy az OSI modell szerinti FTAM, X.400 vagy X.500. Nemzetközi szabványokat a nagyobb nemzetközi szakmai csoportosulások (pl. IEEE, vagy IEC), vagy az ISO, a Nemzetközi Szabványosítási Szervezet hozhat létre. Az ábrán néhány hivatalos szabványosítási szervezet látható, amelyek mûködési területük szerint lehetnek nemzetköziek, regionálisak (pl. Európa), vagy országosak. ISO/IEC

ANSI

BSI

Egyesült Államok

EIA

DIN

Anglia

IEEE

Nemzetközi

Országos

Németország

NIST

X3

Az ANSI által akkreditált szabványfejlesztô szervezetek

Néhány jelentôs szabványosítási szervezet Az ISO-ban a szabvány-alkotási és -fejlesztési munkákat mûszaki csoportok irányítják (TC, Technical Committee). Azokon belül albizottságok vagy munkacsoportok dolgoznak egy-egy részterület lefedésére. A nemzetközi részvételû munkacsoportokban a szabványtervezetekbôl néhány szavazásos ciklus során születnek meg a Draft International Standard (DIS) minôsítésû dokumentumok, majd újbóli 1-2 szavazási ciklus révén jönnek létre az International Standard (IS) minôsítésû, végleges szabványok. Informális, vagy de facto szabványokat tipikusan olyan intézmények fejlesztenek ki és terjesztenek, amelyek széleskörû ipari elismertséggel, kapcsolattal rendelkeznek, de nincsen formális akkreditáltságuk. Ilyenre példa az X/Open, az OSF vagy a UNIX International. Ezek a cégek olyan dokumentumokat tettek közzé, amelyek szerint felépített fejlesztések 11

bizonyították ipari hasznosságukat, mint pl. az OSF MOTIF, a SUN NFS, vagy az AT&T UNIX. A szabványokat megkülönböztethetjük hatókör szerint is. Egyes felhasználók, alkalmazók saját, belsô elôírást, szabványt írhatnak elô (üzemi szabvány), vagy egyes csoportok közös megállapodás szerint dolgozhatnak (szakmai). A technológia szerinti elkülönülésben az iparág-specifikus szakmai szervezetek köthetnek megállapodást, igy jöhetnek létre az országos vagy regionális szabványok. A kormányzati, közigazgatási beruházások rendszeres volta miatt eddig általában formális szabványokat használtak a felhasználói igények specifikálására; megvárták, amíg a de jure szabványok végleges változatukban, kinyomtatva kerültek el a felhasználókhoz. Manapság egyre inkább elfogadott, hogy a szabványokat már DIS státuszuk idôszakában alkalmazzák, és ez tükrözi azt az elégedetlenséget, hogy a nemzetközi szabványok csak évek elteltével válnak érvényes IS-ekké. Nagyobb felhasználói csoportok érdekei kényszerítô hatással vannak a formális szabványosítási szervezetekre, hogy hatékonyabban hozzanak létre gyártófüggetlen specifikációkat. A specifikáció-fejlesztéshez szükséges idôtartam fordítottan arányos a széleskörû elfogadtatással. Minél nagyobb konszenzusra pályázik egy specifikáció, annál hosszabb idôt vesz igénybe annak stabilizálása. A formális szabványalkotók úgy próbálnak széleskörû konszenzust elérni, hogy nyitottá teszik munkacsoportjukat minden érdekelt elôtt. Igy nagyobb az esély, hogy a végsô szabvány minden fél részére elfogadható lesz. A formális szabványok további jellegzetessége, hogy egységes a külalak, a nyelvezet és az ellenôrizhetôség. Az informális szabványfejlesztô csoportok sokkal gyorsabban juthatnak végeredményhez. Mivel a fejlesztô csoportok nem nyitottak, így korlátozott a fejlesztôi csoport létszáma, hamarabb érhetô el a konszenzus. Az informális szabvány létrejötte után gyakori, hogy a szabványt átadják a formális szabványfejlesztôknek, azoktól várva a tartalmi változtatás nélküli, formai kidolgozás befejezését. 7

A SZABVÁNYOK ALKALMAZÁSA A BESZERZÉSPOLITIKÁBAN A beruházásoknál a szabványok figyelembevételét három fô tényezô befolyásolja: 1

a szervezet mérete,

1

a szükségletek mértéke,

1

a jövôbeli üzleti fejlôdés iránya.

Nemzetközi érdekeltségû nagy cégek szívesen alkalmaznak nemzetközi formális szabványokat, hiszen a különbözô országokban eltérô szabványokkal csak széttördelnék a termék gyártási folyamatát. Kisvállalatok könnyen választhatnak egyedi, nem-szabványos megoldásokat, a kockázatuk jelentôsen alacsonyabb. Jó példa a szabványok alapján történô beruházásokra az amerikai kormányzati szervek példája. A hatvanas és hetvenes években a kormányhivatalok mind ki voltak szolgáltatva a gépek beszállítóinak. A 12

felhasználói tudás és tapasztalat növekedésével a gyártók kénytelenek voltak jobban figyelembe venni a felhasználói érdekeket, és mára már ott tart a kapcsolat, hogy a felhasználói igények megjelennek a szabványokban, elôírásokban, így azok már a technológiai fejlôdés, fejlesztés korai szakaszában képesek beépülni a formális elôírásokba. A kormányzati tapasztalatok a kis- és középméretû vállalkozásoknak is jó példával tudnak szolgálni. Megoldható, hogy a formális szabványosítási eljárásban még nem szereplô funkcionális specifikáció miként választható ki. A felhasználóknak ismerniük kell a technológia adta lehetôségeket és korlátokat, ugyanakkor képeseknek kell lenniük a saját igényeik, funkcionális követelményeik megfogalmazására. Ehhez egy folyamatos párbeszéd szükséges a gyártók és alkalmazók között. Ennek hiányában a félreértések elkerülhetetlenek, és már csak a leszállított, installált rendszereken derül ki, hogy melyik funkció miért is nem tud mûködni. A gyártók és felhasználók közti kapcsolat egyik intézményesített formáját éppen a szabványosítási folyamat, és az ennek eredményeképpen elkészülô szabványok alkotják. Persze a beszerzési folyamatban a számtalan szabvány közötti választás során sok szempontot kell mérlegelni. Néhány ezek közül: Nyitottság Az egyes hivatalos és nemhivatalos szabványosítási szervezetek nagyon eltérôek abból a szempontból, hogy a felhasználók és gyártók széles rétegének, vagy csak egy szûk csoportnak az egyetértését tükrözik. Általában a hivatalos szabványok ebbôl a szempontból nyitottabbak. Érettség Gyakran az éppen szükséges funkcionális területen nincsen érvényes szabvány, csupán egyeztetés alatt álló szabvány tervezet. Ezek felhasználása egyfelôl így is értékes támpontul szolgálhat a tervezésnél, viszont kiforratlanságuk miatt nagymértékben eltérhetnek a leendô végleges szabványtól, és ez inkompatibilitáshoz vezethet. A szabványtervezet érettségét viszonylag könnyen megállapíthatjuk, ha megvizsgáljuk a specifikáció történeti fejlôdését. Stabilitás Amíg az érettség a szabvány történeti fejlôdését jellemzi, addig a stabilitás azt mutatja, hogy mennyire gyors a specifikációk változása. Idôrôl idôre még a már elfogadott szabványokat is felülbírálják, módosítják. A stabil szabványok csak ritkán kerülnek módosításra. Területi érvényességi kör Nyilván legnagyobb érvényességi területe a nemzetközi szabványoknak van, ennél szûkebb hatósugarúak a regionális (pl. európai) és nemzeti szabványok. A beszerzés során azonban nem automatikusan a nagyobb hatósugár a döntô, hanem az, hogy az üzleti alkalmazás és a választott szabványok hatósugara megegyezzen. 8

A SZABVÁNYOSÍTÁSI FOLYAMAT Valamennyi egységesítési vagy szabványosítási folyamatra jellemzô, hogy rendelkezik egy életgörbével, amely egy fordított teknôhöz hasonlítható. A 13

kezdeti idôszakaszban a szabványok újszerûségükkel még csak kevés alkalmazásban kaphatnak helyet, és több más — részben korábbi, részben szintén új keletû — szabvánnyal kell felvenniük a versenyt. Általában egy szabvány kialakulása több évig tart. Az egyik eset az, amikor egy meglevô, már kipróbált alkotás válik olyan sikeressé, hogy a gyártó(k) vagy alkalmazók kívánják az adott terméket vagy technológiát szabványosítani. A másik esetben egy még nem termékké érett, inkább elméleti eredményre épülô gondolat, vagy eljárás kerül szabványosításra. Jelen témakörben tipikusnak tekinthetô példa az elsô esetre az Ethernet, míg az OSI referenciamodell jól szemlélteti az utóbbi esetet. A szabványok elfogadtatása akár több évet is igényelhet. Ha csak pusztán arra a kötelezô szabványosítási munkamenetre gondolunk, amelyben 3 ill. 5 hónapos hozzászólási lehetôséget kell biztosítani az ISO tagországai számára, hogy szabványosítási szakértôik véleményezhessék a javasolt szabványtervezetet, látható, hogy a végsô eredmény elérése, egy szabványterv IS státuszúvá válása, néhányszoros szavazási procedúrával valóban több évesre tevôdik össze. Egy szabvány élettartama több mindentôl is függ. A szabványokat több ízben fel is újíthatják, fejleszthetik, bôvíthetik. Elôbb utóbb azonban bekövetkezik az az idôszak, amikor már gátolja az új termékek, technológiák elterjedését. Kívánatos lenne, hogy amikorra egy szabvány eléri a kiöregedési idejének kezdetét, addigra megszülethessen az azt kiváltó új (minél magasabb hatáskörû) szabvány. A gazdaságilag fejlett országok a mûszaki szabványalkotói tevékenységekbôl igen jelentôsen kiveszik részüket. A kormányok saját szabványosítási szervezeteket tartanak fenn azokon a kulcsterületeken, amelyek várhatóan befolyásolják az adott ország ipari, gazdasági vagy szolgáltatásbeli teljesítôképességét. Az alábbiakban röviden megemlítünk néhány ilyen szervezetet, amelyek talán a téma fontosságából eredôen ránk is külön hatással lehetnek. Az USA-ban mûködô IEEE mérnökszervezet nevéhez fûzôdik a híres 802-es szabványsorozat, amelyet késôbb szinte valamennyi információs hálózattal foglalkozó szervezet átvett. Az USA-beli NBS (National Bureau of Standards) intézményt néhány évvel ezelôtt átkeresztelték, és most National Institute of Science and Technology a neve. Jelenleg ez a szervezet foglalkozik a funkcionális szabványok kidolgozásával. A hierarchiában tehát az EIA, az IEEE, a NIST, stb. szervezetek terjesztik elô az ANSI (Amerikai Szabványhivatal) számára a javasolt specifikációkat. Európában is nagy hagyományai vannak a szabványügynek. A funkcionális szabványokat leginkább a CEN (Európai Szabványosítási Bizottság) és a CENELEC (Európai Elektrotechnikai Szabványosítási Bizottság) hozza létre Európai Szabvány (EN) vagy Európai Elôzetes Szabvány (ENV) néven. A Nyílt Rendszerek kérdéskörében a szabványokat az ETSI (Európai Távközlési Szabványügyi Intézet) és az EWOS (Európai Nyílt Rendszerek Munkacsoportja) dolgozza ki leginkább, de ezek mellett sorolhatjuk fel a szûkebb szakmai részterületet lefedô egyéb szabványalkotói csoportokat is, mint pl. az EMUG (a MAP gyártásautomatizálási protokollra,), az OSITOP, a felsôbb rétegekre, vagy a SPAG, ahol a tesztelést, konformancia és együttmûködési képesség teszteket szabványosítanak. Az európai érdekeltek ,

14

mint pl. a DIN, a BSI, az EWOS, stb. már egy harmonizált véleménnyel képviselik a kontinens érdekeit a legfelsôbb (ISO/IEC) fórumokon. Japánban és Ausztráliában is megtalálhatók a megfelelô regionális szabványközpontok, és azok mind kiegészülnek ún. Open Implementors Workshop (OIW) fórumokkal. Ezeken a fórumokon harmonizálják a régiók az esetleges eltérô igényeket és specifikációkat, majd innen terjesztik a kidolgozott szabványterveket az ISO , IEC, vagy a közös JTC1 elé. Ezen struktúra felvázolásával kívántuk érzékeltetni, hogy a fejlett országok milyen jelentôs ráfordítással igyekeznek a gyorsan fejlôdô technológia mellett egységes szabványokra épülô megoldásokat kikényszeríteni. 9

A SZABVÁNYOSÍTÁS ÉS A NYÍLT RENDSZEREK

Az eddigiekben a szabványalkotó folyamat formális csatornáját említettük meg, ugyanakkor napjainkban egyre fontosabb az informális szabványalkotói folyamat, amelyet a nyílt rendszerekkel foglalkozó szervezetek (X/Open, OSF, UniForum, ...) mûködtetnek. Ezek a szervezetek gyártók, vállalatok és felhasználók közös érdekeltségû csoportjai. Nem rendelkeznek akkreditált mûködési joggal, de potenciáljukkal hatni tudnak arra, hogy mely témaköröket és milyen technológiákat, vizsgáljanak meg a formális szabványalkotó testületek. Ezek a szervezetek igyekeznek olyan részeket, architektúrát vagy közös alkalmazói környezetet definiálni, ahol alkalmazhatók a de facto vagy az általuk kifejlesztett informális szabványok. Ide kapcsolódik az úgynevezett nyílt rendszer fogalma, amelynek egyes komponensei a külvilág felé egységes, lehetôleg gyártófüggetlen és szabványokon alapuló interfészeket nyújtanak, valamint a felhasználók és fejlesztôk szempontjából a lehetô legkonzisztensebb felületet próbálják meg biztosítani. Az ilyen rendszerek segítenek összehangolni a különbözô hardver és szoftver termékek használatát, és nagy befolyással vannak a piaci versenyre. Mivel a nyílt rendszerek a pillanatnyi felhasználói igényekhez igazodnak, amelyek olyan területeken is jelentkezhetnek, ahol formális szabványok még nincsenek, kénytelenek áthidalni a szabványosítási folyamatban lévô hézagokat. Az általuk ilyen hézagpótlásra javasolt technológiákat azután szabványnak javasolják, vagy megpróbálják a készülô szabványokkal összeegyeztetni. A nyílt rendszerek alapvetô elônye a gyártófüggetlenség. Mivel a különbözô gyártóktól származó szabványos rendszerkomponensek kompatibilisek egymással, a felhasználó minden összetevôt attól szerezhet be, aki az adott területen a legjobb minôséget vagy ár/teljesítmény mutatót produkálja. Ráadásul késôbb is áttérhet másik szállítóra anélkül, hogy a gyártók közötti váltás kihatna az alkalmazói rendszer egészének mûködôképességére. Érdemes azonban néhány további elônyt jelentô szempontra is felhívni a figyelmet a nyílt rendszerekkel kapcsolatban:

15

1

Megbízhatóság. Mivel elfogadott szabványokra épülnek, a nyílt rendszerek alaposan megtervezettek, teljesítményük megjósolható, és biztosított a kompatibilitás a késôbbi verziókkal.

1

Nagyobb választék. Mivel több gyártó is kínál alkalmazást azonos feladatra, a felhasználó a kedvezôbb ár vagy a hozzáadott szolgáltatások alapján választhat.

1

A felhasználói ismeretek nem évülnek el. A rendszer kezelése, a parancsok és segédprogramok, a felhasználói felület mind szabványosak, tehát amit a felhasználó az egyik rendszeren megtanult, a másik rendszeren is alkalmazhatja.

1

Nyitottság más rendszerek felé. A nyílt rendszerek képesek egymással kommunikálni és adatokat cserélni. Fejlettebb rendszerek közösen oldanak meg egy feladatot.

1

Az adatbázisok hordozhatóak. A régóta használt nagy adatbázisok a felújított rendszerben is használhatók maradnak. Ugyanígy adatbázisok átvihetôk egyik rendszerbôl a másikba.

Az elônyöket áttekinthetjük az elônyt élvezôk szemszögébôl is. A rendszerek gyártói számára kedvezô, hogy: 1

a nyílt rendszerekre készült termékek egyszerûen áttehetôk az ô rendszerükre,

1

a rendszerük kommunikálni tud más nyílt rendszerekkel.

Az alkalmazások gyártói számára elônyös, hogy: 1

az alkalmazást több rendszerben is lehet használni, tehát nagyobb a piaca.

A felhasználó számára elônyös, hogy: 1

rendszertôl független és egységes a környezet,

1

nagyobb a termékek választéka.

S zabványok K ö te le z ô

K onzorcium ok aján lásai

O p c io n á lis

Ú jítások

A mûszaki újdonságok megjelenése a szabványokban Az is kétségtelen azonban, hogy a szabványok illetve a nyílt rendszerek alkalmazása egyfajta innovációs hátránnyal jár. Mivel az egyeztetési folyamat lassú, a legújabb mûszaki eredmények csak késve épülnek be a szabványokba, ajánlásokba. Az innovációs hátrány leginkább a hivatalos szabványok kötelezô részében, legkevésbé pedig az ipari konzorciumok nem hivatalos ajánlásaiban jelentkezik.

16

10

AZ X/OPEN XPG ÉS A GOSIP SZABVÁNYKÖR ÁTTEKINTÉSE

Mielôtt részletesen megvizsgálnánk az egyes technológiai részterületekre vonatkozó mûszaki ajánlásokat, ebben a fejezetben egy átfogó ismertetést adunk a kormányzati szféra számára legfontosabb két szabványcsoportról, az X/Open szervezet XPG specifikációiról és a GOSIP ajánlásokról. Ezzel az áttekintéssel egyrészt az a célunk, hogy háttérinformációval szolgáljunk az említett szabványokat kidolgozó szervezetekrôl és az általuk felügyelt szabványosítási folyamatról. Ezen kívül az X/Open és a GOSIP ajánlások szerkezetének és fô jellemzôinek összefoglalásával azok tájékozódását is szeretnénk segíteni, akik nem kívánnak az egyes részterületekkel olyan mélységben megismerkedni, ahogyan azokat az útmutató további fejezetei taglalják. 11

AZ X/OPEN ÉS AZ XPG VÉDJEGYEK

12

Az X/Open és a nyílt rendszerek

Az X/Open szervezet küldetése, hogy a nyílt rendszer elvet terjessze, és elôsegítse a nyílt rendszerek gyakorlati megvalósítását. Az X/Open meghatározása szerint az tekinthetô nyílt információs rendszernek, ami gyártófüggetlen számítástechnikai architektúrára épül, vagyis egyes komponensei között hivatalos, illetve széles körben elfogadott ipari szabványok írják le a kapcsolatot. Ezeknek az interfész-specifikációknak a támogatása teremti meg az alkalmazások hordozhatóságát (portability), a rendszerek együttmûködési képességét (interoperability) és a folyamatos bôvíthetôséget (scalability). Az X/Open, gyártósemleges nemzetközi szervezetként, vállalta, hogy mind a gyártók, mind a felhasználók érdekeinek szem elôtt tartásával kiválasztja és ellenôrzött módon továbbfejleszti a hivatalos és nem hivatalos szabványok konzisztens kombinációját, amely lehetôleg a nyílt információs rendszerek egészét lefedi. Az X/Open egyben olyan hitelesítési eljárásokat is kidolgoz, amelyek révén ellenôrizhetô, hogy az egyes termékek eleget tesznek-e az elôírt specifikációknak. Az X/Open Company egy független, non-profit szervezet, amelyet 1984-ben alapított az öt legnagyobb európai számítógépgyártó cég: a Bull, az ICL, az Olivetti, a Nixdorf és a Siemens. A konzorcium késôbb részvénytársasággá alakult át, és jelenleg 15 tulajdonos tagja van, köztük sok multinacionális számítógépgyártó óriásvállalat: Amdahl, Bull, DEC, Fujitsu, HP, Hitachi, IBM, ICL, NCR, NEC, Olivetti, Siemens, Sun Microsystems, Unisys. A 15. tulajdonos 1993 októbere óta a Novell, amely egyidejûleg úgy döntött, hogy a Unix System Laboratories (USL) tulajdonosaként a UNIX védjeggyel kapcsolatos jogokat az X/Open-re ruházza át. A továbbiakban a UNIX operációs rendszer interfész specifikációinak a továbbfejlesztése is az X/Open felügyelete mellett történik. Az X/Open igazgatótanácsa a részvényesek képviselôibôl, a Felhasználói, Rendszergyártói és Szoftvergyártói Tanács elnökeibôl és a vezérigazgatóból áll. Bár az X/Open megalakulásakor a gyártók konzorciuma volt, ma egyre inkább a felhasználói szempontok kerülnek elôtérbe, és erôsödik az X/Open híd szerepe a gyártók és a felhasználók között. Ennek biztosítására három tanácsot hoztak létre.

17

A Felhasználói Tanács (User Council) feladata a nyílt rendszerekkel szemben támasztott követelményrendszer kidolgozása és a prioritások meghatározása annak érdekében, hogy a nyílt rendszerek valóban minél gyorsabban megtérülô beruházást jelentsenek a felhasználóknak. A tanácsban a világ legnagyobb ipari és államigazgatási felhasználói is megtalálhatók. Két magyar tagja van: 1992-ben a magyar kormány is csatlakozott a szervezethez a Miniszterelnöki Hivatal Informatikai Koordinációs Irodája révén, 1993-ban pedig az MTA SZTAKI lépett be. A Független Szoftvergyártók Tanácsa (Independent Software Vendors Council) a nagy szoftverházakat (pl. Novell, Oracle, Informix, Sybase stb.) tömöríti annak érdekében, hogy az X/Open specifikációknak eleget tévô platformokon minél hamarabb sok, jó minôségû alkalmazói szoftver álljon rendelkezésre. A Rendszergyártók Tanácsa (System Vendors Council) dolgozza ki, a részvényes tagvállalatokkal szorosan együttmûködve, a technikai programok java részét. Ôk rendelkeznek a szükséges szakmai háttérrel a gyártó-semleges specifikációk kidolgozásához, és végsô soron ôk készítik el a specifikációkat kielégítô rendszereket. A tanácsok, illetve a köréjük létrehozott munkacsoportok munkájának összehangolására 1989-ben beindítottak egy Xtra nevû programot. Ennek lényege, hogy ciklikusan, minden év végén összesítik a felhasználóktól érkezô tapasztalatokat és követelményeket, s a World Congress on Open Systems rendezvény keretében egybevetik azokat a munkacsoportokban folyó technológiai munkákkal. A tapasztalatok birtokában folyamatosan korrigált projektek állását évrôl évre publikálják az Open Systems Directive címû kiadványban. 13

Az X/Open mûködése A Közös Alkalmazási Környezet specifikálása

Mindenekelôtt az X/Open fejleszti és gondozza annak a Közös Alkalmazási Környezet (CAE) elnevezésû, nyílt informatikai rendszerkörnyezetnek a specifikációját, amely az operációs rendszer szintjétôl a felhasználói felületig, beleértve a hálózati kapcsolatokat is, egy teljes informatikai rendszer mûködését lefedi. Ez a specifikáció-gyûjtemény átfogó és konzisztens keveréke a már hivatalosan elfogadott nemzetközi és nemzeti, valamint a széles körben elterjedt ipari (de facto) szabványoknak. A specifikációkat egy folyamatosan frissített X/Open Portability Guide-ban (XPG) adja közre, amely lényegében ipari konszenzusnak tekinthetô arról, hogy mi is a nyílt rendszer. Az XPG specifikáció komponensekre oszlik a fontosabb témák szerint. A komponensek szintjén valósul meg az az elv, hogy a nyílt rendszer létezô szabványokon alapuljon. Az egyes komponensekre meglévô szabványokon az X/Open csak annyit változtat, hogy szervesen be tudjanak illeszkedni az egész környezetbe. Az X/Open szabványpolitikáját a következôkkel lehet körvonalazni:

18

1

az adott témakörben már létezô nemzetközi, területi és nemzeti szabványok alkalmazására törekszik, ha azok már elég széles körben elterjedtek;

1

kész együttmûködni a szabványok fejlesztôivel, és a késôbbiekben igyekszik az elkészült szabványokhoz igazodni;

1

ha széles körû használatuk indokolja, akkor “de facto” szabványokat is felhasznál;

1

ha a szabvány nem képes megfelelôen beilleszkedni az X/Open rendszerkörnyezetbe, akkor azt saját fejlesztésû vagy az iparban elterjedt bôvítésekkel látja el.

1

Az X/Open-nek szerteágazó kapcsolatai vannak a világ szabványosító szervezeteivel, amilyenek például az IEEE POSIX munkacsoportjai, az objektum-orientált technológiát terjesztô és összefogó Object Management Group vagy az SQL Access Group. Alkalmazások

Objektumkezelés

Rendszerfelügyelet PC-s hálózatok Felhasználói felület

Tranzakciók

Programnyelvek Adatok kezelése

Rendszerbiztonság

Nagygépes együttmûködés Adatcsere

Munkamegosztás

Többnyelvûség

Alapkörnyezet

Az 1992-es CAE vázlata jelzi a legfontosabb fejlesztési területeket A hitelesítési eljárás A specifikációk egyeztetése és terjesztése mellett az X/Open szervezet legfontosabb feladata annak a hitelesítési eljárásnak a felügyelete, melynek során a számítógépgyártók, illetve alkalmazói szoftver fejlesztôk egy XPG védjegyet kaphatnak termékeikre. Ez igazolja, hogy azok eleget tesznek az X/Open Portability Guide ajánlásainak. Ez a hitelesítô program természetesen nem csak a tagok részére nyitott. Ahhoz, hogy egy cég védjegyeket igényelhessen termékei számára, alá kell írnia a védjegy-licencszerzôdést (TMLA, Trade Mark Licence Agreement). Ezzel a szerzôdéssel a gyártó elkötelezi magát az X/Open ajánlások mellett, és vállalja, hogy ha egy hitelesített termékérôl kiderül, hogy valamely ponton mégsem felel meg az X/Open specifikációinak, akkor ezt szoftverhibaként kezeli, és mielôbb kijavítja. Ha ezt nem teszi meg egy bizonyos idôn belül, elveszíti a védjegyet. A védjegy érvényessége úgy is megszûnhet, hogy a hozzá fûzôdô specifikációk elavulnak, és az X/Open újakra cseréli ki ezeket.

19

Ennek következtében az X/Open védjegyek hosszabb idôre is biztosítják a termék specifikációkhoz való konformanciáját. A hitelesítendô termékrôl konformancia kérdôíveket (CSQ, Conformance Statement Questionnaire) kell kitölteni, amelyek a specifikációkhoz való konformancia részleteire és módjára kérdeznek rá. A nyílt rendszereket általában profilokra hitelesítik (a profilok meghatározását lásd a 14 pontban), míg egyes alkalmazások kérhetnek komponensekre szóló védjegyeket. A védjegy tartalmazza a hitelesített profil nevét, de a konformancia pontosabb tanulmányozásához csak a CSQ ad elegendô információt. Az X/Open védjegy egy speciális fajtája a forráskód védjegy. Olyan forráskódú részletekre vonatkozik, amelyeket a gyártók saját fejlesztésû termékeikben felhasználva idôt és energiát takaríthatnak meg. Ilyen védjeggyel rendelkezik például a két alapvetô Unix-forrás is, az SVR4 és az OSF/1. A konformancia kérdôívbôl derül ki, hogy a termék a kötelezô specifikációkon felül milyen további választható részleteket valósít meg. Az egyes specifikációkhoz való konformanciát szintekre osztják aszerint, hogy a tesztelés milyen laboratóriumban történt. A formális szabványok tesztelésére a szabványt kifejlesztô társaság módszereit használják, míg az ún. de facto szabványokéra az X/Open készít eljárásokat. A szoftverek egy harmadik kategóriáját nem célszerû tesztelni, de a gyártónak így is el kell köteleznie magát az X/Open ajánlás mellett. Ha a hitelesítés során kiderül, hogy a termék egyes pontokon nem felel meg az X/Open szabványnak, de ez nem befolyásolja jelentôsen a hordozhatóságot és az együttmûködési képessséget, akkor az X/Open úgy dönthet, hogy engedélyezi a hitelesítés folytatását. Ekkor az egy ideiglenes lemondó nyilatkozatot tesz, amely megengedi a védjegy használatát, de egy éven belül kötelezi a gyártót az eltérés kijavítására. Az ilyen hiányosságok nem derülnek ki a védjegybôl, de megtudhatók a konformancia kérdôívbôl. Az eltérések kijavítását és az egyéb változásokat a gyártónak folyamatosan be kell jegyeznie a konformancia kérdôívbe. Az XPG3 VSX3 elnevezésû tesztelô szoftvere több mint 5500 tesztet tartalmaz. Az Ada, COBOL és FORTRAN nyelvek tesztelésére külsô szabványosító szervezetek (NIST, AJPO) tesztjeit kell használni. A VSX3 a POSIX konformancia tesztelésére is alkalmas. A fejlesztési ciklus Az Xtra programot a fejlesztési ciklus kezdetének tekinthetjük, amikor összegyûjtik a felhasználók tapasztalatait és elvárásait. Ez kétéves folyamat, amelynek elsô évében a fentebb említett felhasználói véleménygyûjtés folyik, a másodikban pedig azt figyelik, hogyan válaszolnak a gyártók a felvetett igényekre. A vizsgálatok tapasztalatait az Xtra világkongresszuson szûrik le, és errôl egy kiadvány is készül Open Systems Directive címmel. A kongresszus a meghatározónak tartott területekhez munkacsoportokat nevez ki, amelyek folyamatosan vizsgálják azokat. A ciklus második fázisa az átfogó tanulmányok alapján kiegészített újabb XPG verzió. Az XPG elsô három verziója nagyjából kétéves idôközökkel követte egymást. Az 1988-ban megjelent hármas verzió (XPG3) volt az elsô, amely széles ipari elismerést kapott. Az XPG4-tôl kezdôdôen a frissítés fo-

20

lyamatos lesz, vagyis azonnal közlik az elfogadott specifikációkat. Ezzel lehetôvé teszik, hogy a gyártók hamarabb elkezdhessék a specifikációk megvalósítását, felgyorsítva az egész X/Open ciklust. A ciklus harmadik elemeként a gyártók elkészítik az XPG-nek megfelelô termékeiket, és negyedik elemként megtörténik azok hitelesítése. Az eközben felhalmozódott gyártói, felhasználói és hitelesítôi tapasztalat befolyásolja a ciklus újraindítását. 14

Az XPG dokumentumok Specifikációk

A specifikációkban találhatók az X/Open által javasolt technológiák részletes leírásai és az interfészek pontos definíciói. A specifikáció alapulhat de jure szabványokon vagy de facto szabványok publikus leírásain. A komponensek már nem tartalmaznak technikai leírást, csak hivatkozásokat a megfelelô specifikációkra. A specifikációk külön kötetekben jelennek meg, nem tartoznak az ún. XPG dokumentumkészlethez, melynek részeit ezután ismertetjük. A komponensek leírása A komponens egy jól különválasztható feladatcsoporthoz ad ajánlást (pl. C nyelv, grafikus felület). Ez a legkisebb egység, amely önállóan hitelesíthetô. Egy komponens négy felülettel írható le: ember-számítógép felület, hordozhatósági felület, adatcsere formátumok és kommunikációs felület. Ezek közül az értelemszerûen feleslegesek elhagyhatók. Az egyes felületeken belül háromféle bejegyzés szerepelhet: specifikáció-hivatkozás, hordozhatósági környezet és konformancia feltétel. A specifikációhivatkozások mondják meg, hogy a komponensnek arra a felületére mely X/Open specifikációk vonatkoznak. A hordozhatósági környezet azokat a további interfészeket sorolja fel, amelyek a komponens adott felületének a mûködéséhez még szükségesek. A konformancia feltételekbôl kiderül, hogyan igazolható az, hogy a termék megfelel a specifikációnak. A profilok tartalma A profilok a számítógép egyes tipikus felhasználásához állítanak össze egy komponenscsomagot, összegyûjtve a felhasználás szempontjából hasznos komponenseket. Az XPG3 és XPG4 Alap Profilja tartalmazza a többnyelvûsített rendszerhívásokat és könyvtárakat, a parancsokat és segédprogramokat, valamint a C nyelvet. Ezt az Alap Profilt bôvíti ki a többi profil további komponensekkel. A profilok segítségével a vásárló egyszerûbben fogalmazhatja meg követelményeit. Az XPG3 és XPG4 profilokkal a késôbbiekben még részletesen foglalkozunk. További anyagok Az XPG dokumentumkészlet a komponensek és profilok leírásán kívül egy útmutatót is tartalmaz a hitelesítéshez. A hitelesítés fontos részeiként megtalálható a védjegy-licencegyezmény (TMLA, Trade Mark Licence Agreement) és az egyes komponensekhez tartozó konformancia kérdôívek (CSQ, Conformance Statement Questionnaire). Végül a hitelesített termékek jegyzéke és az X/Open kiadványainak listája következik, de ezek külön is hozzáférhetôk.

21

15

XPG3

Az XPG3 1988-ban jelent meg, és fô célkitûzése az alkalmazások rendszerek közötti hordozhatósága volt. Az alkalmazások más rendszerre való átvitele úgy történik, hogy a forráskódot a másik rendszeren lefordítjuk. A legfôbb garancia arra, hogy ez sikerül, az operációs rendszer és a C fordító szabványossága. Háttértárolás

Felhasználói felület

Forráskódátvitel

Ablakkezelés

Adatkezelés

Hálózati kommunikáció

ISAM

Transzport szolgáltatások (XTI)

SQL

PC-s kapcsolódás

Operációs rendszer felület Többnyelvûsített rendszerhívások és könyvtárak Parancsok és segédprogramok Terminálcsatoló Folyamatok közötti kommunikáció

Programnyelvek C Ada COBOL FORTRAN Pascal

XPG3 komponensek Forráskódátvitel

Folyamatok közötti kommunikáció

Ada

Ablakkezelés Transzport szolgáltatások PC-s kapcsolódás ISA M

SQ L

COBOL

FORTRA N

Parancsok és segédprogramok

Plusz profil

Terminálcsatoló Pascal Alap profil

Többnyelvûsítés Rendszerhívások és könyvtárak

V álasztható

C nyelv

XPG3 profilok Profilok Az XPG3 összesen 16 komponenst tartalmaz. A hitelesítés egyszerûsítése céljából a komponensekbôl két együtt védjegyeztethetô csoportot alkottak. Az Alap Profil biztosítja azt az alapkörnyezetet, amelyre a többi komponens épül. Komponensei: többnyelvû rendszerhívások és könyvtárak, parancsok és segédprogramok, C nyelv. A “Plus” Profil ezenfelül COBOL, FORTRAN és Pascal fordítókat, adatkezeléshez ISAM-ot és SQL-t, X Window ablakkezelést, adatkapcsolatot a hálózaton keresztül, valamint PC- és terminálkapcsolatot biztosít. További, egyik profilban sem szereplô komponensek: Ada fordító, folyamatok közötti kommunikáció és szabványos mágneses tárolás.

22

Operációs rendszer felület Az operációs rendszer felületnek XSI (X/Open Systems Interfaces Specification) a neve, és alapja a POSIX, illetve a System V Interface Definition (SVID). A többnyelvûsített rendszerhívások és könyvtárak (Internationalised System Calls & Libraries) nevû komponens azokat a rendszerszintû szolgáltatásokat tartalmazza, amelyeket egy C nyelven írt programból el lehet érni. Lehetôvé teszi továbbá a programok többnyelvûsítését, azazhogy a program a felhasználó nyelvén és a helyi sajátosságokat figyelembe véve kommunikálhasson. Ezt a bôvítést az X/Open-nél NLS-nek (Native Language System) hívják. Az NLS eszközöket nyújt ahhoz, hogy a programok futás alatt választhassanak betûkészletet és nyelvet, beállíthassák a speciális formátumokat (dátum, pénzegység stb.), s ennek megfelelôen kezelhessék a szövegeket és reguláris kifejezéseket. A parancsok és segédprogramok (Commands & Utilities) címszó alatt felsorolt eszközök a parancsértelmezôbôl (például Unix shell) indíthatók el. A terminálcsatoló (Terminal Interfaces) a lokálisan csatlakoztatott terminálokat teszi elérhetôvé. Végül egy komponens a folyamatok közötti kommunikációra (Inter-Process Communication) ad lehetôséget. Programnyelvek Egy X/Open nyelvi ajánlásnak megfelelôen írt program bármely X/Open környezetben hiba nélkül lefordítható. Az egyes nyelvi ajánlások a megfelelô ISO vagy ANSI szabványokon alapulnak, de tartalmazhatnak kiegészítéseket az X/Open környezetbe való teljes beillesztés céljából. A C nyelvnek kiemelt helye van, mert a nyílt rendszerek általában C nyelven íródnak. Az XPG3 még nem az ANSI szabványos C-t, hanem a régebbi ún. Common Usage C-t ajánlja. Támogatott nyelv még a COBOL, a FORTRAN, a Pascal és az Ada. Adatkezelés Két komponens támogatja az adatkezelést a nyílt rendszerekben: 1

Az ISAM az egyszerûbb alkalmazásokhoz indexszekvenciális adathozzáférést tesz lehetôvé.

1

Az X/Open SQL az ANSI SQL egy változata, C és COBOL nyelvi beágyazást tartalmaz. Felhasználói felület

A felhasználói felület igen fontos mind a program hordozhatósága szempontjából, mind pedig amiatt, hogy a felhasználók egységes felületet lássanak a különbözô rendszerekben. Az XPG3 a felület alapjául az X Window Systemet választotta, és ehhez ad meg egy C nyelvi csatolót. A komponens neve ablakkezelés (Window Management).

23

Hálózati kommunikáció Az XTI (X/Open Transport Interface) felületen keresztül a különbözô gépeken futó alkalmazások összeköttetést létesíthetnek, és adatokat küldhetnek át egymásnak. Ez a mûködés különbözô hálózati protokollok felett is megvalósítható, a hálózat paraméterei közül csak az összeköttetés átviteli sebessége az, amelyre a programnak esetleg figyelnie kell. A PC-s kapcsolódás (PC Interworking) egyelôre csak terminál emulációt és állományátvitelt biztosít egy nyílt rendszer és PC-k között. Forráskódátvitel A megoldandó probléma itt a forráskód átvitele egyik géprôl a másikra. A hordozó fajtáját tekintve 5,25” hajlékonylemezek és 0,5” mágnesszalagok használhatók, mindkettô többféle felírási formátumban. Az archiváláshoz két segédprogram adott, a tar és a cpio. A gépek közötti hálózatos átvitel a uucp segédprogrammal oldható meg. A komponens neve Source Code Transfer. 16

XPG4 XPG4 komponensek

Az XPG negyedik kiadásának idejére (1992 októbere) a hangsúly a hordozhatóságról az összekapcsolódásra és együttmûködési képességre tolódott. Az együttmûködési képesség alatt az értendô, hogy egy alkalmazás más, esetleg távoli rendszeren lévô alkalmazásokkal képes kommunikálni, adatokat cserélni, munkafolyamatokat közösen végrehajtani. Az XPG egyes kiadásai igyekeznek a legnagyobb mértékû kompatibilitást biztosítani az elôzô verziókkal. Az ezekhez verzióhoz képest bevezetett bôvítések és esetleges javítások, változtatások leírása az XPG4 esetén az XPG3-XPG4 Migration Guide-ban található meg. Együttmûködés nagygépekkel CPI-C PC-s együttmûködés (PC)NFS szerver LMX szerver Általános együttmûködés Hálózati állományrendszer (NFS) Transzport szolgáltatások (XTI) Katalóguselérés X.400 üzenetelérés X.400 átjáró BSFT

Háttértárolás Mágneses adathordozók

Adatkezelés ISAM Relációs adatbázis

Felhasználói felület Terminálcsatoló Ablakrendszer-megjelenítô Ablakrendszer-alkalmazási felület

Programnyelvek Ada COBOL FORTRAN Pascal

Alap operációs rendszer felület Többnyelvûsített rendszerhívások és könyvtárak Parancsok és segédprogramok C

XPG4 komponensek

24

XPG4 Profilok Adatbázis platform profil COBOL Relációs adatbázis Transzport szolgáltatások (XTI) Munkaállomás profil Alap profil Rendszerhívások és könyvtárak Parancsok és segédprogramok C nyelv

Terminálcsatoló Ablakrendszer-alkalmazási felület Ablakrendszer-megjelenítô Transzport szolgáltatások (XTI) Hálózati állományrendszer (NFS) OSI kommunikációs platform profil Transzport szolgáltatások (XTI) X.400 üzenetelérés X.400 átjáró Katalóguselérés BSFT Alap szerver profil Terminálcsatoló Ablakrendszer-alkalmazási felület Transzport szolgáltatások (XTI) Hálózati állományrendszer (NFS) LMX szerver (PC)NFS szerver

XPG4 profilok Az XPG4 22 komponensébôl egyelôre 5 profilt alakítottak ki. Az új komponensek és profilok bevezetése folyamatos. Az Alap Profil (Base) változatlan, három komponense: többnyelvû rendszerhívások és könyvtárak, parancsok és segédprogramok, C nyelv. A jelenlegi profilok egy általános munkaállomást, egy általános szervert, valamint egy OSI hálózat, illetve egy adatbázis elérését lehetôvé tevô konfigurációt adnak meg. Az Alap Szerver Profil (Base Server) egy olyan rendszert ír le, amelyhez többféle karakteres és grafikus terminál csatlakoztatható, hálózaton keresztül is. Komponensei (az Alapon felül): terminálcsatoló, ablakrendszeralkalmazási felület, transzport szolgáltatások (XTI), hálózati állományrendszer (NFS), (PC)NFS szerver, LMX szerver. A Munkaállomás Profil (Workstation) egyfelhasználós, hálózatra kapcsolható, szöveges és grafikus megjelenítési lehetôségekkel rendelkezô környezet. Komponensei (az Alapon felül): transzport szolgáltatások (XTI), hálózati állományrendszer (NFS), ablakrendszer-megjelenítô, ablakrendszeralkalmazási felület, terminálcsatoló. Az OSI kommunikációs lehetôségek széles körével rendelkezik az OSI Kommunikációs Platform Profil (OSI Communications Platform). Komponensei (az Alapon felül): transzport szolgáltatások (XTI), X.400 átjáró, X.400 üzenetelérés, katalóguselérés, BSFT. Az Adatbázis Platform Profil (Database Platform) adatbázisok elérését teszi lehetôvé nyílt rendszeri felületeken keresztül. Komponensei (az Alapon felül): COBOL, relációs adatbázis, transzport szolgáltatások (XTI).

25

Az alapfelület A három idetartozó komponens nagyjából azonos az XPG3-ban leírtakkal. Ezek: többnyelvû rendszerhívások és könyvtárak (Internationalised System Calls & Libraries), parancsok és segédprogramok (Commands & Utilities), C nyelv. A módosítások egyrészt a hibák kijavításából, másrészt az ANSI szabvány C bevezetésébôl és a többnyelvûsített környezet fejlesztésébôl adódnak. Az XPG4 az ANSI C bevezetésével együtt megtartja az XPG3-ban specifikált Common Usage C-t is, így a rendszereknek mindkét változatot támogatniuk kell. A folyamatok közötti kommunikáció bekerült a rendszerhívásokat és könyvtárakat tartalmazó komponensbe. Más programnyelvek A nyelvek listája nem változott az XPG3 óta: Ada, COBOL, FORTRAN és Pascal. Adatkezelés A nyílt rendszerekben azt is biztosítani kell, hogy a különbözô nyelveken írt alkalmazások ugyanazokon az adatokon dolgozhassanak és hogy az adatok könnyen és hatékonyan mozgathatók legyenek az alkalmazások között. Az egyik komponens az indexelt állományokra vonatkozó ISAM, a másik neve relációs adatbázis (Relational Database). Ez utóbbi alapjaiban a nemzetközi SQL szabványnak felel meg, de tartalmaz néhány, gyártók által kifejlesztett hasznos újítást, valamint egy opcionális tranzakció-kezelô interfészt is (XA). Felhasználói felület A karakteres terminálcsatoló (Terminal Interfaces) mellett a grafikus felületet két komponens biztosítja. Az ablakrendszer-megjelenítô (Window System Display) a távoli alkalmazások által vezérelt helyi megjelenítést teszi lehetôvé, az ablakrendszer-alkalmazási felület (Window System Application Interface) pedig az alkalmazásoknak ad módot grafikus megjelenítôk vezérlésére. Magas szintû grafikusfelület-kezelést nyújt, az alkalmazások és a felhasználói felületek hálózati megosztási lehetôségével. Az ablakkezelés alapja az X Window System negyedik verziója, összetevôi pedig Xlib, X Protocol, X Toolkit Intrinsics és Inter-client Communications Conventions Manual. Általános együttmûködés Az XTI-nek (X/Open Transzport Interface) az XPG3-hoz képest módosított és bôvített új változata a transzport szolgáltatásokat többféle (OSI, TCP/IP, UDP/IP, NetBIOS) protokoll felett tudja nyújtani. Néhány jellemzô nem teljesen független a protokolltól, de egy útmutató segít a programozóknak protokollfüggetlen szoftvert írni. A BSFT (Byte Stream File Transfer) állományok hálózati átvitelét valósítja meg. Az X.400 átjáró (X.400 Gateway) olyan alkalmazások építését teszi lehetôvé, amelyek különbözô üzenettovábbító rendszerek között teremtenek kapcsolatot, az egyes üzeneteket a megfelelô formára alakítva át. A szolgáltatás nem csak OSI hálózatok számára használható.

26

Az X.400 üzenetelérés (X.400 Message Access) komponens X.400 típusú üzenettovábbító rendszerek készítésére ad lehetôséget (nem csak elektronikus posta vagy X.400 OSI hálózatokban használható). A katalóguselérés (Directory Access) komponenssel az alkalmazások OSI X.500 katalógust vagy más elnevezés-feloldó mechanizmusokat érhetnek el. A hálózati állományrendszer (Network File System, NFS) segítségével távoli állományrendszerek érhetôk el (kliens mûködés) és ugyanakkor saját állományrendszerek ajánlhatók ki a hálózatra (szerver mûködés). Együttmûködés nagyszámítógépekkel Fontos csatlakozást nyújtani a nyílt rendszerek számára a hagyományos nagygépes rendszerekhez. A CPI-C (Common Programming Interface for Communication) az IBM eredeti megoldásának bôvítése, amellyel IBM-kompatibilis nagygépekhez lehet kapcsolódni. Együttmûködés PC-kkel A (PC)NFS és LMX szerver komponensek azt a célt szolgálják, hogy egy nyílt rendszer állomány- és nyomtató-szolgáltatója lehessen egy DOS vagy OS/2 alapú gépekbôl álló hálózatnak. Az NFS protokoll a nyílt rendszerekben használatos, ezért (PC)NFS szerverrel meglévô nyíltrendszeres hálózathoz csatlakoztathatunk PC-t. DOS vagy OS/2 gépek meglévô hálózatához az SMB alapú protokollokat használó LMX szerver csatlakoztatható. Adathordozók Az XPG3 forráskód átviteli részét felülbírálták, és elhagyták belôle egyes hajlékonylemezek támogatását. A komponens új neve "Magnetic media", Mágneses adathordozók lett. Várható viszont a CD-ROM felvétele az adathordozók közé. Várható újabb profilok és komponensek Az XPG4 további fejlesztési irányvonalának néhány részlete: 1

Az adatbázis-kezelés komponensének kettéosztása egy kliens és egy szerver jellegû komponensre.

1

Az objektumkezelés alapjainak lefektetése az OMG CORBA ajánlása alapján.

1

Az OSI technológiák beépítésének folytatása (X.400, FTAM).

1

Tranzakció-kezeléssel foglalkozó önálló komponensek bevezetése.

1

A grafika területén a GKS és PHIGS szabványok beépítése.

1

A CD-ROM felvétele a támogatott információhordozók közé.

1

Az új komponensek segítségével egy vagy több új profil létrehozása az alábbi témakörökben: osztott számítási környezet, osztott adatbázis-kezelés, tranzakció-kezelés.

27

17

GOSIP

18

A GOSIP célja

Napjaink kommunikációjának egyik legjelentôsebb fogalma a nyílt rendszerek összekapcsolása (Open Systems Interconnection, OSI). Az OSI logikai elveit alkalmazva távoli számítógépek együttmûködhetnek a másik gép jellegzetes paramétereinek, mûködésmódjának ismerete nélkül, csak a kommunikációs felületet kell ismerni. Ez azért is nagy jelentôségû, mert így különbözô gyártók számítástechnikai és hálózati termékei felhasználhatók ugyanabban a hálózatban. Az OSI általános célokra készült, a felhasználók széles köre alkalmazhatja. Az OSI-nak a kormányzatok részére kidolgozott változata a GOSIP (Government Open System Interconnection Profile). A kormányzati szervek részére azért hasznos a GOSIP, mert a mûszaki specifikációk olyan gyûjteménye, amely az OSI termékek megrendeléséhez és hatékony felhasználásához szükséges. A GOSIP-nak több változata létezik, a magyar kormányzatban az Egyesült Királyság GOSIP-ját tekintjük irányadónak.

OSI GOSIP A GOSIP és az OSI viszonya A GOSIP ismeretére elsôsorban azoknak a szakembereknek van szüksége, akik hálózatba kapcsolt kormányzati informatikai rendszereket terveznek és ezek elemeinek beszerzésében döntenek. A GOSIP céljai a következôk: 1

az OSI alapú kommunikációs rendszerek tervezésének és beszerzésének egyszerûsítése,

1

a megfelelô, együttmûködésre képes opciók definiálása és kiválasztása az OSI alapszabványban,

1

az adminisztratív felhasználói környezet követelményeinek pontos és egyszerû specifikálása,

1

az egymástól függetlenül vásárolt rendszerek együttmûködésének biztosítása,

1

a késôbbi, kockázatmentes beruházások, bôvítések elôkészítése,

1

kormányzati intézmények számára az OSI implementálási követelmények biztosítása oly módon, hogy ezek a termék tervezôi számára hasznosak legyenek,

1

a konformancia és az együttmûködési képesség tesztelésének megalapozása.

28

19

GOSIP szervezetek

A GOSIP a hálózatba kapcsolt kormányzati informatikai rendszerek beszerzési útmutatója. Az útmutató csak olyan rendszer elemeket ajánl, amelyeket a nyílt rendszerek összekapcsolásával foglalkozó szabvány családba tartoznak. Ezekkel a szabványokkal nemzetközi, regionális és nemzeti szabványügyi szervek foglalkoznak. Nemzetközi OSI elôírásokat az ISO, CCITT és IEC(International Electrotechnical Commission) készített. Nemzetközi GOSIP elôírások nincsenek. Regionális OSI elôírásokat Európában, Észak-Amerikában és Távol-Keleten dolgoztak ki. Az európai OSI szabvány javaslatokat a CEN, CENELEC, CEPT és ETSI készítette, az amerikai szabványajánlásokat pedig az ANSI és NBS, újabb nevén NIST. A regionális OSI elôírásokat 3 mûhely fogja össze, a regionális GOSIP elôírások ezeken alapulnak. Ilyen mûhely Európában az EWOS (European Workshop for Open Systems), az Egyesült Államokban az OIW (OSI Implementors' Workshop), Távol-Keleten pedig az AOW (Asia-Oceania Workshop). Mind a három regionális mûhely dolgoz ki OSI profilokat és a különbözô országok ezen profilok — értelmes mûködésre alkalmas — részleteit valósítják meg. Az értelmes mûködés azt jelenti, hogy különbözô országokban különbözô, már meglévô rendszerelemekhez (pl. már megvalósított transzport osztályhoz) kell csatlakozni és az alkalmazói célok is eltérôek (pl. elektronikus adatcseréhez kívánják alkalmazni a rendszert). Így nemzeti OSI és GOSIP elôírások jönnek létre. Európában az angol GOSIP (UK GOSIP) a legjobban kidolgozott, legrugalmasabb. Magyarországon is az UK GOSIP 4-et ajánljuk a kormányzati beszerzésekhez. Az UK GOSIP, eltérôen például az US GOSIP-tól, inkább tekinthetô beszerzési specifikációnak mint funkcionális szabványnak. Ez olyan rugalmasabb beszerzési tanácsokat is lehetôvé tesz, amelyek nem a szigorúan vett szabványokra alapozottak. Európában még francia és svéd GOSIP elôírásokat dolgoztak ki, ezenkívül az Egyesült Államokban, Kanadában, Ausztráliában és Japánban van nemzeti GOSIP specifikáció. 20

EPHOS

Az Európai Unió EPHOS (European Procurement Handbook for Open Systems) néven is kidolgoztatott egy beszerzési ajánlás gyûjteményt. Az EPHOS is a nyílt rendszerek összekapcsolásához szükséges termékek és szolgáltatások beszerzési útmutatója. Az EPHOS és a GOSIP célja azonos, a módszer amivel célját eléri eltérô. Az EPHOS az OSI szabványokból indul ki, a GOSIP pedig az Internet meglévô és mûködô elemeibôl, amelyek többnyire TCP/IP bázisúak. A TCP/IP elemeit kívánják tiszta OSI termékekkel lecserélni, és erre a GOSIP egy migrálási stratégiát dolgozott ki. A GOSIP és az EPHOS is beszerzési útmutatót ad az érdeklôdôk kezébe, de eltérés az is, hogy a GOSIP elsôsorban kormányszerveknek, míg az EPHOS általában közigazgatási szerveknek ad beszerzési tanácsot. Magyar fordításban az EPHOS 1. változata került kiadásra, amely azonban már túlhaladottnak tekinthetô. A UK GOSIP 4-hez közelítô EPHOS 2-t 1994 tavaszán fogadták el, és terjedése megkezdôdött. OSI Réteg

ISO 8571 (FTAM) 10021 (MHS) 29

CCITT X.400

7

6 5 4

3

2

1

9041 (VT) 10026 (DTP) 9594 (DS) 8613 (ODA) 9579 (RDA) 9596 (CMIP) 8823 (connection) 9596 (connectionless) 8237 (connection) 9548 (connectionless) 8073 (TP0-TP4, connection) 8602/8072 (connectionless) 8208 (1-3 Réteg) 8348 (connection) 8473 (connectionless) 9542 (IS-IS) 8878 (8208-cal együtt) 8880 (LAN) 8881 (X.25 on LANs) 7776 (LAPB) 3309 (HDLC) 8802.2-.7 (LAN) (IEEE 802.2-.7) 9314 (FDDI) 2110 (EIA-232D) 4902 (EIA-449) 2593 4903

X.500 T.410 Series, T.73 X.226 X.225 X.224

X.25 X.213 (X.25) X.25

V.24, V.28 V.24, V.28 V.35 X sorozatok interfészei Más V sorozatok

A GOSIP szabványok

30

21

RÉSZLETES XPG4 AJÁNLÁSOK

Az ajánlás további részében sorra vesszük az XPG és GOSIP által tárgyalt technológiai részterületeket, és részletesen bemutatjuk az azokhoz tartozó mûszaki ajánlásokat. Mint arra a bevezetôben már utaltunk, az XPG és a GOSIP specifikációk mind irányultságukat, mind a dokumentumok szerkezetét tekintve jelentôsen eltérnek egymástól, ezért mi is két külön fejezetben tárgyaljuk azokat. Ebben a fejezetben az X/Open konzorcium legfrissebb, XPG4-es specifikációit részletezzük, abban a sorrendben, ahogyan az egyes komponensek a 6. sz. ajánlás (Termék Útmutató) frissített változatában követik egymást. A két ajánlás jól kiegészíti egymást, mivel itt az egyes komponensekre vonatkozó mûszaki elôírások részleteivel, ott pedig az elôírásoknak eleget tevô, hiteles teszteredményekkel rendelkezô kereskedelmi forgalmazású termékekkel ismerkedhetünk meg. Az egyes alfejezetekben számos hivatkozást találunk hivatalos szabványokra, X/Open, CCTA és GOSIP dokumentumokra. Ezek a dokumentumok az XPG4 specifikációkban is csak mint hivatkozások szerepelnek, így értelemszerûen az ott szereplô részletes elôírásokat nem szerkesztettük bele mi sem az anyagba. (Kivételt képeznek egyes hivatkozott GOSIP elôírások, ezek közül a legfontosabbak ugyanis az 5. fejezetben szerepelnek.) A hivatkozott dokumentumok listáját a 6. és 7. fejezetben külön is megadtuk. Ezen dokumentumok többsége a Miniszterelnöki Hivatal Informatikai Koordinációs Irodájában megtekinthetô, vagy azok a kibocsátó szervezettôl megrendelhetôk. 22

OPERÁCIÓS RENDSZER ÉS NYELVEK

23

Rendszerhívások és könyvtárak

Az XPG4 Többnyelvûsített Rendszerhívások és Könyvtárak Komponens definiálja a rendszer felületeket és header fájlokat, amelyeket közvetlenül hívnak a C nyelvû programokból és az ahhoz tartozó header fájlokból. Ez a definíció illeszkedik az ISO/IEC 9945-1:1990 (POSIX) szabványhoz. De ez az ISO szabvány csak egy részét adja meg annak a rendszerfelületnek, amely az alkalmazás fejlesztôknek szükséges, valamint választási lehetôségeket és többféle mûködést is megenged. Az X/Open azt szeretné, hogy az ô rendszerfelülete egy ·teljes operációs környezet· legyen, és ezért az sok járulékos interfészt és jellemvonást tartalmaz. Ennek a komponens definíciónak a többnyelvûsítési vonala lehetôvé teszi az anyanyelv használatát és támogatja a különbözô kulturális szokásokat. A definíció gondoskodik a rugalmas választásról a kódolt karakterkészletek esetén. Ez a komponens definíció a hivatkozott XPG4 CAE specifikációk alapfunkcionalitásához való konformanciát követeli meg. A specifikációk négy VÁLASZTHATÓ Tulajdonságcsoportot is megadnak, amelyek az alapfunkcionalitáson felül biztosíthatóak: 1

ISO/IEC DIS 9945–2 C nyelvi kapcsolódás

1

Osztott memória

31

1

Titkosítás

1

Bôvített többnyelvûsítés.

Azt, hogy egy védjegyezett termék milyen további tulajdonságokat biztosít az alapfunkcionalitáson felül, a termékhez tartozó konformancia kérdôívbôl lehet megtudni. Szabványokkal való kapcsolat A két specifikáció, amelyre a Többnyelvûsített Rendszerhívások és Könyvtárak Komponens hivatkozik: 1

X/Open CAE Specifikáció, Rendszerhívások és Header–ek, 4. Kiadás

1

X/Open CAE Specifikáció, Rendszerfelület Definíciók, 4. Kiadás

Ez a két specifikáció a következô formális szabványokhoz illeszkedik: 1

ISO/IEC 9945–1:1990, Információ Technológia – Hordozható Operációs Rendszer Felület (POSIX) – 1. Rész: Rendszer Alkalmazás Programozási Felület (API) [C nyelv] (megegyezik az 1003.1–1990 IEEE szabvánnyal)

1

ISO/IEC DIS 9945–2:1992, Információ Technológia – Hordozható Operációs Rendszer Felület (POSIX) – 2. Rész: Parancsértelmezô és Segédprogramok, Felhasználói Hordozhatósági Kiterjesztés (megegyezik az 1003.2–1992 IEEE szabvánnyal)

1

ISO/IEC 9899:1990, Programozási Nyelvek – C (technikailag megegyezik az X3.159–1989 ANSI szabvánnyal).

Az X/Open CAE Specifikációk illeszkednek az ISO szabványokhoz, de sok olyan funkcionális elemet is tartalmaznak, amelyek vagy nincsenek benne a szabványokban, vagy a szabványok választhatónak minôsítik meglétüket. Az ilyen elemekre mint kiterjesztésekre hivatkozunk. Ezek a kiterjesztések garantáltan egyformák minden az X/Open által védjegyezett platformon, és az X/Open specifikációban külön meg vannak jelölve. Bármely alkalmazói programnak, amelyet úgy készítettek, hogy megfeleljen ezeknek az ISO szabványoknak a kiterjesztéseik nélkül, közvetlenül áttehetônek kell lennie minden X/Open által védjegyezett platformra. Azok a platformok, amelyeket az X/Open nem védjegyezett, megfelelhetnek az ISO szabványoknak, de nem az X/Open specifikációknak, és ezért nem támogathatják az X/Open kiterjesztéseit. Egy alkalmazás megírható úgy, hogy kihasználja az X/Open kiterjesztéseit, de ha a platform nem ment keresztül a védjegyezési eljáráson, akkor nincs garancia arra, hogy az alkalmazás áttehetô a platformra. Ha fontos az, hogy az alkalmazás áttehetô legyen az X/Open által nem védjegyezett platformokra is, kerüljük az X/Open kiterjesztések használatát. Kapcsolat az XPG3-mal Az XPG4 sok interfészt tesz hozzá az XPG3-hoz, valamint kötelezôvé tesz egyes az XPG3-ban még opcionális mûködéseket. Az X/Open CAE Specifikáció, Rendszerhívások és Header–ek, 4. Kiadás 78 új interfészt és 12 új header állományt tartalmaz. Ezenkívül 7 interfészt jelöltek ki visszavonásra, 32

ezek alkalmazását kerülni kell a jövôbeni hordozhatóság fenntartása érdekében. Az XPG4 dokumentum készlet egyik kötete az XPG3-XPG4 Migrációs Útmutató, amely útmutatást ad ahhoz, hogy az XPG3 alkalmazásokat hogyan tehetjük át XPG4 környezetbe. Rámutat, hogy melyek az új alkotó elemek, és melyek azok amelyeket visszavontak, vagy hamarosan vissza fognak vonni. A hatodik fejezet tartalmaz egy táblázatot, amely az egyes interfészek állapotát mutatja be az XPG3 és XPG4 ajánlásokban és az ISO/IEC 9945-1, ISO/IEC DIS 9945-1, és ISO/IEC 9899 szabványokban. Az ötödiktôl a nyolcadik fejezetig bezárólag alapos részletességgel tárgyaljuk az XPG3XPG4 áttéréssel kapcsolatos kérdéseket. Ajánlások 1990-ben a CCTA azt ajánlotta az intézményeknek (IS Notice No. 10), hogy az ISO/IEC 9945-1 szabványhoz való konformanciát keressék a többfelhasználós rendszerek vagy magas funkcionalitású munkaállomások beszerzésekor, hogyha követelmény az alkalmazások és a szoftver hordozhatósága különbözô felépítésû gépek között. Hivatkoztak az XPG3-ra is. Ez a tanács most kibôvül az XPG4 Többnyelvûsített Rendszerhívások és Könyvtárak Komponens specifikációjának megjelenése miatt. Számítógépes erôforrások beszerzésekor a vállalati információs rendszerek számára továbbra is lényeges az ISO/IEC 9945-1 szabványhoz való konformancia, különösen akkor, ha ezek megosztottak. Továbbá ajánlott, hogy az 1993 június 1-e után szállított vagy módosított rendszerek esetén az intézmények megköveteljék a termék konformanciáját az XPG4 Többnyelvûsített Rendszerhívások és Könyvtárak Komponens specifikációjához is. Ez az ISO/IEC 9945-1 szabvány opcióinak egységes kiválasztását biztosítja, különösen akkor, ha a négy Jellemzôcsoportban megadott funkciók közül is szükséges néhány. Ahol szoftver alkalmazásokat és segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open ajánlásoknak eleget tevô platformra, a szoftver-fejlesztôk vegyenek figyelembe minden az XPG4 Parancsok és Segédprogramok Komponens specifikációjában adott figyelmeztetést, valamint az XPG3-XPG4 Migrációs Útmutatóban kiemelten szedett figyelmeztetéseket, amelyek a bôvített és szûkített funkcionalitásra vonatkoznak. Ezen felül ne használják az új szoftverekben azokat a parancsokat, amelyeket az XPG4 visszavont vagy kijelölt a visszavonásra, azért hogy fennmaradjon a szoftver hordozhatósága. Azokra a meglévô alkalmazásokra, amelyek az XPG3-hoz igazodnak, és olyan parancsokat használnak, amelyeket visszavontak vagy vissza fognak vonni, terveket kell készíteni arra, hogy adandó alkalommal az XPG4-hez igazítsák. 24

Parancsok és segédprogramok

Az XPG4 Parancsok és Segédprogramok Komponens definíció megadja azokat a rendszerhívásokat és segédprogramokat, amelyeket a parancssor-értelmezôn keresztül elérhetünk. A parancsok és segédprogramok használhatóak

33

terminálról interaktívan vagy script és makró formájában batch üzemmódban, vagy más segédprogramból illetve alkalmazásból hívva. Az XPG4 két specifikáció készletet tartalmaz: a történeti kompatibilitási specifikáció, az X/Open Specifikáció, Parancsok és Segédprogramok, 3. Kiadás, és a POSIX kompatibilitási specifikáció, az X/Open CAE Specifikáció, Parancsok és Segédprogramok, 4. Kiadás, amely illeszkedik az ISO/IEC DIS 9945–2:1992, Információs Technológia – Hordozható Operációs Rendszer Felület (POSIX) – 2. Rész: Parancsértelmezô és Segédprogramok, Felhasználói Hordozhatósági Kiterjesztéshez (amely megegyezik az 1003.2– 1992 IEEE szabvánnyal). 1990-ben a CCTA azt ajánlotta az intézményeknek (IS Notice No. 10), hogy az ISO/IEC 9945-1 szabványhoz való konformanciát keressék a többfelhasználós rendszerek vagy magas funkcionalitású munkaállomások beszerzésekor, hogyha követelmény az alkalmazások és a szoftver hordozhatósága különbözô felépítésû gépek között. Hivatkoztak az XPG3-ra is. Ez a tanács most kibôvül az XPG4 Parancsok és Segédprogramok Komponens specifikációjának megjelenése miatt. Számítógépes erôforrások és termékek beszerzésekor a vállalati, esetlegesen megosztott információs rendszerek számára továbbra is lényeges az ISO szabványhoz való konformancia. Továbbá ajánlott, hogy az 1993 június 1-e után szállított vagy módosított rendszerek esetén az intézmények megköveteljék a termék konformanciáját az XPG4 Parancsok és Segédprogramok Komponens specifikációjához is. Ez az ISO/IEC 9945-1 szabvány opcióinak egységes kiválasztását biztosítja, különösen akkor, ha a négy Jellemzôcsoportban megadott funkciók közül is szükséges néhány. Ezen a komponensen belül az interfészek használatukat tekintve két részre oszlanak: azokra, amelyek egy alkalmazási felületet biztosítanak (alapvetô segédprogramok), és azokra, amelyeket program fejlesztés vagy az alkalmazások migrációja közben használnak (fejlesztôi segédprogramok). Hangsúlyozandó az, hogy ha szükség van a FEJLESZTÔI segédprogramokra valamint a FORTRAN segédprogramokra és az opcionális dis segédprogramra (ld. X/Open CAE Specifikáció, Parancsok és Segédprogramok, 4. Kiadás), akkor ezt az igényt külön meg kell adni. A termék konformancia kérdôívében találhatunk részleteket a támogatott opciókról. Szabványokkal való kapcsolat Azok az XPG4 CAE specifikációk, amelyekre ez a komponens hivatkozik, a következô formális szabványokhoz illeszkednek: 1

ISO/IEC 9945–1:1990, Információs Technológia – Hordozható Operációs Rendszer Felület (POSIX) – 1. Rész: Rendszer Alkalmazás Programozási Felület (API) [C nyelv] (megegyezik az 1003.1–1990 IEEE szabvánnyal)

1

ISO/IEC DIS 9945–2:1992, Információs Technológia – Hordozható Operációs Rendszer Felület (POSIX) – 2. Rész: Parancsértelmezô és Segédprogramok, Felhasználói Hordozhatósági Kiterjesztés (megegyezik az 1003.2–1992 IEEE szabvánnyal)

34

1

ISO/IEC 9899:1990, Programozási Nyelvek – C Nyelv (technikailag megegyezik az X3.159–1989 ANSI szabvánnyal).

A CAE specifikációk egyes elemei nem minden esetben tehetôk át teljes mértékben az ISO/IEC DIS 9945–2 és ISO/IEC 9945–1 szabványokon alapuló rendszerekre. Az ilyen segédprogramok meg vannak jelölve, és a maximális hordozhatóság érdekében használatuk kerülendô. Kapcsolat az XPG3-mal A "történeti kompatibilitási" specifikáció közvetlenül hivatkozik az X/Open Specifikáció, Parancsok és Segédprogramok, 3. Kiadására. Ez megmaradt az XPG4-ben a "POSIX kompatibilitási" specifikáció alternatívájaként, amely viszont az ISO/IEC DIS 9945–2 szabványhoz illeszkedik. Ez lehetôvé teszi a gyártók számára azt, hogy az XPG3 specifikációt megtartva igazodjanak az XPG4-hez, és ezzel idôt ad nekik arra, hogy a kialakuló ISO szabványokhoz hozzáigazítsák a termékeiket. Az X/Open CAE Specifikáció, Parancsok és Segédprogramok 4. Kiadása 35 új segédprogramot tesz hozzá a 3. Kiadásban meglevôekhez, és 5 XPG3 segédprogramot hagy el. Ezenkívül 16 interfészt jelöltek ki visszavonásra, ezek alkalmazását kerülni kell a jövôbeni hordozhatóság fenntartása érdekében. Az XPG4 dokumentum készlet egyik kötete az XPG3-XPG4 Migrációs Útmutató, amely útmutatást ad ahhoz, hogy az XPG3 alkalmazásokat hogyan tehetjük át XPG4 környezetbe. Rámutat, hogy melyek az új alkotóelemek, és melyek azok amelyeket visszavontak, vagy hamarosan vissza fognak vonni. A harmadik és negyedik fejezet vonatkozik a parancsokra és segédprogramokra, ezek részletezik a jelentôs változtatásokat az XPG3-hoz képest. Ajánlások Amikor az intézmények ISO/IEC 9945-1 szabványnak megfelelô platformra keresnek termékeket, követeljék meg, hogy ezek a termékek feleljenek meg az ISO/IEC DIS 9945-2 szabványnak, amennyiben a rendszert 1994 január 1e után szállítják vagy módosítják. Egy közbensô lépésként az intézmények ugyanezt a feltételt mint kívánatost szerepeltessék 1993 június 1-étôl, és adjanak szándéknyilatkozatot arról, hogy ez a feltétel 1994 január 1-étôl kötelezôvé fog válni. Ezen felül ajánlott, hogy az intézmények megköveteljék a termékektôl a konformanciát az XPG4 Parancsok és Segédprogramok Komponens specifikációjához. Ennek célja, hogy egységesítsék az interfészeket az operációs rendszer parancsaihoz és segédprogramjaihoz, valamint hogy biztosítsák a lehetô legjobb áttérési utat a kialakulóban lévô POSIX szabványokhoz. Mivel az XPG4 Parancsok és Segédprogramok Komponenshez lehet illeszkedni mind az XPG3 Parancsok és Segédprogramok mind az ISO/IEC DIS 9945-2 Parancsok és Segédprogramok implementálásával, a vásárlóknak a termék konformancia kérdôívébôl kell megbizonyosodnia arról, hogy ezek mennyire támogatottak a beszerzésre javasolt termékek esetében. Ahol szoftver alkalmazásokat és segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open ajánlásoknak eleget tevô platformra, a szoft-

35

ver-fejlesztôk vegyenek figyelembe minden az XPG4 Parancsok és Segédprogramok Komponens specifikációjában adott figyelmeztetést, valamint az XPG3-XPG4 Migrációs Útmutatóban kiemelten szedett figyelmeztetéseket, amelyek a bôvített és szûkített funkcionalitásra vonatkoznak. Ezen felül ne használják az új szoftverekben azokat a parancsokat, amelyeket az XPG4 visszavont vagy kijelölt a visszavonásra, azért hogy fennmaradjon a szoftver hordozhatósága. Azokra a meglévô alkalmazásokra, amelyek az XPG3-hoz igazodnak, és olyan parancsokat használnak, amelyeket visszavontak vagy vissza fognak vonni, terveket kell készíteni arra, hogy adandó alkalommal az XPG4-hez igazítsák. 25

C nyelv

A C Nyelvi Komponens specifikáció a nyelvi lehetôségeknek egy közös halmazát írja le, amelyet az XPG4-nek megfelelô rendszerek C fordítói támogatni fognak. Szabványokkal való kapcsolat A C Nyelvi Komponens definíció az ISO/IEC 9899:1990, Programozási Nyelvek – C Nyelv szabványra hivatkozik (amely technikailag megegyezik az X3.159–1989 ANSI szabvánnyal),de hogy megkönnyítse az áttérést az XPG3-ról az XPG4-re, az X/Open áthidaló megoldásként fenntartotta az XPG3 definíciót a Common Usage C nyelvrôl (másképpen Kernighan and Ritchie C, K&R C). Kapcsolat az XPG3-mal A C nyelv eredeti definícióját az X/Open az AT&T UNIX System V, Release 2.0 Programozási Útmutatójára (megjelent 1984 áprilisában) alapozta, mivel az XPG3 kiadásának idején még nem létezett nemzetközi szabvány a C nyelvre. Ez a specifikáció a kompatibilitás miatt benne maradt az XPG4-ben. A c89 parancs az ISO C-t hívja be, míg a cc parancs a Common Usage C-t. Az XPG4 dokumentum készlet egyik kötetében, az XPG3-XPG4 Migrációs Útmutatóban a kilencediktôl a tizenhatodik fejezetig foglalkoznak azzal, hogy a programozók hogyan módosítsák meglévô C nyelvû kódjaikat egy XPG4 C fordítóra, és hogyan írjanak új kódot egy ISO C fordítóra. Ajánlások Az ISO/IEC 9945-1:1990 (POSIX) szabványnak megfelelô platformra történô vásárláskor, ha a platformon C nyelvû fejlesztés folyik majd, akkor ajánlott a szállítóktól egy olyan C fordító megrendelése, amely megfelel az ISO/IEC 9989 szabványnak. A házon belül, C nyelven fejlesztett programokat a fejlesztôk ISO/IEC 9989 szabványos C fordítón fordítsák. A fejlesztôk vegyék figyelembe az XPG3XPG4 Migrációs Útmutató tanácsait, amelyek az ISO C szabvány felé irányítják ôket és segítenek elkerülni azokat az XPG3 jellemzôket, amelyeket visszavontak, vagy vissza fognak vonni.

36

26

COBOL nyelv

A COBOL Nyelvi Komponens specifikáció a nyelvi lehetôségeknek egy közös halmazát írja le, amelyet az XPG4-nek megfelelô rendszerek COBOL fordítói támogatni fognak. Szabványokkal való kapcsolat Az X/Open COBOL definícióját az ISO 1989:1985 Programozási Nyelvek — COBOL szabványra (amely az ANSI X3.23-1985 szabvány jóváhagyása) és az ISO 1989/1. Módosítás: Intrinsic Function Module-ra (az ANSI X3.23a1989 szabvány jóváhagyása) alapozta, de elhagyta az összes opcionális modult. Azok a nyelvi elemek, amelyeket az ISO szabvány elavultként jelöl meg, a szabvány következô változatából már ki fognak maradni, és az X/Open definícióban sem szerepelnek. Az XPG4 a következô bôvítéseket adja a COBOL szabványhoz: 1

további lehetôségek a felhasználóval történô online párbeszédre,

1

konzisztensebb és hatékonyabb állomány megosztás és lefoglalás többfelhasználós környezetben,

1

lehetôség az alkalmazások többnyelvûsítésére. Kapcsolat az XPG3-mal

Az XPG3 COBOL definíciója szintén az ISO 1989:1985 szabványon alapult, az opciók és elavult elemek kihagyásával. Az XPG3 kibôvítette a szabványt az online felhasználóval történô párbeszéd támogatásával. Az XPG4 COBOL Nyelvi Komponens specifikációja felfelé kompatibilis az XPG3-éval. Ajánlások Az ISO/IEC 9945-1:1990 (POSIX) szabványnak megfelelô platformra történô vásárláskor, ha a platformon COBOL nyelvû fejlesztés folyik majd, akkor ajánlott a szállítóktól egy olyan COBOL fordító megrendelése, amely megfelel az ISO 1989:1985 szabványnak. A házon belül, COBOL nyelven fejlesztett programokat a fejlesztôk ISO 1989:1985 szabványos COBOL fordítón fordítsák. Ahol szabványbôvítések támogatják a párbeszédes képernyôkezelést vagy az állomány megosztást és lefoglalást, ajánlott, hogy a szállítók és fejlesztôk igazodjanak az XPG4 COBOL Nyelvi Komponens specifikációjához az 1993 június 1-e után implementált alkalmazások esetén. Néhány intézmény kívánatosnak tarthatja a régebbi COBOL '74 szabványnak megfelelô fordító használatát, mivel oly mértékû a befektetésük a COBOL '74 alapú szoftverekbe, hogy ezeket kívánják fenntartani. Az ide vonatkozó szabvány az ISO 1989:1978. 27

Pascal nyelv

Az XPG4 Pascal Nyelvi Komponens specifikáció a nyelvi lehetôségeknek egy közös halmazát írja le, amelyet az XPG4-nek megfelelô rendszerek Pascal fordítói támogatni fognak.

37

Szabványokkal való kapcsolat Az X/Open Pascal definíciója az a formális definíció, amelyet az ISO 7185:1983 (1. szint), Programozási Nyelvek — Pascal szabvány ad meg, de a hordozhatóság javításának érdekében az XPG4 explicit definíciókat ad olyan esetekben, amelyet az ISO szabvány "implementációban definiáltnak" nevez. Részletes információ található ezekrôl az alkotórészekrôl az X/Open Rendszerek és Védjegyes Termékek: XPG4 kiadvány második részében, melynek címe Komponens Definíciók. Kapcsolat az XPG3-mal Az XPG4 Pascal Nyelvi Komponens specifikáció azonos az XPG3-ban találhatóval. Ajánlások Az ISO/IEC 9945-1 szabványnak megfelelô platformra történô vásárláskor, ha a platformon Pascal nyelvû fejlesztés folyik majd, akkor ajánlott a szállítóktól egy olyan Pascal fordító megrendelése, amely megfelel az ISO 7185:1983 szabványnak. A házon belül, Pascal nyelven fejlesztett programokat a fejlesztôk ISO 7185:1983 szabványos fordítón fordítsák. Ha az intézmények javítani akarják a Pascal nyelven fejlesztett alkalmazások hordozhatóságát, ajánlott, hogy a szállítók és a fejlesztôk által 1993 június 1e után szolgáltatott alkalmazások megfeleljenek az XPG4 Pascal Nyelvi Komponens specifikációjának. 28

FORTRAN nyelv

Az XPG4 FORTRAN Nyelvi Komponens specifikáció a nyelvi lehetôségeknek egy közös halmazát írja le, amelyet az XPG4-nek megfelelô rendszerek FORTRAN fordítói támogatni fognak. Szabványokkal való kapcsolat A FORTRAN nyelv X/Open definíciója megegyezik az ISO 1539:1980, Programozási Nyelvek — FORTRAN szabvány formális definíciójával (amely az ANSI X3.9-1978 szabvány jóváhagyása, FORTRAN '77). Kapcsolat az XPG3-mal Az XPG4 FORTRAN Nyelvi Komponens specifikáció azonos az XPG3-ban találhatóval. Ajánlások Az ISO/IEC 9945-1 szabványnak megfelelô platformra történô vásárláskor, ha a platformon FORTRAN nyelvû fejlesztés folyik majd, akkor ajánlott a szállítóktól egy olyan FORTRAN fordító megrendelése, amely megfelel az ISO 1539:1980 szabványnak. A házon belül, FORTRAN nyelven fejlesztett programokat a fejlesztôk ISO 1539:1980 szabványos fordítón fordítsák. Pillanatnyilag elegendô az XPG4 FORTRAN Nyelvi Komponens specifikációra hagyatkozni. Az intézmények azonban vegyék figyelembe, hogy 1990ben megjelent a FORTRAN szabvány egy új változata. A BS 6832 38

segítségével, amely módszert ad ahhoz, hogy hogyan lehet a beszerzô kívánalmait megfogalmazni, valamint ajánl egyes alkotóelemeket, az intézmények fontolják meg az elônyeit annak, hogyha következô feladataikhoz FORTRAN '90-t, azaz ISO/IEC 1539:1991 szabványos FORTRAN-t kérnek. 29

Ada nyelv

Az Ada célkitûzése volt, hogy egy teljes programozási nyelvet és környezetet szolgáltasson. Az XPG4 Ada Nyelvi Komponens specifikáció az ISO szabványos Ada nyelvet vette át. Szabványokkal való kapcsolat Az Ada nyelv X/Open definíciója megegyezik az ISO 8652:1987, Programozási Nyelvek — Ada szabvány formális definíciójával (amely az ANSI 1815a-1983 szabvány jóváhagyása). Kapcsolat az XPG3-mal Az XPG4 Ada Nyelvi Komponens specifikáció azonos az XPG3-ban találhatóval. Ajánlások Az ISO/IEC 9945-1:1990 (POSIX) szabványnak megfelelô platformra történô vásárláskor, ha a platformon Ada nyelvû fejlesztés folyik majd, akkor ajánlott a szállítóktól egy olyan Ada fordító megrendelése, amely megfelel az ISO 8652:1987 szabványnak. A házon belül, Ada nyelven fejlesztett programokat a fejlesztôk ISO 8652:1987 szabványos fordítón fordítsák. Elegendô az XPG4 Ada Nyelvi Komponens specifikációra hagyatkozni. 30

ADATKEZELÉS 31

Indexszekvenciális adatelérési módszer (ISAM)

Az XPG4 ISAM Komponens definíció az X/Open Fejlesztôi Specifikáció, Indexszekvenciális Adatelérési Módszer (ISAM) címû dokumentumra hivatkozik, amely egy kis mértékû szûkítése a C-ISAM nevû termék (2.10-es verzió) specifikációjának. A C-ISAM széles körben elterjedt a UNIX alapú rendszerek alkalmazás fejlesztôi között, és sok vezetô szoftver termék bízza rá a szervezett állományok kezelését. Az X/Open ISAM definíciója elhagyja azokat a részeket a C-ISAM specifikációjából, amelyek implementáció-függôek. Sok alkalmazásnak kell az állományokat rekordok halmazaként kezelnie. Az indexszekvenciális adatelérési módszer (ISAM) indexelt állományok készítésére, kezelésére és változtatására nyújt egy felületet. ISAM állományok C nyelvû interfészeken keresztül és COBOL-ból érhetôk el, bár a COBOL indexszekvenciális állományok kezelésére szolgáló folyamatait le kell cserélni az X/Open kompatibilis ISAM-ra. A C-ISAM-ot használó alkalmazások nagy részét C nyelven fejlesztették és nem használtak változó hosszúságú rekord szerkezetet. Ahol ilyen szerkezetek kezelésére volt szükség, ott inkább választottak adatbázis-kezelô rendszereket és SQL interfészeket.

39

Szabványokkal való kapcsolat Az XPG4 ISAM Komponens definíció opcióként támogatja a változó hosszúságú rekordokat, és ily módon megfelel az ISO 1989:1985 Programozási Nyelvek — COBOL szabványnak (amely az ANSI X3.23-1985 szabvány jóváhagyása). Ez a támogatás azért opcionális, mert C programozási környezetben nem követelmény, de szükséges lehet egy kevert C és COBOL környezetben. Az X/Open szándéka az, hogy a specifikáció következô kiadásában kötelezôvé teszi ezt az elemet. Kapcsolat az XPG3-mal Az XPG3 ISAM Specifikáció, amely az X/Open Specifikáció, Adat Kezelés, 3. Kiadásában található, nem támogatta a változó hosszúságú rekordokat. Ajánlások Ha az intézmények szoftver alkalmazásokat vásárolnak vagy fejlesztenek, és azokat ISO/IEC 9945-1:1990 szabványnak megfelelô platformon és XPG4 környezetben akarják használni, akkor 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén kívánatos azok konformanciája az XPG4 ISAM Komponens definícióhoz. Ez a tanács a szoftver hordozhatóság elôsegítését szolgálja, azonban számoljanak azzal, hogy a nagy állományokat használó vagy sok felhasználóval dolgozó rendszerek teljesítménye így csökkenhet. 32

Relációs adatbázis

Az XPG4 Relációs Adatbázis Komponens definíció hivatkozik az X/Open CAE Specifikáció, Strukturált Lekérdezô Nyelv (SQL) és az X/Open CAE Specifikáció, Osztott Tranzakció Kezelés: XA Specifikáció dokumentumokra. SQL Az SQL XPG4 specifikációjának alapja az Entry SQL-92, de különbözik ettôl annyiban, hogy az "Integrity Enhanced Feature" támogatását opcionálissá teszi, és közvetlenül nem implementálja a CREATE SCHEMA utasítást. Az X/Open szándéka az, hogy a specifikáció következô kiadásában kötelezôvé teszi ezeket az elemeket. Egy javaslat külön kérheti az "Integrity Enhanced Feature" támogatását egy nagy adatbázis esetén. A beágyazási lehetôségek csak C és COBOL nyelvekhez adottak. Továbbá néhány olyan elem is támogatott, amely az Intermediate és Full SQL-92 leírásából származik. Ilyen például a kapcsolatok kezelése, a dinamikus SQL, az ideiglenes táblák és az információs séma. Ezek a megfelelô SQL-92 elemek kompatibilis részhalmazai. A CAE Specifikáció tartalmaz olyan részleteket is, amely az SQL-92 egyetlen szintjén sincs meg. Szabványokkal való kapcsolat Az X/Open CAE Specifikáció, Strukturált Lekérdezô Nyelv (SQL) széleskörben igazodik az SQL szabvány legfrissebb verziójához (ISO 9075:1992 [SQL]), amelyet itt SQL-92-re rövidítünk, de az elôzô fejezetben leírtakban különbözik is attól.

40

Kapcsolat az XPG3-mal Az XPG3 relációs adatbázis definíciója illeszkedik az ANSI X3.135-1986 [SQL], és az ISO 9075:1987 [SQL] szabványokhoz. Az XPG4 a frissebb ISO és ANSI szabványokhoz illeszkedik. Ajánlások SQL alapú adatbázisok vagy ezekhez kapcsolódó termékek beszerzésekor az intézmények minimumként követeljék meg az ISO 9075:1987 [SQL] szabványhoz való konformanciát azokra a rendszerekre nézve, amelyeket 1994 január 1-e után szállítanak vagy lényegesen módosítanak. Kivétel ez alól az az eset, amikor az SQL XPG4 CAE Specifikációja olyan áttérési módszert mutat, amely jobban szolgálja az egyes tervek azonnali szükségleteit. Az intézmények kérjék meg a gyártókat, hogy ismertessék általános irányelveiket az SQL-lel kapcsolatban és jelezzék, hogy termékeik milyen szintû SQL tesztelésen feleltek meg. Figyelembe kell venni azt is, hogy több olyan idevágó témakör van, például az állományok lefoglalási stratégiája vagy a negyedik generációs nyelvek (4GL) használata, amelyet az XPG4 nem tárgyal, de hatással van az alkalmazások hordozhatóságára és együttmûködési képességére. Osztott tranzakció kezelés Az X/Open CAE Specifikáció, Osztott Tranzakció Kezelés: XA Specifikáció egy felületet definiál az erôforrás kezelô (Resource Manager, RM), amely általában egy relációs adatbázis-kezelô, és a tranzakció kezelô (Transaction Manager, TM) között. A tranzakció kezelôk sok különbözô erôforrás kezelô elérését lehetôvé teszik (feltéve, hogy a relációs adatbázis-kezelôk mind támogatják az XA-t), így tehát a heterogén környezetek jó kihasználását biztosítják. Alkalmazás

Erôforrás kezelô

XA felület

4GL

Tranzakció kezelô

Osztott tranzakció kezelés A tranzakció kezelô használatából más elônyök is származhatnak: 1

nagyon sok felhasználót kiszolgálhat jóval kisebb számú alkalmazás és adatbázis szerver, ha a tranzakció kezelô közvetít az alkalmazás program kliens és szerver részei között,

1

a terhelések kiegyensúlyozása és az elsôbbségek kezelése; a tranzakció kezelô automatikusan kiegyensúlyozza az azonos típusú kérések okozta megterhelést a megfelelô szervereken, és ezáltal konzisztens válaszidôket biztosít, 41

1

megfigyeli az operációs környezetet és lehetôvé teszi, hogy az adminisztrátorok közvetlenül válaszoljanak egy alkalmazás sokféle követelményére. Szabványokkal való kapcsolat

Az XA felület akkor alkalmazható, ha az erôforrás kezelôk adatbázis kezelôk vagy nyomtató szerverek. Az X/Open fejleszti az XA felület kibôvített változatát (XA+) is, olyan erôforrás kezelôkhöz, amelyek a rendszerek közötti kommunikációt biztosítják (Communications Resource Manager). Az XA+ felület a tranzakció kezelô és a kommunikációs erôforrás kezelô között helyezkedik el. A kommunikációs erôforrás kezelô szükséges az osztott tranzakciók feldolgozásához, és egy olyan kommunikációs protokollt támogat, mint amilyen az ISO/IEC 10026:1992, Információs Technológia — Nyílt Rendszerek Összekapcsolása (OSI) — Osztott Tranzakció Feldolgozás szabványban van definiálva. Kapcsolat az XPG3-mal Az XA egy új specifikáció az XPG4-ben. Ajánlások Ha az intézmények SQL alapú adatbázisokat és/vagy tranzakció kezelô termékeket szereznek be, amelyeket ISO/IEC 9945-1:1990 szabványos platformon és XPG4-nek megfelelô környezetben használnak majd, akkor keressék az XPG4 XA definíciónak megfelelô termékeket az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén. 33

FELHASZNÁLÓI FELÜLET

34

Terminálcsatoló

Az XPG4 Terminálcsatoló Komponens definíció a curses nevû de facto szabványon alapul. Ez egy C nyelvû eljárás-könyvtár, amely egy termináloktól független módszert ad a felhasználónak a karakteres képernyôk frissítésére ésszerû optimalizálással. Fejlett absztrakciókat tartalmaz, mint például a virtuális képernyôk és ablakok, amelyeket alkalmazások lefoglalhatnak és közvetlenül érhetnek el. A specifikáció karakteres és blokkos terminálokat támogat. Az XPG4 Terminálcsatoló Komponens definíció útmutatást tartalmaz olyan szoftverek készítéséhez, amelyek szinkron, hálózati aszinkron, vagy nem szabványos aszinkron terminálokra dolgoznak. Szabványokkal való kapcsolat Pillanatnyilag nincsen megfelelô nemzetközi szabvány a karakteres és blokkos terminálok interfészeire. Kapcsolat az XPG3-mal Az XPG4 Terminálcsatoló Komponens specifikációja azonos az XPG3 X/Open Specifikáció, Kiegészítô Definíciók, 3. Kiadásának kilencediktôl tizennegyedikig terjedô fejezeteivel.

42

Ajánlások Karakteres és nem hálózati terminálokat használó rendszerek beszerzésekor az intézmények keressék az XPG4 Terminálcsatoló Komponens definíciónak megfelelô termékeket, ha a különbözô felépítésû és operációs rendszert futtató számítógépek közötti hordozhatóság megkövetelt. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy XPG4-nek eleget tevô platformra, a fejlesztôk igazodjanak ehhez a komponens definícióhoz. 35

Grafikus felhasználói interfész

Az XPG4 Ablakrendszer-megjelenítô és Ablakrendszer-alkalmazási Felület Komponensek az X Window System 11. verziójának 4. kiadásán (X11R4) alapulnak. (Az X Window System egy hardver-független, hálózati, bitmap-es ablakmegjelenítô rendszer, amelyre grafikus felhasználói felületek (GUI) építhetôk.) A következô XPG4 CAE specifikációkban találhatunk hivatkozást az XPG4 Ablakrendszer-megjelenítô és Ablakrendszer-alkalmazási Felület komponensekre az "X/Open Ablak Kezelés" általános cím alatt: 1

X Window System protokoll

1

X Window System állomány formátumok és alkalmazási konvenciók

1

Xlib — C nyelvi kapcsolódás

1

X Toolkit Intrinsics Szabványokkal való kapcsolat

Az X Window System 11. kiadásának 5. verziója (X11R5) 1992 szeptemberében jelent meg. Az X11R4-ben meglévôkön felül bemutatott néhány új vonást. A nagyobb bôvítések: Betûkészlet szerver és méretezhetô betûkészletek A negyedik kiadásban a betûkészletek használatának korlátai voltak. A betûkészletek nem voltak méretezhetôk és az egyes gépeken lévô betûkészletek közötti különbségek csökkentették az együttmûködôkészséget. Az ötödik kiadásban a processzorokat lehet úgy konfigurálni, hogy más X Window gépek számára betûkészlet szerverek legyenek. A Font Server protokoll definiálja az adat formátumokat, így növeli az együttmûködôkészséget. Az ötödik kiadásban a bitmap-es betûkészletek is méretezhetôk, valamint exportálni lehet a méretezett on-line betûkészleteket. Eszközfüggetlen színek A negyedik kiadás gépfüggô módon ábrázolja a színeket, ezért egy színkód különbözô típusú gépeken különbözô színt hoz elô. Az ötödik kiadásban lévô X Colour Management System lehetôvé teszi az eszközfüggetlen színek pontos megadását nemzetközileg szabványosított ún. "színterekkel". Ezzel a módszerrel a színek pontosan jeleníthetôk meg és vezérelhetôk, valamint a színek specifikációit át lehet fordítani az egyik színtérrôl a másikra. Háromdimenziós strukturált grafika

43

Az ötödik kiadás bevezeti a Programozók Hierarchikus Interaktív Grafikus Rendszere — Minta Implementációját (PHIGS-SI). A PHIGS egy nemzetközi szabványos alkalmazás programozó interfész (API) a magasszintû háromdimenziós strukturált grafikák kezelésére. Az idetartozó szabványok: 1

ISO/IEC 9592:1989, Információ Feldolgozó Rendszerek — Számítógépes Grafika — Programozók Hierarchikus Interaktív Grafikus Rendszere (PHIGS) — 1-3. Részek

1

ISO/IEC 9592-4:1992, Információ Feldolgozó Rendszerek — Számítógépes Grafika — Programozók Hierarchikus Interaktív Grafikus Rendszere (PHIGS) — 4. Rész: Plus Lumière and Surfaces, PHIGS PLUS

1

ISO/IEC 9593:1990/1, Információs Technológia — Számítógépes Grafika — Programozók Hierarchikus Interaktív Grafikus Rendszere (PHIGS) — 1. Rész: FORTRAN, 3. Rész: ADA, 4. Rész: C.

A PHIGS PLUS primitívákat ad meg görbék és felületek definiálásához, felületek árnyékolásához és más feladatokhoz. A PEX (PHIGS bôvítés az X-hez) az X Window System hálózati protokolljának kibôvítése. Ennek nemzetközi szabványa még elôkészületi fázisban van. A PEX lehetôvé teszi majd, hogy a szerver kihasználja a számára elérhetô speciális grafikus hardverelemeket a teljesítményének növelésére. Többnyelvûsítés Az ötödik kiadás több változtatással, többnyelvûsítést. A meghatározó elemek:

hozzáadással

támogatja

1

lokalizálás kezelô függvények,

1

többnyelvû szövegrajzolás,

1

az Xlib függvények újradefiniálása azért, hogy azok tudják kezelni a különbözô nyelvû karakterláncokat,

1

változtatások az Ablakkezelôben és a kliensek közti kommunikációban,

1

változtatások az erôforrás kezelôn, hogy az támogassa a többnyelvûsített adatbázisokat,

1

többnyelvû szövegbeviteli módszerek.

a

Kapcsolat az XPG3-mal Az XPG3 idején befejezetlen munkák, név szerint az X/Open X Window System Protokoll, az X Toolkit Intrinsics és a Kliensek Közötti Kommunikációs Konvenciók Kézikönyve (ICCCM), mostanra elkészültek és bekerültek az XPG4 X/Open Ablakkezelési CAE specifikációk közé. Így az X/Open hozzá tudta igazítani az XPG4-et az X11R4-hez. Az X11R5-bôl azonban kevés elemet vett át az X/Open, nevezetesen a további kurzor betûkészletek támogatását, a keysym értékeket és szín elnevezéseket.

44

Ajánlások Ha az intézmények grafikus terminálokat támogató rendszereket szereznek be, amelyeket ablakos felhasználói felülettel és ISO/IEC 9945-1:1990 szabványos platformhoz kapcsolódva fognak használni, akkor az XPG4 Ablakrendszer-megjelenítô és Ablakrendszer-alkalmazási Felület komponens definíciókhoz való konformanciát szabják meg követelményként az 1994 január 1-e után beszerzett rendszerek esetén. Ez elôsegíti a szoftverek hordozhatóságát és az egységes felhasználói felület megteremtését. Jelentôs számú olyan termék kapható, amely az X11R4-et használja. Ha az X11R5 nyújtotta többletszolgáltatások egyikére sincsen szükség, akkor az XPG4 felhasználói felületre vonatkozó szabványokhoz való konformancia elegendô. A felhasználók vegyék figyelembe azt, hogy az XPG4 Ablakrendszeralkalmazási Felületnek való konformancia nem biztosítja a külsôleg generált betûkészletek importálását és a szöveges adatok cseréjét mint szolgáltatásokat, mivel ezek opcionálisak a komponens specifikációjában. Szükség esetén az intézmények külön emeljék ki az ilyen opciók iránti igényeiket. Az XPG4 felhasználói felületre vonatkozó szabványokhoz való konformancia önmagában nem elegendô ahhoz, hogy minden a felhasználói felületre vonatkozó követelmény teljesülését biztosítsák. Több olyan dolog van az X Window System használatával kapcsolatban, amelyeket, bár az XPG4 nem foglalkozik velük, az intézményeknek számításba kell venni: 1

teljesítmény tényezôk az X Window System kliens-szerver architektúrájával kapcsolatban,

1

biztonsági tényezôk a kliensek és szerverek meghatalmazásával kapcsolatban,

1

a szabványok hiánya a környezet megjelenésével (look-and-feel) kapcsolatban,

1

az XPG4 nem vonatkozik a DOS-alapú munkaállomásokra, és ezek közül például a Microsoft Windows-ra.

Az olyan rendszerek beszerzésekor, ahol különbözô nyelven írt klienseknek kell kommunikálni, együtt létezni és együttmûködni ugyanazon a szerveren, az ICCCM-et mint kötelezôen teljesítendô követelményt adják meg. 36

ÁLTALÁNOS EGYÜTTMÛKÖDÉS 37

Byte Stream File Transfer (BSFT)

Az XPG4 Byte Stream File Transfer (BSFT) Komponens egy parancssoros felület specifikációja és annak a funkcionalitásnak a megadása, amely lehetôvé teszi strukturálatlan (byte stream) állományok átvitelét XPG4-nek megfelelô rendszerek között. A BSFT általános célja az, hogy az FTP parancssoros felületének használatában járatos felhasználónak egy hasonló felületet adjon az FTAM-hoz. Ennek a specifikációnak a célja egy egységes felhasználói parancssoros felület megadása. E felület alatt a protokoll verem kicserélhetô a TCP/IP-n

45

futó FTP protokollról az OSI kapcsolat-orientált átviteli protokoll felett mûködô OSI FTAM (Állomány átvitel, hozzáférés és kezelés) protokollra. Az OSI FTAM szabvány nagy számú függvényt és opciót tartalmaz, ezért az együttmûködés elôsegítésére az ISO és más csoportok (EWOS, OIW, AOW) kisebb készleteket definiáltak a szabványhoz, amelyeket profiloknak ismerünk. A BSFT az FTAM funkcionalitásának azt a részét adja meg, amely egy implementáció számára lehetôvé teszi az FTP funkcionalitásának megvalósítását. Szabványokkal való kapcsolat A BSFT nem felel meg semmilyen nemzetközi szabványnak. Egy parancssoros felhasználói felületet definiál, és egy ezen a felületen megvalósítható funkcionalitást, hivatkozva az ISO/IEC 8571, Információ Feldolgozó Rendszerek — Nyílt Rendszerek Összekapcsolása (OSI) — Állomány Átvitel, Hozzáférés és Kezelés [FTAM] szabványban definiált funkcionalitásra. Az ISO/IEC 8571 a konformanciát a protokollhoz képest adja meg, míg a BSFT nem ad meg protokollt. Kapcsolat az XPG3-mal A BSFT egy új specifikáció az XPG4-ben. Ajánlások A BSFT-ben és a GOSIP 4-ben leírt funkcionalitás különbözik. A GOSIP 4 egy kicsit gazdagabb profilt ad meg, és ez legyen az a specifikáció, amelyhez a konformanciát kérik. A GOSIP 4 a parancssoros felületet egy lehetôségként adja meg a felhasználói felület opciókon belül. Ez a felület nem felhasználóbarát, ezért a BSFT mint többlet-követelmény csak akkor szükséges, ha az alábbi összes feltétel teljesülése fontos a vásárló számára: 1

Jelenleg az FTP segédprogramot használják állományok átvitelére.

1

Az FTP-hez csak parancssoros felület van.

1

A felhasználói felület a jövôben is egyszerû parancssoros stílusú marad.

38

X.400 átjáró

Az XPG4 X.400 Átjáró Komponens definíció célja az, hogy lehetôvé tegye hordozható átjáró alkalmazások készítését, amely az egyik fajta üzenetküldô rendszerbôl (pl. elektronikus posta) érkezô üzeneteket egy másik rendszer formátumára konvertálja és a másik rendszer szokásai szerint továbbítja. Egy saját levelezô rendszer hozzákapcsolódhat egy X.400 Üzenettovábbító ügynökhöz (Message Transfer Agent, MTA) bizonyos programkönyvtárak felhasználásával, amelyeket általában az üzenettovábbító szoftver gyártója bocsát rendelkezésre. A szóban forgó levelezô rendszer minden felhasználóját az üzenettovábbító ügynök úgy tekinti, mintha azok egy szomszédos üzenettovábbító ügynökhöz tartoznának. Ezért a levelezô rendszer szervere felel minden üzenet célbajuttatásáért azután, hogy átvette azokat az X.400-as üzenettovábbító ügynöktôl. Az X/Open CAE Specifikáció, Elektronikus Posta Alkalmazás Programozási Interfész (X.400) ezt a programkönyvtárat definiálja C nyelven és nyelvfüggetlen jelölésben. A specifikáció B függeléke egy áttekintést tartalmaz az X/Open-rôl és 46

elmagyarázza annak funkcionális modelljét, alkalmazás protokolljait és kezelési hatásköreit (domain). Ezt a specifikációt az X/Open az X.400 API Association-nel (APIA) közösen fejlesztette ki. X.400 Átjáró API Üzenettovábbító ügynök A levelezô rendszer átjárója

X.400 Átjáró Szolgáltatás Kimenô sor

X.400 MTS Alkalmazás vagy levelezô rendszer

Bejövô sor

Felhasználók

Az X.400 Átjáró API fogalmi modellje A második specifikáció, amelyre ez a komponens definíció hivatkozik: X/Open CAE Specifikáció, OSI Absztrakt Adat Kezelés API (XOM). Ez a dokumentum az Objektum Kezelô API-t részletezi, amelybôl számos más API-t származtattak. Az alkalmazásnak (pl. elektronikus posta), amely az üzenettovábbító szoftverhez csatlakozik, az XOM szabványos programhívásaival az elküldendô adatait objektum formátumra kell hoznia (és hasonlóképp értelmeznie a beérkezô objektumokat). Az X.400 Átjáró API az XOM interfészre épül. Ez az API oldja meg az összetett X.400 objektumok (pl. az X.400 levelezéshez kapcsolódó adatstruktúrák) létrehozását, kiolvasását, módosítását és törlését. Szabványokkal való kapcsolat Bármely XPG4 X.400 Átjáró Komponens definíciónak megfelelô termék a következô X.400 profilok közül legalább egyet kell, hogy támogasson: 1

MHS (1984): Interpersonal Messaging UA + MTA: PRMD/ADMD to ADMD (P2 and P1): M-IT-02 Profile: A/311; CEN/CENELEC Functional Standard: ENV41 202

1

MHS (1984): Interpersonal Messaging UA + MTA: PRMD to PRMD (P2 and P1): M-IT-02 Profile: A/3211; CEN/CENELEC Functional Standard: ENV41 201

A fenti profilok közül az elsô használandó személyes kezelési hatáskörök (private management domain, PRMD) és adminisztrációs kezelési hatáskörök (administration management domain, ADMD) ADMD-khez kapcsolására, míg a második PRMD-k egymáshoz kapcsolására. A Nemzetközi Szabvány Profilok (ISP) még nem készültek el, de szándék szerint csak az 1988-as X.400-ra fognak hivatkozni. Az 1988-as X.400-nak megfelelô termékek száma még nagyon csekély. Az X/Open ezért az 1984-es

47

X.400-on alapuló Európai Profilokat alkalmazta, de szándékában áll felhasználni az 1988-as X.400-on alapuló ISP-ket, mihelyst elfogadták azokat. Az IEEE Std. 1224-1993 Általános Objektum Kezelés szabvány átvette az X/Open XOM specifikációját. Az IEEE Std. 1224.1-1993 Üzenetkezelô Szolgáltatás API szabvány az X/Open X.400 API-t vette át, és csak ez az X.400 API specifikáció kerül szabványosításra, és nem tervezik magasabb szintû felület hozzáadását a szabványhoz. Kapcsolat az XPG3-mal Az X.400 átjáró specifikációja új az XPG4-ben. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô kell legyen, és egy X.400 alapú üzenetkezelô szolgáltatás részeként üzenettovábbító ügynököket kell mûködtetnie, akkor az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén követeljék meg a konformanciát az XPG4 X.400 Átjáró Komponens definícióhoz. Ez elôsegíti az együttmûködést az egyéni levelezô rendszerekkel. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy XPG4-nek eleget tevô platformra, a fejlesztôk igazodjanak ennek az XPG4 komponensnek az API definícióihoz. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. 39

X.400 üzenetelérés

Az XPG4 X.400 Üzenetelérés Komponens az X.400 üzenetközvetítô rendszerek készítéséhez szükséges, mivel elérhetôvé teszi az üzenettovábbító ügynök (MTA) szolgáltatásait a hordozható alkalmazások számára, amelyek egy felhasználói ügynököt (User Agent, UA), vagy egy üzenettárolót (Message Store, MS) valósítanak meg. Egy alkalmazás program (például egy felhasználói ügynök vagy egy üzenettároló) használhatja a megfelelô üzenettovábbító ügynök nyújtotta szolgáltatásokat egy X.400 üzenetközvetítô rendszeren belül, ha hozzákapcsolódik egy programkönyvtár készlethez. Az X/Open CAE Specifikáció, Elektronikus Posta Alkalmazás Programozási Interfész (X.400) ezt a programkönyvtárat definiálja C nyelven és nyelvfüggetlen jelölésben. A specifikáció B függeléke egy áttekintést tartalmaz az X/Open-rôl és elmagyarázza annak funkcionális modelljét, alkalmazás protokolljait és kezelési hatásköreit (domain). Azokat az X.400 vonatkozású specifikációkat, amelyekre ez a komponens definíció hivatkozik, az X/Open az X.400 API Association-nel (APIA) közösen fejlesztette ki. Bár az X/Open és az X.400 APIA felismerték a szükségességét annak, hogy az API specifikációkat azok a programozók is használhassák, akiknek nincs átfogó tudásuk az OSI-ról vagy az X.400-ról, ez az API még mindig viszonylag alacsony szintû, és a programozótól megköveteli az alatta dolgozó proto-

48

kollok ismeretét. Az X.400 APIA tanácskozik arról, hogy megadjanak-e késôbb egy magasabb szintû API verziót. X.400 Alkalmazásí API Felhasználói ügynök

Feladási sor

Kézbesítési sor

X.400 MTS

Fogadási sor Üzenettovábbító ügynök

Az X.400 Alkalmazás API fogalmi modellje Az X.400 Alkalmazás API szolgáltatásaival kezelni lehet a felhasználó feladási sorát. Ez lehetôvé teszi üzenetek továbbítását a szolgáltatás felé és vissza olyan esetekben, mint például jelentések kézbesítése, fogadása és kézhezvétele. Az XPG4 X.400 Üzenetelérés Komponens hasonló módon, mint az X.400 Átjáró Komponens definíciójában részletezett API, az Objektum Kezelô (XOM) interfészre épül fel, amely az X/Open CAE Specifikáció, OSI Absztrakt Adat Kezelés API (XOM) dokumentumban van leírva. Ez az API oldja meg az összetett X.400 objektumok (pl. az X.400 levelezéshez kapcsolódó adatstruktúrák) létrehozását, kiolvasását, módosítását és törlését. Az X/Open jelezte, hogy ezt a komponens definíciót nem kell csak a személyes üzenetek közvetítésére leszûkíteni, hiszen az interfészek és protokollok alkalmasak tetszôleges bináris adat (például EDI, Electronic Data Interchange) továbbítására is. Az X/Open Útmutató, Útmutató egyes X.400 és Katalógus szolgáltatások Alkalmazás Programozói Interfészeihez címû kiadványt is használják a fent említett specifikációkkal együtt. Szabványokkal való kapcsolat Bármely XPG4 X.400 Üzenetelérés Komponens definíciónak megfelelô termék a következô X.400 profilok közül legalább egyet kell, hogy támogasson: 1

MHS (1984): Interpersonal Messaging UA + MTA: PRMD/ADMD to ADMD (P2 and P1): M-IT-02 Profile: A/311; CEN/CENELEC Functional Standard: ENV41 202

1

MHS (1984): Interpersonal Messaging UA + MTA: PRMD to PRMD (P2 and P1): M-IT-02 Profile: A/3211; CEN/CENELEC Functional Standard: ENV41 201

A fenti profilok közül az elsô használandó személyes kezelési hatáskörök (private management domain, PRMD) és adminisztrációs kezelési 49

hatáskörök (administration management domain, ADMD) ADMD-khez kapcsolására, míg a második PRMD-k egymáshoz kapcsolására. A Nemzetközi Szabvány Profilok (ISP) még nem készültek el, de szándék szerint csak az 1988-as X.400-ra fognak hivatkozni. Az 1988-as X.400-nak megfelelô termékek száma még nagyon csekély most, 1993 márciusában. Az X/Open ezért az 1984-es X.400-on alapuló Európai Profilokat alkalmazta, de szándékában áll felhasználni az 1988-as X.400-on alapuló ISP-ket, mihelyst elfogadták azokat. Kapcsolat az XPG3-mal Az X.400 üzenetelérés specifikációja új az XPG4-ben. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô kell legyen, és egy X.400 alapú üzenetkezelô szolgáltatás részeként üzenettovábbító ügynököket kell mûködtetnie, akkor az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén követeljék meg a konformanciát az XPG4 X.400 Üzenetelérés Komponens definícióhoz. Ez elôsegíti az együttmûködést az egyéni levelezô rendszerekkel. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy XPG4-nek eleget tevô platformra, a fejlesztôk igazodjanak ennek az XPG4 komponensnek az API definícióihoz. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. 40

Katalóguselérés

Az XPG4 Katalóguselérés Komponens azokat a szolgáltatásokat definiálja, amelyek egy felhasználó vagy alkalmazás program és a Katalógus Felhasználó Ügynök (Directory User Agent, DUA) között egy API-n keresztül hozzáférhetôk, és amelyekkel az X.500 Katalógus elérhetô. A komponens által hivatkozott dokumentum: X/Open CAE Specifikáció, API a Katalógus Szolgáltatásokhoz (XDS). A Katalógus mûködését leírja egyrészt az 1988-as CCITT X.500 Ajánlási Sorozat valamint az ISO/IEC 9594:1990, Információs Technológia — Nyílt Rendszerek Összekapcsolása (OSI) — A Katalógus. A definíciók a Katalógus Rendszer Ügynök (Directory System Agent, DSA) és DUA vonatkozásában vannak megadva. Általánosan, a DSA-k az egyes számítógépeknek felelnek meg, amelyek a Katalógus részeit tárolják. A DUA a felhasználó DSA-kkal folytatott párbeszédeit jelképezi. A DUA a Katalógus Elérési Protokollon (Directory Access Protocol, DAP) keresztül kéri a szolgáltatásokat a DSA-tól. Ha a felkért DSA nem tudja nyújtani azt a szolgáltatást, akkor egyrészt láncolhatja a kérést más DSA-k felé a Katalógus Rendszer Protokoll (Directory System Protocol, DSP) felhasználásával, vagy pedig egy hivatkozást adhat meg válaszul, amely kijelöl egy olyan DSA-t, amelyik jobban tudja teljesíteni a kérést. A nemzetközi szabvány azokat a szolgáltatásokat definiálja, amelyeket a DUA használhat a Katalógus tartalmának lekérdezésére és megváltoztatására.

50

DSA DUA DSP DAP

Katalógus R endszer Ügynök Katalógus Felhasználó Ügynök Katalógus R endszer Protokoll Katalógus Elérési Protokoll

Katalógus DSA

Felhasználói progra m

DUA

DAP

DSA DSP DSA

Katalógus szolgáltatások interfésze (XDS)

Az XDS és az X.500 Katalógus Eszköz Komponensek Az X.400 API-khoz hasonlóan az XDS is kapcsolódik az Objektum Kezelô interfészhez, amely az X/Open CAE Specifikáció, OSI Absztrakt Adat Kezelés API (XOM) dokumentumban van leírva. Ez az interfész oldja meg az összetett X.500 objektumok (pl. az X.400 levelezéshez kapcsolódó adatstruktúrák) létrehozását, kiolvasását, módosítását és törlését. A felhasználók különböztessék meg a Katalógus Szolgáltatások interfésze alatt elhelyezkedô, de valójában az Objektum Kezelô interfészhez tartozó objektumokat és attribútumokat azoktól az objektumoktól és attribútumoktól, amelyeket a Katalógus Szolgáltatás felépítéséhez használtak. Az API definiálásán túl az XDS dokumentum példaprogramokat is tartalmaz, amelyek az API helyes használatát mutatják. Az X/Open Útmutató, Útmutató egyes X.400 és Katalógus szolgáltatások Alkalmazás Programozói Interfészeihez címû kiadványt is használják a fent említett specifikációkkal együtt. Szabványokkal való kapcsolat Az X/Open CAE Specifikáció, API a Katalógus Szolgáltatásokhoz (XDS) dokumentum konzisztens a következô szabványokkal, de nincs leszûkítve ezekre a szabványokra: az 1988-as CCITT X.500 Ajánlási Sorozat és az ISO/IEC 9594:1990, Információs Technológia — Nyílt Rendszerek Összekapcsolása (OSI) — A Katalógus (ez a két de jure szabvány technikailag megfelel egymásnak). Az IEEE Std. 1224.2 Katalógus Szolgáltatások API, amelyet 1993 márciusában elfogadtak a POSIX szabványosítási program részeként, az X/Open XDS API-n alapul. A munkacsoport meg szándékozik tartani az XDS technikai tartalmát, ha nincsenek nyomós okok a megváltoztatására. Kapcsolat az XPG3-mal Az XDS specifikáció új az XPG4-ben. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô kell legyen, és egy X.500 alapú katalógus szolgáltatást kell támogatnia, akkor az 1994 január 1-e után 51

szállított vagy lényegesen módosított rendszerek esetén biztosítson elsôbbséget azon rendszerek számára, amelyek megfelelnek az XPG4 Katalóguselérés Komponens definíciónak. Ez az együttmûködés és a hordozhatóság megkönnyítésére szolgál. Ahol ki akarják használni az XDS alacsonyabb szintû szolgáltatásait is, ott egy magasabb szintû konformancia is megszabható követelményként. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open platformra, a fejlesztôket ösztönözzék arra, hogy használják ennek az XPG4 komponensnek az API definícióit és igazodjanak az API definícióihoz. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. Az X.500 Katalógus igen összetett és egy beszerzés elôtt sok kérdést kell tisztázni. Az X.500 Katalógus szolgáltatásokról további részletek az Ajánlás 58 fejezetében találhatók. 41

Hálózati állományrendszer (NFS)

Az XPG4 Hálózati Állományrendszer Komponens az X/Open CAE Specifikáció, Protokollok az X/Open Együttmûködésre: XNFS, 4. kiadására hivatkozik. Ez egy eszközt nyújt távoli rendszereken elhelyezkedô könyvtárak és állományok elérésére. Ezt úgy éri el, hogy kibôvíti a helyi rendszer interfészeinek szemantikáját, és így az alkalmazások és végfelhasználók amennyire lehetséges, figyelmen kívül hagyhatják a helyi és távoli objektumok közötti különbséget. Ezáltal egy virtuális állományrendszeren belül megvalósul az átlátszó állományelérés a különbözô hardver architektúrák és operációs rendszerek között (nem szükséges a távoli állományokat áthozni, ha hozzájuk akarunk férni). Az XNFS magába építi az összes protokollt, amelyet a Sun Microsystems NFS definiál, és formalizálja azoknak az X/Open Rendszer Interfészeknek (XSI) és segédprogramoknak a szemantikáját, amelyek távoli állományrendszereken is mûködnek. Az X/Open szándéka az, hogy az XNFS-t támogató rendszerek együtt tudjanak mûködni más rendszerek NFS implementációival. Az NFS protokoll, amelyet egy réteges szerkezetként mutatunk itt be, felfogható úgy is, mint távoli eljárásoknak, argumentumaiknak, eredményértékeiknek és hatásaiknak egy készlete.

NFS XDR RPCkönyvtár

Az NFS/XDR/RPC verem

52

Az NFS Külsô Adatreprezentációs (XDR) eljárások használatával oldja meg a különbözô processzor architektúrák belsô adatábrázolásainak áttetszô kezelését. Az XDR viszont távoli eljáráshívásokat (RPC) használ arra, hogy távoli szolgáltatásokhoz kapcsolódjon, azokkal feladatokat végeztessen és az eredményeket kiolvassa. Ennek megfelelôen az XNFS Specifikáció protokoll specifikációkat tartalmaz az XDR, RPC és NFS szolgáltatásokra, valamint néhány "járulékos XNFS protokollra". Az XNFS Specifikáció XPG3 vagy XPG4 Többnyelvûsített Rendszerhívások és Könyvtárak környezetben használandó. Az XNFS Specifikációhoz tartozik még az XNFS Kezelési Modell (Service Model, XNFSSM), amely az adminisztratív mûveleteket specifikálja azokkal az objektumokkal és attribútumaikkal együtt, amelyeket egy NFS környezetben kezelni kell. Szabványokkal való kapcsolat Az X/Open CAE Specifikáció, Protokollok az X/Open Együttmûködésre: XNFS, 4. Kiadása a Sun Microsystems által kifejlesztett és 1984 végén bemutatott hálózati állományrendszerre (NFS) hivatkozik. Azóta az NFS-t és az alatta húzódó távoli eljáráshívást (RPC, szintén a Sun-tól) sok szervezet oly mértékben magáévá tette, hogy ezek de facto szabványnak tekinthetôk. Megjegyzés: Ez az RPC nem azonos az OSF DCE RPC-vel. Az X/Open XNFS a Sun Microsystems NFS 2. verzióján alapszik. Megemlítendô, hogy funkcionalitásbeli különbség van az NFS (XNFS) és az FTAM (ISO/IEC 8571, Információ Feldolgozó Rendszerek — Nyílt Rendszerek Összekapcsolása (OSI) — Állomány Átvitel, Hozzáférés és Kezelés [FTAM]) között. Az NFS célja egy áttetszô és osztott állományrendszer biztosítása, míg az FTAM pillanatnyilag állomány átviteli lehetôséget nyújt, de a jövôben egy osztott állományrendszerhez szükséges funkcionalitást is képes lesz nyújtani. Ezért az NFS, mint követelmény ne zárja ki az FTAM-ot, mint követelményt (és fordítva). További információk találhatók az FTAM alkalmazhatóságáról az 56 fejezetben. Azt a folyamatot, amikor távoli állományokat és könyvtárakat érünk el oly módon, mintha azok a helyi állományrendszer hierarchiájának részét képeznék, közismert néven áttetszô állomány elérésnek (TFA) nevezzük. Az X/Open elismeri, hogy az IEEE P1003.8 bizottsága a TFA szabványosításán dolgozik, és az X/Open igazodni fog a szabványhoz, miután azt jóváhagyták. Kapcsolat az XPG3-mal Bár az XNFS elôször jelent meg az XPG4-ben, az alkalmazás interfészei azokon az állományrendszer-hívásokon alapulnak, amelyek az XPG3-ban már benne voltak. Ezért az olyan alkalmazások fejlesztôi, amelyek az XPG3 XSI Rendszer Interfész és Header Állományok, valamint az XSI Parancsok és Segédprogramok komponensekre hagyatkoztak, vegyék figyelembe azokat a szemantikai változásokat, amelyeket az XNFS használata okozhat. Ezek a változások az X/Open CAE Specifikáció, Protokollok az X/Open Együttmûködésre: XNFS, 4. Kiadásának A, B, és C függelékében vannak leírva. 53

Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô kell legyen, és egy NFS-t támogató osztott számítógépes környezetben kell mûködnie, akkor az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén vegyék figyelembe a rendszerek konformanciáját az XPG4 Katalóguselérés Komponens definícióhoz. Ez az együttmûködés és a hordozhatóság megkönnyítésére szolgál. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy XPG4 ajánlásoknak eleget tevô platformra, a fejlesztôk vegyék számításba azoknak a definícióknak a használatát, amelyeket ez az XPG4 komponens ad meg. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. Fontos megjegyezni azt, hogy az XNFS egyetlen kapcsolatnélküli átviteli szolgáltatás használatát definiálja, nevezetesen az IP feletti UDP-t az Internet protokollok közül, amely magába foglalja a TCP/IP-t (bár az implementáció választhat valamilyen más átviteli protokollt). Az UDP/IP és a TCP/IP nem formális OSI szabványok. Annak megállapítására, hogy az NFS hogyan tehetô át egy OSI hálózatra, az olvasó a Towards Open Systems: A TCP/IP to OSI Migration Strategy for U. K. Government Departments címû CCTA kiadványban talál tájékoztatást. Tanácsos alaposan megfontolni, hogy ez a komponens hogyan használható egy OSI alapú hálózatban, mielôtt a beszerzésrôl döntenek. 42

Transzport szolgáltatások (XTI)

Az XPG4 Transzport Szolgáltatások (XTI) Komponens alapjául az X/Open CAE Specifikáció, X/Open Transzport Interfész (XTI) dokumentum szolgál. Ez az alkalmazások számára definiál egy olyan átviteli szolgáltatásokat nyújtó interfészt, amely független az egyes szolgáltatóktól. Az XTI egy C nyelvû API-t tartalmaz, amellyel az alkalmazás fejlesztô használhatja a hálózat szolgáltatásait, amelyeket az összes támogatott hálózatra általánosítottak, így azok hordozhatóak. Az XTI célja, hogy: 1

független legyen az operációs rendszertôl,

1

lehetôvé tegye a hálózati technológiától független, osztott alkalmazások fejlesztését,

1

támogassa az OSI Átviteli szolgáltatások definíciót és a de facto szabvány protokollokat, mint amilyen a TCP.

Az XTI Specifikáció útmutatást is tartalmaz a protokoll-független alkalmazás szoftverek írásához, és kiemel minden olyan részletet, amely függ az alatta húzódó környezettôl. Az XTI a UNIX International TLI API-ból lett átdolgozva, amely a TCP/IP-t és az OSI TP4-et is támogatta. Az XTI és a TLI közötti fô különbségek: 1

Az XTI-nek kevesebb bôvítménye van.

1

Az XTI már nem függ a UNIX verziótól, a meghajtó típusától és az átvitel szolgáltatójától.

54

1

Az XTI már ANSI szabványos C-ben van specifikálva, nem Kernighan és Ritchie C-ben.

Egy részletes leírás található az XTI és TLI különbségeirôl az X/Open CAE Specifikáció, X/Open Transzport Interfész (XTI) E függelékében. Szabványokkal való kapcsolat Az XPG4 XTI Specifikáció a következôkre hivatkozik: 1

ISO ISP 10608-2 (TA 51): TP4 and CLNS over LLC1 and 8802-3 LAN

1

ISO ISP 10608-5 (TA 1111): TP4 and CLNS over PSTN SVC

1

ISO ISP 10609-6 (TC 51): TP0,2 and CONS over PSTN SVC

1

ISO ISP 10609-7 (TD 51): TP0 and CONS over PSTN SVC

1

TCP/IP (nem OSI szabvány)

1

UDP/IP (nem OSI szabvány)

E specifikációk közül legalább egyet támogatnia kell minden olyan terméknek, amelyik meg akar felelni az XTI Specifikációnak. Az intézmények a termék konformancia kérdôívébôl (CSQ) állapíthatják meg, hogy ezek közül mely specifikációk támogatottak, melyek nem, és melyek azok, amelyeket ezeken kívül támogat a termék (pl. NetBIOS). Az IEEE P1003.12 munkacsoport két POSIX API-n dolgozik: Egyszerû Hálózati Interfész (Simple Network Interface, SNI) és Részletes Hálózati Interfész (Detailed Network Interface, DNI). Az utóbbi fel fogja használni az XTIt, és várhatóan az IEEE P1003.12 kevés változtatást hajt végre az XTI-n a POSIX szabványosítási folyamat közben. Kapcsolat az XPG3-mal Az XTI API eredetileg az XPG3-on belül jelent meg 1988-ban, de 1990-ben megjelent a javított kiadás, a gyakorlatból adódó változtatásokkal és bôvítésekkel. A változtatások elsôsorban az eredeti XTI specifikációk tisztázásai voltak, a félreértéseket elkerülendô. Néhány új függvényt is hozzátettek az XTI-hez. Az XPG4 XTI ennek a specifikációnak a továbbfejlesztése. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô környezetben kell mûködjön, és szükség van kommunikációs lehetôségekre, akkor az XPG4 Transzport Szolgáltatások (XTI) Komponens definíciónak megfelelô termékeket keressék, hogy megkönnyítsék az együttmûködést. A Towards Open Systems: A TCP/IP to OSI Migration Strategy for U. K. Government Departments címû CCTA kiadvány ajánlja az XTI-t. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy XPG4 ajánlásoknak eleget tevô platformra, a fejlesztôktôl követeljék meg azoknak a definícióknak a használatát illetve az azokhoz való konformanciát, amelyeket ez az XPG4 komponens ad meg. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését.

55

43

EGYÜTTMÛKÖDÉS NAGYSZÁMÍTÓGÉPEKKEL 44

CPI-C

Az XPG4 CPI-C (Common Programming Interface Communications) Komponens egy adatkommunikációs API-t biztosít, amely az IBM SAA (System Application Architecture) platformokon használatos, és támogatja az SAA adatkommunikációs protokollt. Az XPG4 CPI-C Komponens definíció egy olyan API-t szolgáltat, amely segítségével egy X/Open-hez igazodó rendszer képes kommunikálni az IBM SNA LU6.2 (Logical Unit Type 6.2) protokollt megvalósító rendszerekkel. Ezt az X/Open kulcsfontosságúnak tekinti annak elérése céljából, hogy egy közös API-t vezessenek be azok felé a számítógépes környezetek felé, amelyek gyártói (IBM és mások) ezt az egyedi protokollt használják. B program

A program

X/Open CPI-C SNA hálózat

LU X (type 6.2) LU-LU kapcsolat

LU-LU kapcsolat LU-LU kapcsolat

LU Y (type 6.2)

LU Z (type 6.2)

BAA CPI Comms

APPO

D program

C program

Az SNA hálózat feletti CPI-C fogalmi modellje A CPI-C tulajdonképpen programok közötti kommunikációt tesz lehetôvé az IBM SNA hálózatokon, az IBM LU6.2 protokoll felhasználásával. Az X/Open XPG4 CPI-C definíciója az IBM CPI-C 1-es verzióján alapul. Az X/Open CPI-C a következôkkel bôvítette ki az IBM SAA CPI-C-t: 1

több párbeszéd és nem blokkoló feldolgozási mód,

1

ASCII és EBCDIC konverziók,

1

biztonsági bôvítések.

Az itt felsorolt LU6.2 protokollhoz tartozó elemeket viszont az X/Open nem találta megfelelôknek és elhagyta a CPI-C definíciójából: 1

sync-point,

1

Program-Initialisation-Parameters (PIP) data.

Az XPG4 specifikáció célul tûzi ki azt, hogy a CPI-C interfészt használó programok tudjanak kommunikálni más, APPC (Advanced Peer-to-Peer

56

Communication) interfészt használó programokkal. Az X/Open CAE Specifikáció, CPI-C D függeléke sorolja fel az ekkor életbe lépô megszorításokat. Szabványokkal való kapcsolat Az X/Open CAE Specifikáció, CPI-C csak akkor helyénvaló, ha IBM SNA LU6.2 környezetben dolgozunk. A CPI-C Implementors' Workshop nevû nyilvános fórum azonban most fejleszti a CPI-C API "nyitott" változatát, amely a szabványos OSI Tranzakció-feldolgozó (TP) protokollja felett mûködne az SNA környezetek LU6.2 protokollja helyett. Várhatóan 1994 közepére ez az új változat nyilvánosan hozzáférhetô lesz. Akkor az X/Open is jóváhagyhatja ezt a "nyitott" CPI-C változatot. Kapcsolat az XPG3-mal A CPI-C specifikáció új az XPG4-ben. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformot szereznek be, amely XPG4-nek megfelelô környezetben kell mûködjön, valamint együtt kell mûködnie nagyszámítógépekkel és adatcseréket kell végrehajtania egy LU6.2 protokollt támogató IBM SNA hálózaton, akkor követeljék meg a konformanciát az XPG4 CPI-C Komponens definícióhoz. A teljes kompatibilitás elérése érdekében célszerûbb a teljes IBM CPI-C specifikációhoz való konformanciát feltételül szabni. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open-nek megfelelô platformra, amelyek együtt fognak mûködni nagyszámítógépekkel és adatcseréket fognak végrehajtani egy LU6.2 protokollt támogató IBM SNA hálózaton, ott a fejlesztôk igazodjanak ennek az XPG4 komponensnek az API definícióihoz és ezeket az API definíciókat használják. Ez segíti a hordozható és újrafelhasználható szoftveralkalmazások fejlesztését. 45

EGYÜTTMÛKÖDÉS PC-KKEL 46

Bevezetés

A személyi számítógépek (PC) és XPG4-nek megfelelô rendszerek közötti szabványos együttmûködés területén az X/Open két elkülönülô esetre osztotta az együttmûködés kezelését: 1

DOS vagy OS/2 operációs rendszerû PC integrálása X/Open ajánlásoknak eleget tevô rendszerek létezô hálózatába,

1

X/Open ajánlásoknak eleget tevô rendszer integrálása DOS vagy OS/2 operációs rendszerû PC-k létezô hálózatába, amely SMB (Server Message Block) alapú protokollt használ.

Ezeket az eseteket külön X/Open Komponens definíciók tárgyalják: XPG4 (PC)NFS Szerver és XPG4 LMX Szerver. Ezek az X/Open definíciók protokollokat adnak meg, amelyeket az XPG4-hez igazodó rendszereknek támogatniuk kell. Így az NFS és LMX protokollokon keresztül állományokat és nyomtatókat lehet megosztani a PC-kkel is felszerelt helyi hálózati környezetben.

57

47

(PC)NFS Szerver

Az XPG4 (PC)NFS Szerver Komponens gondoskodik a PC-k együttmûködésérôl, mivel lehetôvé teszi, hogy a DOS-t vagy Microsoft Windows-t futtató számítógépek megosszák az erôforrásokat és az információt a munkaállomásokkal, mini- és nagyszámítógépekkel. Az NFS egy virtuális állományrendszer megvalósításával éri el azt, hogy a távoli gépek állományrendszerei is úgy jelennek meg, mint a helyi PC állományrendszere. (Az NFS-rôl további információ található az Általános Együttmûködés címû részben.) A (PC)NFS definíciót akkor használjuk, amikor PC-ket csatlakoztatunk X/Open ajánlásoknak eleget tevô rendszerek egy hálózatához. Ezeknek a rendszereknek már lehet, hogy van egy osztott állományrendszere, amely NFS-t használ. Ez a komponens azokat az NFS protokollokat definiálja, amelyeket ezeknek a rendszereknek támogatniuk kell ahhoz, hogy DOS alapú személyi számítógépek számára állomány és nyomtató szerverként mûködhessenek. A (PC)NFS definícióját az X/Open Fejlesztôi Specifikáció, X/Open PC-s Együttmûködési Protokollok: (PC)NFS dokumentum tartalmazza. Ez az XDR (eXternal Data Representation), RPC és NFS protokollok specifikációit tartalmazza (de API-kat nem), valamint a néhány "járulékos XNFS protokollt". Bár a teljes NFS rendszerfüggetlen, ebben a Fejlesztôi Specifikációban csak azok a részek szerepelnek, amelyek egy egyfelhasználós kliens rendszereket ellátó szerver megvalósításához kellenek. Külön figyelmet fordítottak az olyan, csak PC-s együttmûködésnél elôforduló problémákra, mint: 1

felhasználó azonosítás,

1

távoli nyomtatók várakozási sorai,

1

DOS állományok megosztása és lefoglalása.

Ez az XPG4 specifikáció azoknak szól, akik egy XPG4-nek megfelelô rendszeren szeretnének NFS szervert létesíteni DOS-os kliensek számára. Szabványokkal való kapcsolat Jelenleg az ISO/IEC 8571, Információ Feldolgozó Rendszerek — Nyílt Rendszerek Összekapcsolása (OSI) — Állomány Átvitel, Hozzáférés és Kezelés [FTAM] szabvány csak állomány átviteli lehetôséget nyújt, a jövôben viszont egy osztott állományrendszerhez szükséges funkcionalitást is képes lesz szolgáltatni. Ezért a (PC)NFS és az NFS, mint követelmény ne zárja ki az FTAM-ot, mint követelményt (és fordítva). További információk találhatók az FTAM alkalmazhatóságáról az 56. fejezetben. Kapcsolat az XPG3-mal A (PC)NFS új az XPG4-ben. Azokban a konfigurációkban, ahol az NFS protokollok az UDP/IP protokoll vermén keresztül mûködnek, bizonyos konformancia követelményeknek eleget kell tenni. Az implementációk konformanciájáról szól az X/Open Fejlesztôi Specifikáció, X/Open PC-s Együttmûködési Protokollok: (PC)NFS hetedik fejezete, melynek címe: RPC interfész az UDP átviteli szolgáltatásokhoz. Az X/Open további segítséget ad 58

az Internet protokollokkal kapcsolatban az X/Open Útmutató, Útmutató az Internet Protokoll Készlethez címû kiadványban. Ajánlások Ha az intézmények rendszereket szereznek be, amelyeket egy olyan osztott számítógépes környezetbe akarnak integrálni, amely támogatja az NFS-t az UDP/IP és/vagy TCP/IP kommunikációs protokollok felett, akkor az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén vegyék figyelembe a rendszerek konformanciáját az XPG4 (PC)NFS Komponenshez. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open ajánlásoknak eleget tevô platformra, a fejlesztôk vegyék számításba azoknak a definícióknak a használatát, amelyeket ez az XPG4 komponens ad meg. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. Megjegyzendô, hogy a (PC)NFS csak egyetlen, összeköttetésmentes átviteli szolgáltatás használatáról szól, és ez az UDP/IP, amely a TCP/IP-vel együtt az Internet Protokoll Készlethez (IPS) tartozik. Az UDP/IP és a TCP/IP nem formális OSI szabványok. Annak megállapításához, hogy a (PC)NFS hogyan tehetô át egy OSI hálózatra, az olvasó a Towards Open Systems: A TCP/IP to OSI Migration Strategy for U. K. Government Departments címû CCTA kiadványban talál tájékoztatást. A felhasználók ne vásárolják meg ezt a komponenst, illetve a gyártók ne implementálják addig, amíg jól meg nem értették, hogyan tehetô használhatóvá ez a komponens OSI alapú hálózatban is. 48

LMX Szerver

Az XPG4 LMX Szerver Komponens definíció olyan szituációkban használható, amikor egy X/Open ajánlásoknak eleget tevô rendszert kapcsolnak hozzá egy meglévô SMB (Server Message Block) protokollon alapuló DOSos vagy OS/2-es PC hálózatba, ahol az új gép állomány és nyomtató szerverként fog üzemelni. Ez a komponens definíció a két specifikációra hivatkozik; X/Open CAE Specifikáció, X/Open PC-s Együttmûködési Protokollok: SMB, 2. Verzió és X/Open CAE Specifikáció, IPC mechanizmusok SMB protokollra. Az elsô specifikáció leírja az X/Open LAN Manager (LMX) architektúrát, az SMB protokollt és ezek alkalmazhatóságát a DOS és OS/2 kliensek valamint XPG4-nek megfelelô szerverek közötti együttmûködés megteremtésére. A második specifikáció az XPG4-nek megfelelô rendszeren használandó API-t írja le, és a folyamatok közötti kommunikációhoz (Inter-process Communication, IPC) szükséges SMB bôvítéseket. Az SMB viszonylag nyíltnak tekinthetô (több platformra kapható több gyártótól), de az intézmények tartsák szem elôtt azt is, hogy a létezô PC-s hálózatok többsége nem SMB alapú protokollt használ. Az XPG4 nem ad meg semmilyen specifikációt vagy komponenst arra nézve, hogy hogyan integrálható egy XPG4-es rendszer Novell Netware környezetbe. Az X/Open konvenciókat definiált, amelyeket egy XPG4-nek megfelelô LMX szerver rendszernek támogatnia kell, illetve amelyeknek alá kell magát

59

vetnie. Ezzel azt akarják elkerülni, hogy létrejöjjön több különbözô implementáció, amelyek a kliens számára ugyanazt a szemantikát biztosítják, de a hatásuk különbözô a szerverre és a helyi állományrendszerre. Ezekkel a konvenciókkal az állományhozzáférés vezérlését, az állományok attribútumait, a lefoglalási (locking) mechanizmusokat és az elnevezéseket lehet az SMB modelljébôl az X/Open környezetébe konvertálni. Más konvenciók leírják az alkalmazkodó (opportunistic) lefoglalási stratégiát, több kérés láncolását egyetlen üzenetbe, a helyettesítô karakterek, a NetBIOS és a hibakódok használatát. Szabványokkal való kapcsolat Megemlítendô, hogy funkcionalitásbeli különbség van az LMX és az FTAM (ISO/IEC 8571, Információ Feldolgozó Rendszerek — Nyílt Rendszerek Összekapcsolása (OSI) — Állomány Átvitel, Hozzáférés és Kezelés [FTAM]) között. Az LMX célja erôforrások (állományok és nyomtatók) áttetszô megosztása, míg az FTAM pillanatnyilag csak állomány átviteli lehetôséget nyújt, de a jövôben egy osztott állományrendszerhez szükséges funkcionalitást is képes lesz nyújtani. Ezért az LMX, mint követelmény ne zárja ki az FTAM-ot, mint követelményt (és fordítva). További információk találhatók az FTAM alkalmazhatóságáról az 56 fejezetben. Kapcsolat az XPG3-mal Az XPG4 LMX Szerver Komponens új az XPG4-ben. Ajánlások Ha az intézmények rendszereket szereznek be, amelyeket egy létezô DOS-t vagy OS/2-t futtató PC-s környezetbe akarnak integrálni, amely SMB alapú protokollt használ, akkor az 1994 január 1-e után szállított vagy lényegesen módosított rendszerek esetén biztosítsanak elônyt az XPG4 LMX Szerver Komponensnek megfelelô rendszerek számára. Ahol szoftver alkalmazásokat vagy segédprogramokat vásárolnak, vagy fejlesztenek házon belül egy X/Open ajánlásoknak eleget tevô platformra, amely a fent leírt tulajdonságú PC-s hálózathoz csatlakozik, ott a fejlesztôket ösztönözzék az ebben az XPG4 komponensben megadott definíciókhoz való konformanciára illetve azok használatára. Ez segíti a hordozható és újrafelhasználható szoftver-alkalmazások fejlesztését. 49

ADATHORDOZÓK 50

Mágneses adathordozók

Az XPG4 Mágneses Adathordozók Komponens definíció azokat a problémákat kívánja megoldani, amelyek akkor keletkeznek, amikor az egyik XPG4nek megfelelô rendszerrôl a másikra akarunk átvinni olvasható formában lévô forráskódot vagy inkompatibilis média alkalmazásokat. Ennek a komponens definíciónak nem tárgya az adatok archiválása és mentése, így nem foglalkozik egyes olyan technológiákkal, amelyekkel nagy mennyiségû adatot lehet lementeni (például DAT).

60

Szabványokkal való kapcsolat Azoknak a termékeknek, amelyeket meg kívánnak feleltetni ennek a komponens definíciónak, támogatniuk kell az írási/olvasási hozzáférést egy vagy több fajtához a táblázatban felsorolt mágneses adathordozók közül. A mágneses adathordozóknak viszont a rá vonatkozó ISO adatcsere szabványoknak kell megfelelnie. Az adathordozóknak cpio, tar vagy pax segédprogramokkal hozzáférhetôknek kell lenniük. Adathordozó QIC 150 1/4" kazetta 1600 bpi-s mágnesszalag 6250 bpi-s mágnesszalag 3,5" 1,4 Mbyte-os mágneslemez

Szabvány ISO 8063:1986 ISO/IEC 3788:1990 ISO 5652:1984 ISO/IEC 9529:1989

Felhívjuk a felhasználók figyelmét arra, hogy a következô fajtájú adathordozókat ez a komponens definíció nem javasolja: 1

3,5" 720 kbyte-os mágneslemez,

1

5,25" 80 sávos mágneslemez,

1

5,25" 360 kbyte-os mágneslemez. Kapcsolat az XPG3-mal

Az 1600 bpi-s és 6250 bpi-s mágnesszalagok támogatása folytatódik az XPG4-ben is. Az 5,25" és 3,5" 720 kbyte-os mágneslemezeket elhagyták az XPG4-bôl. Ajánlások Ha az intézmények olyan ISO/IEC 9945-1:1990 szabványos platformokat szereznek be, amelyek XPG4-nek megfelelôek, és 3,5" mágneslemezmeghajtókat igényelnek, akkor követeljék meg az konformanciát a következô specifikációhoz: 1

80 sáv (135 sáv inch-enként),

1

cilinderenként 2 sáv,

1

sávonként 18 szektor,

1

szektoronként 512 byte,

1

MFM felvételi mód minden sávon,

1

két oldal, nagy kapacitás.

Ha kazettás meghajtóra van szükség hasonló környezetben, akkor a következô specifikáció legyen kötelezô: 1

QIC 150,

1

18 sáv,

1

DC6150 szalagok,

1

cpio.

Mindkét esetben az ajánlásokat az adatátvitel és az együttmûködés megkönnyítésére tettük.

61

Az intézmények vegyék figyelembe azt, hogy a különbözô méretû QIC meghajtók kompatibilitása nincs garantálva.

62

51

RÉSZLETES GOSIP AJÁNLÁSOK

52

BEVEZETÉS

53

GOSIP dokumentumok

Az UK GOSIP4 dokumentumköteteket két különálló készletben jelentették meg. Az elsô készletbe a beszerzôknek szóló 5 kötet tartozik, s ennek megfelelôen a "Beszerzési kézikönyv" címet viseli. Ezek a kötetek mérsékelt OSI és kommunikációs ismeretet tételeznek fel, és az összekapcsolható kormányzati informatikai rendszerek tervezésében nyújtanak segítséget. A mûszaki részletek elegendôek a beszerzési döntéshozatalhoz, de az üzemeltetéshez már nem. Az 5 kötet témakörei: 1

GOSIP áttekintés

1

GOSIP architektúra

1

LAN, WAN hálózatok és ISDN

1

Alkalmazói szolgálatok (file kezelés, üzenet kezelés, virtuális terminál, névjegyzék).

1

Formátumok (dokumentum, elektronikus adatok, karakterkészlet)

1

Support (címzés, biztonság, menedzselés)

1

Alkalmazói program interfész

1

Tesztelés

A második készletbe a termékek, szolgáltatások és tesztelô eszközök szállítóinak és az üzemeltetôknek szánt a "Specifikáció" címet viselô 6 kötet tartozik, a GOSIP követelmények részletes technikai leírásával. Ezek a kötetek már lényegesen több mûszaki ismeretet tételeznek fel. A 6 kötet témakörei: 1

GOSIP architektúra részletesebben

1

Transzport réteg és hálózati réteg

1

LAN, FDDI LAN

1

Hálózatok összekapcsolása

1

Alkalmazói szolgálatok részletesebben

1

Formátumok és support részletesebben

54

GOSIP-architektúra és az alprofilok

Az anyag ismertetése továbbiakban a GOSIP architektúrát követi. Az architektúra profilokra bomlik, s rendre ismertetjük a profilokat és elemeit.

63

F-profil 7 6 5 4 3 2 1

S-profil

A-profil T-profil A GOSIP architektúra

A nyílt rendszerek összekapcsolását és a rendszerek felhasználói igényeinek teljesítését az OSI szabványok szabályozzák. Az OSI-architektúra több nyílt rendszerbôl, alkalmazói folyamatokból, logikai és fizikai összeköttetésbôl áll. A GOSIP-architektúra az OSI-architektúra szûkítését jelenti, mert csak azokat az elemeket tartalmazza, amelyeket kormányzati feladatokra felhasználnak. Különbözô feladatokhoz, feladatcsoportokhoz különbözô GOSIP-architektúrák tartoznak. Ezért célszerû a GOSIP-architektúrát építô elemekre, jól definiált részekre bontani, amelyekbôl a különbözô architektúrák összerakhatók. Ezeket az építôelemeket nevezik alprofilnak vagy profilnak. A GOSIP-architektúra a következô elemekbôl áll: 1

A-profil: alkalmazói profil

1

T-profil: transzport profil

1

F-profil: formátum profil

1

S-profil: support (támogatás) profil

1

R-profil: relay profil

Egyetlen rendszerhez az elsô 4 profil tartozik:

7 6 A-profil 5 4 3 T-profil1 2 1 GOSIP profilok

64

Két rendszer összekapcsolásához kell definiálni a relay profilt:

7

7 6 A-profil

A-profil

5

6 5

4 3 T-profil 1

4 3

T-profil 2

2

2

1

1 R-profil 1-2 GOSIP profil kapcsolatok

Az alkalmazói profil azoknak az alkalmazói szolgálatoknak az együttese, amelyek a három felsô OSI rétegben vannak és az üzenetkezelô (MHS), file (FTAM), katalógus (DIR) és terminál (VT) szolgálatokat tartalmazzák. A transzport profil az OSI alsó négy rétegét és ezek szolgálatait foglalja magában. Fôbb részei a lokális hálózatok (LAN), nagykiterjedésû hálózatok (WAN), a szállítási réteg és a relay rendszerek. A formátum profil az adatcsere és a dokumentumcsere szintaxisával foglalkozik és definiálja az információ formátumát a karakterkészlettôl a dokumentum formátumokig (EDIFACT és ODA). A support profil a kommunikáció menedzselését, a címzést és névadást, valamint a biztonságot és az ezekkel kapcsolatos elôírásokat tartalmazza. A relay profil az elôzô 4 profil kiegészítôje és a nyílt rendszerek összekapcsolását valósítja meg. Minden egyes profilt OSI szabványok együttese határoz meg. A 4 fôbb profilt a továbbiakban részletesen ismertetjük. A GOSIP-profilokhoz tartozó szabványok az OSI-profilokhoz tartozó szabványoknak részhalmazát alkotják. A nemzeti GOSIP-profilok a GOSIP-profilok további szûkítései, mert nincs értelme olyan profilelemeket definiálni, amelyek nem szerepelhetnek az architektúrában. Ha pl. a formátum profil nem tartalmaz ODA típusú dokumentumcsere formátumokat, akkor az ezekre vonatkozó elôírásokat nem érdemes kormányzati szinten megszabni. 55

ALKALMAZÓI PROFIL

A GOSIP alkalmazói profil a nyílt rendszerek összekapcsolásának felsô három rétegébe esô szolgáltatásokat tartalmazza.

7 6 5

F T A M M H S M H S (1 9 8 4 ) (1 9 8 8 ) Alkalmazói profil

65

D IR

V T

56

Állománykezelés — a GOSIP szabvány FTAM fejezete szerint A célszerû alkalmazás feltételei

A GOSIP FTAM (File Transfer Access and Management = állomány átvitel, hozzáférés, kezelés) szabványos szolgálatokat rögzít, amelyek segítségével távoli állománytárolókban lévô állományok olvashatók, írhatók, hozzáférhetôk és kezelhetôk. Ezen szolgálatokról még bôvebben szólunk az alábbiakban. Elôtte azonban tekintsük át a GOSIP FTAM alkalmazási feltételeit. A GOSIP FTAM szolgálatai célszerûen alkalmazhatók, ha a) a megkívánt információ-átvitel alapvetôen két rendszer között zajlik le, melyek egyike alapvetôen küldô, másika pedig fôként fogadó funkciókat lát el; b) több fogadó félre többnyire nincs szükség, vagy ha van is, akkor ez az igény megfelelô alkalmazói programmal kielégíthetô; c) biztosítható, hogy az információ-átvitel idejére az információ-átvitelében érintett rendszerek üzemkészek (vagyis "online" állapotban vannak); d) az információ-átvitel közvetlen, vagyis nincs szükség valamilyen alkalmazás rétegbeli közvetítôre; e) az átvinni kívánt információ állományokból áll (állomány-orientált információ-átvitel), mely állományok esetleg további feldolgozásra szorulnak. A GOSIP FTAM szimmetrikus kialakítású abban az értelemben, hogy használható mind állománytároló funkciót ellátó rendszerek esetében, mind az állománytárolóhoz hozzáférô rendszerek esetében. Megjegyzendô, hogy a korai GOSIP FTAM implementációk nyújtotta szolgáltatások várhatóan szegényesebbek lesznek, mint egyes, már meglévô lokális hálózati állományszolgáltatók (file server) szolgáltatásai. Ez különösen az állományok kezelésére (file management) vonatkozik. Ezért nem szükséges a GOSIP FTAM-ra egy csapásra áttérni. Jelenleg még nem célszerû feladni a rendelkezésre álló, megszokott szolgáltatásokat, azonban érdemes a jövôbeli beszerzésekre gondolni, amikor is komoly választék-csökkenést és/vagy magasabb árakat eredményezhet, ha valamilyen, nemzetközi szabvánnyal nem támogatott állománykezeléshez kell igazodni. Kihasználható, hogy a GOSIP FTAM — a nyílt rendszereknek elvének megfelelôen — alkalmas különféle gyártók által készített rendszerek közötti információátvitel megvalósítására is. Célszerû lehet az ilyen esetekben a GOSIP FTAM szolgáltatásait a meglévôvel párhuzamosan vagy azzal felváltva használni. Így például a GOSIP FTAM használata elônyös lehet nagykiterjedésû hálózatokra történô csatlakozási helyeken (pl. "WAN gateway"-ként), ennek módja azonban — vagyis hogy az adott lokális hálózat esetében ezen csatlakozási helyek centralizáltan vagy elosztva szerepel — az a GOSIP FTAM által nem szabályozott kérdés. Ezt a beszerzés kapcsán kell eldönteni.

66

A GOSIP FTAM szabvány jelenlegi állapota A GOSIP szabvány FTAM fejezete az ISO File Transfer Access and Management c. (ISO 8571) — mûszakilag stabil — szabványán alapszik. A GOSIP FTAM további nemzetközi szabványokkal is kompatibilis. Megállapítható, hogy a GOSIP szabvány FTAM fejezete — mint szabvány — mûszakilag stabil. A GOSIP FTAM szerinti termékek beszerezhetôek. Különösen elterjedtek a GOSIP FTAM-nak a T1 alfejezetével konform, egyszerû állomány-átviteli funkciókat ellátó termékek. Megjegyzendô, hogy léteznek és beszerezhetôek a GOSIP FTAM konformancia tesztjei is. A GOSIP FTAM beszerzési állapota: "megerôsített". A GOSIP FTAM funkciói A GOSIP FTAM az általa definiált szolgálatokat funkcionálisan rendszerezi, funkció-csoportokat képez. E funkció-csoportokra az angol elnevezésük kezdôbetûjével hivatkozik. A GOSIP FTAM funkció-csoportjai a következôk: T) állományátvitel (file transfer), A) állományhozzáférés (file access), M) állománykezelés (file management). Ezen funkció-csoportokból egy vagy több is választható a megkívánt alkalmazásnak megfelelôen. Tekintsük át az egyes funkció-csoportokba tartozó szolgálatokat. Az állományátvitel funkció-csoportja a következô szolgálatokat tartalmazza: állományok létrehozása, törlése, továbbá az állományok attribútumainak (fontos adminisztratív adatainak) kiolvasása, valamint ezen attribútumok módosításával kapcsolatban állományok kiválasztása és elengedése. A funkciócsoport T1-gyel jelölt szintje csupán a (teljes) struktúrálatlan állományokra, míg a funkció-csoport T2-vel jelölt szintje a (teljes) lineáris struktúrájú állományokra vonatkozik. A T1 szinthez tartozik — a már felsorolt szolgálatokon kívül — a struktúrálatlan állományok olvasása, írása (fölülírása, kiegészítése); a T2 szinthez pedig a lineáris struktúrájú állományok (ld. az 1.b táblázatot) olvasása, írása (fölülírás, hozzáírás állományhoz, közbeiktatás). Az állományhozzáférés funkció-csoportjának az alábbi elemei vannak: állományok létrehozása, törlése, továbbá az állományok attribútumainak (fontos adminisztratív adatainak) kiolvasása, valamint ezen attribútumok módosításával kapcsolatban állományok kiválasztása és elengedése. Az állományhozzáférés funkció-csoportja a lineárisan strukturált állományok azonosítható (címezhetô) adategységeit használja. Ezen adategységek (vagyis az állományhozzáférési adategységek) mérete, értelmezése az állomány típusától függnek. Az állományhozzáférés funkció csoportja tartalmazza még a következô szolgálatokat: adategység olvasása, írása (fölülírás, hozzáírás, közbeiktatás), lokalizálása, kitörlése. Opcionális szolgálat az adategységhez való többszörös hozzáférés letiltása. Az állománykezelés funkció-csoport lehetôséget ad az állomány-attribútumok megváltoztatására. Megjegyzendô, hogy az állománykezelés funkció-csoport

67

implementálása esetén az implementálására is szükség van.

állományátvitel

funkció-csoportjának

Az FTAM-nak van két, bizonyos alkalmazásoknál rendkívül fontos, opcionális funkció-egysége. Ezek az újraindíthatóság (restart) és a helyreállíthatóság (recovery). Az újraindíthatóság azt jelenti, hogy az adatátvitel pl. egy kommunikációs hiba után, megállapodás szerinti ponttól újraindítható. A helyreállíthatóság pedig azt jelenti, hogy az adatátvitel — valamilyen rendszer-összeomlás után — megállapodás szerinti állapotba visszaállítható. Az FTAM az információ-átvitel különféle módjait támogatja. Különféle — számukat tekintve a késôbbiekben várhatóan tovább bôvülô — információ típust és formátumot kezel. Megjegyzendô, hogy bizonyos információ-átviteli módok alkalmazásához megfelelô formátum vagy formátumok használatára van szükség. Struktúrálatlan dokumentum típusok FTAM-1 (kötelezôen implementálandó) FTAM-3 (kötelezôen implementálandó) NBS-9 INTAP-1

Leírásuk Struktúrálatlan szövegállomány Struktúrálatlan bináris állomány Állomány halmazt leíró állomány Rekord-szerkezetû adatállomány

A GOSIP FTAM által támogatott struktúrálatlan dokumentum-típusok Az FTAM szerinti információ-átvitel módját az határozza meg, hogy az adott FTAM implementáció mely, a GOSIP szabvány FTAM fejezetében leírt, funkció-csoportokat támogat, implementál. Bizonyos dokumentum típusok azonban kötelezôen implementálandók, míg mások a felhasználó igényei szerint implementálandók ill. elhagyhatók. A GOSIP FTAM által használt dokumentum típusokról a táblázatok adnak áttekintést. Strukturált dokumentum típusok FTAM-2 szekvenciális szöveg (T2 szint esetén implementálandó) FTAM-4 szekvenciális bináris állomány NBS-6 szekvenciális állomány NBS-7 véletlen hozzáférésû állomány NBS-8 indexelt állomány

Adategység tartalma karaktersorozat

Hozzáférési mód

byte-sorozat

szekvenciális pozíció

struktúra paraméterek struktúra paraméterek struktúra paraméterek + kulcsszó

szekvenciális pozíció (csak elôre) szekvenciális pozíció, struktúra sorszám szekvenciális pozíció, nem egyedi kulcsszó

68

szekvenciális pozíció

NBS-10 véletlen hozzáférésû bináris állomány NBS-11 indexelt állomány egyértelmû kulcsszavakkal NBS-12 egyszerû szöveg állomány

1 byte

pozíció szerint

struktúra paraméterek + egyedi kulcsszó 1 karaktersorozat

szekvenciális pozíció, egyértelmû kulcsszó szekvenciális pozíció (csak elôre)

A GOSIP FTAM által támogatott lineáris struktúrájú dokumentum-típusok A GOSIP FTAM e funkció-csoportjaira vonatkoznak bizonyos közös követelmények. Ilyen követelmény például, hogy minden GOSIP FTAM implementáció képes legyen az FTAM kommunikációs szerepkörök mindegyikének ellátására. Ezen szerepkörök a következôk: kezdeményezô, válaszoló, küldô, fogadó. (Amennyiben a felhasználó — valamilyen oknál fogva — ezen szerepkörök valamelyikét el akarja hagyni a kívánt implementációból, úgy ez speciális igényként értelmezendô. Megjegyzendô, hogy ilyen esetekben célszerû szakértôvel konzultálni észszerû specifikáció kialakításához.) A kezdeményezô szerepkörhöz az FTAM felhasználót kiszolgáló szolgálatok tartoznak. A felhasználó bizonyos esetekben tisztában van — tisztában kell, hogy legyen — azzal, hogy az FTAM szolgálatait használja (pl. parancssoros vagy menüvezérelt felhasználói interfész esetében). Más esetben az FTAM szolgálatok rejtve marad(hat)nak a felhasználó elôl. (Pl. valamilyen alkalmazói program használja az FTAM szolgálatokat). Egyes GOSIP FTAM implementációk alkalmazói program interfészt adnak a felhasználó kezébe, s ezeket használva FTAM szolgálatokat használó programokat írhat a felhasználó, vagy szoftver-fejlesztô. A kezdeményezô szerepkörben használt implementációk általában több funkciót támogatnak, mint a válaszoló szerepkörben használtak. Ily módon ugyanis a kezdeményezô szerepkörben használt implementáció más GOSIP vagy GOSIP-tól eltérô implementációval jobban együtt tud mûködni. A kezdeményezô szerepkörben használt implementációval szemben a GOSIP FTAM a következô alapelvárásokat támasztja: megállapítható legyen a kezdeményezô kiléte, számlája (account-ja), megadható legyen az állománytárolóhoz használt jelszava, állományt lehessen létrehozni, megnyitni (és ehhez pl. jelszót megadni). A GOSIP FTAM válaszoló szerepkörre vonatkozóan a virtuális állománytároló fogalmát használja. A virtuális állománytároló nem rendelkezik különösebb belsô szerkezettel, állományok gyûjteményének tekintendô. Az állományok elôírt tulajdonságokkal rendelkeznek. A virtuális állománytároló különféle valóságos állománytárolók modellezésére alkalmas; s lehetôvé teszi, hogy eltérô szoftver/hardver rendszerben lévô kezdeményezô és állományszolgáltató esetén is a kezdeményezô ezen állományszolgáltatók állományaival dolgozhasson. A virtuális állománytároló tehát valóságos állománytárolókra van leképezve. Megjegyzendô azonban, hogy a GOSIP FTAM nem definiálja a leképzés mikéntjét. Az állományokra a GOSIP FTAM a következô megkötéseket teszi:

69

1

Egyértelmû állománynevek használata.

1

Az állományokhoz adminisztrációs attribútumok tartoznak.

1

Az állományok egy vagy több hozzáférési adategységet tartalmaznak.

Az adminisztrációs attribútumok négy csoportba sorolhatók, úgymint alapvetô, tárolási, biztonsági és speciális magánhasználatú attribútumok. (Megjegyezzük, hogy ez utóbbi attribútum használatát a GOSIP FTAM határozottan ellenjavallja.) Az alapvetô attribútumok a következôk: állománynév, az állományon végezhetô állománymûveletek, dokumentum formátum. A tárolási attribútumok: tárolási számla (account), az állomány létrehozásának idôadatai, az állomány utolsó módosításának idôadatai, az állomány utolsó olvasásának idôadatai, az állomány utolsó attribútumváltoztatásának idôadatai, a létrehozó kiléte, az utolsó olvasó kiléte, az utolsó attribútum-változtatást végrehajtó személy kiléte, az állomány "rendelkezésre állása", az állomány jelenlegi és jövôbeli mérete. A biztonsági attribútumok pedig a következôk: hozzáférési státusz, jogi minôsítés. A táblázatokból látható, hogy a GOSIP FTAM igen sok attribútumot értelmez, ugyanakkor azonban nem szükséges ezek mindegyikét elôírni, használni, mivel jelenleg a legtöbb állománytároló ezen attribútumoknak csak töredékét támogatja. Itt jegyezzük meg, hogy a támogatás teljes, vagy részleges lehet. Megjegyezzük, hogy a GOSIP FTAM hibakezelési osztályokat is definiál (0, 1, 2 és 3), amellyel megadható, hogy valamely hiba elôfordulása esetén milyen hiba-elhárító mûvelet kerüljön használatra. (A 0 osztály esetén nincs semmilyen hiba-elhárítási mûvelet implementálva. Ez egyébként az alapértelmezés.) GOSIP FTAM implementáció beszerzésekor célszerû a GOSIP FTAM adott implementációra vonatkozó konformancia kérdôívet (a nyilatkozat a protokoll implementáció konformanciájáról) kitölteni ill. a gyártóval kitöltetni. A nyilatkozatban — a nyilvánvaló adminisztrációs adatokon túlmenôen — egyrészt szerepel az egyes szolgálatok GOSIP FTAM minôsítése (kötelezô, opcionális), másrészt a felhasználói specifikáció, harmadrészt a gyártó részletes nyilatkozata arról, hogy az implementáció mely GOSIP FTAM funkciókat valósítja meg, mennyiben tesz eleget a felhasználói specifikációnak, továbbá, hogy melyik GOSIP FTAM verzió szerinti konformanciáról van szó. Megjegyzendô, hogy alaposan mérlegelni kell — esetleg szakértô bevonásával — hogy bizonyos látszólag egyszerû igényeknek milyen anyagi vonzata van. A felhasználói specifikációt úgy kell összeállítani, hogy az a jelenlegi és várható igényeknek megfeleljen, de az indokoltnál ne legyen szigorúbb. Nem szabad, hogy a GOSIP FTAM szolgáltatások gazdag tárháza megtévessze és elkápráztassa a vevôt.

70

A FTAM beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 3. kötet 2A-1-tôl 2A-14 oldal). 57

Üzenetkezelés — GOSIP MHS GOSIP MHS(84), GOSIP MHS(88)

A GOSIP MHS szabvány a "store-and-forward" ("tárold és továbbítsd") típusú üzenetkezelô rendszerekre vonatkozik. A GOSIP MHS szabványnak két része van. A korábbi, a GOSIP MHS(84) elsôsorban különbözô elektronikus levelezési rendszerek közötti szabványos kapcsolat kialakítására szolgál. Az újabb rész, a GOSIP MHS(88) jelentôsége leginkább abban rejlik, hogy a helyi üzenettovábbító rendszereken belüli szabványos protokollokat adja meg, továbbá abban, hogy fontos funkciókkal bôvíti a korábbi részt. A GOSIP MHS szabvány állapota A GOSIP MHS(84) szabvány a CCITT X.400 (1984) Recommendations for Message Handling Systems c. — mûszakilag stabil — ajánlásán alapszik, és további CCITT és európai szabvány magyarázatokat és értelmezéseket ismer el. A GOSIP MHS(84) szabvány — mûszaki értelemben — stabil. A GOSIP MHS(88) szabvány az ISO MOTIS — mûszaki értelemben stabil — szabványon és az azzal egyenértékû CCITT X.400 (1988) — mûszaki értelemben stabil — ajánláson alapszik. A GOSIP MHS(88) — mint szabvány — mûszakilag ideiglenes. A GOSIP MHS(84) szabvány szerinti termékek általánosan hozzáférhetôk. A GOSIP MHS(84) szabvánnyal rokon szabványokra vonatkozó konformancia tesztek léteznek, ezek kisebb módosítással az MHS(84) szerinti konformancia vizsgálatra alkalmassá tehetôk. A GOSIP MHS(84) beszerzési állapota: megerôsített. GOSIP MHS(88) szabvány szerinti termékek léteznek, bár számuk messze elmarad a korábbi rész szerinti termékek számától. Konformancia tesztek fejlesztése folyamatban van. A GOSIP MHS(88) beszerzési állapota: meg nem erôsített. Megjegyzendô, hogy az MHS(88) nem az MHS(84) helyettesítésére szolgál, inkább alternatívát kínál a felhasználó részére. A GOSIP MHS funkciói Egyszerû, de használható üzenetkezelô rendszer specifikálható olymódon, hogy egyszerûen a GOSIP MHS valamelyik részére hivatkozunk és megköveteljük, hogy a beszerzendô termék azzal a résszel konform legyen. (A késôbbi rész esetén már van néhány alapvetô választási lehetôség, és természetesen mindkét rész esetében számos másodlagos opció közül lehet választani. Tanácsos azonban ilyen másodlagos opcióknak a specifikációba történô beiktatása elôtt szakértô véleményét kikérni.) A GOSIP MHS(84) elsôdleges célja, hogy a "store-and-forward" típusú üzenetkezelô rendszerrel kapcsolatos beszerzésekhez a gyakorlatban alkalmazható specifikációt adjon. A GOSIP MHS(84) alapkiépítésû implementációja üzenettovábbító szolgálatot (MTS) lát el. E szolgálat címzett-listán szereplô címzettekhez továbbít üzeneteket és értesítést küld a feladónak a kézbesítés

71

tényérôl. Az ilyen üzenettovábbító szolgálattal személyek közötti üzenetközvetítô rendszer (Interpersonal Messaging) hozható létre, mely üzenetközvetítô rendszerre épül az elektronikus levelezés. Az üzenetek itt ASCII karakterekbôl állnak. Megjegyzendô, hogy a legtöbb esetben MHS(84) szabvány szerinti interfésszel látták el a már meglévô termékeket, s így nem készültek teljes MHS(84) implementációk. Az említett interfész lehetôvé teszi, tetszôleges MHS(84) szolgálati elem elérését, a megfelelô szolgálatot azonban a meglévô elektronikus levelezést kezelô program hajtja végre. Megemlítjük, hogy az EDI felhasználók egy részének is megfelel az MHS (84), bár bizonyos esetekben az EDI-hez jobban illeszkedô megoldást kell választani, mint amilyen az EDI alapú üzenetkezelés (EDIM). Az elektronikus levelezéstôl eltérô alkalmazások esetére a GOSIP MHS(84) részleges konformancia szintet (GOSIP MHS(84) MTS) definiál, amely csak az üzenettovábbító szolgálati funkciók konformanciájára vonatkozik. A GOSIP MHS(88) új szolgáltatásokkal bôvítette ki az 1984-es MHS nyújtotta funkciókat. Bevezetésre kerültek a disztribúciós listák. Új biztonsági szolgáltatást vezettek be. Új lehetôséget kínál a katalógus szolgálat használata. Mód nyílik célravezetôbb konfigurációk kialakítására. A GOSIP MHS(88) funkció-csoportokat definiál, mely funkció-csoportok külön-külön, vagy egymással kombinálva is használhatók, s így — e moduláris kialakítással — széleskörû felhasználói igényeket lehet kielégíteni. A GOSIP MHS(88) implementáció támogathat személyek közötti üzenetközvetítôi rendszert, amelyre — mint azt az MHS(84) kapcsán említettük — elektronikus levelezési rendszer épülhet, de támogathat más jellegû üzenetközvetítô rendszert is, mint például az EDI alapú üzenetkezelést (EDIM). A GOSIP MHS(88) nem vett át bizonyos szolgálatokat az 1988-as rokon MHS szabványokból. Ilyen át nem vett szolgálat a nem-elektronikus kézbesítés (physical delivery), telex-hozzáférés, az üzenetek konverziója. (Ilyen szolgálatok azonban külsô, nem GOSIP MHS rendszerekben rendelkezésre állnak, így GOSIP MHS(84) implementációból kezdeményezhetôk.) A komponens beszerzési lehetôségek jelentôsen bôvültek, így célszerû volt a hálózati munkát megbízhatóbbá, egységesebbé, áttekinthetôbbé tenni. Ezért volt szükség a GOSIP MHS(88) kidolgozására és ez indokolja azt, hogy a GOSIP MHS(88) szolgálatai átfogóbbak, mint a GOSIP MHS(84)-é. A GOSIP MHS(88) szabvány szerinti implementációk, már teljesebbnek ígérkeznek, s várható, hogy nem csupán meglévô programokhoz készül MHS interfész. Ez egyúttal azt is jelenti, hogy a meglévô programok nem korlátozzák a nyújtható szolgálatokat. Megjegyzendô, hogy az MHS(88) más szabványokkal párhuzamosan készült, és így tág tere volt az együttmûködésnek. A GOSIP MHS(84) implementációkban az üzenettovábbító ügynök (MTA) és a személyek közötti üzenetközvetítô rendszer (IPM) felhasználói ügynöke (UA) egy fizikai rendszerben helyezkedik el. Ezek együttmûködése lokális kérdés, kialakítását többnyire a gyártó határozza meg.

72

A GOSIP MHS(84) támogatja az adott üzenettovábbító ügynök és más hasonló ügynökök együttmûködését, de önmagában egy ilyen ügynök implementálása nem tartozik a GOSIP MHS(84)-be. A GOSIP MHS(84) az üzenettovábbító ügynök és a felhasználói ügynök alkotta párnak csak a külsô viselkedését adja meg. Foglalkozik még a GOSIP MHS(84) szolgálat felhasználói elérhetôségével. Ily módon a GOSIP MHS (84) alkalmazkodott a meglevô rendszerekhez, s nem korlátozta fölöslegesen a szabványtermékek elérhetôségét. A GOSIP MHS(88) a beszerzés nagyobb szabadságát tûzte ki célul, rugalmasabb rendszer-összeállítást tesz lehetôvé. A rendszer elemei a következôk: üzenettovábbító ügynök, felhasználói ügynök és üzenettár (MS). A szabványos elemek különbözô gyártóktól is beszerezhetôk, kombinálhatók. Lássunk néhány példát a GOSIP MHS(88) szabvány szerinti jellemzô konfigurációkra: a) Üzenettár, felhasználói ügynök és üzenettovábbító ügynök; b) üzenettovábbító ügynökkel egybeépített üzenettár v. üzenettárak (ez a konfiguráció mind az üzenetküldést, mind az üzenetkézbesítést támogatja); c) üzenettovábbító ügynökkel egybeépített felhasználói ügynök v. ügynökök (ez a konfiguráció mind az üzenetküldést, mind az üzenetkézbesítést támogatja); d) távoli felhasználó ügynök támogatására szolgáló üzenet-továbbító ügynökkel egybeépített felhasználói ügynök és üzenettár; e) távoli felhasználói ügynök, amely üzenettovábbító ügynökhöz és üzenettárhoz férhet hozzá. A GOSIP MHS(88) szabványos határfelületeket ad az említett elemek között, s ily módon kiküszöbölhetôk a nem szabványos interfészek valamely lokálisan elosztott MHS rendszerbôl, s így a nyílt rendszerek elve nem szenved csorbát. (Így például célszerû kiküszöbölni a különbözô gyártók használta protokollokat a GOSIP MHS(88) szerintire olyan esetben, amikor a felhasználói ügynök és az üzenettovábbító ügynök nem azonos rendszerben helyezkedik el.) Megjegyzendô, hogy a GOSIP MHS(88) szabvány megôrzi a kompatibilitást az X.400 (1984) rendszerekkel, de — minthogy ez az igény nem merül fel minden üzenettovábbító ügynök esetében — ez nem feltétele a minimális konformanciának. Az MHS(84) kétféle szolgálati elemet definiál, úgy mint üzenettovábbító szolgálati elemet, amely a felhasználói ügynökökkel tartja a kapcsolatot, és amely az üzenettovábbító rendszer mûködését szabja meg, ill. a személyek közötti üzenetközvetítô rendszer szolgálati elemet, amely az üzenettovábbító szolgálati elemet teszi az MHS felhasználó számára hozzáférhetôvé. A GOSIP MHS(88) szabványnak az alapvetô üzenetkezelô funkciókat felölelô része (Common Messaging) alap-szolgálatokra (kernel) és funkciócsoportokra van osztva. Az alapszolgálatok az adott üzenettovábbító-terület minimális konformancia elôírásait adják. A funkciócsoportok további

73

opcionális szolgálatokat definiálnak — konzisztens módon — fontos területeken. Az alapszolgálatok a következôk: - üzenettovábbító ügynök alapszolgálatai (P1 protokoll), - üzenettovábbító rendszer alapszolgálatai, - üzenettár alapszolgálatai (P7 protokoll). Az MHS beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 3. kötet 3A-1-tôl 3A-14 oldal, és 3B-1-tôl 3B-6 oldal). 58

Katalógus szolgálatok — GOSIP DIR A katalógus szolgálatok szerepe

A nyílt, elosztott rendszerek hatékony használata iránti igény magával hozta a katalógus szolgálatok iránti igényt is. Szükség van ugyanis olyan szolgálatokra, amellyel csökkenthetô az elosztott rendszer valamely távoli elemére, vagy távoli részére, továbbá ezek használatára vonatkozó ismeretek mennyisége, vagy ezen elemek, részek használatához szükséges egyeztetési munka. A katalógus szolgálatok — függetlenül attól, hogy lokálisan, vagy elosztott módon mûködnek — lehetôséget teremtenek arra, hogy felhasználó-barát módon lehessen valamilyen távoli rendszert, programot, felhasználót, alhálózatot azonosítani. A GOSIP DIR szabvány jelenlegi állapota A GOSIP DIR szabvány az ISO Directory Standard (ISO 9594) — mûszakilag stabil — szabványon és a vele megegyezô CCITT X.500 (1988) ajánláson alapszik és további nemzetközi szabványokkal van kapcsolatban. Megjegyzendô azonban, hogy a GOSIP DIR szabvány szolgálatainak bôvítése napirenden van. A GOSIP szabvány DIR fejezete — mint szabvány — mûszaki értelemben ideiglenes. A GOSIP DIR szerinti termékek beszerezhetôek, bár a termékek választéka nem kielégítô. Vonatkozik ez a GOSIP DIR szerinti kereskedelmi szolgáltatásokra is. Konformancia-tesztek részben hozzáférhetôek, részben még fejlesztés alatt állnak. A GOSIP DIR beszerzési állapota: meg nem erôsített. A GOSIP DIR funkciója A GOSIP DIR szabvány elsôdleges feladata, hogy gyakorlatban használható specifikációt adjon katalógus szolgálati és/vagy katalógus szolgálathoz hozzáférô termékek beszerzéséhez. A katalógus szolgálat ugyanis a nyílt rendszerekben történô kommunikáció egyik fontos szolgálata, amelynek szolgáltatásait mind az OSI felhasználók, mind az OSI alkalmazási réteg programjai, mind az egyéb OSI kommunikációs szolgálatok igénybe veszik, igénybe vehetik. A GOSIP DIR szabvány — mint arra utaltunk — még nem végleges: fejlôdôben, bôvülôben van (pl. a GOSIP FTAM, a GOSIP EDI és a GOSIP VT szabványokkal összefüggésben). A GOSIP DIR jelenlegi verziója szerinti ter-

74

mékekkel szemben a GOSIP DIR azt a követelményt támasztja, hogy a ma már elôrelátható, s az újabb GOSIP verziókba várhatóan bekerülô elôírások teljesítésére — megfelelô kiegészítéssel alkalmassá tehetôk legyenek. A GOSIP DIR kellôen rugalmas a tekintetben, hogy a katalógus szolgálati komponensek külön-külön történô beszerzésének a lehetôségét biztosítja. Ezek a komponensek aztán egymással kombinálhatók, attól függetlenül, hogy az adott termék katalógus felhasználói ügynöki (DUA) funkciót, vagy katalógus szolgálati ügynöki (DSA) funkciót lát el. Ezen kombinálhatóság nem függ attól, hogy az adott termék a katalógus szolgálati ügynök funkcióját önállóan, vagy külsô katalógus szolgálatokhoz kapcsolódva látja el. Megjegyzendô, hogy a katalógus felhasználói ügynökök és a katalógus szolgálati ügynökök lehetnek azonos fizikai rendszerben, de lehetnek különálló — pl. lokális hálózattal összekötött — rendszerekben is. Valamely katalógus szolgálat lehet általános célú, ekkor sokféle katalógus adattípus kezelésére van szükség, vagy lehet speciális abban az értelemben, hogy valamilyen adott alkalmazással (pl. üzenetkezeléssel) kapcsolatos — többé-kevésbé homogén — adatokra vonatkozik. Nyilvánvaló, hogy az adott katalógus szolgálat rendeltetése jelentôsen befolyásolja az ésszerû konfigurációt. A GOSIP DIR funkció-csoportokat ad meg, amelyek akár külön-külön, akár egymással kombinálva használhatók a felhasználó által megszabott igényeknek megfelelôen. A katalógus szolgálati ügynökök lehetnek önállóak (standalone), vagyis olyanok, amelyek valamilyen oknál fogva még nem elosztott szolgálat részeként mûködnek. Megjegyzendô, hogy a GOSIP DIR szabvány elôírja, hogy késôbb ezen önálló katalógus szolgálati ügynökök, megfelelô kiegészítéssel, más katalógus szolgálati ügynökökkel képesek legyenek együttmûködni. Az önálló katalógus szolgálati ügynök támogatja katalógushoz való hozzáférést. A katalógus szolgálati ügynökök tartozhatnak valamilyen elosztott katalógus szolgálathoz, mely szolgálat tehát több katalógus szolgálati ügynök együttmûködésén alapszik. Amennyiben ez a rendszer kommunikál a külvilág nyilvános katalógus szolgálataival, úgy ezen elosztott katalógus szolgálati rendszer részét képezi az ún. globális katalógus szolgálatnak. A GOSIP DIR éppen az önálló katalógus szolgálati ügynök késôbbi, elosztott rendszerbe történô integrálását elôsegítendô elôírja, hogy az ilyen ügynök is a katalógus információs fa (DIT) elnevezési rendszerét használja és tartalmazhassa ezen információs fa valamely részét. Az elosztott katalógus szolgálatban mûködô szolgálati ügynökök kétfélék lehetnek: olyanok, amelyek támogatják a katalógushoz való hozzáférést és olyanok, amelyek nem. Az utóbbiak például továbbíthatják az információ-kéréseket az elosztott katalógus megfelelô helyére, valamint maguk is tartalmazhatják az elosztott katalógus információs adatbázis (DIB) valamely részét. Mindazonáltal a katalógushoz való hozzáférést nem támogató katalógus szolgálati ügynök alkalmazása nem túl gyakori. A GOSIP DIR szerinti elosztott katalógus szolgálati ügynök képes kell legyen információ kérések, valamint folytatólagos hivatkozások generálására 75

és fogadására, s a szükséges és megfelelô irányú válaszlépések megtételére (pl. ezen folytatólagos hivatkozások összekapcsolására, megfelelô helyre — valamely katalógus felhasználói ügynökhöz, vagy szolgálati ügynökhöz — történô továbbítására). A katalógus felhasználói ügynök megjelenési formája sokféle lehet, s ily módon különbözô alkalmazói igényeknek felelhet meg. Biztosíthat felhasználói felületet, vagy programozói határfelületet. Bizonyos esetekben csak az információ kinyerése a cél, más esetekben szükség lehet az adatok módosítására, kiegészítésére, megváltoztatására. A GOSIP DIR — jelenleg — nem rögzíti ezen határfelületeket, és így a beszerzés kapcsán kell ezeket megfelelôen specifikálni. A GOSIP DIR a katalógus felhasználói ügynökök két alapvetô típusát adja meg: az általános célú ill. az alkalmazásfüggô ügynököket. Az általános célú ügynök számos katalógus információs fa szerkezetet és sémát támogat, és többnyire emberi használatra készül. Az alkalmazásfüggô ügynök jóval kisebb számú katalógus információs fa szerkezetet és sémát támogat, és az ügynököt többnyire valamilyen alkalmazói program (pl. üzenet továbbító ügynök vagy felhasználói ügynök) használja. A GOSIP DIR a definiált szolgálatait a következô három funkciócsoportokba osztja: a katalógus szolgálati ügynök alapszolgálatai (DSA Kernel), ez a funkció-csoport megadja a szolgálati ügynök — a felhasználói ügynök számára a katalógus hozzáférés során — nyújtotta szolgálatokat; a katalógus felhasználói ügynök alapszolgálatai (DUA Kernel), ez a funkciócsoport megadja katalógus hozzáféréssel kapcsolatos szolgálatok használatának módját és a felhasználó katalógushoz való hozzáférési lehetôségeit; az elosztott katalógus mûveletek (Distributed Operation) funkció-csoportja az elosztott katalógusban lévô szolgálati ügynökök egymásnak nyújtott szolgálatait tartalmazza. A szolgálati ügynököknek a katalógus szolgálatok teljes rendszerét kell tudni támogatniuk. Ezek a következôk: olvasási mûveletek (olvasás, összehasonlítás, elengedés); keresési mûveletek (listázás, keresés); módosító mûveletek (új tétel beiktatása, tétel törlése, tétel módosítása). A felhasználói ügynökök legalább az olvasási mûveleteket kell, hogy támogassák. A katalógus sémáján a teljes katalógus szabályainak összességét értjük. Ezen szabályok vonatkoznak az egyes tételek nevére, hierarchiájára, a tételekben lévô információra. A sémának lehetnek alsémái, ezek a különbözô szervezetek által kezelt katalógus részekre vonatkoznak. Az alsémák objektum osztályokkal, objektum attribútumokkal, katalógus információs fa szabályokkal, az attribútum szintaxisával, egyezési szabályokkal vannak megadva. A GOSIP DIR jelenleg két standard sémát ismer, úgy mint az általános célút és a a GOSIP MHS (88)-hoz kapcsolódót. A katalógus szolgálat kapcsán szólni kell a katalógusokban tárolt adatokhoz való hozzáférés biztonsági vonatkozásiról is. Bizonyos esetekben nyilvánvaló igény, hogy a katalógushoz történô hozzáférést a hozzáférést kérô kilététôl lehessen függôvé tenni. Ehhez megfelelô azonosítási rendszert kell alkalmazni. A GOSIP DIR jelenlegi verziója csak egyszerû védelmi

76

funkcióra képes. Megjegyzendô, hogy más szolgálatoknak (pl. üzenetkezelés részére) még ilyet sem nyújt. A GOSIP DIR konformancia nyilatkozat még nincs kidolgozva, a beszerzésnél megadandó minimális specifikáció és nyilatkozat azonban rendelkezésre áll, s az elôbbiek alapján megfelelôen kitölthetô. A DIR beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 3. kötet 4A-1-tôl 4A-5 oldal). 59

Virtuális terminál — GOSIP VT Forms A GOSIP VT Forms alkalmazása

A GOSIP szabvány VT fejezetének egyetlen jelenlegi alfejezete a Forms, amely az ûrlap üzemmódú virtuális terminálra vonatkozik. A kormányzati adminisztratív környezetben az ûrlap üzemmódú termináloknak nyilvánvalóan van létjogosultságuk, hiszen általában mind az adatok bevitele történhet ûrlapszerûen, mind a kiolvasásuk történhet ily módon. A kormányzati adminisztratív környezet gyakori jellemzôje, hogy az adott adminisztratív funkció ellátása érdekében sok esetben elosztott számítógéphálózat használatára van szükség. Ilyenkor a terminálon keresztül bevitt adatok távoli rendszerben vagy rendszerekben kerülnek tárolásra, feldolgozásra, illetve a terminálon megjelenô adatok távoli rendszerbôl vagy rendszerekbôl származnak. A GOSIP VT Forms szabvány különösen olyan esetekben alkalmazandó, amikor ezen távoli rendszerek különbözô gyártóktól származnak, s ezeken többféle alkalmazói program használja az említett terminált és további terminálokat. A GOSIP VT Forms szabvány nem köti meg, hogy a terminált használó gép a terminálhoz milyen "közel" van, a kapcsolat lehet közvetlen, vagy létrejöhet lokális vagy nagykiterjedésû hálózaton keresztül. Megjegyzendô azonban, hogy a GOSIP VT Forms szabvány alkalmazásának leginkább olyan esetekben van létjogosultsága, amikor is a távoli gép viszonylag kis sávszélességgel üzemelô, nagy kiterjedésû hálózaton keresztül kommunikál számos terminállal. A virtuális terminálokra vonatkozó szabványok számos létezô terminálrendszer szolgáltatásaiból, mûveleteibôl, mûködési módjaiból szûrôdtek le. Valamely adott felhasználás esetében ezen lehetôségeknek csupán a töredékére van szükség. A szabványok használatát megkönnyítendô bizonyos szokásos szolgáltatásoknak egy-egy konzisztens körét és a hozzájuk tartozó alkalmasan választott paraméter-értékeket megadják és elnevezik. Ezeket az együtteseket virtuális terminál környezeteknek nevezik. A (távoli) gép és a terminál a közöttük folyó kommunikáció során egyezteti a használható terminál funkciók körét, és ezen funkciókra vonatkozó korlátozásokat. Ezután csupán ezen egyeztetett funkciók használatára korlátozzák magukat. Egy viszonylag széleskörû funkció-készlet kialakításához megfelelô segédletet nyújt valamely virtuális terminál környezet kiválasztása. A GOSIP VT Forms is egy ilyen virtuális terminál környezetet definiál — az ISO Basic Class VT szabvány alapján —, amely tehát egy ûrlappal dolgozó adminisztratív munkahelyi környezet számára megfelelô.

77

A GOSIP VT Forms szabvány állapota A GOSIP VT Forms szabvány — mint azt az elôbbiekben már említettük — az ISO Basic Class Virtual Terminal — mûszakilag stabil — szabványon alapszik és további nemzetközi szabványokhoz kapcsolódik. A GOSIP VT Forms — mint szabvány — mûszakilag stabil. GOSIP VT Forms szerinti termékek beszerezhetôk. Azonban GOSIP VT Forms szerinti konformancia tesztek jelenleg nem ismertek, mindazonáltal rokon szabványokhoz készültek ilyenek. A GOSIP VT Forms szabvány beszerzési állapota megerôsített. A GOSIP VT Forms funkciói A GOSIP VT Forms szabvány specifikálja az OSI környezetben futó interaktív alkalmazásokhoz szükséges kommunikációs támogatást, mely interaktív alkalmazás — valamilyen terminálon keresztül — emberi közremûködést igényel. A GOSIP VT Forms szabvány fôképpen a hálózatban mûködô terminálok kommunikációs vonatkozásaival foglalkozik. A GOSIP VT Forms olyan alkalmazásokat támogat, amelyeknél az interaktív párbeszéd karakteres (vagyis karaktereket használó) terminállal leírható. A szabvány opcionálisan támogatja az egyszerû grafikus karakterek használatát. A karakterek megjelenítése — a szabvány szerint — lehet színes, vagy monokróm. A GOSIP VT Forms lehetôséget ad különféle egyszerû, figyelemorientáló hatásokra, úgy mint villogtatás, inverz megjelenítés, vastag betûs megjelenítés, aláhúzás. Megjegyzendô, hogy a szabvány megengedi nyomtató illesztését a terminál konfigurációhoz. A nyomtatót azonban valamely terminálhoz rendelt lokális erôforrásként kezeli, más terminálok e nyomtatóhoz nem férnek hozzá. A nyomtató egyébként nem csak a képernyôn látható ûrlapot nyomtathatja, van arra lehetôség, hogy a (távoli) gép más szövegeket (pl. kapcsolódó ûrlapot) nyomtasson. A GOSIP VT Forms szerinti ûrlap üzemmódú terminál a teljes képernyôt használja (nagyobb adatmegjelenítési igény esetén a képernyôk között lapoz). Kezeli a képernyôn (a lapon) a GOSIP VT Forms szolgálat a képernyô-részekre (adatmezôkre) vonatkozó elrendezését. Az ûrlap üzemmódú terminál több lapból álló karakteres információt is tárolhat lokálisan. Ezen lapokat a (távoli) gépen futó alkalmazói program — az érvényben lévô hozzáférés-vezérlés függvényében — frissítheti, átírhatja. Megjegyzendô, hogy a terminál által történô frissítésre, átírásra beviteli szabályok vonatkoznak, amelyek — a futó alkalmazás által az adatmezôkre megadott specifikáció szerint — az egyes adatmezôkbe kerülô adatok ellenôrzését írják elô. Ily módon a (távoli) gép megszabadulhat a bevitel közvetlen ellenôrzésével kapcsolatos vezérlési és kommunikációs tehertôl. Ez az eredmény különösen fontos sok terminált kezelô gép esetén. A kitöltendô ûrlap elrendezése és beviteli szabályai (vagyis mintája) lehetnek "egyszer és mindenkorra" rögzítettek, ekkor az adott minta lokálisan tárolható, vagy lehet változó, mely esetben az ûrlap mintája a (távoli) gépbôl — "egyszer és mindenkorra", vagy valamilyen rendszerességgel — letölthetô.

78

A jelenleg érvényes GOSIP VT Forms nem adja meg az ûrlap-minták használati módját, mindazonáltal a terminál ilyen jellegû használatát nem zárja ki. Kívánatos és várható, hogy a késôbbi GOSIP VT Forms verziók foglalkoznak majd az alábbi funkciókkal (pl. úgy, hogy más nemzetközi szabványra hivatkoznak): egy vagy több lokálisan tárolt ûrlap-minta betöltése a virtuális terminál környezetébe, egy vagy több ûrlap-minta státuszának lekérdezése, egy vagy több ûrlap-minta betöltése (távoli) géprôl. Jelenleg azonban, amennyiben a beszerzés során az ûrlap-minta kezelésére vonatkozó igény fennáll, akkor azt a gyártóval kell egyeztetni. A GOSIP VT Forms szerinti ûrlap üzemmódú terminál kiegészítôje lehet valamilyen ablakos terminálkezelô programnak. Valamelyik ablak például ilyen ûrlap üzemmódú terminált valósíthat meg, amelyet például egy távoli gép használ. A GOSIP VT Forms szabvány szerinti rendszerek beszerzésekor nem lehet közömbös, hogy milyen fejlesztôi eszközök állnak rendelkezésre alkalmazói programok írásához. E kérdéssel persze hangsúlyosan abban az esetben kell csak foglalkozni, ha komoly méretû alkalmazói programok fejlesztésére van kilátás. A GOSIP VT Forms szabvány szerinti termék beszerzésénél célszerû a konformancia kérdôívet használni, s azt a gyártóval kitöltetni. Amennyiben lehetséges, célszerû a beszerzendô termék specifikálásánál csak az alapvetô, a konformancia nyilatkozat összefoglaló részében szereplô opciókat választani. Ha azonban — valamilyen oknál fogva — további opciók megadása is szükségesnek látszik, akkor tanácsos szakértô tanácsát kérni. Meg kell adni, vagy a gyártótól erre vonatkozó információt kell kérni, hogy a virtuális terminál funkcióit fizikailag hol látja el. Meg kell adni továbbá a különféle speciális követelményeket, így például sebességi elôírásokat, tesztelésre vonatkozó elvárásokat. Tekintsük át most a konformancia nyilatkozat összefoglaló részében szereplô, alapvetô specifikációs kérdéseket. A vásárlónak meg kell adnia, milyen rendszer konfigurációt kíván beszerezni. Gépen elhelyezkedô virtuális terminál implementációra, vagy a terminálokban elhelyezkedô virtuális terminál implementációra van-e szüksége, vagy esetleg a két megoldást egyszerre igényli. Fontos tudni, hogy a GOSIP VT Forms mind a kezdeményezô, mind a válaszoló szerepkör implementálását megköveteli. (Ha azonban a felhasználó valamelyik szerepkör implementálásától el kíván tekinteni, akkor azt a gyártóval kell egyeztetnie.) A GOSIP VT Forms funkció-egységei közül kettô opcionális. Az elsô az üzemmód átkapcsolási lehetôség biztosítása (Switch Profile), amely — implementálása esetén — lehetôvé teszi a virtuális terminál mûködési módjának megváltoztatását a társulás során. A második a sürgôs adatok kezelésével kapcsolatos (Urgent Data) funkció-egység. A GOSIP VT Forms kétféle virtuális terminál környezet támogatását írja elô: az OSI virtuális terminál szabványban szereplô szinkronmodell szerinti ûrlap üzemmódú virtuális terminál környezetet és az európai szabványokban szereplô OIW ûrlap üzemmódú virtuális terminál környezetet. 79

A VT beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 3. kötet 6A-1-tôl 6A-10 oldal). 60

GOSIP TRANSZPORT PROFIL

A GOSIP transzport profil (továbbiakban GOSIP-T) a nyílt rendszerek összekapcsolásának alsó négy rétegét tartalmazza. 4 3 LAN

2

RELAY

WAN

Relaying

Wide Area Networking

1 Local Area Networking

A GOSIP-T profil A GOSIP 4 lokális hálózata CSMA/CD (Carrier Sense Multiple Access/Collision Detection), token gyûrû és FDDI (Fiber Distributed Data Interface) típusú lehet. A nagykiterjedésû hálózat az X.25 interfészre épül. A szállítási réteg protokollok az ISO transzport protokollok 0-s, 2-es és 4-es osztályába tartozhatnak. A GOSIP-T mindhárom esetben (LAN, WAN, RELAY) meghatározza, hogy mely szabványoknak megfelelô termékekbôl tervezhetô a rendszer transzport profilja. GOSIP-T

4

8073 (Classes 0, 2 & 4) CLNS

3

2 1

8473 8802-2 LLC1 8802-3 CSMA/CD LAN

8802-5 Token Ring LAN

CONS 8878 8881 8208 8802-2 LLC2 9314 FDDI LAN

CONS 8878 8208 X.25 (1984) 7776 X.21 / X.21 bis X.25 WAN

A GOSIP 4 T-profilja Az ábrán lévô CLNS és CONS rövidítés az összeköttetés módjára utal. CLNS az összeköttetésmentes (Connectionless-mode Network Service), a CONS az összeköttetés-orientált (Connection-mode Network Service) hálózati szolgálatot jelenti. Összeköttetésmentes üzemmód esetén nem kell létrehozni az összeköttetést, mert ez állandóan létezik (pl. permanens virtuális áramkör biztosítja). Összeköttetés-orientált üzemmód esetén hívásonként fel kell építeni az összeköttetést és az adatátvitel végén lebontani.

80

61

Lokális hálózatok

Az OSI LAN szabványok a fizikai réteget, a közegelérés vezérlési (Medium Access Control, MAC) alréteget és a logikai kapcsolatvezérlési (Logical Link Control, LLC) alréteget szabványosítják. A fizikai réteg specifikáció az elektromos és mechanikus elôírásokat, a MAC specifikáció a fizikai közegen átvitt adatkeretek formátumát és a közegelérés szabályait, az LLC specifikáció pedig az adatkapcsolati adatelemeket, címzést és eljárásokat határozza meg. A GOSIP 4 beszerzési ajánlásokban háromféle lokális hálózat van: 1

CSMA/CD

1

Token gyûrû

1

FDDI

A CSMA/CD elérési módot használják a leggyakrabban, a különbözô változatait legegyszerûbben az átviteli közeg szerint osztályozhatjuk. A GOSIP a következôket támogatja: 1

10 Mb/s alapsávú koaxiális kábelen,

1

10 Mb/s alapsávú vékony koaxiális kábelen,

1

10 Mb/s alapsávú árnyékolatlan csavart érpáron,

1

10 Mb/s alapsávú valamilyen szélessávú átviteli közegen.

A token gyûrût IBM-kompatibilis PC-kre fejlesztették ki, irodai környezetben való alkalmazás céljára. A GOSIP jelenleg 4 Mb/s alapsávú megvalósításokat tekint szabványosnak. Az FDDI (Fibre Distributed Data Interface) specifikáció lesz valószínûleg a legelterjedtebb a következô években. Az FDDI 100 Mb/s-os száloptikai hálózatot definiál gyûrû topológiával és token továbbító módszerrel. A GOSIP LAN elôírások nem foglalkoznak a kábelezési infrastruktúrával, ezek külön CCTA publikációkban találhatók. A GOSIP LAN beszerzések elôtt dönteni kell a következô kérdésekben: 1

az üzemmód összeköttetés-orientált vagy összeköttetésmentes,

1

melyik LAN a három felsorolt közül; ha CSMA/CD, akkor melyik a 4 alcsoport közül,

1

az LLC réteg összeköttetés-orientált vagy összeköttetés-mentes,

1

milyenek a hálózati szolgáltatások (CONS vagy CLNS),

1

milyen a szállítási réteg a rendszerben, mely osztály, hány byte a transzport protokoll adatelem, mûködhet-e az implementáció kezdeményezôként illetve válaszolóként.

A LAN beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 2. kötet 3A-1-tôl 3A-6 oldal).

81

62

Nagykiterjedésû hálózatok

A nagykiterjedésû hálózatok (Wide Area Network, WAN) távolabbi helyeken lévô végberendezéseket kötnek össze, amelyek közti távolság meghaladja a LAN-okkal áthidalható 1-2 km-t. A nagykiterjedésû hálózatok a csomagkapcsolás (packet-switching) elvén mûködnek. Az átvivendô adatok kisebb egységekre, csomagokra (packets) bomlanak, amelyek a csomag fôbb paramétereit (pl. cím) is tartalmazzák. A csomagok több úton haladhatnak a célállomás felé, tipikusan 64 kB/sec sebességgel. A GOSIP WAN elôírások az X.25 csomagkapcsolt hálózati szabványnak megfelelô termékek beszerzését javasolják. A fizikai interfészt az X.21 és a V-sorozat definiálja. A 2. szint az adatkapcsolati réteg, amely a HDLC családba tartozó LAPB szabályai szerint mûködik. A GOSIP WAN az ISO 7776 szerinti LAPB specifikációt írja elô. A harmadik réteg a csomagszint (ISO 8878 és ISO 8208), amely összeköttetés-orientált szolgáltatást nyújt a szállítási rétegnek. A GOSIP WAN profil a szállítási réteg elôírásait is tartalmazza. A GOSIP WAN vagy két OSI végberendezést köt össze vagy egy együttmûködô egységen (Interworking Unit, IWU) keresztül egy másik WAN-nal vagy egy LAN-nal kommunikál. A GOSIP WAN beszerzések elôtt dönteni kell a következô kérdésekben: 1

a fizikai interfész adatátviteli sebessége (2400, 4800, 9600, 19200, 48000 vagy 64000 b/s),

1

a fizikai interfész elektromos jellemzôi X.21 vagy X.21 bis szerintiek,

1

az adatkapcsolati réteg LAPB protokolljában az információs keretek sorszámozása modulo 8 vagy modulo 128,

1

mennyi a nyugtázatlan keretek száma, 7 vagy 127,

1

mennyi az információs keret mérete (256, 512 vagy 1024 oktett),

1

hányszor kell ismételten küldeni egy keretet, az ismétlések max. száma kisebb vagy nagyobb 10-nél,

1

a hálózati réteg interfész DTE-DCE vagy DTE-DTE kapcsolatot jelent,

1

a virtuális áramkör kapcsolt vagy permanens,

1

az adatcsomagok sorszámozása modulo 8 vagy modulo 128,

1

mekkora az információs csomag mérete (128, 256, 512, 1024, 2048 vagy 4096 byte)

1

milyen a szállítási réteg a rendszerben, mely osztályú és hány oktettbôl áll a transzport protokoll adatelem, mûködhet-e az implementáció kezdeményezôként illetve válaszolóként.

A WAN beszerzése elôtt több döntést kell hozni, a döntésekhez tartozó kérdéseket és lehetséges válaszokat a PICS konformancia záradék tartalmazza (lásd "Beszerzési kézikönyv" 2. kötet 2A-1-tôl 2A-8 oldal).

82

63

Transzport protokollok

Az ISO OSI a transzport protokollok (ISO 8073) 5 osztályát specifikálja, 0tól a 4-es osztályig. A GOSIP-T csak a 0-s, 2-es és 4-es osztályt fogadja el. Ha a WAN-on keresztül üzenetkezelô rendszer (Message Handling System, MHS) valamely egyszerû típusa érhetô el, akkor a GOSIP-T a 0-s transzport protokollt ajánlja. Ha a végberendezés közvetlenül WAN-ra kapcsolódik, akkor a 2-es osztályú transzport protokoll használata javasolt. Ha pedig LANhoz van kötve, akkor 4-es osztályú transzport protokoll használata javasolt. 64

FORMÁTUM PROFIL

A formátum profil (F-profil) a GOSIP dokumentumok és adatok formátumát és karakterkészletét definiálja. A dokumentumok A4-es lapokból álló szöveges és grafikus információk, amelyek cseréjét az üzleti dokumentum csere (Office Document Architecture, ODA) szabványok határozzák meg. E dokumentumok formátuma a felhasználó ember számára érthetô és jól áttekinthetô. Az adatok számítógépek között továbbított információk, hierarchikusan strukturált elektronikus adatok. Az elektronikus adatcsere (Electronic Data Interchange, EDI) szabványai adminisztratív, kereskedelmi és szállítási okiratok formátumát (EDIFACT) szabványosítják. Karakter készlet ODA

EDIFACT

A formátum profil Az ODA dokumentumok formátuma szövegszerkesztôvel készített jól olvasható írásos anyagok formátumához hasonló, az EDI dokumentumok hierarchikus struktúrája a gépi megértést könnyíti meg. Mindkét okirat alapeleme a karakter. A GOSIP karakter készlet szabványok az európai és Észak-Amerikai nyelvek karaktereit szabványosítják. 65

Dokumentum csere (ODA)

A GOSIP dokumentum csere alapszabványa az ISO ODA és ODIF szabványa. A GOSIP ODA specifikálja a kormányzati dokumentum alkalmazói profilt (Government Document Application Profile, GDAP). A GDAP-nak két szintje van: GDAP1 és GDAP2. A GDAP1 szöveges, a GDAP2 szöveges és grafikus információt tartalmazó dokumentumok formátumát szabványosítja. A GOSIP dokumentumok OSI környezete a GOSIP MHS és a GOSIP FTAM. A GDAP1 és a GDAP2 teljesen megfelel az ODA DAP-nak, amelyet az ISO 8613 elsô 8 része és a CCITT T.410-es ajánlása szabványosít. A szabványok még nem véglegesek. Beszerzési állapotuk meg nem erôsített. A jelenlegi GOSIP ODA specifikáció a vásárlóknak irányelveket és nem végleges, részletes elôírásokat jelent. A dokumentumokat a küldô (originator) és a fogadó (receiver) szerkesztheti. Ha a fogadó fél szerkesztheti, akkor a dokumentum feldolgozható (processable). Ha csak a küldô szerkesztheti, akkor a dokumentum formattált

83

(formatted). Ha mindkét fél átalakíthatja, akkor formattált feldolgozható (formatted processable). A GDAP1 a szöveges dokumentumok struktúrájáról és elrendezésérôl rendelkezik. Az elrendezés jellemzôi a következôk: 1

A4-es oldalméret,

1

margók,

1

paragrafusok,

1

oldalak tördelése,

1

oldalak számozása,

1

karakter készlet (lásd 67)

1

sortávolság,

1

tabulálás stb.

A GDAP2 tartalmazza a GDAP1-et és a grafikus megjelenítés szabályait raszter és geometriai ábrázolás esetén. Lehetôvé teszi a több oszlopos tördelést és az oldalaknak jól körülhatárolt részekre bontását. A részekbe ábrák is behelyezhetôk. A GDAP1 és GDAP2 OSI környezete az MHS és az FTAM. A GDAP dokumentum az X.400 IPM részének tekinthetô, az FTAM-ban pedig egy teljes strukturálatlan bináris vagy szöveg file-nak. 66

Elektronikus adatcsere (EDI)

Az elektronikus adatcsere (Electronic Data Interchange, EDI) üzenetszabványokban rögzített, strukturált adatok cseréje számítógépes alkalmazások között. A GOSIP EDI két részbôl áll: 1

EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) szabványos transzfer szintaxisa

1

a jelenlegi GOSIP-A alkalmazói szolgálatok használata

Az EDIFACT-ot az ISO 9735 szabványosítja, amelyet az ISO 7372 (United Nations Trade Data Element Dictionary) egészít ki. Mindkét szabvány mûszakilag stabil és beszerzési állapotuk megerôsített. Az EDI üzenetek szegmensekbôl állnak. A szegmensek szabványos, adatcserére alkalmas elemek, amelyek az üzenet valamely specifikus részéhez vannak rendelve. Egy szegmens általában a dokumentum egy sorának felel meg az elektronikus adatcsere során. A szegmens adatelemek füzérébôl áll. Az adatelemek típusát a szegmensben meg kell adni (pl. numerikus). Az adatok strukturálását az EDI szabvány szintaxisa rögzíti. A szintaxis határozza meg a karaktereket és a kódokat, amelyek elôírják, hogyan kell egy üzenetben az adatelemeket és a szegmenseket kombinálni. Tehát a papír dokumentumból adatelemek füzérét állítjuk elô, amelyet a forrásállomás továbbít a célállomásnak. Ha két állomás az adatelemek szempontjából heterogén, akkor olyan transzfer szintaxisra van szükség, amely egy közbülsô kódra alakít át. A szegmens kulcs az EDI szerves része, ezért nem kell a borítékkal együtt küldeni, hanem ez már az elôzetes tárgyalások során kicserélésre kerül. A szegmenskulcs tartalmazza az adatszegmens azonosítót, 84

az adatelem nevét, referencia számát, az adatelem típusát, hosszát és más lényeges jellemzôjét. Az EDIFACT használatára MHS vagy FTAM környezetben kerülhet sor, lényegében az ODA-hoz hasonló módon. AZ EDI egyik legfontosabb célja a szabványos üzenetek használata. Jelenleg az UK GOSIP EDI kereskedelmi üzenetei kidolgozás alatt állnak és lehetôség van felhasználók által definiált üzenetek használatára is. Az EDI biztonsági és jogi szempontjai külön megfontolást igényelnek. 67

Karakter készletek

A karakter készletek elemei szöveges és vezérlô karakterek, alapjuk az ASCII 8-bites karakter készlete. A GOSIP karakterkészletnek 5 változata van, 0-tól a 4-es verzióig. A 0-s készlet azonos az ASCII vagy IA5-ös karakterkészlettel. Az 1-es és 2-es készlet a nyugat-európai nyelvek karaktereit tartalmazza két különbözô kódolási eljárással (1-es opció: ISO 8859 szabvány, 2-es opció: ISO 6937 szabvány). A 3-as opció a görög betûket is tartalmazza. A 4-es opcióban vannak a keleteurópai nyelvek, így a magyar is. 68

SUPPORT PROFIL

69

Elnevezés és címzés

A rendszereknek gyakran különbözô, összekapcsolt LAN-okon és WANokon keresztül kell együttmûködniük. Ezért fontos, hogy a teljes hálózatnak egységes címzési rendszere legyen, amely alkalmas arra, hogy az egyes rendszerek és alkalmazói szolgálatok egyértelmûen definiálhatók legyenek és a hozzájuk vezetô út is meghatározható legyen. A GOSIP segít abban, hogy a hálózati címek egyediek legyenek és hogy bármely végberendezés bármely más végberendezéssel tudjon együttmûködni. Elnevezés és címzés Biztonsági szolgálatok

Menedzselés

A support profil A név az objektumot (pl. a számítógépet vagy a felhasználót) azonosítja, a cím az objektum helyét. A névnek rövidnek és logikusnak kell lennie. A rövidebb cím esetén a tévesztés valószínûsége kisebb, a logikus cím a felhasználó munkáját könnyíti meg. Fontos az is, hogy a név stabil legyen (pl. ne függjön kisebb átkonfigurálásoktól). Az OSI réteghatáronként szolgálatelérési pontokat (Service Access Point, SAP) definiál és ezekhez címeket rendel, a rétegeken belül pedig entitásokat (logikai funkciókat) határoz meg és ezekhez neveket rendel. A GOSIP a hálózati réteg szolgálatelérési pontjainak címét az ISO 8348 2. kiegészítésében, az UK GOSIP a British Standard 7306 számú szabványában rögzíti. Emlékeztetünk arra, hogy a LAN és WAN rendszerekben ezekhez a hálózati

85

szolgálatelérési pontokhoz (NSAP) csatlakozik a transzport réteg. Az ábrán látható egy példa az UK GOSIP NSAP-jának bit-képére. IS O

U K R e g is z trá c ió sC C T A

K o rm á n y z a ti ré s z le g e k

H a tó s á g (B S I) 38

826

1

104

029

12345 123456789 123

ré s z le g a lh á ló z a t a z o n o s ító c ím a lh á ló z a t a z o n o s ító

fag / s z e k to r

Példa az NSAP címzési formátumára A felsô rétegek címzésével a GOSIP-A profil foglalkozik. Az alkalmazói processzhez két külön szintaxis tartozik: 1

a katalógus (directory) név szintaxisa,

1

az objektumazonosító szintaxisa.

A Katalógus név ember számára is könnyen érthetô, hierarchikus felépítésû: 1

ország,

1

szervezet,

1

szervezeti egység,

1

processz azonosító.

Az objektumazonosító számok sorozatából áll. Pl.: { 1 2 826 25 56 10} Megemlítjük, hogy Angliában kidolgozás alatt áll az országos címjegyzék, amelyben a jelenlegi és a jövôben várható rendszerek címeit kívánják összegyûjteni. 70

Menedzsment

A GOSIP több profilra (modulra) oszlik, amelyeket mint építôelemeket lehet az adott rendszerbe beépíteni a kívánt felhasználói specifikációnak megfelelôen. Az egyik ilyen a menedzselési modul (GOSIP MGT), amely a rendszer erôforrásait ellenôrzi illetve irányítja. Feladata igen bonyolult, s jelenleg kialakulóban van. Fôbb funkciói: 1

hiba menedzselés

1

számlázás-nyilvántartás (accounting management)

1

konfiguráció menedzselése

1

biztonság védelem menedzselése

1

teljesítmény menedzselése.

További funkciók specifikálása történt meg az ISO/IEC 10164-n (Systems Management) szabványokban: 1

objektum menedzselés

1

állapot menedzselés (állapot attribútumok: objektum foglaltság, objektum használható, vagy kikapcsolás alatt stb)

86

1

objektum és attribútum, s ezek kapcsolata

1

riasztás riport (paraméter kezelés)

1

esemény riport menedzselés

1

belépés vezérlés

1

biztonság riasztás riport.

További részek kidolgozás (szabványosítás) alatt vannak. Egy olyan szakterület ez, ahol a szabványok száma a jövôben még nôni fog. Ez gondos elemzést igényel a beszerzéskor. Lehetséges olyan választás, hogy a rendszer alap menedzsment tevékenysége a meglévô OSI szabványok szerinti, míg az ezen kívül mutató tevékenységek nem OSI szabvány szerintiek. (A fentiek miatt ajánlatos beszerzéskor a már meglévô szabványokhoz igazítani a felhasználó igényeit figyelembe véve a szabványosítás alatt lévô lehetôségeket is. Szükséges a megfelelô publikációk áttanulmányozása. Az eligazodást segíti az alábbi tanulmányok figyelembe vétele: IT Infrastructure Library és Information Systems Guides — CCTA — kiadványok.) Az elsô szabványok között dolgozták ki az OSI menedzsmentre (Management Framework, OSI Basic Reference Model: ISO/IEC 7498-4) vonatkozó elôírást, amely az általános felépítésre vonatkozik, ezek a következôk: 1

Réteg mûködés (Layer Operation): egy adott protokollal (pl. X25.) kapcsolatos szolgáltatásokat vezérli.

1

Réteg menedzselés (Layer Management) egy rétegre vonatkozó specifikus információ irányítása (pl. hálózati rétegben a "routing" protokoll esetén).

1

Rendszer menedzselés (Systems Management) a rendszerben lévô eszközök közti információ csere irányítása, a kommunikáló erôforrások irányítása, vezérlése és koordinálása.

Néhány fogalom: 1

Managing system (menedzselô rendszer) ez lényegében egy menedzser funkciót ellátó rendszer.

1

Managed system (menedzselt rendszer), az irányítás alatt lévô objektumokat tartalmazza. (A menedzselt rendszer természetesen elláthat menedzser funkciót, felügyelhet más rendszerekre is.)

1

Managed objects (menedzselt objektumok) a rendszer erôforrások (diszk, nyomtató stb..) absztrakt megfogalmazása: azok az objektumok, amelyeken az operációk végrehajtódnak (természetesen objektumok lehetnek egy menedzselt rendszer irányítható funkciói is).

1

Notification: az az információ, amit az objektum kibocsát.

A rendszer menedzselés modelljének alapkoncepciója az ISO/IEC 10165-1 (Management Information Model) szabványban van rögzítve. A modell az objektum-orientált koncepcióra épül, s használja az öröklôdés, tulajdonság fogalmát az objektum leírására.

87

Az ISO/IEC 10165-4 (Guidelines for the Definition of Managed Object) szabvány megad egy sablont, hogy hogyan kell egységes módon definiálni az objektumokat. Ez a definíció vonatkozik az objektumra vonatkozó mûvelet, az objektum által kibocsátott információ és az objektum viselkedésének a leírására. Az objektum öröklôdésére vonatkozó eszközök illetve szabályok lehetôvé teszik az objektum általánosabb definícióját, ami az objektum újra felhasználását elôsegíti. Az ISO/IEC 10165-2 (Definition of Management Information) szabvány egy gyûjteményben foglalja össze az objektumok definícióját további felhasználás céljából. A rendszer menedzselés számára kidolgozták a következô két szabványt (további szabványok vannak kidolgozás alatt): 1

Common Management Information Protocol (CMIP): OSI alkalmazói réteg protokoll specifikáció, amely a menedzseléshez szükséges információkat közvetíti.

1

Common Management Information Service (CMIS): egy szolgálat definiálására alkalmazható. Parancsai: objektum attribútumának beállítása (set), objektum attribútumának lehívása (get), egy összetett szolgáltatás elindítása (action).

Amint elôzôleg említettük sok szabvány fejlesztés alatt van. Szükséges lehet (a felhasználó igényének kielégítésére) olyan opciók beépítése, ami szabványon kívül esik. Ebben az esetben a felhasználó és a szolgáltató egyezsége alapján lehet dönteni, hogy az erre vonatkozó szabvány megjelenése után az adott funkció hogyan lesz szabványosítva. A fentiek miatt a konformancia vizsgálatok jogossága bizonyos funkciókra kérdéses. A már meglévô szabványokhoz viszont szükséges ragaszkodni. 71

Biztonság

A GOSIP a rendszerek közti útvonalak biztonságával foglalkozik, például azzal, hogy a feladott üzenet ne változzon meg átvitel közben. A végrendszerek biztonságával a GOSIP nem foglalkozik. Az OSI külön biztonsági architektúrát is kidolgozott, a GOSIP is ezt követi. A GOSIP biztonsági architektúra jelenlegi kidolgozottságában inkább a vásárló és a szállító közötti megállapodások alapja és nem beszerzési opciók gyûjteménye. A GOSIP biztonsági architektúra az OSI biztonsági architektúra részhalmaza, jelenleg még kidolgozás alatt áll, mivel az OSI biztonsági architektúra még csak az utóbbi idôben lett stabil. A CCTA a kockázat analízisre és menedzselésre egy módszertant dolgozott ki (CCTA Risk Analysis and Management Methodology CRAMM), amely információs rendszerek érzékeny adatai számára hiteles védelem. Az ITB következô, 8. számú ajánlása foglalkozik a biztonságtechnika teljes kérdéskörével. A GOSIP jelenleg csak a biztonsági architektúrát definiálja, amely csak korlátozott mértékben segít a biztonsági szolgálatok kiválasztásában és a GOSIP környezetben való elhelyezésében. Még további munkára van szükség az egyes protokollok és más mechanizmusok használatának

88

specifikálására, amelyek a GOSIP biztonsági architektúrába beilleszthetôk. A biztonsági termékek még nem érhetôk el általánosan a piacon. 72

TESZTELÉS (VIZSGÁLAT) ÉS HITELESÍTÉS

A következôkben protokollok és végberendezések alkalmasság vizsgálatával foglalkozunk. Erre az eljárásra szokás alkalmazni a konformancia tesztelés megjelölést is. 73

Konformancia tesztelés (vizsgálat)

A nyílt rendszerek sok egymással kommunikáló rendszerbôl, vagy részegységek együttesébôl állnak. A jó mûködés feltétele, hogy az egyes egységek közti kommunikáció hibátlan legyen, az egyes egységek közti kommunikációs szabályok — protokollok — azonosak legyenek bárhol is készültek ezek az egységek. Ezeket a szabályokat nemzetközi szabványokban rögzítették, s az OSI rendszerbe illô berendezéseknek, illetve programoknak ezen szabványoknak kell eleget tenni. Itt két probléma vetôdik fel: 1

Hogyan lehet a protokollokat mindenki számára félreérthetetlen formában megfogalmazni?

1

Hogyan lehet bebizonyítani, hogy a megvalósított protokoll egyértelmûen megfelel (konform) a szabványban rögzített leírásnak?

Jelenleg a protokollokat a nemzetközi szabványok természetes nyelveken írják le. Ez sok esetben félreértésekre vezethet. Egyes szabványokban állapot táblát (ahol a protokollok állapotai, s ezen állapotokhoz tartozó ki/bemenô jelek vannak feltüntetve) is használnak a protokollok leírására. Más szabványokban egyes protokoll részeket formális leíró nyelveken (SDL, LOTOS, Estelle) is definiálják. Sok esetben ezek csupán a szabvány megértését segítik, de nem tekinthetôk a szabvány definíciójának (mivel csupán egyes részekre vonatkoznak). Az implementálás fázisai: 1

szöveges szabvány leírása formális nyelven

1

a formális leírás ellenôrzése

1

az implementálásra vonatkozó dokumentumok (PICS, PIXIT) elôállítása

1

a berendezés elôállítása

1

konformancia vizsgálat.

A PICS és PIXIT dokumentumok elengedhetetlenek a megvalósítás azonosításához, valamint elengedhetetlen a protokoll konformancia vizsgálatához. A PICS (Protokoll Implementation Conformance Statement) dokumentum ("ISO/IEC 9646-5 (Information technology — Open Systems Interconnection — Conformance testing methodology and framework.) Part 5. "Requirements on test laboratories and clients for the assessment process." Reference number: ISO/IEC 9646-5: 1992(E)) pontosan feltünteti a protokoll azonosítóját és a protokoll elôállítójának pontos adatait, valamint egy mellékletben a protokoll megvalósítására vonatkozó pontos információt. Ez valójában a nemzetközi protokoll szervezetek által elfogadott szabványos 89

kérdôív, amelyet országközösségek (pl. európai országok) némileg módosíthatnak. A PICS dokumentumban a megvalósítónak arra kell válaszolnia, hogy a szabványban leírtakat hogyan valósította meg a valóságban (hogyan implementálta a szabványban leírtakat). A GOSIP PICS forma további finomításokat ad az általános szabványhoz viszonyítva. A protokoll szabványban vannak kötelezô elôírások, és vannak feltételes, valamint opcionális elôírások (a PICS dokumentumban ezeket m, c, o betûkkel jelölik, rendre az angol mandatory, conditional, options szavak kezdôbetûi után). A feltételes és az opcionális elôírásokat az implementáló nem köteles megvalósítani: ezek közül "szabadon" választhat, bár helytelen választás esetén elôfordulhat, hogy terméke korlátozottan lesz alkalmazható. A PICS dokumentum egy nagyon pontosan megfogalmazott dokumentum: minden egyes kitöltendô kérdés mellett (amely kérdésekre általában "igen" vagy "nem" választ kell adni) fel van tüntetve a protokoll szabvány fejezetszáma, ami pontosan felsorolja a kérdésre adható válaszokat, s ezt mérlegelheti az implementáló. Ennek a dokumentumnak rendkívüli fontossága van a protokoll konformancia tesztelésnél, de még fontosabb a rendszerbe állításkor, amikor több protokoll együttmûködését kell vizsgálni, vagy a mûködés közben felmerült hiba okát kell meghatározni. A PIXIT (Protocol Implementation eXtra Information for Testing) leírása az "ISO/IEC 9646-5 (Information technology — Open Systems Interconnection — Conformance testing methodology and framework.) Part 5. "Requirements on test laboratories and clients for the assessment process." Reference number: ISO/IEC 9646-5: 1992(E) dokumentumban található. Ez pontosan feltünteti a protokoll azonosítóját és a protokoll elôállítójának pontos adatait, valamint egy a protokoll beállítására vonatkozó kérdôívet, ami szintén az implementációkor kerül kitöltésre. A dokumentum szabványos (a nemzetközi szabványosító hivatal által kibocsátott) vizsgálókészlet része, szerkezete hasonló a PICS dokumentumhoz. Kitöltésekor a megvalósítónak pontosan meg kell adnia a protokoll implementációjakor beállított idôzítôk, számlálók és egyéb változók értékeit. Nélküle a protokoll vizsgálata nem kezdhetô meg. A protokoll fejlesztés utolsó fázisa a protokoll konformancia vizsgálata, majd megfelelô dokumentumok (SCTR: System Conformance Test Report, PCTR: Protocol Conformance Test Report) kiállítása. Ezek leírása szintén az "ISO/IEC 9646-5 (Information technology — Open Systems Interconnection — Conformance testing methodology and framework.) Part 5. "Requirements on test laboratories and clients for the assessment process." Reference number: ISO/IEC 9646-5: 1992(E) dokumentumban található. A dokumentumok formája, és hogy mire kell válaszolni a vizsgálat befejezésével szabványban van rögzítve. Természetesen az egyes laboratóriumok a szabványügyi hivatallal egyetértésben ettôl valamennyire eltérhetnek. Az alkalmazható konformancia vizsgálati elrendezéseket az "ISO/IEC 9646-1 (Information technology — Open Systems Interconnection — Conformance testing methodology and framework.) Part 1. "General concept." Reference number: ISO/IEC 9646-1: 1992(E) szabvány határozza meg. A vizsgálandó egyed lehet egy protokoll megvalósítás (IUT: Implementation Under Test), vagy egy több protokollt tartalmazó berendezés (SUT: System Under Test). A vizsgálat során a szabványban rögzített vizsgáló sorozatokra adott válaszok

90

alapján lehet megállapítani, hogy a vizsgált berendezés (IUT/SUT) megfelele a szabványban elôírtaknak, vagyis konform-e a szabvánnyal. A konformancia vizsgálatot végezheti a rendszer elôállítója, vagy egy független jogi személy (egy független laboratórium, a laboratóriumoknak nagyon fontos szerepük van). A vizsgálat két nagy fázisra bontható: a vizsgálat elôkészítésére illetve a tényleges vizsgálat végrehajtására. A konformancia vizsgálat elôkészítése a kliens (ami jelen esetben lehet a gyártó, de lehet egy vásárló is) és a vizsgáló laboratórium között történik, ami magában foglalja a: 1

Protokollra vagy protokollokra (ha rendszer vizsgálatról van szó) vonatkozó dokumentumok (PICS, PIXIT) áttekintését: annak megvizsgálását, hogy a kitöltött dokumentumok megfelelnek-e a rájuk vonatkozó szabványoknak, illetve azok hiánytalanul vannake kitöltve.

1

Megállapodás történik a szabványos vizsgálati módszer kiválasztására, vizsgálati készlet megnevezésére. Rendszer vizsgálata esetén a PIXIT dokumentumban meg kell adni a kapcsolódó protokollok pontos megnevezését, illetve az azokhoz tartozó dokumentumokat.

A vizsgáló laboratórium ezek után rátér a tényleges konformancia vizsgálatra, amely a következô fázisokból áll: 1. Statikus konformancia vizsgálat. A PICS dokumentum összevetése a protokollra vonatkozó szabvánnyal: hibás a kötelezô érvényû szabványelôírások elhagyása, vagy helytelen megvalósítása, illetve az opcionális, vagy feltételes elôírások ellentmondásos összeválogatása. 2. Vizsgálati sorozat kiválasztása. Az egyes protokollok a szabványos un. absztrakt vizsgáló készlettel (ATS: Abstract Test Suite) rendelkeznek. Ezek közvetlenül nem végrehajtható vizsgáló sorozatok, s a teljes megvalósított szabvány vizsgálatára készültek. Ha a vizsgálandó protokoll a PICS alapján a szabvány teljes megvalósítása, akkor használható a teljes vizsgáló készlet. Ha a vizsgálandó protokoll nem teljes megvalósítás, akkor PICS dokumentum alapján ki kell választani azokat a vizsgáló sorozatokat, amelyek a vizsgálandó protokollon lefuttathatók. 3. Vizsgálati készlet parametrizálása. Az ATS vizsgálati készlet futtathatóvá tétele azt jelenti, hogy a vizsgáló készlet változóinak (idôzítôk, számlálók stb) értéke a megvalósítás PIXIT dokumentuma alapján fel lesz töltve. Ezzel válik a vizsgáló készlet alkalmassá a konkrét megvalósítás (protokoll) vizsgálatára. 4. Vizsgálati ciklus. A futtatható vizsgáló készlet sorozatonkénti lefuttatása. Az egyes vizsgáló lépések kiküldése a vizsgált rendszernek, majd a kapott válasz értékelése. 5. Vizsgálat eredménye: PCTR, SCTR dokumentumok kiállítása. A protokoll alkalmasság vizsgálati riport (PCTR) a konformancia vizsgálat eredményét adja, feltüntetve a protokoll és a hozzátartozó 91

dokumentumok (PICS, PIXIT) pontos megnevezését, valamint a vizsgálati módszert a vizsgálati sorozat megnevezésével. A riport tartalmazza a statikus (PICS és a szabvány összevetésébôl) és a dinamikus (a vizsgálati sorozatok lefuttatásából származó) eredmények összefoglalását. A rendszer alkalmassági riport (SCTR) egy több protokollból álló rendszer vizsgálati eredményét foglalja össze. A vizsgálat kiterjed a teljes rendszerre, de vonatkozhat egy vagy több, a rendszer elemeként szereplô protokoll részletes vizsgálatára. Az utóbbi esetben a protokoll(ok)ra vonatkozó vizsgálati eredményt is szerepeltetni kell a dokumentumban. Mint elôzôleg láttuk a konformancia vizsgálat egy igen bonyolult és hosszadalmas eljárás, oka: 1

A sok dokumentum (PICS, PIXIT, PCTR, SCTR) elkészítésének a szükségessége, ami egy nagyon egyszerû protokoll esetén is kb. 50 oldal, míg egy közepes, vagy bonyolult protokoll esetén a száz oldalt is meghaladja.

1

A dokumentumok átvizsgálása (PICS, PIXIT) — statikus konformancia vizsgálat — szintén hosszú idôt vesz igénybe és nagy szakértelmet igényel.

1

A dinamikus konformancia vizsgálat is egy hosszú folyamat, mivel a vizsgáló készlet egy egyszerû protokoll esetén 200-300 oldal, egy közepes bonyolultság esetén pedig 800-1000 oldal körüli (a számítógépeknél megismert módszertôl eltérô módon — TTCN nyelven — írt) "programcsomag" (pl. az FTAM protokoll esetén 4000 vizsgálati lépés). A vizsgálat során ezen sorozatokat kell átvizsgálni (értékelni, hogy az adott megvalósításra lefuttatható-e, vagy nem), valamint a lefuttatott sorozatok eredményét kell értékelni.

1

A konformancia eljárás végén el kell készíteni a minôsítô dokumentumokat (SCTR, PCTR), ami szintén nagy körültekintést és szakértelmet igényel.

A konformancia eljárás eredménye: 1

gondosan elvégzett konformancia vizsgálat után ki lehet jelenteni, hogy a vizsgált protokoll (vagy rendszer) — a vizsgálat gondosságától függôen — nagy valószínûséggel jól, a szabványban elôírt módon fog mûködni,

1

ugyancsak nagy valószínûséggel (de nem garantálhatóan) jól fog mûködni olyan rendszerben, ahol más módon (más gyártó által) implementált protokollal (rendszerrel) kell együttmûködni,

1

hibás együttmûködés esetén a gyártó által gondosan kitöltött (PICS, PIXIT), valamint a pontos vizsgálati eredmények (SCTR, PCTR dokumentumok) segítenek a hiba kiderítésénél.

74 Az együttmûködési képesség tesztelése (együttmûködtetés vizsgálat) Az együttmûködési képesség (interoperability) vizsgálata azt kívánja eldönteni, hogy két különbözô implementálás képes-e egy rendszerben hibát92

lanul együttmûködni. Jelen esetben azt sem lehet megfogalmazni (egyelôre nincs nemzetközi szabvány), hogy mit kell ahhoz megvizsgálni, hogy biztosan ki lehessen jelenteni, hogy két protokoll (rendszer) hibátlanul fog együttmûködni. Elvégezhetetlen az a feladat, hogy minden létezô berendezést minden lehetséges kombinációban kipróbáljunk és levizsgáljunk. Az együttmûködtetés vizsgálat egy sokkal átfogóbb vizsgálat mint a konformancia vizsgálat: 1

a vizsgálatnál törekedni kell a pontos, mindenre kiterjedô vizsgálatra, amely bizonyítja, hogy az implementálás a szabvány szerint történt,

1

a vizsgálatnak ki kell terjednie arra, hogy a vizsgált implementáció hogyan viselkedik a hibás és nem várt üzenetekre (ez lényegesen megnövelheti a vizsgálat idejét, aminek természetesen gazdasági következményei is vannak),

1

be kell mutatni, hogy a berendezések olyan körülmények között tudnak mûködni, mint a valóságban, vagyis, mint a felhasználónál,

1

a rendszer hibakezelésére is ki kell terjednie a vizsgálatnak (valós rendszerben ez igen sok probléma forrása lehet),

1

lehet az együttmûködô berendezések üzeneteit mûködés közben "monitorozni" (protokoll analizátor segítségével), vagy konformancia vizsgáló sorozatokat lefuttatni, s közben "monitorozni",

1

szükséges lehet egy "referencia" protokoll, vagy rendszer kifejlesztése, ami a szabvány összes elôírásának eleget tesz, s ezzel összekapcsolva (esetleg monitorozás igénybe vételével) lehetséges lesz a kérdéses rendszer bemérése.

Az elôzôekbôl világos, hogy az együttmûködtetés vizsgálata igen nagy szakértelmet igényel, és egy igen költséges folyamat. Vannak szervezetek, amelyekkel megállapodást lehet kötni egy-egy kritikus vizsgálat elvégzésére. A konformancia vizsgálatokra a szabványokban egy igen jó eljárás van definiálva. Az együttmûködtetési vizsgálatokra egyes szervezetek (EurOSInet) készítenek elô eljárásokat (amik természetesen finomításra szorulnak), de jó alapot jelentenek a további fejlesztések számára. Az EurOSInet és a SPAG együttmûködése révén egy szabvány van kialakulóban egy közös konformancia és együttmûködtetési vizsgálati módszertan kidolgozására. A munkába az amerikai OSINET szervezet is bekapcsolódott. A SPAG 1991-ben jelentett be egy PSI (Process to Support Interoperability) projektet, ami az MHS(84) és FTAM egységes vizsgálatára vonatkozik, s nagy valószínûséggel biztosítja, hogy az ilyen vizsgálatok után ezek a termékek együtt fognak tudni mûködni. Javasolják, hogy a sikeres vizsgálat esetén ezeket a termékeket lássák el különleges márkajelzéssel. Közbensô megoldásként egyes cégek olyan tulajdonságokkal látják el a berendezéseiket, amelyek elôsegítik a monitorozást és a protokoll analizálást.

93

75

Harmonizálás

Szükséges, hogy a különbözô helyen készült eszközök egységes (konformancia vizsgálati) eljárás szerint legyenek bevizsgálva. Ezeket az eljárásokat nemzeti és nemzetközi szervezetek hangolják össze, de szükséges, hogy a vizsgálatokat végzô szervek kölcsönös elismertséget élvezzenek. Az egységes vizsgálati készleteket, vizsgálati eljárásokat szabványként a GOSIP definiálja (beleértve a WAN, LAN, MHS és FTAM-ra vonatkozókat is). A munka összehangolását a CTS (European Conformance Testing Services) szervezet végzi, és koordinálja a vizsgáló laboratóriumokat és a gyártókat. Angliában az NCC (BT, IBM, ICL és Digital gyártókkal közösen) végez hasonló munkát, míg Amerikában a Corporation for Open System (COS) szervezet. A harmonizációs szervezetek hangolják össze a konformancia vizsgálatokkal kapcsolatos munkákat. Nagyon fontos szerepe van az ECITC (European Committee for IT Testing & Certification) szervezetnek, amelyik az európai és az EFTA országokban hangolja össze a konformancia szabványosítási törekvéseket. Az ECITC két szervezetet felügyel: 1

Az OSTC-t (Open System Testing Consortium), amelyet a CTSWAN konzorcium hozott létre, azért hogy a vizsgálatokat összehangolja (jelenleg tíz ilyen laboratórium mûködik hat országban, beleértve a NCC-t és a BT-t Angliában). Feladata az MHS, FTAM, Transport, Session és Network rétegek vizsgálatanak összehangolása.

1

Az ETCOM (European Testing and Certification for Office and Manufacturing) hasonló feladatot lát el mint az elôzô szervezet: feladata a CTS-LAN, és MAP/TOP-pal kapcsolatos munkák összehangolása.

A COS és a SPAG (Standard Promotion and Application Group) közti megegyezés hasonló harmonizációs szerepet tölt be mint az elôzô szervezetek. Kialakulóban van a TLFF (Technical Level Feeders Forum), amelyik világviszonylatban kívánja betölteni a harmonizációs szerepet. A szabványosítás következô felügyelôi szervei a nemzeti koordinációs és akkreditáló szervezetek (pl. a NAMAS: National Measurement Accreditation Scheme szervezet Angliában), amelyek az egyes országokban mûködô vizsgáló laboratóriumok egységes rend szerinti mûködését és a minôségi (vagy egyes berendezésekre a használhatósági) bizonyítvány kiállításának feltételeit szabják meg. Ezek közvetve a vásárlói érdekek védelmét biztosítják azzal, hogy olyan egységes vizsgálati módszereket követelnek meg, amelyek valószínûsítik a különbözô országokban gyártott berendezések azonos minôségét. Más szervezetek is léteznek hasonló feladattal, de ezek kiválasztásánál gonddal kell eljárni (pl a COS, hasonló jogokkal rendelkezik mint a NAMAS, de alacsonyabb követelmény rendszerrel dolgozik). A termékek minôsítése a nemzeti laboratóriumok kezében van, ezek a (gyártótól) független szervezetek állnak szerzôdéses kapcsolatban a szolgál-

94

tató és gyártmány forgalmazó cégekkel (vagy a vásárlókkal) a vizsgálat idejére. A forgalmazók és a gyártók (vagy vásárlók) számára a nemzeti hitelesítô szervezek (nem biztos, hogy minden ország rendelkezik ezekkel a szervezetekkel) állítják ki a használatba vételhez szükséges okmányokat, a vizsgáló laboratóriumok által kiállított SCTR, PCTR dokumentumok alapján. A felhasználóra van bízva, hogy milyen kísérô dokumentummal fogadja el a berendezést. A következô táblázat az egyes dokumentumok és berendezések megbízhatósági szintjét mutatja. Látható, hogy csak olyan berendezéstôl lehet elvárni jó mûködést (4-es szint a táblázatban), amely egy kijelölt (független, akkreditált, vagyis mindenki által elfogadott) laboratóriumban szabványos módon és szabványos vizsgáló készlettel lett levizsgálva. Megbízhatósági szint 4

3

2

1 0

Konformancia vizsgálat módja Konformancia vizsgálatot végezte: - akkreditált OSI laboratórium - GOSIP által megjelölt speciális konformancia vizsgálatok is rendelkezésre állnak Konformancia vizsgálatot végezte: - nem akkreditált laboratórium, nem OSTC és ETCOM által jóváhagyott vizsgálati készlettel - GOSIP által megjelölt speciális konformancia vizsgálatok is rendelkezésre állnak Konformancia vizsgálatot végezte: - nem akkreditált (de független) laboratórium, ad hoc vizsgálati készlettel - GOSIP által megjelölt speciális konformancia vizsgálatok is rendelkezésre állnak Konformancia vizsgálatot végezte: - nem akkreditált (nem független) laboratórium, ad hoc vizsgálati készlettel - GOSIP által megjelölt speciális konformancia vizsgálatok is rendelkezésre állnak Eszköz nincs vizsgálva.

A konformancia vizsgálat módja és megbízhatósági szintje A felhasználó dönthet a szabványos konformancia vizsgálatokat meghaladó speciális (együttmûködtetési) vizsgálatokról, s erre szerzôdést köthet független (erre szakosodott) laboratóriumokkal (SPAG PSI szolgálat). Annak ellenére, hogy sok szervezet specializálódott konformancia és együttmûködtetési vizsgálatokra, egyes szervezetek saját maguknak is kiépítették az ellenôrzési rendszert, s ez a következôkkel magyarázható: 1

az együttmûködtetési vizsgálatok szélesebb körû ellenôrzése,

1

felhasználó specifikus GOSIP elôírások megfelelô kiválasztása,

1

megfelelô referencia implementációk kritériumainak kiválasztása,

1

felesleges vizsgálatok elkerülése, tanácsadás a vásárlóknak,

1

házon belüli specialisták kiképzése,

95

1

probléma felderítés,

1

ismételt vizsgálatok elvégzése, ha mûködés közben probléma merült fel. Megbízhatósági szint 4 3 2 1 0

Együttmûködtetési vizsgálat módja - házon belüli vizsgálat a felhasználó speciális igényeinek megfelelôen - technikai segítség igénybe vétele az akkreditált OSI szervezetektôl - a szolgáltató házon belüli vizsgálata a felhasználó speciális igényeinek megfelelôen - a szolgáltató házon belüli ad hoc vizsgálata, további vizsgálatok a mûködés demonstrálására (EurOSInet igénybevétele) - a szolgáltató házon belüli ad hoc vizsgálata - a berendezés nem rendelkezik együttmûködtetési vizsgálattal

Az együttmûködtetési vizsgálat módja és megbízhatósági szintje 76

A GOSIP HASZNÁLATA

A GOSIP dokumentumok (ajánlások) halmaza, amelyek kidolgozására az egyes nemzeti kormányok adnak felhatalmazást. (Angliában az UK GOSIPot a CCTA — Government Centre for Information Systems — dolgozta ki a gyártókkal közösen). A cél az volt, hogy segítséget nyújtsanak a vásárlóknak az OSI (Open Systems Interconnection) szabványnak eleget tevô berendezések vásárlásához és beszerzéséhez. Ehhez a vásárlók kívánságait (az egyes nemzeti kormányok kívánságai nyelvi és más okokból is eltérhetnek egymástól) kell megfelelô formában összefoglalni, illetve a berendezéseknek egységes szabvány szerint kell mûködniük, valamint a berendezéseket olyan szabvány szerinti vizsgálatnak kell alávetni, amelyek biztosítják, hogy ezek a berendezések együttmûködtethetôk legyenek. Az egyes nemzeti GOSIP elôírásoknak olyanoknak kell lenniük, hogy lehetôvé váljék a berendezések nemzetközi szintû összekapcsolása és az együttmûködtetése is. A GOSIP elôírások szerepe: 1

A tervezés és az igények megfogalmazásának megkönnyítése az OSI szabvány szerinti berendezésekre.

1

Az OSI elôírásoknak megfelelô opciók definiálásának megkönnyítése.

1

Az adminisztratív felhasználói igényeknek megfelelô opciók precíz (az együttmûködtetés igényeinek is megfelelô) megfogalmazása.

1

Annak biztosítása, hogy a berendezések képesek legyenek hatékonyan együttmûködni, a beszerzés helyétôl függetlenül.

1

Annak elôkészítése, hogy további a jövôben felmerült igényeket is ki lehessen majd elégíteni a rendszer bôvítésével.

96

1

OSI irányelvek megfogalmazása — az új igényeknek megfelelôen — a fejlesztôk számára, új berendezések kifejlesztésére.

1

A gyártók, a szabványosító szervezetek és a laboratóriumok ösztönzése új és hatékonyabb konformancia és együttmûködtetési vizsgálatok kifejlesztésére.

77

GOSIP a tervezésben és a beszerzésben

Az OSI nemzetközi szabvány biztosítja, hogy különbözô célokra és különbözô helyrôl vásárolt berendezéseket az igényeknek megfelelôen összekapcsoljunk és együtt, egységes rendszerként mûködtethessünk. Az OSI alkalmazásának elônyei: 1

Lehetôvé tesz többfelhasználós összekapcsolásokat.

1

Függetleníti a vásárlót az iparban alkalmazott helyi szabványoktól.

1

Az új berendezések kifejlesztése egy (a szabvány által) szabályozott fejlôdési folyamaton megy keresztül.

1

A szabad piac lehetôvé teszi, hogy a felhasználó optimálisan használhassa fel anyagi erôforrását.

1

A erôforrások optimális felhasználása hosszú távon biztosítható.

1

A házon belüli szakértôk (karbantartók) száma csökkenthetô.

Az OSI szabványt több nemzeti és nemzetközi szabványosító szervezet elfogadta, így: 1

ISO (International Organisation for Standardisation).

1

CCITT (International Telegraph and Telephone Consultative Commitee).

1

CEN (the European standard body).

1

CENELEC (the European electrical standard body)

1

CEPT (the European Confederation Telecommunication Administration).

1

Számos észak-amerikai és távol-keleti szabványosító szervezet is elfogadta.

of

Postal

and

Ezen három világrész szervezetei több finomítást végeztek a szabványon, amelyek az ISP (International Standardized Profile) dokumentumokban jelennek meg. A UK GOSIP — a nemzetközi és európai — OSI szabványra alapozott, de a jövôben várható az ISP elôírások megjelenése is. Ennek a kormányajánlásnak a használata magánszervezeteknél is bátorítást kapott, amikor az Európai Közösség 87/95/EEC határozatával közös ajánlásnak fogadta el. 78

PICS használata a tervezésben

A konformancia vizsgálatok — mint ahogy azt elôzôleg vázoltuk — nem garantálják a teljes rendszer együttmûködési képességét. A PICS dokumentumok kapcsolódnak az egyes GOSIP szabványleírásokhoz. A PICS dokumentumok a szabvány teljes leírását adják, amire elsôsorban a gyártónak és a szolgáltatónak van szüksége, a vásárlónak azokra a részekre van szüksége, 97

amibôl ki tudja választani a neki szükséges (igényeinek megfelelô) berendezést. Ezeket a fontos információkat a GOSIP profil dokumentumban (GOSIP subprofile) adják meg jól áttekinthetô formában. A vásárló a "rövidített PICS" dokumentum alapján választhatja ki a számára legjobban megfelelô berendezéseket. A vásárlónak elvileg lehetôsége lenne a PICS dokumentumok korrigálására is, vagyis olyan (a szabvány által megengedett) opciók megrendelésére a gyártótól, ami számára kedvezôbb tulajdonságokkal rendelkezô berendezést eredményezne. Ezek a próbálkozások nem veszélytelenek, igen nagy körültekintést, s a szabványok teljes ismeretét igénylik. Ugyanakkor ilyen igény kielégítése nagy valószínûséggel az együttmûködési képességet is veszélyezteti. Fontos tudni, hogy a GOSIP elôírások "szigorúbbak" mint az OSI elôírások. Más szóval: azok a berendezések, amelyek megfelelnek a GOSIP elôírásnak, azok mindig megfelelnek az OSI-nak, de fordítva nem mindig igaz.

98

79

A HIVATKOZOTT SZABVÁNYOK ÉS RÖVIDÍTÉSEIK

CCITT T.410

ODA and Interchange Format (ODIF)

CCITT X.25

X.25 LAPB-Compatible Procedures

CCITT X.25

X.25 Packet Level Protocol for Data Terminal Equipment

CCITT X.400 (1984)

MHS(84): Message Handling System

CCITT X.400 (1988)

MHS(88): Message Handling System

CCITT X.500

DIR: Directory Standard

IEEE 1224

Common Object Management

IEEE 1224.1

MHS API

IEEE 1224.2

Directory Services API

ISO 1539

Programming Languages – FORTRAN

ISO 1989

Programming Languages – COBOL

ISO 3788

1600 bpi tape

ISO 5652

6250 bpi tape

ISO 6937

Coded Character Sets for Text Communication

ISO 7185

Programming Languages – Pascal

ISO 7372

United Nations Trade Data Elements Dictionary (UNTDED)

ISO 7498

Basic Reference Model for OSI

ISO 7776

X.25 LAPB-Compatible Procedures

ISO 8063

QIC 150 1/4" cartridge

ISO 8073

Connection-Oriented Specification

ISO 8208

X.25 Packet Level Protocol for Data Terminal Equipment

ISO 8348

Network Service Definition

ISO 8571

FTAM: File Transfer, Access and Management

ISO 8613

Office Document Interchange Format

ISO 8652

Programming Languages – Ada

ISO 8859

8-bit Single-byte Coded Graphic Character Sets

ISO 8878

Use of X.25 to Provide the Connection-mode Network Service

ISO 9040

VT: Virtual Terminal Basic Class Service

99

DTE

DTE

Data

Data

Transport

Architecture

Link

Link

Protocol

(ODA)

&

ISO 9041

VT: Virtual Terminal Basic Class Protocol

ISO 9075

SQL

ISO 9314

Fibre Distributed Data Interface (FDDI) Token Ring

ISO 9529

3,5" 1,4 Mbyte floppy

ISO 9592

PHIGS (Programmers' Hierarchical Interactive Graphics System)

ISO 9593

PHIGS (Programmers' Hierarchical Interactive Graphics System: FORTRAN, Ada, C bindings)

ISO 9594

DIR: Directory Standard

ISO 9595

Common Mangement Information Service (CMIS)

ISO 9596

Common (CMIP)

ISO 9646-1

IT — OSI — Conformance testing methodology and framework, Part 1. "General concept"

ISO 9646-2

IT — OSI — Conformance testing methodology and framework, Part 2. "Abstract test suite specification"

ISO 9646-3

IT — OSI — Conformance testing methodology and framework, Part 3. "The Tree and Tabular Combined Notation (TTCN)"

ISO 9646-4

IT — OSI — Conformance testing methodology and framework, Part 4. "Test realisation"

ISO 9646-5

IT — OSI — Conformance testing methodology and framework, Part 5. "Requirements on test laboratories and clients for the assesment process"

ISO 9735

EDIFACT: Electronic Data Interchange Administration, Commerce and Transport

ISO 9899

Programming Languages – C

ISO 9945–1

IT – POSIX – Part 1. System Application Programming Interface (API) [C language]

ISO 10026

IT — OSI — Distributed Transaction Processing

ISO 10164

System Management

ISO 10165

Management Information

ISO 10165-1

Management Information Model

ISO 10165-2

Definition of Management Information

ISO 10165-4

Guidelines for the Definition of Managed Object

ISO DIS 9945–2

IT – POSIX – Part 2. Shell and Utilities, User Portability Extension

ISO ISP 10608-2

TP4 and CLNS over LLC1 and 8802-3 LAN 100

Management

Information

Protocol

for

ISO ISP 10608-5

TP4 and CLNS over PSTN SVC

ISO ISP 10609-6

TP0,2 and CONS over PSTN SVC

ISO ISP 10609-7

TP0 and CONS over PSTN SVC

101

80

HIVATKOZÁSOK

CCTA, Towards Open Systems: A TCP/IP to OSI Migration Strategy for U.K. Government Departments GOSIP 4 UK Government OSI Profile, Procurement Handbook X/Open CAE Specifikáció, API a Katalógus Szolgáltatásokhoz (XDS) X/Open CAE Specifikáció, CPI-C X/Open CAE Specifikáció, Elektronikus Posta Alkalmazás Programozási Interfész (X.400) X/Open CAE Specifikáció, IPC mechanizmusok SMB protokollra X/Open CAE Specifikáció, OSI Absztrakt Adat Kezelés API (XOM) X/Open CAE Specifikáció, Osztott Tranzakció Kezelés: XA Specifikáció X/Open CAE Specifikáció, Parancsok és Segédprogramok, 4. Kiadás X/Open CAE Specifikáció, Protokollok az X/Open Együttmûködésre: XNFS, 4. Kiadás X/Open CAE Specifikáció, Rendszerfelület Definíciók, 4. Kiadás X/Open CAE Specifikáció, Rendszerhívások és Header–ek, 4. Kiadás X/Open CAE Specifikáció, Strukturált Lekérdezô Nyelv (SQL) X/Open CAE Specifikáció, X/Open Transport Interfész (XTI) X/Open CAE Specifikáció, X/Open PC-s Együttmûködési Protokollok: SMB, 2. Verzió X/Open Fejlesztôi Specifikáció, Indexszekvenciális Adatelérési Módszer (ISAM) X/Open Fejlesztôi Specifikáció, X/Open PC-s Együttmûködési Protokollok: (PC)NFS X/Open Rendszerek és Védjegyes Termékek: XPG4 X/Open Specifikáció, Adat Kezelés, 3. Kiadás X/Open Specifikáció, Kiegészítô Definíciók, 3. Kiadás X/Open Specifikáció, Parancsok és Segédprogramok, 3. Kiadás X/Open Útmutató, Útmutató az Internet Protokoll Készlethez X/Open Útmutató, Útmutató egyes X.400 és Katalógus szolgáltatások Alkalmazás Programozói Interfészeihez XPG3-XPG4 Migrációs Útmutató

102

81

RÖVIDÍTÉSEK

ADMD

Administration Management Domain

AJPO

Ada Joint Program Office

ANSI

American National Standards Institute

AOW

Asia-Oceania Workshop

API

Application Program Interface

APIA

API Association

APPC

Advanced Peer-to-Peer Communication

ASCII

American National Standard Code for Information Interchange

ATS

Abstract Test Suite

BSFT

Byte Stream File Transfer

BSI

British Standard Institution

CAE

Common Application Environment

CCTA

Government Center for Information Systems

CEN

Comité Européen de Normalisation (European Committee for Standardization)

CENELEC

Comité Européen de Normalisation ELECtrotechnique (European Committee for Electrotechnical Standardization)

CEPT

European Confederation of Postal and Telecommunications Administrations

CLNS

Connectionless-mode Network Service

CMIP

Common Management Information Protocol

CMIS

Common Management Information Service

CONS

Connection-mode Network Service

COS

Corporation for Open System

CPI-C

Common Programming Interface for Communication

CRAMM

CCTA Risk Analysis and Management Methodology

CSMA/CD

Carrier Sense Multiple Access / Collision Detection

CSQ

Conformance Statement Questionnaire

CTS

Conformance Testing Services

DIB

Directory Information Base (X.500)

DIR

Directory Services

DIS

Draft International Standard

DIT

Directory Information Tree (X.500)

DNI

Detailed Network Interface

DSA

Directory Service Agent (X.500) 103

DSP

Directory System Protocol

DUA

Directory User Agent (X.500)

DUA

Directory Access Protocol

EBCDIC

Extended Binary Coded Decimal Interchange Code

ECITC

European Committee for IT Testing and Certification

EDI

Electronic Data Interchange

EDIFACT

EDI for Administration, Commerce and Transport (UN/ISO)

EDIM

EDI Messaging

EN

European Norm

ENV

European Pre-norm (Vornorm)

EPHOS

European Procurement Handbook for Open Systems

ESTELLE

Extended Finite State Machine Specification Language

ETCOM

European Testing and Certification for Office and Manufacturing

ETSI

European Telecommunications Standard Institute

EWOS

European Workshop for Open Systems

FDDI

Fibre Distributed Data Interface

FTAM

File Transfer, Access and Management (ISO)

FTP

File Transfer Protocol

GKS

Graphical Kernel System

GOPIP

Government Open Systems Interconnection Profile

INTAP

Interoperability Technology Association for Information Processing

IPM

Interpersonal Messaging (X.400)

IS

International Standard

ISAM

Indexed Sequential Access Method

ISDN

Integrated Services Digital Network

ISP

International Standardized Profile

IT

Information Technology

IUT

Implementation Under Test

LAN

Local Area Network

LLC

Logical Link Control

LOTOS

Language of Temposal Ordering Specification

LU

Logical Unit

MHS

Message Handling System (X.400)

MOTIS

Message-Oriented Text Interchange System 104

MS

Message Store

MTA

Message Transfer Agent (X.400)

MTS

Message Transfer System (X.400)

NAMAS

National Measurement Accreditation Scheme

NBS

National Bureau of Standards

NCC

National Computer Center

NFS

Network File System

NIST

National Institute of Standards and Technology

NLM

Network Lock Monitor

NSM

Network Status Monitor

ODA

Open (Office) Document Architecture (ISO)

OIW

OSI Implementors Workshop (VT)

OMG

Object Management Group

OSI

Open System Interconnection

OSTC

Open System Testing Consortium

PCTR

Protocol Conformance Test Report

PHIGS

Programmer's Hierarchical Interactive Graphics System

PICS

Protocol Implementation Conformance

PIXIT

Protocol Implementation eXtra Information for Testing

POSIX

Portable Operating System Interface

PRMD

Private Management Domain

PSI

Process to Support Interoperabiity

PSTN

Public Switched Telephone Network

RPC

Remote Procedure Call

SAA

System Application Architecture

SCTR

System Conformance Test Report

SDL

Specification and Description Language

SMB

Service Message Block

SNA

System Network Architecture (IBM)

SNI

Simple Network Interface

SPAG

Standard Promotion and Application Group

SQL

Structured Query Language

SUT

System Under Test

SVC

Switched Virtual Circuit

TC

Technical Committee

105

TCP/IP

Transmission Control Protocol / Internet Protocol

TFA

Transparent File Access

TLFF

Technical Level Feeders Forum

TMLA

Trade Mark Licence Agreement

TP

Transaction Processing

UA

User Agent (X.400)

UDP

User Datagram Protocol

UN

United Nations

VT

Virtual Terminal (ISO)

WAN

Wide Area Network

XTI

X/Open Transport Interface

106