Ahhoz, hogy az elkövetkezõ fejezetek tartalmát megérthessük, szükségünk van a CORBA szabvány bizonyos fokú ismeretére. Mivel a szabvány eléggé szerteágazó és bonyolult, ezért ebben a fejezetben csak egy áttekintésre törekszünk. Az érdeklõdõ olvasónak a következõ könyvet tudjuk ajánlani:

Michi Henning - Steve Vinoski:

A fenti kötet nagy elõnye a hivatalos szabvány dokumentummal (TODO) szemben, hogy programozóknak készült, és így szinte minden, a CORBA használata során felmerülõ kérdésre választ kaphatunk belõle.

1. A CORBA története

A CORBA szabványt az OMG (Object Management Group) hozta létre. Az OMG egy ipari konzorcium (TODO), amely azért jött létre, hogy megoldást találjon a heterogén, hordozható osztott-rendszerek létehozása során felmerülõ problémákra. Az OMG 1989-ben alakult, és mára már több mint 800 tagja van.

A CORBA szabvány elsõ változata 1991-ben jelent meg, ezt több javított verzió követte. Jelenleg a 2.3 verzió az aktuális, mi is ezt fogjuk tárgyalni. Érdemes megjegyezni, hogy már készülõben van a 3.0 verzió, melynek legfontosabb újdonsága a CORBA komponents modell. Ez a modell a Windows világból már ismert OLE/ActiveX, és a JAVA világból származó Enterprise JAVABeans specifikációk adaptálása a CORBA-hoz. Segítségével a fejlesztõk újrafelhasználható CORBA komponenseket hozhatnak létre.

2. A CORBA jellemzõi

A CORBA célja osztott, objektum-orientált alkalmazások fejlesztésének segítése. A CORBA a következõ jellemzõkkel rendelkezik:

3. Alapfogalmak

Ebben a szakaszban a CORBA alapvetõ fogalmait igyekszünk ismertetni. A fogalmak neve ismerõs lehet, de a CORBA-ban ezekhez a nevekhez speciális jelentés tartozik, amely nem feltétlenül egyezik meg azzal a jelentéssel, amit az olvasó megszokott.

A következõ ábra a CORBA architektúráját szemlélteti:

<TODO>

4. Az OMG IDL (Interface Definition Language)

Ahhoz hogy egy kliens kéréseket intézhessen egy CORBA objektumhoz, ismernie kell az objektum által nyújtott felülelet. A CORBA-ban az objektumok felületét az IDL nyelven írhatjuk le. Az IDL nem programozási nyelv, egyedüli célja a felületek leírása. Az alábbiakban egy egyszerû IDL definíciót láthatunk:

A fenti példa egy banki számlát reprezentáló objektum felületét írja le. Az objektumnak három mûvelete van, melyek segítségével pénzt tehetünk be, pénzt vehetünk ki, illetve lekérdezhetjük a számla egyenlegét.

Mivel az IDL deklaratív nyelv, nem alkalmas számítások leírására, csakis a kommunikációs felületek definiálhatóak benne. Ahhoz, hogy IDL definícókban lévõ információt programjainkban felhasználhassuk, szükségünk van nyelvi leképezésekre. Egy nyelvi leképezés azt adja meg, hogy az IDL hogyan fordítható le egy adott programozási nyelvre. A nyelvi leképezés rögzíti, hogy az IDL nyelv egyes konstrukcióinak a programozási nyelv mely konstrukciói felelnek meg. A leképezés ezenkívül azt is megadja, hogy az adott nyelven írt alkalmazások hogyan érhetik el a különbözõ CORBA szolgáltatásokat.

A jelenleg használt programozási nyelvek legtöbbjéhez létezik nyelvi leképezés. Ezek legnagyobb részét és OMG alkotta meg, és a CORBA szabvány részét képezik. Ezen dolgozat egyik célja éppen egy nyelvi leképezés definiálása a Clean programozási nyelvhez.

Az IDL definíciókat általában fileokban tároljuk. Az IDL fileokból a nekik megfelelõ nyelvi elemeket egy IDL fordító (IDL compiler) állítja elõ. Az IDL fordító a CORBA szoftver termékek része. Mivel a gyakorlati CORBA fejlesztésekhez használt programozási nyelvek köre szûk (C++ és JAVA), ezért a legtöbb IDL fordító csak ezt a két nyelvet támogatja. A diplomamunka keretében elkészült egy IDL fordító is, amely az IDL fileokat Clean-re fordítja.

5. Az IDL nyelv elemei

5.1 Beépített típusok

5.2 Elnevezett típusok

A typedef kulcsszó használatával új nevet adhatunk egy típusnak:

5.3 Felsorolási típusok

Az IDL felsorolási típusai nagyon hasonlóan a C++-ból megismert felsorolási típusokhoz:

Különbség a C++-hoz képest, hogy nem adhatóak meg az egyes nevekhez tartozó numerikus értékek.

5.4 Direkt szorzat típusok (struktúrák)

5.4 Unió típusok

Az IDL tervezõi szakítottak a C/C++ unió típusával, annak gyenge típusossága miatt. Minden IDL unió típusnak van egy diszkriminátora (discriminant), amelynek értéke dönti el, hogy az unió éppen milyen típusú értéket tartalmaz. A diszkriminátornak egész típusúnak kell lennie (short, long, char, boolean, felsorolási típusok). Lehetõség van egy default ág megadására, amely akkor aktív, ha a diszkriminátor értéke egyik felsorolt értékkel sem egyezik meg. Egy példa:

Egy gyakori alkalmazása az unió típusnak az opcionális értékek megadása:

5.5 Tömb típusok

Az IDL-ben lehetõségünk van mind egy, mind többdimenziós tömbök használatára. Az tömb elemeinek típusa tetszõleges lehet. Például:

5.6 Szekvencia típusok

Az IDL szekvenciák megfelelnek a programozás elméletbõl megismert szekvencia típus fogalmának. Egy IDL szekvencia hossza és elemeinek típusa tetszõleges lehet. A programozónak lehetõsége van a maximális hossz megadására. Például:

Az első szekvencia hossza tetszőleges lehet, míg a másodiké maximum 100.

5.7 Rekurzív típusok

Struktúrák és szekvenciák felhasználásával lehetõségünk van rekurzív szerkezetû típusok definiálására. Például:

Az ilyen struktúrák felhasználásával tetszőleges bonyolultságú adatstruktúrák vihetők át a klients és a szerver program között.

5.8 Konstansok

Az IDL konstansok szintaxisa és szemantikája megegyezik a C++ konstansaival. Példák:

5.9 Interfészek

Az IDL nyelv legfontosabb célja, hogy lehetõvé tegye az objektumok által nyújtott felület leírását. Ezeket a felületeket interfész típusok (interface types) írják le. Az interfész típusok hasonlatosak a JAVA interfész fogalmához, azaz csak a objektumok felületét adják meg, az implementációt nem. Az interfész tuljadonképpen mûveleti szignatúrák gyûjteménye. Bármely CORBA objektum megvalósíthat egy adott interfészt azzal, hogy implementálja az interfészben szereplõ mûveleteket. Az interfész típusok egyenértékûek más IDL típusokkal, azaz használhatjuk õket struktúrák elemeiként, mûveletek ki és bemenõ paramétereiként stb. Ahol az IDL definícióban egy interfész típus szerepel, ott futás közben egy, az adott interfészt megvalósító objektumra mutató objektum referencia kell, hogy szerepljen.

Egy egyszerű példa:

Mûveletek definiálása

Egy mûvelet definicíója a következõ részekbõl áll:

• a mûvelet neve
• az egyes paraméterek deklarációja
• a visszatérési érték

A visszatérési érték tetszõleges IDL típus lehet. Ha a mûvelet nem ad vissza eredményt, akkor azt a C++-hoz hasonlóan, a void kulcsszóval jelöljük.

Minden paraméternek van egy neve, típusa, és iránya (direction). A paraméterátadás iránya háromféle lehet:

A következő példa szemlélteti a paraméterátadási lehetőségeket:

Kivételkezelés

Miután definiáltuk a kivétel típusát, a művelet definíciójában jeleznünk kell, hogy a művelet kiválthatja az adott kivételt:

A felhasználó által definiált kivételeken kívül minden IDL mûvelet kiválthat néhány elõre definiált kivételt is. Ilyenek például: OBJECT_NOT_EXIST, COMM_FAILURE stb.

Attribútumok

Öröklődés

Lehetőség van arra is, hogy interfészeink örököljenek egymástól. Ez hasonló a JAVA által használt megoldáshoz. Például:

interface Vehicle {

...

};

interface Car : Vehicle {

...

};

Minden IDL interfész implicite örököl az Object nevű interfésztől. Ez azt jelenti, hogy lehetőségünk van olyan IDL műveleteket definiálni, melyek bármilyen típusú interfésszel működnek. Például:

Egy objektum referencia lehet NIL. Ez az objektum referencia „nem mutat sehová", ha megpróbáljuk felhasználni egy CORBA kérés céljaként, hibajelzést kapunk. A nil referenciát például a fenti lookup mûvelet használhatja annak jelzésére, hogy nem létezik adott kulcsú objektum a hash táblában.

5.10 Az IDL modulrendszere

Nagyobb alkalmazások készítéséhez elengedhetetlenül szükséges egy modulrendszer, melynek segítségével IDL definícióinkat rendszerezhetjük és az esetleges névütközéseket kizárhatjuk. Az IDL modulrendszere a C++-ból ismert namespace-okhoz hasonlatos. Lehetõségünk van egy hierarchikus modulrendszer kialakítására, tetszõleges mélységben.

Példa:

Az OMG által definiált konstansok, típusok, interfészek stb. mind a CORBA modulon belül helyezkednek el, így például a fent említett Object típus teljes neve CORBA::Object.

5.11 Az Any típus

Utoljára hagytuk az any típus tárgyalását annak speciális jellege miatt. Az any típus egyike az IDL beépített típusainak. Sajátossága, hogy bármely más IDL típus értékét képes tárolni. Ez nagyon hasznossá teszi akkor ha nem tudjuk elõre, hogy milyen típusú értékeket szeretnénk átvinni a kliens és a szerver között.

Az any típushoz kapcsolódik egy másik CORBA típus, a TypeCode. A TypeCode típus, mint a neve is mutatja, típusinformációt hordoz. Segítségével tudjuk például meghatározni, hogy egy any-ben tárolt érték tulajdonképpen milyen típusú is. A TypeCode típus definícióját a CORBA szabvány IDL-ben adja meg.

6. Az ORB pszeudo-objektum

A CORBA szabvány a programozó rendelkezésére álló szolgáltatásokat un. pszeudo-objektumok segítségével definiálja. A pszeudo-objektumok hasonlatosak a felhasználó által definiálható objektumokhoz, de nem feltétlenül igazak rájuk azok a szabályok, amelyek a valódi objektumokra igazak. Például, a pszeudo objektumok referenciáit nem lehet átküldeni egy CORBA kérés során a szerver oldalra, nem hozható létre tetszõleges számú belõlük stb. A szabvány a pszeudo-objektumokat (pszeudo)IDL segítségével írja le. Ennek legnagyobb elõnye, hogy ezeket az objektumokat a programozó ugyanolyan módon használhatja, mint az általa definiált objektumokat.

A legfontosabb pszeudo objektum az ORB objektum. Ennek a definíciója az alábbi:

Az ORB interfész nagyon sok mûveletet tartalmaz, de nekünk csak a fenti három a lényeges, mivel csak ezekkel fogunk találkozni a késöbbiekben.

Az object_to_string és a string_to_object mûveletek segítségével objektum referenciák és sztringek között konvertálhatunk. Erre például akkor van szükség, ha egy szerver objektum referenciáját el szeretnénk juttatni a kliens programhoz. A sztring formátumu objektum referenciát IOR-nak (Interoperable Object Reference) nevezzük. Az Interoperable elnevezés arra utal, hogy az IOR formátuma szabványosított, így az egyik CORBA implementáció által elõállított IOR-t be fel tudja használni egy másik CORBA implementációt használó program is.

7. A CORBA szolgáltatások

Az alkalmazásfejlesztés megkönnyítésére az OMG definiált néhány szolgáltatást (CORBAServices), melyeket a CORBA-t használó programok igénybe vehetnek. Ezeknek a szolgáltatásoknak a felülete OMG IDL-ben van megadva. A fontosabb szolgáltatások a következõk:

• Naming Service - Ennek segítségével a CORBA objektumoknak nevet adhatunk, és név szerint kereshetünk köztük. (Telefonkönyv)
• Trader Service - A Naming Service általánosítása. Az objektumokhoz tulajdonságokat rendelhetünk, és ez alapján kereshetünk köztük. (Yellow Pages)
• Event Service - Osztott rendszerünket eseményvezérelten mûködtethetjük.
• Transaction Service - Osztott tranzakciókat hozhatunk létre segítségével.
• Lifecycle Service - CORBA Objektumainkat perzisztenssé tehetjük.

8. Az Interface Repository

Az Interface Repository (IR) nem más, mint olyan CORBA objektumok halmaza, amelyet az IDL fileokban tárolt információt teszik elérhetûvé CORBA alkalmazások számára. Ez olyan alkalmazásokban lehet fontos, ahol futás közben van szükség típusinformációra. Ilyen alkalmazás lehet például egy „object explorer", mellyel a rendszerben levõ objektumokat vizsgálhatjuk meg, üzeneteket küldhetünk nekik stb.

Az IR-t általában egy, a CORBA szoftverhez adott szerverprogram valósítja meg. Némely IDL fordító képes arra, hogy az IDL fileok tartalmát „feltöltse" az IR-be, illetve hogy az IR tartalma alapján generáljon kódot.

9. A Dynamic Invocation Interface

Amikor CORBA alkalmazást írunk, általában pontosan tudjuk, hogy mi a használni kívánt szerver objektumok felülete. Az IDL fordító azzal segíti a mi munkánkat, hogy minden IDL interfészhez definiál un. stub-okat. A stub egy olyan nyelvi elem az általunk használt programozási nyelvben, mely segítségével a CORBA kéréseket biztonságos módon küldhetjük el. Például, ha adott az alábbi CORBA interfész:

interface Echo {

short echo_int(in short what);

};

class Hello {

CORBA::short echo_int(CORBA::short what);

};

Amikor a kliens program meghívja a fenti metódust, a metódus átalakítja a what paramétert átviteli formátumra (marshalling), elküld egy CORBA kérést a szervernek a paraméterrel, megvárja az eredményt, visszaalakítja azt C++-formátumra (unmarshalling), majd visszaadja az eredményt a hívónak.

Látható, hogy a fenti módszer sok hibalehetőségtől megkíméli a felhasználót. Nem fordulhat elő, hogy túl sok, vagy túl kevés paramétert adunk át a műveletnek, olyan objektumnak küldünk üzenetet, melynek nincs is ilyen művelete etc.

A stub-oknak van egy „párja" a szerver oldalon, melyeket skeleton-oknak nevezünk. A skeleton-ok a CORBA objektumok implementálásában segítik a programozót. C++-ban például minden skeleton egy absztrakt osztály virtuális függvényekkel, melybõl a programozónak kell a CORBA objektumot megvalósító osztályt származtatnia.

A DII-nek is van szerver oldali párja, a DSI (Dynamic Skeleton Interface). A DSI úgy mûködik, hogy a programozó megadhat egy speciális függvényt, a DIR-t (Dynamic Implementation Routine), melyet az ORB meghív, ha az adott objektumhoz kérés érkezik. A DIR megkapja a mûvelet nevét és általános formában a paramétereket. Feladata a mûvelet eredményének és az kimenõ paraméterek értékének kiszámítása.

A DII-t és a DSI-t azért tárgyaljuk ilyen mélységben, mert sok olyan szoftver, amely a CORBA-t illeszti egy adott programozási nyelvhez, ezt a két szolgáltatást használja az illesztés megvalósításához. A mi Clean-CORBA interfészünk is erre a két technológiára épül.

10. A MICO CORBA implementáció

A fejezet lezárásaként szóljunk néhány szót arról a CORBA implementációról, amelynek segítségével ez a diplomamunka készült.

A MICO egy szabadon felhasználható, nyílt forráskódú (open source) CORBA megvalósítás. Szinte teljes egészében támogatja a CORBA 2.3 szabványt, és elég sokan használják mint akadámiai, mint üzleti körökben. Bõvebb információ a

http://www.mico.org

A MICO-nak van néhány jellemzője, amelyek szinte ideálissá teszik az ebben a munkában történő felhasználásra:

Hasonlóan a CORBA-t bemutató fejezethez, ez a fejezet arra törekszik, hogy az olvasót megismertesse a Clean programozási nyelvel. Ez azért hasznos, mert így a funkcionális nyelvekben kevésbé járatos olvasó is képes követni a késõbbi fejezetek tartalmát. Helyhiány miatt nem törekedhetünk a nyelv teljes bemutatására. Az érdeklõdõ olvasónak egy, az Interneten szabadon elérhetõ könyvet tudunk ajánlani (TODO).

1. A Clean nyelvrõl általában

A Clean egy funkcionális programmozási nyelv, amelyet egy, a hollandiai Nijmegen egyetemen mûködõ kutatócsoport hozott létre, és fejleszt ma is. A nyelv rendelkezik a modern funkcionális nyelvektõl elvárható fontosabb jellemzõkkel, azaz:

2. Kifejezések

Egy Clean kifejezés literálokból és függvény applikációkból épül fel. A Clean beépített típusai a következõk:

• 32 bites egész számok: 0, 1, 2, -1, ....
• valós számok: 3.14, 0.0, ....
• Karakterek: ‘a’, ‘b’, ....
• Sztringek: „foo", „bar", „Hello, World!" ...
• Logikai értékek: True, False

Egy függvény applikáció a fv. nevébõl és a fv. paramétereibõl épül fel. Például:

add 1 1 Þ 2

inc 5 Þ 6

not True Þ False

2 * 2 Þ 4

True && False Þ False

1 == 1 Þ True

Az operátoroknak van priorítása, amely általában megfelel a matematikából ismert konvencióknak. A programozónak lehetõsége van saját operátorokat definiálni.

A legfontosabb adatszerkezet a Clean-ben a lista. A Clean lista típusai hasonlóak a Lisp nyelv listáihoz. Minden listának van egy feje (head), illetve egy törzse (tail). A törzs lehet üres is. Például, az 1,2,3 lista a következõképpen írható le Clean-ben:

[1:[2:[3:[]]

[1..10] Þ [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

[1,3..10] Þ [1, 3, 5, 7, 9]

[1..] Þ [1, 2, 3, .......... (végtelen sorozat)

A Clean-ben alkalmazott lusta kiértékelés biztosítja, hogy a fenti végtelen lista használata egy programban nem vezet végtelen ciklushoz.

Ha bonyolultabb listákat akarunk létrehozni, akkor szükségünk lehet un. listakifejezések (list comprehensions) használatára. Például:

[ x + y | x <- [1..2], y <- [1..3] \\ x == y] Þ [2, 4]

A Clean rendszer nagyon sok előre definiált függvényt tartalmaz listákon. Néhány ezek közül:

Listákon kívül lehetõségünk van rendezett párok használatára is. Egy rendezett pár a következõképpen írható: (1, 2). A rendezett párok jelentõségét azt adja, hogy Clean-ben minden függvénynek csak egy visszatérési értéke lehet, ezért több értéket csak párok használatával tudunk visszaadni.

3. Függvénydefiníciók

Egy Clean program nem más, mint függvény definíciók halmaza. Egy függvénydefiníció a következõ formájú:

<fv nev> <formalis parameterek> = <kifejezes>

Például:

add x y = x + y

Minden függvénynek van egy típusa, melynek megadása nem kötelezõ, de növeli a kód olvashatóságát. Ha nem adjuk meg a típust, a fordító levezeti nekünk. A fenti fv. típusa:

add :: Integer Integer -> Integer

A függvényeket alkalmazhatjuk úgy is, hogy nem adjuk meg meg minden paraméterüket. Ekkor egy un. curried függvényt kapunk. Például:

inc = add 1

A fenti függvény típusa az alábbi:

inc :: (Integer -> Integer)

Mint látható, az inc egy argumentum nélküli (konstans) fv, amelynek eredménye egy olyan egyváltozós függvény, amely az argumentumához egyet ad hozzá. Használata:

inc 1 Þ 2

Nagyon fontos eszköze a funkcionális nyelveknek az un. mintaillesztés (pattern matching). Segítségével függvényeinket a matematikában megszokott módon definiálhatjuk:

isZero 0 = True

isZero x = False

A fenti függvényt úgy értékeli ki a rendszer, hogy sorban veszi a bal oldalon található mintákat, és megvizsgálja, hogy a fv. aktuális paraméterei illeszkednek-e a mintára. Ha igen, a függvény értéke az illeszkedõ egyenlõség jobb oldalán található kifejezés lesz.

Mintáinkban nem csak számokat használhatunk, hanem sztringeket, listákat stb. is:

length2 :: [Integer] -> Integer

length2 [] = 0 // Üres lista

length2 [_:xs] = 1 + (length2 xs) // Olyan lista, amelynek törzsét xs-nek

// nevezzük el

Mint a fenti példa mutatja, a mintaillesztés arra is használható, hogy az adatstruktúráinkat részekre bontsuk, a részeket elnevezzük, és a részeket a függvénydefiníció jobb oldalán felhasználjuk. Az aláhúzásjel egy olyan minta, amelynek bármely érték illeszkedik. Akkor érdemes használni, ha az adott értéket nem akarjuk felhasználni a függvényérték kiszámításánál.

Gyakran elõfordul, hogy függvényeink kiszámításához szükségünk van segéddefiníciókra, akárcsak a matematikában. Ezeket a definíciókat egy where kifejezésnek nevezett szerkezetben adhatjuk meg:

length2 [_:xs] = 1 + len

where

len = length2 xs

Mint látható, a segéddefiníciókban felhasználhatók a fv formális paraméterei.

Egy utolsó példaként adjuk meg a fentebb már emlegetett map függvény definícióját egészeket tartalmazó listákra:

map :: [Integer] [Integer->Integer] -> [Integer]

map [] fun = []

map [x:xs] = [fun x:map xs fun]

4. Polimorfizmus és paraméteres típusok

Az elõzõekben ismertetett lista típus un. paraméteres típus azaz eleminek típusa tetszõleges lehet. Létrehozhatunk egészek listáját, függvények listáját stb. Az ilyen típusokat más néven polimorfikus típusoknak is szokás nevezi.

Azokat a függvényeket, amelyek polimorfikus típusokkal végeznek mûveleteket, szintén polimorfikusnak nevezzük. Az egyik legegyszerûbb ilyen fv a length fv:

length :: [a] -> Int

length [] = 0

length [_:xs] = 1 + (length xs)

Fontos észrevennünk, hogy a length fv eredménye csak a lista szerkezetétől függ, és nem a konkrét lista elemektől. Ez teszi lehetővé, hogy bármilyen elemtípusú listára definiáljuk.

A korábban említett rendezett párok is polimorfikus típusok. Az alábbi függvény visszaadja egy rendezett pár első tagját:

fst :: (a, b) -> a

fst (x,_) = x

Utolsó példaként tekintsük a map fv immár általánosított definícióját:

map :: [a] (a -> b) -> [b]

map [] = .....

5. Algebrai és rekord típusok

:: Color = Red | Green | Blue

:: List = Cons Int List

| Nil

:: Person = Person String Int String // Name, Age, Address

Hasonlóan a lista típusokhoz, az algebrai típusokat is paramétezhetjük más típusokkal:

:: Tree a = Leaf a | Node (Tree a) (Tree a)

Az algebrai típusokat kezelő függvényeket a legegyszerűbben a struktúrájuk szerinti rekurzió segítségével definiálhatjuk. Ehhez segítségünkre van, hogy a mintaillesztés algebrai típusokra is működik:

sum_nodes :: (Tree Int) -> Int

sum_nodes (Leaf i) = i

sum_nodes (Node a b) = (sum_nodes a) + (sum_nodes b)

Az algebrai típusok legnagyobb problémája, hogy a bennük tárolt információk csak mintaillesztés segítségével és csak pozíciónálisan érhetők el:

name (Person n _ _) = n

Ha egy adatkonstruktornak sok paramétere van, fárasztó lehet a paraméterek sorrendjének megjegyzése. Erre nyújt megoldást a Clean rekord típusa:

:: Person = { name :: String, age :: Int, address :: String }

A rekord komponenseit az imperatív nyelvekben megszokott szintaxissal érhetjük el:

get_name p = p.name

Rekord típusú értéket az értékek felsorolásával hozhatunk létre:

{ Person | name = „Wyat Earp", age = „75", address = „Tombstone"}

set_name :: Person String -> Person

set_name person newname = {p & name = newname}

7. Egzisztenciális típusváltozók

Tekintsük újra a régi lista típusunk definícióját:

:: List a = Cons a List | Nil

:: List = E.a: Cons a List | Nil

A fenti definíció azt jelenti, hogy a típusváltozó értéke az egyes adatkonstruktorok alkalmazásánál más és más lehet, például:

(Cons ‘a’ (Const 5 Nil))

A fenti kifejezés típusa List, amelyben nem szerepel már az elemek típusa. Ez azt is jelenti, hogy a típusinformáció elveszik, így bizonyos kifejezéseknek már nem lehet meghatározni a típusát. Például:

head (Cons x _) = x

Ennek a fv-nek nincsen meghatározható típusa, így a fordító hibajelzést ad.

:: Drawable = E.a: {

local_state :: a,

draw :: a Canvas -> Canvas,

moveBy :: a Int -> a

};

draw :: Drawable Canvas -> Canvas

draw d canvas = d.draw d.local_state canvas

moveBy :: Drawable Int -> Drawable

moveBy d distance = {d & d.local_state = d.moveBy d.local_state distance}

Most már létrehozhatunk néhány Drawable típusú objektumot:

createPoint :: Int Int -> Drawable

createPoint x y = { Drawable |

local_state = (x, y),

draw ls canvas = <code to draw a point on the canvas>,

moveBy ls distance = (x + distance, y + distance)

}

Az objektumorientált programozásban használt terminológiával szólva a createPoint fv egy konstruktor. Az osztályok fogalma itt nem jelenik meg explicite. Azok az objektumok tartoznak egy „osztályba", melyeket ugyanaz a konstruktor hozott létre.

8. A Clean modulrendszere

9. Típusosztályok

Egy típusosztály nagyon hasonló a JAVA nyelv interfész fogalmához. A típusosztály nem más, mint függvénydefiníciók halmaza, ahol minden függvény ugyanazzal a típusváltozóval van paraméterezve. Például:

class Showable a where

show :: a -> String

instance Showable Bool where

show True = „True"

show False = „False"

instance Showable [a] where

show [] = „"

show [x:xs] = concat (show x) (show xs)

Természetesen egy típusosztály egynél több függvényt is tartalmazhat. Így például definiálhatók algebrai struktúrákat leíró típusosztályok, ezek segítségével pedig általánosított műveletek, például mátrixszorzás stb. Persze ekkor a programozó dolga biztosítani, hogy a műveletekre valóban igazak legyenek az algebrai struktúra axiómái.

10. Unique típusok

A Clean nyelv legnagyobb újítása az un. uniqueness típusrendszer bevezetése. Ennek a típusrendszernek a célja kettõs:

• segítségével a fordítóprogram sokkal hatékonyabb kódot tud generálni a Clean forrásprogramból. A Clean az egyik leggyorsabb funkcionális nyelv implementáció a világon.
• a típusrendszer lehetõséget teremt interaktív programok írására anélkül, hogy a funkcionális stílus elõnyeit (referenciális átlátszóság) fel kellene adnunk.

Bevezetésként foglalkozzunk az interaktív programok funkcionális nyelvben való írásának nehézségeivel. A probléma gyökere a referenciális átlátszatóság, vagyis az, hogy egy függvény visszatérési értéke csak az argumentumainak értékétõl függhet. Egy interaktív programra ez sajnos nem igaz. Tekintsük például a getc fv-t, amely egy karakter olvas be a felhasználótól:

getc :: Char

Ennek a fv-nek nincs argumentuma, mégis minden kiértékelésekor más értéket ad vissza, tehát nem igaz rá a referenciális átláthatóság.

A fenti problémára többféle megoldás lehetséges:

• A Haskell funkcionális programozási nyelv an un. Monad-ok segítségével valósítja meg az interaktív folyamatokat. A Monad-ok a kategória elméletbõl származó absztrakt objektumok, melyek segítségével sok, a funkcionális programozás során felmerülõ problémát kezelni lehet. Az érdeklõdõ olvasó a Haskell nyelvi szabványból (TODO) juthat további információhoz.
• Ahelyett hogy a getc fv-t argumentum nélküli fv-nek tekintenénk, tekinthetjük állapotátmenet függvénynek, amely a funkcionális programot körülvevõ világ állapotát változtatja meg futása közben:

getc :: World -> (Char, World)

(getc w, getc w)

Mi az értéke ennek a kifejezésnek? A válasz az, hogy ez a kiértékelés sorrendjétől függ, azaz megint elvesztettük a funkcionális nyelvekre jellemző determinisztikusságot. A megoldást az jelentené, ha a világot megváltoztató függvények között sorrendet tudnánk felállítani, azaz pontosan meg tudnánk határozni melyik következik melyik után. Pontosan erre nyújt lehetőség a Clean uniqueness típusrendszere.

A fentiek szerint a megoldás az, hogy az állapotátmenet függvényeinket úgy definiáljuk, hogy a világot jelképezõ argumentum és visszatérési érték unique attribútumot kapjon. Ezt Clean-ben a típusnév elõtt álló csillaggal jelöljük:

getc :: *Word -> (Char, *World)

Ha ezzel a definícióval probáljuk a (getc w, getc w) kifejezést lefordítani, a fordító típushibát jelez.

Állapotátmenet függvények használata esetén kényelmetlen lehet, hogy az egyre újabb világok jelölésére új változókat kell bevezetni:

getc2 w = ((c1, c2), w2)

where

(c1, w1) = getc w

(c2, w2) = getc w1

Ennek kiküszöbölésére a Clean bevezetett egy új szintaktikus formát, amely megjelenésében nagyon hasonlít az imperatív nyelvek szekvencia programkonstrukciójához:

getc2 w

# (c1, w) = getc w

# (c2, w) = getc w

= ((c1, c2), w)

Ahogy az elõzõ fejezetben említettük, ahhoz, hogy a CORBA szolgáltatásait egy adott programozási nyelvbõl elérhessük, szükségünk van egy nyelvi leképezésre (language mapping). Ebben a fejezetben egy ilyen nyelvi leképezést definiálunk a Clean programozási nyelvhez.

A fentieknek megfelelõen ez a fejezet több alfejezetre bomlik, melyek a leképezés különbözõ részeit ismertetik. A száraz ismertetést példák bemutatásával igyekszünk érdekesebbé tenni, ezenkívül igyekszünk a leképezés mögött álló tervezési döntéseket ismertetni.

TODO: IDL Compiler

1. Az IDL fordító

Az IDL fileokból a megfelelõ Clean definíciók elõállítását az IDL fordítóprogram végzi. Ennek bemenete egy IDL file, kimenete pedig két Clean forrásfile. Az elsõ file a modul definíciós file, amely a modul által kiexportált típusok és függvények definícióját tartalmazza. A másik file az implementációs file, amely a függvények törzsét tartalmazza. Az IDL fordító használatára egy késõbbi szakaszban láthatunk példákat.

1. Az IDL modulrendszer

Az IDL file-okban található azonosítóknak ugyanaz az azonosító felel meg a Clean kódban is. Például, ha adott a következõ IDL deklaráció:

A fenti IDL típusnak a Clean-ban is egy Color nevû típus fog megfelelni.

Bonyoltabb a helyzet akkor, ha a definíció egy IDL modulban helyezkedik el, pl.

Mivel a Clean modulrendszere, ellentétben az IDL-ével, nem hierarchikus, ezért nem tehetjük meg, hogy az IDL moduloknak Clean modulokat feleltetünk meg. Ehelyett azt a módszert választjuk, amit a CORBA-C leképezés is követ, vagyis a Clean-beli azonosító nevében elhelyezzük az õt tartalmazó modul(ok) nevét, ezzel kerülve el az esetleges névütközéseket. A fenti példában tehát a Clean-beli típus neve Useless_An_enum lesz.

Sokszor elõfordul, hogy az IDL fordítónak automatikusan kell Clean azonosítókat generálnia. Ezek az azonosítók mindig két egymás melleti aláhúzás jelet (__) tartalmaznak, így kerülve el a névütközéseket az IDL fileokban használt azonosítókkal.

2. Az egyszerû típusok megfeleltetése

Az alábbi táblázat tartalmazza a beépített IDL típusokat, és a nekik megfelelõ Clean típusokat:

Mivel a Clean-ben csak egyetlen egész típus van, ezért minden IDL-beli egész típusnak ezt feleltetjük meg. Ez problémát okozhat akkor, ha olyan értékeket adunk át az IDL-ben definiált mûveletek paramétereként, melyek Int típusúak ugyan, de kívül esnek az adott IDL egész típus értelmezési tartományán. Az implementácíó feladata, hogy ezeket a hibás értékeket kiszûrje. Hasonló a helyzet a lebegõpontos típusokkal.

Az IDL tartalmaz egy un. korlátozott (bounded) sztring típust is, ahol a programozó megszabhatja, hogy mennyi lehet az adott sztring maximális hossza. Ezt a mi leképezésünk (egyenlõre) nem támogatja.

Bár a leképezés támogatja a wchar és wstring típusokat, a Clean-ben nincs UNICODE támogatás, így a fenti típusok használata eléggé nehézkes.

A fenti táblázatból hiányzik néhány IDL típus, amelyeket a jelenlegi Clean leképezés nem támogat. Ezek a következõk:

Az IDL-nek a fentieken kívül van még két elõredefiniált típusa, az Any és a TypeCode, melyekrõl a következõ szakaszban lesz szó.

3. A TypeCode típus

Az Any típus leképezésének ismertetése elõtt szólnunk kell a TypeCode típusról. A TypeCode típus, ahogy a neve is mutatja, típusinformációt tárol, azaz segítségével az IDL típusokra vonatkozó információhoz futás közben is hozzáférhetünk.

Minden IDL típusnak van egy fajtája (kind), amely egyértelmûen meghatározza, milyen információt kell a TypeCode-nak tárolnia az adott típusról. Külön fajta tartozik minden beépített típushoz, és minden típuskonstrukcióhoz.

A CORBA szabvány a TypeCode típust is egy IDL definíció segítségével definiálja. Ez azzal az elõnnyel jár, hogy a nyelvi leképezéseknek nem kell külön megadniuk a TypeCode típus leképezését, mert az leképezés többi részébõl már következik. Hátránya ennek a megközelítésnek, hogy az így kapott típus használata egy kissé kényelmetlen lehet, mert nem használja ki a típus speciális jellemzõit.

A mi leképezésünkben a TypeCode típusnak a következõ algebrai típus felel meg:

etc.

A sztring és szekvencia típusoknál a ‘bound’ argumentum a sztring és a szekvencia maximális hosszát adja meg. Ha nincs korlátozás, akkor ez az érték 0.

Példaképpen tekintsük a következõ IDL típust:

Ezt a típust a következõ TypeCode írja le:

Azért, hogy a felhasználónak ne kelljen ezeket a bonyolult kifejezéseket magának leírnia, az IDL-CLEAN fordító minden, az IDL file-ban talált típushoz generál egy fv-t, amely az adott típus TypeCode-ját adja vissza. Például, a fenti típus TypeCode-ját a APrettyBoringStruct__tc függvény segítségével kaphatjuk meg.

4. Az Any típus

Ahogy az elõzõ fejezetekben elmondtuk, az Any típus bármely létezõ IDL típus értékét képes tárolni. Ennek megfelelõen a Clean nyelvre való leképezése is egy kicsit bonyolultabb, mint a többi típusé.

Az Any típusnak a következõ algebrai típus felel meg a Clean-ben:

// TODO:

Ahogy látható, minden IDL típushoz, vagy típus konstrukcióhoz tartozik egy Clean adatkonstruktor. A konstruktor neve meghatározza a Any által tartalmazzott érték típusát. Ahol további típusinformációra van szükség (például a szekvencia típusnál tárolni kell a szekvencia elemeinek a típusát is), ott az adatkonstruktor paraméterei hordozzák ezt az információt.

Például, az elõzõ szakaszban definiált IDL struktúra egy példányát a következõ Clean kifejezés írja le:

Azért, hogy Any típusú értékek létrehozását egyszerûbbé és biztonságosabbá tegye, az IDL-CLEAN fordító minden típushoz generál két függvényt:

Az encode fv egy adott típusú értéket konvertál Any-vé, a decode fv pedig a megadott Any-ben tárolt értéket próbálja az adott típussá konvertálni. Ezeket a mûveleteket a CORBA szabvány beszúrásnak (insertion), illetve kivételnek (extraction) nevezi. A decode fv eredményében szereplõ MayBe típus definíciója a következõ:

Mint sejthetõ, a decode fv (Just result)-ot ad vissza, ha a dekódolás sikerült, és Nothing-ot, ha nem.

A decode fv *World argumentuma azt fejezi ki, hogy a dekódolás során esetleg a program környezetét érintõ mûveleteket is végre kell hajtani. Például, ha az Any egy objektum referenciát tartalmaz, és mi egy adott típusú objektum referenciát szeretnénk kiolvasni az Any-ból, akkor a rendszernek kapcsolatot kell teremtenie azzal a távoli rendszerrel, ahol az objektum van, hogy megtudja hogy az objektum az adott típusú-e.

5. Felsorolási típusok

Leképezésünk az IDL felsorolási típusainak (természetes módon) algebrai típusokat feleltet meg. Például:

Ennek az IDL típusnak a következõ Clean típus felel meg:

Az adatkonstruktorok nevébe azért került bele a típus neve, hogy elkerüljük a névütközéseket a más modulokban deklarált, hasonló nevû felsorolási értékekkel.

A használat megkönnyítése érdekében az IDL-CLEAN compiler minden felsorolási típushoz elkészíti az == és a toString függvények példányait, így a programozónak ezek már a rendelkezésére állnak.

6. Struktúrák (Direkt szorzat típusok)

Az IDL struktúráknak rekord típusok felelnek meg a Clean-ben. A rekord típus neve megegyezik a struktúra nevével, a rekord mezõnevei pedig a struktúra mezõinek a neveivel. Például:

Ennek az IDL struktúrának a következõ Clean rekord felel meg:

Ahogy az IDL ismertetésénél említettük, az IDL exception (kivétel) típusai nagyon hasonlóak a direkt szorzat típusokhoz. Ebbõl következik, hogy nyelvi leképezésük tökéletesen megegyezik azokéval.

7. Unió típusok

Az unió típus leképezésénél az a probléma merül fel, hogy nincs olyan Clean nyelvi elem, amely tökéletesen megfelelne az IDL nyelvi elemnek. A legközelebbi analógiát a Clean algebrai típuskontrukciói kínálják, de az algebrai típusoknál az adatkonstruktor neve dönti el, hogy a az adott változó éppen melyik értéket tartalmazza. Az IDL unió típusainál ezzel szemben a diszkrimináns értéke határozza meg ugyanezt. Az ellentmondást úgy oldjuk fel, hogy az diszkrimináns értékeibõl generáljuk az adatkonstruktorok neveit. Például:

Ennek az IDL definíciónak az alábbi Clean definíció felel meg:

A default konstruktor azért rendelkezik két argumentummal, mert az unió értékén kívül tárolnia kell a diszkriminátor értékét is.

8. Szekvencia és tömb típusok

A szekvencia típusok természetes módon képezhetõk le a Clean nyelvre: minden ilyen típusnak egy Clean lista felel meg. Hasonló a helyzet az IDL tömb típusival is. Egy példa:

Érdekesebb a helyzet akkor, ha a szekvencia elemtípusa egy un. anonym típus, tehát egy olyan típus, melynek nincsen neve. Például:

Milyen típusnév szerepeljen ekkor a Clean deklarációban? A válasz az, hogy az IDL fordítóprogram automatikusan generál nevet az ilyen típusoknak, ahogy az az alábbiakban látható:

10. Konstansok

A funkcionális nyelvekben a konstansok szerepét argumentum nélküli függvények töltik be. Ez az alapja az IDL konstansok Clean-be való leképezésének is:

A megfelelő Clean deklarációk:

11. Interfész típusok

Ebben a szakaszban az IDL interface típusainak leképezését fogjuk ismertetni. Ellentétben a leképezés többi részével, az interfészek és mûveleteik leképezése más a kliens és a szerver oldalon. A kliens oldali programozó az interfész használatához akar segítséget kapni, míg a szerver oldali programozó az interfész mûveleteinek megvalósításához. Ez a szakasz a kliens oldali leképezést ismerteti, a szerver oldalra késõbb térünk ki.

A leképezés minden interfész típusnak egy átlátszatlan (opaque) típust feleltet meg. Ezek olyan típusok, melyeket belsõ struktúrája a programozó számára hozzáférhetetlen, és csak elõre adott függvényeken keresztül lehet elérni õket.

Példaképpen tekintsük az egyik elõzõ fejezetben leírt Bank interfészt. Az ehhez tartozó Clean definíció a következõ:

Mint látható, a modul definíciós file-jában csak a típus nevét adtuk meg, a teljes definíció az implementációs file-ban található.

12. Műveletek

Az IDL fordító minden, az IDL interfészben szereplõ mûvelethez egy Clean függvényt generál, amelynek kiértékelésével hívhatja meg a programozó a CORBA objektum megfelelõ mûveletét. Például, a már említett Account interfészhez az alábbi függvényeket generálja a fordító:

Ha a műveletnek vannak out vagy inout típusú paraméterei, akkor a Clean függvény ezek hívás utáni értékét is visszaadja, például:

Ehhez a művelethez a következő Clean fv generálódik:

Minden, az IDL interfészben definiált attribútumhoz két függvény generálódik: egy az attribútum lekérdezésére, és egy a beállítására. Például:

attribute long balance3;

Ehhez az attribútumhoz a következő két Clean fv generálódik:

13. A MICO Binder szolgáltatása

14. Példák

Ennyi száraz elmélet után ideje, hogy gyakorlati példákkal is szolgáljunk. Ebben a szakaszban két példát ismertetünk: az egyik a klasszikus „Hello, World!" program CORBA stílusban, a másik pedig a már korábban ismertetett Account interfész használatát bemutató program. Mivel a szerver oldali leképezést még nem ismertettük, ezért feltesszük, hogy a szerver programok már korábban megírásra kerültek egy másik programozási nyelvben (például C++-ban).

14.1 A Hello, World! példaprogram

Az elosztott alkalmazásunk készítéséhez először is definiálnunk kell a kliens és a szerver közti felületet:

A fenti definíciókat tároljuk el egy hello.idl nevű fileban. Ahhoz, hogy ezt az interfészt Clean-ből használni tudjuk, le kell futtatnunk a Clean IDL fordítót:

bash$ idl2clean hello.idl

A fordító két file-t hoz létre, amelyek a Hello interfészhez tartozó Clean definíciókat tárolják.

Most már készen állunk a kliens program megírására:

A program a következőképpen működik:

A fenti programot a Clean fejlesztő környezet segítségével fordíthatjuk le. A kipróbálásához először el kell indítanunk a szerver folyamatot:

A -ORBIIOPAddr argumentum azt határozza meg, hogy a szerver folyamat melyik IP címen és melyik TCP porton figyeljen a MICO Binder-től érkező kérésekre.

A szerver indítása után elindíthatjuk a kliens folyamatot is:

A futás eredménye remélhetőleg egy „Hello, World!” üzenet lesz.

14.2 Az Account példaprogram

Az Account interfészt már korábban ismertettük, most csak a kliens programot fogjuk bemutatni:

A program szerkezete hasonló az elõzõ példaprograméhoz. Elõször inicializáljuk a CORBA rendszert, majd megszerezzük az Account objektum egy referenciáját. Ezután különbözõ kéréseket intézünk az objektumhoz, végül kiiratjuk az objektum végsõ állapotát, azaz a számla egyenlegét.

15. A Dynamic Invocation Interface

Leképezésünk nagyon egyszerű: A DII használatát egyetlen függvény, a corba_invoke valósítja meg. Ennek definíciója az alábbi:

A paraméterek jelentése a következõ:

• Az elsõ argumentum azt a CORBA objektumot adja meg, amelynek a kérést küldjük.
• A második argumentum a mûvelet neve. Ez ugyanaz a név, mint amelyet az IDL file-okban adunk meg. Kivétel ez alól az attribútumokat lekérdezõ és beállító mûveletek neve, amelyek elnevezése „_get_<ATTRIBUTE_NAME>" és „_set_<ATTRIBUTE_NAME>".
• A harmadik argumentum a paraméterek típusát és értékét adja meg. A paramétereket egy-egy CorbaArg típusú érték ír le. Ennek definíciója:

Minden paraméterátadási módhoz két adatkonstruktor tartozik. Az elsõnél meg kell adni a paraméter nevét és értékét, a másodiknál pedig a nevét és a típusát. A második formára out típusú paraméterek esetén van szükség, mivel ilyenkor a paraméter csak a szerver oldalon kap értéket.

Felmerülhet az olvasóban, hogy miért van szükség ennyi információ megadására, miért kell például a visszatérési érték típusát is megadni. A válasz az, hogy a CORBA alapjául szolgáló hálózati protokoll, az IIOP, nem hordoz típusinformációt, így a CORBA szoftver nem tudná a felhasználói program segítsége nélkül dekódolni a vonalon érkezõ információt.

Végezetül lássunk egy példát a DII használatára. Tegyük fel, hogy az Account interfész deposit nevû mûveletét szeretnénk meghívni. Ezt a következõképpen tehetjük meg:

16. A szerver oldali leképezés

16.1 A szerver program

Az elõzõ szakaszokban a CORBA kliens oldali aspektusait tárgyaltuk, vagyis azt, hogy egy kliens program hogyan képes CORBA objektumoknak kéréseket küldeni, és ezek eredményét feldolgozni. A szerver oldali leképezés ezzel szemben azt definiálja, hogy egy szerver program hogyan valósíthat meg CORBA objektumokat, és hogyan szolgálhatja ki az objektumoknak érkezõ kéréseket.

A funkcionális programmozás eszközeivel egy CORBA szerver folyamat egy állapotátmenet rendszernek (state transition system) tekinthetõ. A rendszer események hatására lép át egyik állapotból a másikba. A mi esetünkben az események a CORBA objektumokhoz érkezõ kérések. A rendszer állapota három tényezõbõl tevõdik össze:

• A rendszer privát, a programozó által láthatatlan állapota. Ide tartozik például az, hogy milyen CORBA objektumok lettek eddig létrehozva, hogyan kell reagálni a nekik érkezõ kérésekre stb.
• A rendszer globális, a programozó által definiált állapota. Egy bank rendszerében ide tartozhat például az aktív számlák listája.
• Az egyes CORBA objektumok állapota. Ilyen lehet például az egyes Account objektumokban a számla egyenlege.

A Clean rendszer tartalmaz egy Object IO-nak nevezett keretrendszert (framework), amellyel eseményvezérelt alkalmazások valósíthatóak meg. Sajnos az Object IO újabb verziói csak Windows platformon érhetõek el, míg ez a dolgozat UNIX rendszereken készült. Így magát a keretrendszert nem tudjuk felhasználni, de felhasználjuk a keretrendszer által nyújtott modellt (design reuse).

A rendszer állapotát a PSt (program state) típus tárolja. Ennek definíciója a következõ:

Mint látható, a program állapota két részbõl áll. Az ls a local state, ezt a programozó adhatja meg. Az io az IO state, ebben tárolódik az IO rendszer állapota. A programozó az IO állapothoz csak függvényeken keresztül férhet hozzá. Ezeket a függvényeket késõbb részletesen is ismertetni fogjuk.

A szerver folyamatot a CORBA_Server_run függvény meghívásával futtathatjuk. Ennek definíciója:

Az elsõ paraméter az ORB-t reprezentáló objektum, a második pedig a program kiinduló állapota. Ha a programnak nincs lokális állapota (például késõbbi példaprogramjainknak sincs), akkor ide a Void értéket írhatjuk.

A harmadik paraméter az inicializáló függvény, melynek feladata a program kezdeti állapotának létrehozása. Ebben a függvényben hozhatjuk létre a program CORBA objektumait.

16.2 CORBA objektumok

Ahogy egy elõzõ fejezetben említettük, a CORBA objektumokat servant-oknak nevezett programozási nyelvbeli objektumok valósítják meg. A mi esetünkben a servant-ok Clean rekordok lesznek. A rekordok kétféle komponenst tartalmaznak:

• Az adott CORBA objektum lokális állapota
• Az IDL interfészhez tartozó mûveleteket megvalósító Clean függvények.

Például, a már sokszor említett Account típushoz tartozó servant objektumokat az alábbi típus írja le:

Ahogy fent látható, az objektum lokális állapota nem más, mint a számla egyenlege. Az objektum mûveletei ezt állapotot kérdezik le, illetve változtatják meg.

Ahhoz, hogy egy objektum a külvilág számára is látható legyen, be kell jegyeztetni az ORB-nél. Ezt esetünkben az Account_servant_open fv végzi, melynek definíciója:

A függvény bemenete a program állapota és az általunk megadott servant objektum. A fv bejegyezteti a servant-ot az IO rendszerbe, így amikor egy kérés érkezik a servant által reprezentált CORBA objektumhoz, a rendszer az általunk megadott függvényeket fogja meghívni a kérés kiszolgálásához.

Elérkezett az ideje, hogy a teljes Account szerver programot bemutassuk:

Ahhoz, hogy egy Clean programozó a CORBA szolgáltatásait élvezhesse, két dologra van szüksége:

Ebben a fejezetben ennek a két szoftverkomponensnek az implementációjáról lesz szó.

1 A Clean-C interfész

Ahhoz, hogy egy funkcionális programozási nyelv széles körben elterjedjen, szükség van egy olyan eszközre, amelyel a más programozási nyelvekkel készült szoftverkönyvtárakat el lehet érni. Ezt az eszközt Idegen Nyelvi Interfésznek (Foreign Language Interface-FFI) nevezik. Mint sok más funkcionális nyelv, a Clean is rendelkezik egy FFI eszközzel. Ezt az eszközt fogjuk a továbbiakban ismertetni.

Egy példa egy C függvény meghívására:

Az átvihető paraméterek típusa erősen korlátozott. A következő típusok a megengedettek:

Lehetőség van pointerek használatára is, ezeket a Clean-ben Int típusként kezelhetjük.

A paraméterek típusa elött látható felkiáltójel azt jelzi, hogy a függvény szigorú (strict) az adott paraméterben. Ez azt jelenti, hogy a függvény értéke nem határozható meg az adott paraméter kiértékelése nélkül. Mivel a paraméterek értékét mi egy C függvénynek szeretnénk átadni, ezért minden paraméternek strict-nek kell lennie.

Ahogy az előzőkben említettük, a Clean-C interfész meglehetősen primitív, ami jelentősen megnehezítette a szoftverünk elkészítését. A főbb problémák a következők:

A fenti problémák jelentős részét megoldaná, ha a Clean valamelyik más funkcionális nyelv külső interfészét használná, például a Haskell-hez készült Green Card-ot.

Ennek a Clean modulnak a segítségével érheti el a programozó az ORB szolgáltatásait. Ez a modul valósítja meg az elözö fejezetben ismertetett Any és TypeCode típusokat, a CORBA_ORB_Init, CORBA_Server_run függvényeket stb.

A modul több egymásra épülő rétegből áll, melyet az alábbi ábra szemléltet:

<TODO>

A legfelső réteg az, amit a Clean programozó használni fog. Ez a réteg definiálja az előző fejezetben megismert adattípusokat és függvényeket. A legfelső réteg által nyújtott programozási felület teljes definíciója az A mellékletben TODO található meg.

3. Az IDL fordítóprogram

Egy IDL fordítóprogram két részből áll:

3.1 A front end

3.2 A back end

A back end feladata a kódgenerálás a front end által előállított belső reprezentáció alapján. A belső reprezentáció esetünkben nem más, mint egy Clean algebrai adattípus, mely az IDL fileokban található információt tárolja:

OMG homepage

CORBA specification

CORBA book

MICO homepage

tclMico homepage

Clean homepage

Clean tutorial

Haskell homepage

Green Card homepage