3. szám

2010. Március

Informatikai NavigátorGondolatok a szoftverek használatáról és fejlesztéséről

3. szám

Informatikai Navigator Gondolatok a szoftverek használatáról és fejlesztéséről

Tartalomjegyzék1. SQLite - Lokális adatbáziskezelés 3

2. Objektumaink tudása – A Decorator minta 14

3. A Java biztonsági rendszere - Authentikáció, Authorizáció 293.1. Alapfogalmak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2. A kliens hogyan használ egy JAAS LoginModule-t? . . . . . . . . . . . . . . . . . . 313.3. Hogyan készítsünk el egy saját JAAS LoginModule-t? . . . . . . . . . . . . . . . . . 333.4. A Java authorizáció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4. Session replikációs alternatívák 45

5. Az üzleti informatikai rendszerek fejlődése és típusai 515.1. Rövid áttekintés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2. Operatív szintű információs rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . 565.3. Döntéstámogató rendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4. Az üzleti intelligencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5. Tudásmenedzsment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6. Az integráció szerepe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.7. Irodaautomatizálás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.8. A jövő - ami már itt van (SOA, Cloud Computing) . . . . . . . . . . . . . . . . . . 61

6. SOA – a jövő üzleti és architekturális modellje 62

7. Informatikai szilánkok - tippek és trükkök 687.1. Folyamatábrák készítése - a flow értelmező . . . . . . . . . . . . . . . . . . . . . . . 687.2. Weblogic ejb készítése NetBeans alatt . . . . . . . . . . . . . . . . . . . . . . . . . . 707.3. Seession cookie nevének beállítása Weblogic környezetben . . . . . . . . . . . . . . . 717.4. Webservice kliens proxy generálás Weblogic környezetben . . . . . . . . . . . . . . . 727.5. Amikor a CPU „túlpörög” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Főszerkesztő: Nyiri Imre ([email protected])

2

Adatbáziskezelés SQLite - Lokális adatbáziskezelés

1. SQLite - Lokális adatbáziskezelés

Az SQLite egy szoftver library és néhány utility, amik lehetővé teszik a szerver nélküli, lokálisSQL adatbázisok létrehozását. Célja, hogy olyan eszközt adjon a programozók kezébe, ami magasszinten támogatja az SQL alapú adatkezelést olyan esetekben is, amikor nem szükséges egy ko-moly hálózati adatbázis szerver. Jellegénél fogva kiváló komponense lehet sok mobileszköz belsőadatkezelésének. Alapelvei között van a zéró konfiguráció, ismeri a tranzakciókezelést.Webhelye: http://www.sqlite.org/

Kik és miért használják?

Az SQLite egy beágyazott (embedded) relációsadatbáziskezelő, azaz az őt használó szoftver-hez linkelve lehet használni, nem egy külön SQLszerver. Nincs user adatbázisa. Ettől elte-kintve nagyrészt megvalósítja az SQL-92 szab-ványt. Olyan esetekben érdemes megfontolni azalkalmazását, amikor a helyi rendszeren, azaz alocalhost-on szeretnénk az adatainkkat tárolni.Az SQLite-ot neves szoftverek és eszközök hasz-nálják: MAC OS, Solaris 10, Skype, iPhone, Fi-refox. A fejlesztők szlogenje szerint használjukott ezt a könyvtárat, ahol egyébként a fopen()parancsot használnánk. Gondoljunk arra, hogyegy hordozható eszközhöz írt szoftvernek általá-ban pont ilyen adatbáziskezelőre van szüksége.

Adatbázisok esetén az ACID mozaikszóaz Atomicity (atomicitás), Consistency (kon-zisztencia), Isolation (izoláció), és Durability(tartósság) rövidítése. Ezek az adatbázis-kezelő rendszer tranzakciófeldolgozó képességei-nek alapelemei. Enélkül az adatbázis integritásanem garantálható, így a tranzakciókezelés támo-gatott ebben a környezetben is.

Részlegesen megvalósítja a triggereket és alegtöbb komplex/összetett lekérdezést. Az SQ-Lite szokatlan típuskezelést használ az SQLadatbázis-kezelőhöz: egy adattípus nem a táblaoszlopaihoz, hanem egyedi értékekhez van hoz-zárendelve, más szóval dinamikus típuskezelésthasznál, gyengén típusos adatkezelés mellett.Amennyiben string típusú adat beilleszthető in-

teger oszlopba, akkor a SQLite először a strin-get integerre konvertálja, ha az oszlop preferálttípusa integer. Ez nagyobb rugalmasságot ad azoszlopoknak, ami hasznos lehet dinamikus típus-kezelésű script-nyelvekben való alkalmazás ese-tén, azonban ez a technika nem vihető át másSQL adatbázis-kezelőkbe. Az SQLite képtelen atipikus adatbázisokban található szigorúan típu-sos oszlopok kezelésére.

Ugyanazt az adatbázist több processz ésszál használhatja egyidejűleg problémamente-sen. Az olvasási kérelmek kiszolgálása párhuza-mosan történik. Az írási kérelmek végrehajtásaakkor történik meg, amikor nincs folyamatbanmás kérelem kiszolgálása, egyébként az írási ké-relem sikertelen lesz és hibakóddal tér vissza, il-letve lehetőség van egy beállítható várakozási időelteltével a kérelem ismétlésére. Ez a konkurenshozzáférési állapot megváltozható ideiglenes táb-lák használata esetén.

Az SQLite számos programnyelvből használ-ható, így BASIC, C, C++, Common Lisp, Java,C#, Visual Basic .NET, Delphi, Curl, Lua, Tcl,R, PHP, Perl, Ruby, Objective-C (Mac OS X-en), Python, newLisp, Haskell, OCaml, Small-talk és Scheme nyelvekhez rendelkezik illesztőfe-lülettel.

Az adminisztrációs kliens felület

Az SQLite rendelkezik parancssoros (neve: sq-lite3 ) és GUI-s (neve: SQLite Database Browser,1. ábra) kezelőfelülettel is. A GUI egy minimális

3


és szokásos adatkezelő felületet ad, amin inter-raktív módon elvégezhetjük a legfontosabb fel-adatokat: adatbázisok létrehozása, megnyítása,SQL parancsok kiadása, browse funkciók. Hasz-nálata nem jelenthet gondot.

1. ábra. SQLite Database Browser GUI

A mindennapi adminisztratív munkát haté-konyan az sqlite3 parancsoros eszközzel tud-juk elvégezni. Indítása: sqlite3 <adatbázis-file-név>. Egy SQLite adatbázis egyetlen file-kéntjelenik meg az operációs rendszerben, ami ké-nyelmes kezelhetőséget eredményez a minden-napi munkában.

Hozzunk létre egy inyiri.sqlite nevű adatbá-zis az sqlite3 inyiri.sqlite paranccsal! A továb-biakban ezt az adatbázis fogjuk használni pál-dáinkban. Lépjünk be az adatbázisba, ami-nek az eredményét az alábbiakban látható sqliteprompt megjelenése mutat:$ s q l i t e 3 i n y i r i . s q l i t eSQLite v e r s i on 3 . 6 . 1 6Enter " . he lp " f o r i n s t r u c t i o n sEnter SQL statements terminated with a " ;"s q l i t e >

A .help „pontparancs” segítséget arról, hogyezen a konzolon mit tehetünk. Az adatbázis táb-láit például a .tables mutatja meg:

s q l i t e > . t ab l e sActors Rese rvat ions peopleCustomers passwords phoness q l i t e >

Látható, hogy jelenleg 6 db tábla van. A táb-lák szerkezetét (sémáját) a .schema paranccsaltudhatjuk meg. Nézzük meg a Customers és Re-servations táblákat!s q l i t e > . schema CustomersCREATE TABLE Customers ( CustomerId i n t e g e r PRIMARY KEY,Name text ) ;s q l i t e > . schema Reservat ionsCREATE TABLE Reservat ions ( Id i n t e g e r PRIMARY KEY,

CustomerId in t ege r , Day text ) ;

Érdekes lehetőség a .dump parancs, ami egytábla tartalmát SQL parancsban adja vissza:s q l i t e > .dump CustomersBEGIN TRANSACTION;CREATE TABLE Customers( CustomerId i n t e g e r PRIMARY KEY, Name text ) ;INSERT INTO "Customers" VALUES(1 , ’ Paul Novak ’ ) ;INSERT INTO "Customers" VALUES(2 , ’ Terry Ne i l s ’ ) ;INSERT INTO "Customers" VALUES(3 , ’ Jack Fonda ’ ) ;INSERT INTO "Customers" VALUES(4 , ’Tom Wi l l i s ’ ) ;COMMIT;s q l i t e >

A .output customers.sql parancs olyan, minta .dump, de az eredményt egyből a megadottfile-ba menti. Nagyon gyakori, hogy egy külsősql file – mint script – végrehajtása szükséges.A Customers és Reservations táblákat példáulígy hoztuk létre, erre szolgál a .read parancs.Nézzük ezt az sql scriptet (a file neve: test.sql):−− SQL f o r the Customers , Rese rvat ions t ab l e s

BEGIN TRANSACTION;CREATE TABLE IF NOT EXISTSCustomers ( CustomerId i n t e g e r PRIMARY KEY, Name text ) ;INSERT INTO Customers (Name) VALUES( ’ Paul Novak ’ ) ;INSERT INTO Customers (Name) VALUES( ’ Terry Ne i l s ’ ) ;INSERT INTO Customers (Name) VALUES( ’ Jack Fonda ’ ) ;INSERT INTO Customers (Name) VALUES( ’Tom Wi l l i s ’ ) ;

CREATE TABLE IF NOT EXISTSReservat ions ( Id i n t e g e r PRIMARY KEY,

CustomerId in t ege r , Day text ) ;INSERT INTO Reservat ions ( CustomerId , Day)VALUES(1 , ’2009−22−11 ’);INSERT INTO Reservat ions ( CustomerId , Day)VALUES(2 , ’2009−28−11 ’);INSERT INTO Reservat ions ( CustomerId , Day)VALUES(2 , ’2009−29−11 ’);INSERT INTO Reservat ions ( CustomerId , Day)VALUES(1 , ’2009−29−11 ’);INSERT INTO Reservat ions ( CustomerId , Day)

4


VALUES(3 , ’2009−02−12 ’);COMMIT;

A fenti script futtatása:

s q l i t e > . read t e s t . s q l

Az sqlite3 konzol tudása ennél természetesentöbb, itt csak ízelítő és kedvet szerettünk volnaadni a használatához.

Az SQL használata

Maradjunk még az sqlite3 konzolban, de a továb-biakban már nem az SQLite parancsokat néz-zük, hanem a használható SQL-92 nyelv lehe-tőségeit mutatjuk be. Az SQLite támogatja aszokásos DDL (Data Definition Language) lehe-tőségeket:

• CREATE – tábla, index, view, trigger lét-rehozás

• ALTER TABLE – egy tábla sémájánakmódosítása

• DROP – tábla, index, view, trigger törlés

Egy tábla oszlopainak típusai ilyenek lehetnek:

• NULL - The value is a NULL value

• INTEGER a signed integer

• REAL - a floating point value

• TEXT - a text string

• BLOB - a blob of data

Ezek az SQL parancsok szabványosak, itt nemismertetjük emiatt. Például az Actors tábla át-nevezése ilyen:s q l i t e > . t ab l e sActors Rese rvat ions peopleCustomers passwords phoness q l i t e > ALTER TABLE Actors

RENAME TO Sz ine s z ;s q l i t e > . t ab l e sCustomers Sz ine s z peopleReservat ions passwords phoness q l i t e >

Az SQLite ismer egy sor beépített operátort,nézzük meg őket a program webhelyén!

Az ismert constraints-ek támogatottak:NOT NULL, UNIQUE, PRIMARY KEY, FO-REIGN KEY, CHECK, DEFAULT. Ezek ter-mészetesen az oszlopok attributumai itt is.

Nézzük meg a select parancs lehetőségeit! Azoszlop nevének lekérdezéskori átkeresztelése ittis lehetséges. Ezt mutatja ez a 2 select parancs:

s q l i t e > s e l e c t name from Customers ;Name−−−−−−−−−−Paul NovakTerry Ne i lJack FondaTom Wi l l i ss q l i t e > s e l e c t name as nev from Customers ;nev−−−−−−−−−−Paul NovakTerry Ne i lJack FondaTom Wi l l i ss q l i t e >

A limit záradék használható, azaz a select-ben megadott limit n biztosítja, hogy maximumn sora legyen az eredményhalmaznak. Létezikaz offset n záradék is, ami az eredményhalmazelső n sorát kihagyja.

Az SQL egyik érdekes lehetősége a JOIN, amiitt is támogatott. A következőekben áttekintjükőket. Ehhez példaképpen a Customers és Reser-vations táblákat fogjuk használni:−− Ez a vevő f o g l a l szobákats q l i t e > s e l e c t ∗ from Customers ;CustomerId Name−−−−−−−−−− −−−−−−−−−−1 Paul Novak2 Terry Ne i l3 Jack Fonda4 Tom Wi l l i s

5


−− Fog la lásoks q l i t e > s e l e c t ∗ from Reservat ions ;Id CustomerId Day−−−−−−−−−− −−−−−−−−−− −−−−−−−−−−1 1 2009−22−112 2 2009−28−113 2 2009−29−114 1 2009−29−115 3 2009−02−12s q l i t e >

Az alapértelmezett összekapcsolása a táblák-nak az Inner Join, azaz a belső összekapcsolás.Itt csak azokat Customers sorokat hozza le, aholvan összekapcsolódás a Reservations táblábanlévő valamely sorral.s q l i t e > SELECT Name, Day FROM Customers AS C

JOIN Reservat ionsAS R ON C. CustomerId=R. CustomerId ;

Name Day−−−−−−−−−− −−−−−−−−−−Paul Novak 2009−22−11Terry Ne i l 2009−28−11Terry Ne i l 2009−29−11Paul Novak 2009−29−11Jack Fonda 2009−02−12s q l i t e >

Látható, hogy Terry Neil 2 foglalt nappal isrendelkezik. Ez az SQL select egyébként ekvi-valens a megszokottabb kinézetű következő pa-ranccsal:s q l i t e > SELECT Name, DayFROM Customers , Rese rvat ionsWHERECustomers . CustomerId = Reservat ions . CustomerId ;

Name Day−−−−−−−−−− −−−−−−−−−−Paul Novak 2009−22−11Terry Ne i l 2009−28−11Terry Ne i l 2009−29−11Paul Novak 2009−29−11Jack Fonda 2009−02−12s q l i t e >

Támogatott a NATURAL INNER JOIN,ami kihasználja az oszlopok névegyezőségét, ese-tünkben ez most a CustomerId oszlop:s q l i t e > SELECT Name, Day FROM Customers

NATURAL JOIN Reservat ions ;

Name Day−−−−−−−−−− −−−−−−−−−−Paul Novak 2009−22−11Terry Ne i l 2009−28−11

Terry Ne i l 2009−29−11Paul Novak 2009−29−11Jack Fonda 2009−02−12s q l i t e >

Csak érdekességképpen említjük meg aCROSS INNER JOIN nevet, amivel mindenkicsak a „where nélküli többtáblás” select névenszokott találkozni:s q l i t e > SELECT Name, Day FROM CustomersCROSS JOIN Reservat ions ;

Name Day−−−−−−−−−− −−−−−−−−−−Paul Novak 2009−22−11Paul Novak 2009−28−11Paul Novak 2009−29−11Paul Novak 2009−29−11Paul Novak 2009−02−12Terry Ne i l 2009−22−11Terry Ne i l 2009−28−11Terry Ne i l 2009−29−11Terry Ne i l 2009−29−11Terry Ne i l 2009−02−12Jack Fonda 2009−22−11Jack Fonda 2009−28−11Jack Fonda 2009−29−11Jack Fonda 2009−29−11Jack Fonda 2009−02−12Tom Wi l l i s 2009−22−11Tom Wi l l i s 2009−28−11Tom Wi l l i s 2009−29−11Tom Wi l l i s 2009−29−11Tom Wi l l i s 2009−02−12s q l i t e >

Ez természetesen ekvivalens ezzel:SELECT Name, Day FROM Customers , Rese rvat ions ;

Most térjünk át a külső összekapcsolások(Outer joins) tesztelésére! Itt nem csak az össze-illeszkedő sorok kerülnek bele az eredménytáb-lába, hanem azok is, amiknek nem találtunkpárt a másik táblában. Talán feltünt, hogy TomWillis neve nem került be az eredménybe (ki-véve a CROSS esetet). Ez azért van, mert az őCustomerId-je 4, ilyen érték pedig nincs a Re-servations táblában. Amennyiben mégis látniakarjuk őt is, úgy a LEFT OUTER JOIN-t kellhasználni:

6


s q l i t e > SELECT Name, Day FROM CustomersLEFT JOIN Reservat ions

ON Customers . CustomerID=Reservat ions . CustomerId ;

Name Day−−−−−−−−−− −−−−−−−−−−Paul Novak 2009−22−11Paul Novak 2009−29−11Terry Ne i l 2009−28−11Terry Ne i l 2009−29−11Jack Fonda 2009−02−12Tom Wi l l i ss q l i t e >

Természetesen ekkor a Tom Willis soránakDay értéke NULL, de létezik ez a sor is. Ez azSQL parancs ezzel ekvivalens:SELECT Name, Day FROM CustomersLEFT JOIN Reservat ions USING (CustomerId ) ;

A RIGHT és FULL OUTER JOIN típusú le-kérdezések jelenleg nem támogatottak.

A select utasításban használhatóak a szab-ványos SQL függvények (core, agregáló, dátum),például:s q l i t e > s e l e c t max( CustomerId ) from Customers ;max( CustomerId )−−−−−−−−−−−−−−−4s q l i t e >

Néha fontos, hogy az adattáblákat egy view-n keresztül lássuk, legyen ez most a már ismertLEFT JOIN-os select-ünk:s q l i t e > c r ea t e view a l l cu s tomer asSELECT Name, Day FROM CustomersLEFT JOIN Reservat ions USING (CustomerId ) ;

s q l i t e > . t ab l e sCustomers Sz ine s z passwords phonesRese rvat ions a l l cu s tomer people

Látható, hogy a nézetek a táblák között lis-tázódnak.

A triggerek bemutatásához létrehozunk 2 újtáblát!CREATE TABLE Log( Id i n t e g e r PRIMARY KEY,OldName text ,NewName text , Date t ext) ;

CREATE TABLE Friends( Id i n t e g e r PRIMARY KEY,

Name text UNIQUE NOT NULL,Sex text CHECK( Sex IN ( ’M’ , ’F ’ ) ) ) ;

CREATE TRIGGER mytr iggerUPDATE OF Name ON FriendsBEGININSERT INTO Log (OldName , NewName, Date )VALUES( old .Name, new .Name, datet ime ( ’now ’ ) ) ;END;

A bemutatott trigger feladata, hogy loggoljaa Friends tábla változtatásait.

A tranzakciókezelésre már láttuk a megfelelőparancsokat: BEGIN TRANSACTION, ROLL-BACK, COMMIT.

Az SQLite átttekintése után kezdjük el hasz-nálni programjainkban. A részletekbe nem me-gyünk bele, inkább csak szeretnénk felvillantania használat lehetőségét C, Java, C# és Pascal(Lazarus) környezetekből.

A C nyelvű felület

A C nyelvű SQLite megvalósítás az alap, így ter-mészetesen az SQLite programozás bemutatásátis ezzel kezdjük. Példaprogramunk (1. prog-ramlista) azt fogja csinálni, hogy parancssorbólfogad 2 paramétert: az adatbázis file nevét ésa kiadandó SQL parancsot, amit mindjárt végreis hajt az adatbázison. A 3. sorban az APIhasználatát tesszük lehetővé az sqlite3.h headerbeemelésével. A 7-17 sorok közötti callback nevűfüggvény feladata, hogy az eredménytábla egy-egy sorát ő dolgozza fel. Az argc paraméterkapja meg az aktuális rekord oszlopainak szá-mát. Az argv egy stringekre mutató tömb, amiaz adott sor konkrét oszlopértékeit tartalmazza,míg az azColName az oszlopok neveit adja át.A működés a lehető legegyszerűbb. Az aktuá-lis rekord minden oszlopát egymás után kiirjaa képernyőre. A 19. sorban kezdödő főprog-ram db változója reprezentála az adatbázist. A25-29 sorok azt vizsgálják meg, hogy a paran-csorból 3 paraméter jött-e át a programunknak,

7


amennyiben nem, úgy megjeleníti a helyes hasz-nálat helpjét. Azért kell 3 paraméter, mert Cnyelven az elindított program a 0. és utána jönmég 2 valódi paraméter. Az argv[1] tartalmazzaaz adatbázis nevét, amit a 30. sorban próbá-lunk megnyitni, később majd a 45. sorban fog-juk lezárni. A 37. sorban az argv[2] paramé-terben átvett SQL parancs lesz meghívva. Az

sqlite3_exec() első paramétere a már említettdb, azaz az adatbázis, hiszen egyszerre többetis használhatunk. A 4. paraméter az esetlegeshibaüzenet szövege, amennyiben a 38-44 sorok-ban erre szükség lenne. A 3. paraméter pe-dig a mi callback() függvényünk, amit belül azsqlite3_exec() minden eredménysorra meg foghívni.

1 // 1 . p rog raml i s t a : Egy C nye lvű mini s q l commander23 #include <s td i o . h>4 #include <s t d l i b . h>5 #include <s q l i t e 3 . h>67 stat ic int ca l l ba ck (void ∗NotUsed , int argc , char ∗∗argv , char ∗∗azColName )8 {9 NotUsed=0;10 int i ;11 for ( i =0; i<argc ; i++)12 {13 p r i n t f ( "%s ␣=␣%s\n" , azColName [ i ] , argv [ i ] ? argv [ i ] : "NULL" ) ;14 }15 p r i n t f ( "\n" ) ;16 return 0 ;17 }1819 int main ( int argc , char ∗∗ argv )20 {21 s q l i t e 3 ∗db ;22 char ∗zErrMsg = 0 ;23 int rc ;2425 i f ( argc !=3 )26 {27 f p r i n t f ( s tde r r , "Usage : ␣%s ␣DATABASE␣SQL−STATEMENT\n" , argv [ 0 ] ) ;28 e x i t ( 1 ) ;29 }30 rc = sq l i te3_open ( argv [ 1 ] , &db ) ;31 i f ( rc )32 {33 f p r i n t f ( s tde r r , "Can ’ t ␣open␣database : ␣%s \n" , sq l i t e3_errmsg (db ) ) ;34 s q l i t e 3_c l o s e (db ) ;

8


35 e x i t ( 1 ) ;36 }37 rc = sq l i t e3_exec (db , argv [ 2 ] , ca l lback , 0 , &zErrMsg ) ;38 i f ( rc !=SQLITE_OK )39 {40 f p r i n t f ( s tde r r , "SQL␣ e r r o r : ␣%s \n" , zErrMsg ) ;41 /∗ This w i l l f r e e zErrMsg i f a s s i gned ∗/42 i f ( zErrMsg )43 f r e e ( zErrMsg ) ;44 }45 s q l i t e 3_c l o s e (db ) ;46 return 0 ;47 }

A C API használatát a http://www.sqlite.org/cintro.html helyen tanulmányozhatjukrészleteiben, illetve magát az API-t a http://www.sqlite.org/c3ref/funclist.html helyentaláljuk meg.

A program fordítása és futtatása így lehetsé-ges.Ford í tá s :gcc t e s t . c −I / usr / in c lude − l s q l i t e 3 −o t e s t

Futtatás :$ . / t e s t i n y i r i . s q l i t e " " s e l e c t ∗ from phones"datum = 2010−01−01name = Nyi r i Imrenumber = 5791832

Az inyiri.sqlite a már fentiekben ismertetettadatbázis neve (a phones táblában tényleg csak1 record volt!).

Java alapú SQLite adatbáziskezelés

Az SQLite-hoz van JDBC driver, így a Java-bólhasználni egy adatbázist nem okoz gondot. Ezérdekes lehetőség olyan mobil eszközök esetén,amik Java alapon működnek, ugyanis ez a driver100%-ig Java nyelven van implementálva, nemigényel semmilyen külső natív könyvtárat. A2. programlistán láthatjuk a példaprogramun-kat. A 17-19 sorokból a connection string for-mátumát érdemes megnézni, ahogy átadjuk azadatbázis file nevét (inyiri.sqlite). A 21. és 22.sorok a DDL műveletet mutatják. Észrevehetjükazt a lehetőséget, hogy egy mező típusát nem kö-telező megadni, ekkor TEXT lesz. A program amost létrehozott people táblába beszúr 3 recor-dot, majd ki is listázza azokat a képernyőre.

1 // 2 . p rog raml i s t a : SQLite ha s zná l a ta Java nye lven23 package cs . t e s t . s q l i t e ;45 import java . s q l . Connection ;6 import java . s q l . DriverManager ;7 import java . s q l . PreparedStatement ;8 import java . s q l . Resu l tSet ;9 import java . s q l . Statement ;1011 public class Test

9


12 {1314 public stat ic void main ( St r ing [ ] a rgs ) throws Exception15 {16 Class . forName ( " org . s q l i t e .JDBC" ) ;17 Connection conn =18 DriverManager . getConnect ion (19 " jdbc : s q l i t e : / home/ tanu la s / s q l i t e / i n y i r i . s q l i t e " ) ;20 Statement s t a t = conn . createStatement ( ) ;21 s t a t . executeUpdate ( "drop␣ tab l e ␣ i f ␣ e x i s t s ␣ people ; " ) ;22 s t a t . executeUpdate ( " c r e a t e ␣ tab l e ␣ people ␣ (name , ␣ occupat ion ) ; " ) ;23 PreparedStatement prep = conn . prepareStatement (24 " i n s e r t ␣ in to ␣ people ␣ va lue s ␣ (? , ␣ ? ) ; " ) ;2526 prep . s e t S t r i n g (1 , "Gandhi" ) ;27 prep . s e t S t r i n g (2 , " p o l i t i c s " ) ;28 prep . addBatch ( ) ;29 prep . s e t S t r i n g (1 , "Turing" ) ;30 prep . s e t S t r i n g (2 , " computers " ) ;31 prep . addBatch ( ) ;32 prep . s e t S t r i n g (1 , "Wittgenste in " ) ;33 prep . s e t S t r i n g (2 , " smartypants " ) ;34 prep . addBatch ( ) ;3536 conn . setAutoCommit ( fa l se ) ;37 prep . executeBatch ( ) ;38 conn . setAutoCommit ( true ) ;3940 Resu l tSet r s = s t a t . executeQuery ( " s e l e c t ␣∗␣ from␣people ; " ) ;41 while ( r s . next ( ) )42 {43 System . out . p r i n t l n ( "name␣=␣" + r s . g e tS t r i ng ( "name" ) ) ;44 System . out . p r i n t l n ( " job ␣=␣" + r s . g e tS t r i ng ( " occupat ion " ) ) ;45 }46 r s . c l o s e ( ) ;47 conn . c l o s e ( ) ;48 }49 }

C# (mono) alapú SQLite adatbázis-kezelés

A .NET a másik fontos környezet, így nemcsoda, hogy innen is használható az SQLite. Aki

ismeri a C# (.NET) adatbáziskezelést, annak a3. programlista valószínűleg csak egyetlen új in-formációt jelent, ami a 15-16 sorokból kiolvas-

10


ható connection URI. A program futtatásánakeredményét a 47-52 sorok között láthatjuk, azazez a példaprogram kilistázza a Java-s példában

már megismert people tábla tartalmát.

1 // 3 . p rograml i s t a : Az SQLite és a C#23 using System ;4 using System . Data ;5 using Mono . Data . S q l i t eC l i e n t ;67 namespace s q l i t e8 {910 class MainClass11 {12 public stat ic void Main( s t r i n g [ ] a rgs )13 {14 Console . WriteLine ( "SQLite␣ S e l e c t : " ) ;15 s t r i n g connec t i onSt r ing =16 "URI=f i l e : / home/ tanu la s / s q l i t e / i n y i r i . s q l i t e , v e r s i on=3" ;17 IDbConnection dbcon ;18 dbcon = ( IDbConnection ) new Sq l i t eConnect i on ( connec t i onSt r ing )19 dbcon .Open ( ) ;20 Console . WriteLine ( "Name\ t \ t \ tJob" ) ;21 Console . WriteLine ( "−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−" ) ;22 IDbCommand dbcmd = dbcon . CreateCommand ( ) ;23 s t r i n g s q l = " s e l e c t ␣∗␣ from␣people " ;2425 dbcmd .CommandText = sq l ;26 IDataReader reader = dbcmd . ExecuteReader ( ) ;27 while ( reader . Read ( ) )28 {29 s t r i n g name = reader . GetStr ing ( 0 ) ;30 s t r i n g occup = reader . GetStr ing ( 1 ) ;31 Console . WriteLine (name + "\ t \ t \ t " + occup ) ;32 }3334 // c l ean up35 reader . Close ( ) ;36 reader = nu l l ;37 dbcmd . Dispose ( ) ;38 dbcmd = nu l l ;39 dbcon . Close ( ) ;40 dbcon = nu l l ;41 }4243 } // end c l a s s44 } // end namespace4546 Futtatás :47 SQLite S e l e c t :

11


48 Name Job49 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−50 Gandhi p o l i t i c s51 Turing computers52 Szabó Almaszedő

2. ábra. Az SQLite és a Lazarus

Lazarus (Open source Delphi)

Az utolsó példa egy kiváló desktop alkalmazásfejlesztő környezetből, a Lazarus-ból való hasz-nálatot mutatja be. Előljáróban 3 fontos URL-tszeretnék kiemelni:

• Lazarus honlap: http://www.lazarus.freepascal.org/

• Magyar lazarus közösség: http://lazarus.freepascal.hu/

• Free Pascal honlap: http://www.freepascal.org/

A Lazarus projekt 1999 februárjában indult az-zal a céllal, hogy megalkossa a 90-es évek nép-szerű Delphi környezetének a nyílt forráskódú

12


3. ábra. SQLite, Lazarus és Pascal emblémák

változatát. Együtt fejlődik a Free Pascal pro-jecttel, ami egy open source Object Pascal imp-lementáció. Ez a vállalkozás mára egy nagyonérett, kiváló környezetet eredményezett, aminekhasználatára bíztatok mindenkit (2. ábra). Akiismeri a Delphi-t, annak a 2. ábra ismerős le-het. Az adatbázisok használatának elve termé-szetesen Lazarusban is ugyanaz. A Form2 mu-tatja, hogy szükségünk van egy connection kom-ponensre, itt adjuk majd meg az inyiri.sqliteadatbázisunk nevét is. Az SQLQuery1 egy se-lect parancsot reprezentál, aminek az eredmé-nye egy tábla. Ezen komponens SQL property-jében lehet megadni a kérdéses select-et, ahogyazt Delphi-ben is megtanultuk korábban.

A Datasource1 komponens a híd az adatfor-rás és a GUI vezérlők között. Most 2 vezérlővan a Form2 -ön: egy grid és az azt kezelő na-vigátor. Az SQLQuery1 komponenst – ahogyláthatjuk – fejlesztési időben is aktívvá tehetjük,ekkor a vezérlőkben megjelennek az élő adatok.A fenti példát nem részletezzük tovább, aki is-meri a Delphi-t, annak ennyi induló muníció iselegendő a használathoz.

Csak röviden megemlítjük a használható tí-pusokat a TSqliteDataset és TSqlite3Datasetosztályok esetén: Integer, AutoInc, String,Memo, Bool, Float, Word, DateTime, Date,Time, LargeInt és Currency.

Az SQLQuery1 SQL property használata:SQL := ’Select * from TABLENAME’.

13

Design patterns Objektumaink tudása – A Decorator minta

2. Objektumaink tudása – A Decorator minta

Folytatjuk a tervezési mintákról szóló cikksorozatunkat, ezúttal a dekorátor minta lehetőségeirőlelmélkedünk. Amikor egy objektumnak csak kicsit kell másképpen viselkednie, akkor természetesötlet az öröklődés használata. Van azonban egy kis gond. Amennyiben túl sok apró eltérésünkvan és azok kombinációja is szerepet játszik, rengeteg osztály jönne létre. Ezen segít ez a tervezésiminta, ahol az objektumaink tudását dinamikusan rakjuk össze. Érdekes következménye ennek aszemléletnek, hogy a csatornák fölötti szűrőkre is remek megoldást ad.

Mire jó ez a minta?

Képzeljük el, hogy van egy osztályunk, ami tudvalamit. Legyen a neve: AlapClass és rendelke-zik néhány publikus metódussal: pm1(), pm2(),... . Nevezzük ezt az osztály használati felüle-tének. Sokszor adódik, hogy ez a felület maradés azért kell egy utód class-t létrehozni, mertkissé (vagy nagyon) változik az a specifikáció,amit az osztály működésétől elvárnánk. Ezeka működésbeli módosítások a tapasztalat sze-rint csak 1 vagy néhány metódust szoktak érin-teni, a többi változatlan marad. Legyen pél-dául M1, M2, M3 3 különféle működési módo-sítási igény, amire M1AlapClass, M2AlapClass,M3AlapClass utód-osztályokat készítettük el ésreménykedünk, hogy mindegyiket akkor és ottfogjuk használni, amikor éppen szükséges. Az-tán kiderül, hogy olyan osztályokra is szükségvan, amik egyszerre több módosítási igénynekis megfelelnek, azaz kellenek ilyen utód osz-tályok is: M1M2AlapClass, M1M3AlapClass,M1M2M3AlapClass. Ez 6 új osztály, pedig csak3 módosítási feltételünk van. A helyzet és azosztályok fölösleges elszaporodásának kezeléséreegy elegáns megoldás a decorator (ismert ne-vei még: díszítő, toldalék, csomagoló, wrapper)minta.

4. ábra. Decorator design pattern

Egy konkrét példa. Legyen az AlapClassmost a Window, ami egy téglalap alakú terü-let részért felelős a képernyőn. Az M1=lehessengörgetni, M2=lehessen naplózni tartalmának aváltozását, M3=lehessen menteni az előző ab-laktartalmat. A Window metódusai elég szűk-számúak, de a példánknak ez most megfelel:show(), hide(), addContent(). Az M1 felté-tel a show() metódusra lesz hatással, ami egyscrollbar-t is elhelyez az ablakon. Az M2 feltételaz addContent()-re hat, ami a metódus napló-zásra való felkészítését jelenti. Az M3 feltétellehetséges, hogy szintén csak az addContent()-re fog hatni. Már itt is lehet érezni, hogy az Mi

feltételeket osztályörökléssel nem lenne gazdasá-

14


gos megvalósítani, főleg amennyiben ezek gazdagkombinációira is szükség van.

Az M1, M2, ... feltételekre gondolhatunk úgyis, mint az alap class egy-egy aspektussal valótudásbővítési igényei.

A decorator minta UML diagramját a 4.ábra mutatja. A következőkben 2 konkrét pél-dán keresztül elmagyarázzuk a használatát és akonstrukció mögött meghúzódó filozófiát. Ezenaz ábrán a Component egy interface (milyen me-tódusok játszanak szerepet), míg az AlapClassneve itt a ConcreteComponent class. A Decora-tor interface és annak implementációi pedig azM1, M2, ... szempontok megvalósításának felelmeg.

A minta használhatóságának alapfeltétele,hogy létezzen egy közös Component interface adekorálandó és a dekoráló osztályok számára,azaz a kliens programot úgy lehessen meg-írni, hogy annak mindegy legyen a megkonstru-

ált Component objektum létrehozásának módja(azaz, hogy mennyi M1, M2, ... feltételt, mintaspektust igyekeztünk figyelembe venni az ob-jektum kliensbeli használatakor).

Első példa: Egy naplózó környezet

A decorator minta bemutatásához nézzünk megegy egyszerű napló szolgáltatást! A közösinterface-t a 4. programlista tartalmazza. A 3interface metódus szemantikája a következő:

• getEntries() – visszaadja a bejegyzések lis-táját. Az egy bejegyzést reprezentáló Dia-ryEntry class-t a 6. programlista mutatja

• newEntry() – egy új naplóbejegyzés elhe-lyezése a naplóba

• getEntry() – az i. naplóbejegyzés lekérésea naplóból.

// 4 . p rograml i s ta : A naplót haszná ló k l i e n s e k ez t// az i n t e r f a c e−t l á t j á k .// A 3 . UML ábra Component i n t e r f a c e−ének f e l e l meg .

package cs . t e s t . dp . decora to r ;

import java . u t i l . L i s t ;

pub l i c i n t e r f a c e IDiary{

pub l i c L i s t<DiaryEntry> ge tEnt r i e s ( ) ;pub l i c void newEntry ( DiaryEntry entry ) ;pub l i c DiaryEntry getEntry ( i n t index ) ;

}

Nézzük meg ezekután azt a Diary class-t, ami egy alapnaplót valósít meg, szerepe a4. ábra ConcreteComponent szerepével egyezikmeg. Az implementációt az 5. programlista tar-

talmazza, annyira triviális, hogy nem is részle-tezzük. Azt azonban kiemeljük, hogy csak azIDiary interface-t használja majd a kliens.

15


// 5 . p rograml i s t a : Az UML diagram ConcreteComponent// s z e r e p kö r é t t ö l t i be . Ez az a lap tudású napló c l a s s és// implementá l ja az IDiary i n t e r f a c e−t ( ahogy a 3 . ábra s z e r i n t k e l l )package cs . t e s t . dp . decora tor ;import java . u t i l . ArrayList ;import java . u t i l . L i s t ;

public class Diary implements IDiary{

List<DiaryEntry> diary = new ArrayList<DiaryEntry >() ;

public List<DiaryEntry> ge tEnt r i e s ( ){

return d iary ;}

public void newEntry ( DiaryEntry entry ){

d iary . add ( entry ) ;}

public DiaryEntry getEntry ( int index ){

return d iary . get ( index ) ;}

}

// 6 . p rograml i s t a : Egy nap l ó b e j e g y z é s t í pu sa

package cs . t e s t . dp . decora tor ;

public class DiaryEntry{

public St r ing t i t l e ;public St r ing content ;public St r ing date ;

public DiaryEntry ( S t r ing t i t l e , S t r ing content , S t r ing date ){

this . t i t l e = t i t l e ;this . content = content ;this . date = date ;

}}

Elérkeztünk oda, hogy meghatározzuk azo-kat az aspektusokat, amiket a naplónknak időn-ként tudnia kell, persze nem mindig. Vegyükőket számba, továbbra is jelöljük az egyes deko-rációkat M betűvel:

• M1: Olyan napló, amit perzisztálni lehetvalamilyen tárolóra

• M2: Olyan napló, ahol a műveletek log-golva lesznek

16


• M3: Olyan napló, ahol minden bejegyzésautomatikusan kap egy időpecsétet

• M4: Olyan napló, aminek a kinézete kisséjobban formázva van

Nézzük először M1-et, amely decorator-nakmost a sokkal kifejezőbb PersistentDiaryDeco-rator nevet adtuk. Ez egy jelölési konvenciótkövet, aminek a szerkezete: <az M konkrétneve><DiaryDecorator>. A kódot a 7. prog-ramlista tartalmazza. Van néhány általános, kö-vetendő szabálya egy ilyen decorator class elké-szítésének:

1. A decorator class-nak implementálnia kella Component interface-t, azaz az IDiary-t. Ez teszi lehetővé majd, hogy a dekoráltobjektumra való hivatkozást tárolhassa elegy IDiary osztálybeli objektum.

2. Kell egy tagváltozó, ami Component inter-face szerepkörű, azaz esetünkben IDiarytípusú. Ezen keresztül tudjuk a dekorá-landó objektum metódusait elérni és „tol-dalék” kódot hozzáadva dekorálni.

3. A decorator class konstruktorában mindigszerepelni kell ez a Component interface

szerepkörű paraméternek, azaz esetünkbenPersistentDiaryDecorator(IDiary diary) akonstruktor kinézete.

4. Meg kell vizsgálni, hogy a közös Compo-nent interface-ben szereplő metódusok kö-zött melyek érintettek ebben az aspektus-ban. Az M1 aspektus perzisztenciát köve-tel, így a listába szúrás mellett egy táro-lóba is menteni kell a bejegyzésünket. Ezazt is jelenti, hogy csak a newEntry() me-tódus most az érintett. A 7. program-listából látható, hogy a perzisztálást csakjelöltük egy képernyőre írással, hiszen nemennek implementálása volt most a célunk,hanem annak megmutatása, hogy hol kéneazt megtenni.

A newEntry() metóduson kívül a többi nem vál-tozik, azaz egyszerűen továbbhívja a konstruk-torban kapott IDiary objektum megfelelő metó-dusait. A newEntry() is meghívja a diary objek-tum newEntry() metódusát, de annak funkcio-nalitását kiegészíti még a perzisztálással. Emi-att a kiegészítés miatt hívják még ezt a mintáttoldaléknak is (vagy hozzácsatolt felelősségnek).

// 7 . p rograml i s t a : Pers i s t en tDiaryDecora torpackage cs . t e s t . dp . decora tor ;


public class Pers i s t entDia ryDecora to r implements IDiary{

IDiary d iary ;

public Pers i s t entDia ryDecora to r ( IDiary d iary ){

this . d ia ry = diary ;}


return d iary . g e tEnt r i e s ( ) ;}

17



d iary . newEntry ( entry ) ;System . out . p r i n t l n ( "The␣ d iary ␣was␣ saved␣ in to ␣ p e r s i s t e n t ␣ s t o r e " ) ;

}


return d iary . getEntry ( index ) ;}

}

Másodjára nézzük meg az M2 aspektust is!Ez a loggolásért felel, ezért adjuk ezt a nevetneki: LoggedDiaryDecorator. Milyen metóduso-kat érint ez az aspektus? A 8. programlistán lát-

ható, hogy mindegyiket, ugyanis minden naplóműveletet loggolni akarunk (ezt is csak jeleztükegy képernyőre írással).

// 8 . p rograml i s t a : LoggedDiaryDecorator



public class LoggedDiaryDecorator implements IDiary{

IDiary d iary ;

public LoggedDiaryDecorator ( IDiary d iary ){



System . out . p r i n t l n ( " I t ␣ i s ␣ logged . ␣GET␣ L i s t : ␣" ) ;return d iary . g e tEnt r i e s ( ) ;

}


System . out . p r i n t l n ( " I t ␣ i s ␣ logged . ␣New␣ entry : ␣" + entry . t i t l e ) ;d ia ry . newEntry ( entry ) ;

}


System . out . p r i n t l n ( " I t ␣ i s ␣ logged . ␣GET␣ entry : ␣" ) ;return d iary . getEntry ( index ) ;

}}

18


Az M3 az esetlegesen igényelt időpecsételé-sért felel, ezért a neve TimeStampedDiaryDeco-

rator lesz. Látható, hogy csak a newEntry() me-tódust érinti, azaz csak ő kap toldalékot.

// 9 . p rograml i s t a : TimeStampedDiaryDecorator


import java . t ex t . SimpleDateFormat ;import java . u t i l . Calendar ;import java . u t i l . L i s t ;

public class TimeStampedDiaryDecorator implements IDiary{

IDiary d iary ;

public TimeStampedDiaryDecorator ( IDiary d iary ){



return d iary . g e tEnt r i e s ( ) ;}


entry . content += "\nTime : ␣"+getNow ( ) + "␣\n" + entry . content ;d ia ry . newEntry ( entry ) ;

}


return d iary . getEntry ( index ) ;}

/∗∗∗ This method w i l l update the i n t e r n a l nowString data f i e l d∗/

private St r ing getNow ( ){

Calendar ca l endar = Calendar . g e t In s tance ( ) ;java . u t i l . Date d = null ;d = ca l endar . getTime ( ) ;SimpleDateFormat formatte r = new SimpleDateFormat ( "yyyyMMddHHmm" ) ;return f o rmatte r . format (d ) . sub s t r i ng (2 , 1 2 ) ;

}}

19


Az utolsó, M4 aspektus – igény esetén – egykis formázással látja el naplónkat, így a neve a10. programlista alapján FormattedDiaryDeco-

rator lett. A „toldalékolásban” érintett metódu-sok nyilván a getEntries() és getEntry() lekérőmetódusok.

// 10. p rograml i s t a : FormattedDiaryDecorator



public class FormattedDiaryDecorator implements IDiary{

IDiary d iary ;

public FormattedDiaryDecorator ( IDiary d iary ){



System . out . p r i n t l n ( "Format␣ the ␣whole␣ d iary " ) ;return d iary . g e tEnt r i e s ( ) ;

}


d iary . newEntry ( entry ) ;}


System . out . p r i n t l n ( "Format␣ the ␣ reques ted ␣Entry" ) ;return d iary . getEntry ( index ) ;

}}

Elkészítettük az összes előre elképzelt deco-rator class-t. Látható a filozófia, ahogy a be-ágyazott IDiary típusú diary objektumot – amita konstruktor vesz át nekünk – hogyan hívjukvissza, majd igény esetén toldalékolunk.

Próbáljuk ki az eddigi eredményeinket, amita 11. programlista mutat. A lényeget a 9. sor-ban láthatjuk, ahogy felépítjük a nekünk szüksé-ges IDiary objektumot, ami így most a loggolástés időpecsételést is tudni fogja.

1 // 11. p rograml i s t a : Tesztprogram23 package cs . t e s t . dp . decora tor ;45 public class TestDecorator

20


6 {7 public stat ic void main ( St r ing [ ] a rgs )8 {9 IDiary d1 = new TimeStampedDiaryDecorator (new LoggedDiaryDecorator ( new Diary ( ) ) ) ;1011 d1 . newEntry ( new DiaryEntry ( "Első ␣ entry " , " b1111 lab la " , " 2010 .01 . 10 " ) ) ;12 d1 . newEntry ( new DiaryEntry ( " 2 . ␣ entry " , " b222 lab la " , " 2010 .01 . 10 " ) ) ;13 d1 . newEntry ( new DiaryEntry ( " 3 . ␣ entry " , " b3333 lab la " , " 2010 .01 . 10 " ) ) ;1415 System . out . p r i n t l n ( d1 . getEntry ( 2 ) . content ) ;16 }17 }

Második példa: A Decorator, mintFilter

A decorator minta lehetőséget ad az adat vagycsatornafilterezés (szűrők) megvalósítására. AJava nyelv java.io könyvtára is ezt a mintát al-kalmazza. A következőkben mindezt egy példánérdemes megérteni, ami természetesen a deco-rator mintát követi, azonban a szűrési funkció

kihangsúlyozása miatt ilyenkor a névkonvenciószerint a Decorator szót mindenütt a Filter szószokta helyettesíteni.

A feladat a következő: Van egy olyan csator-nánk, amin Stringek sorozata jön és az egyetlencsatorna-művelet a getLine(), azaz a következőString megszerzése. A „Component” szerepkörűinterface most az IFuzer lesz, amit a 12. prog-ramlista mutat.

1 // 12. p rograml i s t a : A közös komponens i n t e r f a c e23 package cs . t e s t . dp . decorator2 ;45 public interface IFuzer6 {7 public St r ing getL ine ( ) ;8 }

Az egyes aspektusok – amiket itt inkább szű-rőknek nevezünk – legyenek a következőek:

• M1: ReplaceFuzerFilter – a bejövő sorokbizonyos karaktereit más karakterekre cse-réli

• M2: MirrorFuzerFilter – a bejövő Stringe-ket visszafelé olvasva adja vissza

• M3: ConcatFuzerFilter – a következő n dbsort összekapcsolja és azt adja vissza

• M4: CharByCharFuzerFilter – a csatornát1 karakteres String-enként olvassa fel

• M5: CounterFuzerFilter – a csatorna kö-vetkező sora helyett annak hosszát adjavissza, mint String

• M6: FlushFuzerFilter – a teljes csatornatartalmat 1 db String-ként adja vissza

Egy lehetséges „ConcreteComponent” szerepkör-ben lévő osztály példánkban a Fuzer class (13.programlista). Itt a csatornát belül egy Stringtömb reprezentálja, de természetesen ez lehetneegy text file vagy bármi más is (például HTTPresponse). A getLine() felolvassa az összesStringet (minden hívásnál 1 darabot), amennyi-ben már üres lett a csatorna, úgy null -t advissza.

21


1 // 13. p rograml i s t a : Fuzer23 package cs . t e s t . dp . decorator2 ;45 public class Fuzer implements IFuzer6 {7 St r ing [ ] l i n e s ;8 int index = 0 ;910 public Fuzer ( S t r ing [ ] l i n e s )11 {12 this . l i n e s = l i n e s ;13 }1415 public St r ing getL ine ( )16 {17 i f ( index < l i n e s . l ength )18 {19 return l i n e s [ index++];20 }21 else22 {23 return null ;24 }25 }26 }

Tekintsük át a filterek implementációjátegyenként. Könnyű dolgunk van annak a meg-ítélésében, hogy az egyes aspektusok mely metó-dusokat érintik, hiszen csak a getLine() az egyet-len, azt pedig kötelezően érinti, hiszen ha nemígy lenne, akkor a Filter sem csinálna semmiújat.

A 14. programlista mutatja a ReplaceFuzer-Filter -t. Az itteni getLine() annyit tesz hozzá

(azaz annyit toldalékol vagy díszít) az eredeti-hez, hogy lekérve az eredetit, mindig áteresztiazt egy replace filteren, amit a visszaadott got-Line.replaceAll(mit, mire) sor mutat. A konst-ruktorban azt is láthatjuk, hogy nem kell mindigcsak a kötelezően megadandó közös interface-t –azaz itt az IFuzer -t – átvenni, lehet több para-méter is. Itt például értelemszerűen a mit ésmire paraméterek ilyenek.

1 // 14. p rograml i s t a : Rep laceFuzerF i l t e r23 package cs . t e s t . dp . decorator2 ;45 public class Rep laceFuze rF i l t e r implements IFuzer6 {7 IFuzer l i n e ;8 S t r ing mit , mire ;910 public Rep laceFuze rF i l t e r ( IFuzer l i n e , S t r ing mit , S t r ing mire )11 {12 this . l i n e = l i n e ;

22


13 this . mit = mit ;14 this . mire = mire ;15 }1617 @Override18 public St r ing getL ine ( )19 {20 St r ing gotLine = l i n e . getL ine ( ) ;21 i f ( gotLine == null ) return null ;22 return gotLine . r e p l a c eA l l (mit , mire ) ;23 }24 }

Az M2 Filter a tükrözés, azaz a kapott sortvisszafelé olvasva adjuk vissza, ahogy ezt a 15.programlista is mutatja. Itt semmilyen műkö-dést definiáló további paraméter nem szükséges,a feladat egyértelmű, ezért a konstruktor is csak

az IFuzer paramétert kapja meg. A toMirror()private metódus végzi a tükör sztring előállítást,amit az itteni getLine() a „toldalék” részben foghasználni.

1 // 15. p rograml i s t a : A tük rö z é s23 package cs . t e s t . dp . decorator2 ;45 public class Mir ro rFuze rF i l t e r implements IFuzer6 {7 IFuzer l i n e ;89 public Mir ro rFuze rF i l t e r ( IFuzer l i n e )10 {11 this . l i n e = l i n e ;12 }1314 @Override15 public St r ing getL ine ( )16 {17 St r ing gotLine = l i n e . getL ine ( ) ;18 i f ( gotLine == null ) return null ;19 return toMirror ( gotLine ) ;20 }2122 private St r ing toMirror ( S t r ing s )23 {24 S t r i ngBu f f e r sb = new St r i ngBu f f e r ( "" ) ;25 for ( int i=s . l ength ()−1; i >=0; i−−)26 {27 sb . append ( s . charAt ( i ) ) ;28 }29 return sb . t oS t r i ng ( ) ;30 }31 }

23


A következő, M3 aspektusú filter kicsit más,mint az előző M1 és M2, ugyanis ez már nemcsak az aktuális, örökölt soron végez valamilyentranszformációt, hanem a paraméterként meg-adott következő sorokon (a számát a koteg para-méter adja meg) dolgozva, „összeragasztja” azo-

kat. A 16. programlista egy olyan filtert mutat,aminek a konstruktorában azt is megadtuk, hogyhány sort ragasszon össze az ő getLine() metó-dusa. Persze elképzelhető, hogy kevesebbet fogkonkatenálni, amennyiben a csatorna már nemrendelkezik koteg számú sorral.

1 // 16. p rograml i s t a : Több s o r t v i s s z adó f i l t e r23 package cs . t e s t . dp . decorator2 ;45 public class ConcatFuzerFi l te r implements IFuzer6 {7 IFuzer l i n e ;8 int koteg ;910 public ConcatFuzerFi l te r ( IFuzer l i n e , int koteg )11 {12 this . l i n e = l i n e ;13 this . koteg = koteg ;14 }1516 @Override17 public St r ing getL ine ( )18 {19 S t r i ngBu f f e r sb = new St r i ngBu f f e r ( "" ) ;20 St r ing gotLine = l i n e . getL ine ( ) ;21 int cnt = 1 ;22 i f ( gotLine == null ) return null ;23 while ( gotLine != null )24 {25 sb . append ( gotLine ) ;26 i f ( cnt == koteg ) return sb . t oS t r i ng ( ) ;27 gotLine = l i n e . getL ine ( ) ;28 cnt++;29 }30 return sb . t oS t r i ng ( ) ;31 }323334 }

A 17. programlista által mutatott filter ka-rakterekre szedi szét a teljes csatorna tartalmat.A működése egyszerű, csak akkor hívja meg azörökölt getLine()-t, ha elfogyott az aktuális sorösszes karaktere. Amennyiben az örökölt sorol-

vasó null -t ad vissza, úgy ezen filter sorolvasójais ezt továbbítja a hívónak, jelezve, hogy elfogy-tak a karakterek.

24


1 // 17. p rograml i s t a : 1 sor = 1 karak t e r23 package cs . t e s t . dp . decorator2 ;45 public class CharByCharFuzerFilter implements IFuzer6 {7 IFuzer l i n e ;8 S t r ing gotLine ;9 int index = 0 ;1011 public CharByCharFuzerFilter ( IFuzer l i n e )12 {13 this . l i n e = l i n e ;14 gotLine = l i n e . getL ine ( ) ;15 }1617 @Override18 public St r ing getL ine ( )19 {20 i f ( gotLine == null ) return null ;21 i f ( gotLine . l ength ( ) > index )22 {23 return "" + gotLine . charAt ( index++);24 }25 else26 {27 gotLine = l i n e . getL ine ( ) ;28 i f ( gotLine == null ) return null ;29 index = 0 ;30 return "" + gotLine . charAt ( index++);31 }32 }33 }

A 18. programlista talán a legegyszerűbbszűrők egyike. A getLine() az aktuális sor ka-

rakterekben mért méretét adja vissza.

// 18 . p rograml i s ta : egy sor = a hossza karakterekben

package cs . t e s t . dp . decorator2 ;

pub l i c c l a s s CounterFuzerFi l t e r implements IFuzer{

IFuzer l i n e ;

pub l i c CounterFuzerFi l t e r ( IFuzer l i n e ){

t h i s . l i n e = l i n e ;

25


}

@Overridepub l i c S t r ing getLine ( ){

St r ing gotLine = l i n e . getL ine ( ) ;i f ( gotLine == nu l l ) r e turn nu l l ;r e turn "" + gotLine . l ength ( ) ;

}}

A 19. programlista szűrője az input sorokcsatornájáról felolvassa az összes sort és a get-Line() egyetlen sorként adja vissza. Ez azt is

jelenti, hogy itt a getLine() a 2. hívástól mármindig a null értéket fogja visszaadni.

1 // 19. p rograml i s t a : Egyszere v i s s z a a d j a a t e l j e s c sa to rná t23 package cs . t e s t . dp . decorator2 ;45 public class FlushFuze rF i l t e r implements IFuzer6 {7 IFuzer l i n e ;8 boolean endOfChannel = fa l se ;910 public FlushFuze rF i l t e r ( IFuzer l i n e )11 {12 this . l i n e = l i n e ;13 }1415 @Override16 public St r ing getL ine ( )17 {18 i f ( endOfChannel ) return null ;19 S t r i ngBu f f e r sb = new St r i ngBu f f e r ( "" ) ;20 St r ing gotLine = l i n e . getL ine ( ) ;21 while ( gotLine != null )22 {23 sb . append ( gotLine ) ;24 gotLine = l i n e . getL ine ( ) ;25 }26 endOfChannel = true ;27 return sb . t oS t r i ng ( ) ;28 }293031 }

26


Az eddigiekben létrehoztunk több szűrőt,hogy érzékeltessük a lehetőségeket és azok imp-lementációjában jártasabbak legyünk. Most be-fejezzük ezt a tevékenységet és megnézzük egyteszt program segítségével a szűrőink haszná-latát. Megjegyezzük, hogy a szűrők számá-nak csak a képzelet és a racionalitás szab ha-tárt. Létrehozhattuk volna például az Upper-caseFuzerFilter, HuEnFuzerFilter, stb... filtere-ket, amennyiben a feladatban fontos a nagybe-tűs kezelés vagy a magyarról angolra fordítás.A tesztprogramot, azaz a Filterek használatát a

20. programlista mutatja. Fontos itt is észre-venni, hogy az f változó IFuzer típusra van fel-véve, hiszen ez az egyik lényege a tervezési min-tának. Az aktuális változat futási eredményétis láthatjuk. A CounterFuzerFilter mindegyiksort annak hosszával helyettesít, ami ezt ered-ményezné, ha csak ő működne: 865544. Mind-egyik számjegy egy-egy getLine() hívás eredmé-nye. Itt azonban van egy másik szűrő is, a Con-catFuzerFilter. Ez kettesével kötegeli a sorokat,így kapjuk meg a látható futási eredményt.

1 // 20. p rograml i s t a : A F i l t e r−ek t e s z t e l é s e23 package cs . t e s t . dp . decorator2 ;45 public class Test6 {78 public stat ic void main ( St r ing [ ] a rgs )9 {10 St r ing [ ] s = {" abcdefgh " , " ik l lmn " , " pqrs t " , "12345" , "6789" , "0000" } ;1112 // IFuzer f = new MirrorFuzerFi l t e r (13 new Rep laceFuze rF i l t e r (new Fuzer ( s ) , "alma" , " körte " ) ) ;14 // IFuzer f = new MirrorFuzerFi l t e r (new Fuzer ( s ) ) ;15 IFuzer f = new ConcatFuzerFi l te r (new CounterFuzerFi l t e r ( new Fuzer ( s ) ) , 2 ) ;161718 St r ing l i n e ;19 while ( ( l i n e = f . getL ine ( ) ) != null )20 {21 System . out . p r i n t l n ( l i n e ) ;22 }2324 }25 }2627 Futás i eredmény :28 8629 5530 44

A példánkban lévő Fuzer class (ami a Conc-reteComponent szerepkörben van) egy Stringtömbből veszi a sorokat. Persze készíthetnénk

egy olyan osztályt is, ami textfile-ból veszi. Le-hetne ennek a neve például: TextFileFuzer, amipersze implementálja az IFuzer interface-t, a

27


konstruktora paraméterként kapná a textfile ne-vét. Ennek a design patterneknek a nagy előnye,hogy filtereink minden további nélkül itt is hasz-nálhatóak maradnak.

Összefoglalás

Áttekintettük a decorator mintát. Befejezésülszeretnénk kiemelni, hogy a gyakorlatban sok

helyen lehet ezeket használni. A Java környe-zetben főleg az java.io csomag csatorna megva-lósításaiban vagy a GUI framework-ök környé-kén használatosak. Példa: OutputStream out =new DataOutputStream (new FileOutputStream( "test.txt"));

28

Java A Java biztonsági rendszere

3. A Java biztonsági rendszere - Authentikáció, Authorizáció

Indítunk egy cikksorozatot, ami a Java biztonsági kérdéseivel és megoldásaival foglalkozik. Azelső rész témája annak a vizsgálata, hogy ez a technológiai környezet milyen módon oldja mega kliensek azonosítását és jogosultság kezelését. Elöljáróban szeretnénk kiemelni, hogy a Javais a jól ismert PAM (Pluggable Authentication Module) rendszert alkalmazza – nem véletlenül.Egyrészt ezt a megoldást a SUN fejlesztette ki a Solaris operációs rendszerhez, másrészt a Java isa SUN gyermeke. Megjegyezzük, hogy a PAM rendszer meglehetősen elterjedt, például a Linuxdisztribúciók – a szabványosság miatt – is ezt használják.

Miről fog szólni a cikksorozat?

A több részből álló cikksorozatunk egy fontos té-mát szeretne górcső alá venni: a biztonságot. Se-gítségül a Java környezetet hívjuk, így gyakorla-tilag a Java biztonsági megoldások áttekintésérőlírunk. A mai korszerű szoftverek nem elszigetel-ten működnek egymástól, sőt inkább együttmű-ködnek. Egy elosztott rendszerre maga az Inter-net a legjobb példa, de a modern többrétegű al-kalmazások is hasonló modellt követnek. Milyenfeladatai vannak a biztonságnak? Vegyünk pél-daképpen egy képzeletbeli rendszert: repülőjegyfoglalás az Interneten. Nézzük meg milyen biz-tonsági problémák adódhatnak, azaz miket kellmegoldanunk:

1. Utólagosan meghamisított tranzak-ció (azaz jegyfoglalás és fizetés) előál-lításának veszélye. Ez érintheti a jegy-vásárlót és a jegyszolgáltatót is, ugyanismindkét fél rosszindulata lehetséges (pél-dául más típusú jegyre vagy dátumra ha-misítás). Megoldás: a tranzakció digitálisaláírása és időpecsételése.

2. Más nevében feladott tranzakciók,azaz példánkban a nevünkben rendel va-laki repülőjegyet. Megoldás: a kölcsönöshitelesítés (authentication).

3. Tranzakciók lehallgatása, módosí-tása, törlése. Például valaki drágább

jegyre módosítja vagy törli menet közbenaz igényünket. Megoldás: a tranzakciórejtjelezése.

4. A szolgáltató letegad egy tranzak-ciót, azaz esetünkben úgy hisszük, hogylesz repülőjegyünk, de utólag ezt az el-adó letagadja. Megoldás: digitális, alá-írt és időpecséttel ellátott nyugta. Ez aztjelenti, hogy a tranzakcióról a szolgáltatóegy nyugtát (visszaigazolást) készít, amitaláírásával és időpecsétjével hitelesít.

5. Az elindított hálózati program nemaz eredeti. Megoldás: a program eredeté-nek vizsgálata úgy, hogy azt a gyártó digi-tálisan aláírja, a kliens pedig tárolja, hogymely aláírókban bízik meg.

6. A program különféle funkcióit, illetve azamögött lévő erőforrásokat (a programunkegy szolgáltatása, adatbázis, hálózati szol-gáltatás, nyomtató, képernyő, stb...) el-térő jogosultsággal használhatják a klien-seink. Megoldás: jogosultság kezelés ésaccess management használata (authorizá-ció).

A cikksorozatban a fenti szempontokat fogjukvégigtekinteni. Az első cikkben a Java JAASrendszer alapjait nézzük meg.

29


3.1. Alapfogalmak

Mielőtt elmerülnénk a Java alapú hitelesítés vi-lágában, fontos megértenünk néhány alapfogal-mat.

1. Meghatározás (Authentikáció). Az au-thentikáció (más szóval: hitelesítés) egy állítóla-gos személyazonosság ellenőrzésének folyamata,mely során egy publikus (példa: username) és egyprivát (példa: password) információdarab alap-ján dől el az érvényesség (azonosság) úgy, hogya hitelesítő rendszer ezeket összehasonlítja a sa-ját adatbázisában tárolt információval.

A privát és publikus információkat hitelesí-tési adatoknak nevezzük, amelyek a gyakorlat-ban 3 fő formában szoktak megjelenni: egy pass-word, egy birtokláson alapuló eszköz (hardver-kulcs) vagy egy biometria azonosítás (ujjlenyo-mat, retina, ...).

A Java PAM megvalósítás a JAAS (Java Au-thentication and Authorization Service) része,ami a Java 1.4 óta kötelező része az SDK-nak.A központi eleme a LoginModule interface, amiegy authentication képes objektum felülete.

Függetlenül attól, hogy egy program haszná-lója természetes személy vagy egy másik prog-ram, az mindig egy entity (entitás)1nevében fut,amely rendelkezik valamilyen felismerhető azo-nosítóval (pontosabban: azonosító halmazzal),azaz identitása (identity=azonosság) van. Ez azentity általában maga a felhasználó, egy másikprogram, vagy egy szervezet, csoport lehet.

2. Meghatározás (Subject). A Subject(alany, a hitelesítés célszemélye) az Entity (en-titás) objektum reprezentálása a programban.

Általában 1 entity több identity-vel ren-delkezhet, amelyekre példák: azonosítója, nickneve, e-mail címe, csoportjainak a nevei, szemé-lyi kódjai, stb.

3. Meghatározás (Principal). A principalaz identity fogalom programbeli objektum-reprezentációja. Egy Subject-hez természetesentöbb fajta Principal tartozhat.

A Principal interface – ahogy nemsokáralátni is fogjuk – meglehetősen egyszerű, hi-szen feladata leginkább csak az, hogy a kü-lönféle identity típusok neveit, értékeit tárolja(példa: nick: morci, törzsszám: 2345634, e-mail:[email protected], ...).

4. Meghatározás (Credential). Credential(rokonértelmű szavak: tanúsítvány, igazolvány,igazoló valami). A való világban ilyen a sze-mélyi igazolvány, útlevél, stb. Ezek hosszabbidejűek, de lehet például a megszerzett színház-jegy, tömegközlekedési jegy. A Credential min-dig valamit bizonyít. Lehet ujjlenyomat, kép(biometrikus információk). Sokszor jelszó, vagymás hitelesítési eszköz vagy megbízólevél. A hi-telesítést adó Credential tehát egy adategyüttes,aminek általában publikus és private (csak a hi-telesítést kérő alany ismeri)része is van. Példáulegy user/password alapú hitelesítésnél a user-name a publikus, a password pedig a privát részea Credential-nak.

Authentication alatt tehát egy entity azono-sítását értjük, ami a gyakorlatban az identitása-inak meghatározását jelenti. Ez más szavakkalazt jelenti, hogy az entity (Subject, alany) a si-keres azonosítás után (amihez Credential -t hasz-nál) összekapcsolódik az általunk ismert összesidentity azonosítókkal (Principálokkal, identitá-sokkal), azaz olyan nevekkel, ami az alanyra jel-lemző és így tőle bármikor lekérdezhető.

1Valaminek a létszerűsége, ahol a hangsúly azon van, hogy létezik valami, és nem azon, hogy mi létezik.

30


3.2. A kliens hogyan használ egyJAAS LoginModule-t?

Ebben a pontban röviden tisztázzuk, hogy mi-képpen tudunk használni egy más által már el-készített LoginModule-t. Mit jelent egyáltalánaz, hogy bejelentkeztünk? A JAAS szoftveresfelépítését a 5. ábra mutatja.

5. ábra. A JAAS architecture

Az ábráról leolvasható, hogy alkalmazása-ink a LoginContext osztály segítségével tartjáka kapcsolatot a JAAS hitelesítő, elérés és jogo-sultságkezelő alrendszerrel. A LoginModule classpedig a hitelesítést adó háttér modulokkal mű-ködik együtt. Ez azt is jelenti, hogy a Login-Module egy infrastruktúra szoftver komponens,azzal emiatt nem is kerül vele kapcsolatba az a

szakember, aki az alkalmazást készíti. Persze azis lehet, hogy szükséges egy új hitelesítő module-t is készíteni, de akkor azt is csak a LoginCon-text class-on keresztül fogjuk használni. A javaaz 1.4 verzió óta több előre elkészített, beépítettLoginModule-t is tartalmaz:

• JndiLoginModule: ezen keresztül useradatbázisként egy tetszőleges JNDI (JavaNaming and Directory Interface) kompati-bilis címtár használható

• Krb5LoginModule: Az ismert Kerberosprotocol alapján működik

• NTLoginModule: Az operációs rendszertőlveszi át az azonosított user-t

• UnixLoginModule: Az operációs rendszer-től veszi át az azonosított user-t

Az utolsó 3 LoginModule használatát ezen cikkkésőbbi részében a gyakorlatban is be fogjuk mu-tatni.

Amikor egy LoginModule-t használni szeret-nék, akkor a java virtuális gépnek ezt meg kellmondanunk néhány egyszerű konfigurációs lé-pésben, amit szintén a 3.2 pontban mutatunkmeg. Most fogadjuk el, hogy bekonfiguráltunkegyet és szeretnénk használni. Ennek módját a21. programlista mutatja.

1 // 21. p rograml i s t a : Be j e l e n t k e z é s egy LoginModule s e g í t s é g é v e l23 LoginContext l c = new LoginContext ( "MyExample" ) ;4 try5 {6 l c . l o g i n ( ) ;7 } catch ( LoginException )8 {9 // Authen t i ca t ion f a i l e d .10 }11 // Authen t i ca t ion su c c e s s f u l , we can now cont inue .12 // We can use the re turned Sub j e c t i f we l i k e .13 Subject sub = l c . ge tSub jec t ( ) ;14 Subject . doAs ( sub , new MyPrivi legedAction ( ) ) ;

31


A 3. sorban megszerezzük a LoginContextobjektumot, amit a MyExample paraméterrelgyártunk le. Ez a LoginModule konfigurációneve is egyben, így itt véglegesül, hogy melyikPAM modul szerint akarjuk a hitelesítést elvé-gezni. Ezután a 6. sorban tehetünk egy pró-bát a bejelentkezésre. Amennyiben ez sikerültés nem dobódik kivétel, úgy a hitelesítés és egy-ben a bejelentkezésünk is sikerült. A 13. sorbanmár megtehetjük, hogy lekérdezzük a Subject-et,azaz a bejelentkezett entity-t (egyedet, ami egyszemély vagy egy másik program), amelyen ke-resztül az alkalmazásunk számára egyértelművé

válik, hogy éppen ki használja ezen a kapcsola-ton keresztül az alkalmazást. Emiatt a 14. sor-ban látható authorizációs műveletet is képessekvagyunk immár elvégezni. A folyamatot az 6.ábrán lévő szekvencia-diagram érzékelteti, érde-mes áttanulmányozni.

Összefoglalásként megállapíthatjuk, hogy ak-kor vagyunk bejelentkezve, ha a futó progra-munk tartalmaz egy Subject objectumot, ame-lyen keresztül lekérhetjük a fontosabb tulajdon-ságainkat, azaz a principáljainkat (például melynevű csoportok tagjai vagyunk, milyen a szerep-körünk vagy éppen mi a lakcímünk, stb...).

6. ábra. A JAAS alapú hitelesítés folyamata

32


3.3. Hogyan készítsünk el egy sa-ját JAAS LoginModule-t?

A hitelesítési folyamat használatának megérté-sét mélyítsük úgy el, hogy készítünk egy sajátLoginModule-t! A neve legyen TestLoginModuleés a hitelesítésnél használt credential most egye-dül csak egy titkos jelszó lesz. Emlékezzünk rá,hogy a hitelesítéshez használt credential-ok töb-ben lehetnek, egy részük publikus, más részükprivát, azaz titkos.

A JAAS környezet az előzőekben már de-

finiált 2 fontos fogalomhoz (Principal és Sub-ject) reprezentációt is készített. Nézzük előszöra Principal -t, ami triviális módon egy interface,ugyanis bármelyik objektum lehet ebben a sze-repben, amely identity-t tud adni magáról. Abeépített Java Principal interface-t a 22. prog-ramlista mutatja, azaz látható, hogy ez lényegé-ben tényleg csak egy névvel rendelkező objektuminterface-e, ahol az összehasonlítás és hash táb-lában való tárolhatóság a követelmény. Bármilehet principál, ami ezt tudja, ami egy nevet tudtárolni a Subject-ről.

1 // 22. p rograml i s t a : A Pr inc i pa l i n t e r f a c e23 package java . s e c u r i t y ;45 public interface Pr i n c i pa l6 {7 public boolean equa l s ( Object another ) ;8 public St r ing toS t r i ng ( ) ;9 public int hashCode ( ) ;10 public St r ing getName ( ) ;11 }

A Principal interface csak a legalapvetőbbdolgot követeli meg az őt implementáló objek-tumtól. Legfontosabb a getName() metódus, hi-szen ez adja vissza az azonosság konkrét értékét,mint karaktersorozatot. A Principal gyakorlati-lag egy azonosító konkrét értékének eltárolásáraképes osztály. Egy új principal class készítésénéljavasolt egy elnevezési konvenció, ami ilyen for-mátumú: <TTT>Principal, ahol a TTT a prin-cipal típusa. Például egy e-mail jellegű principáljavasolt class neve: EMailPrincipal.

A Java-ban az entity-t a final Subject osz-tály valósítja meg, azaz a programozó ezen márnem változtathat. A metódusai közül néhány aprincipál-okhoz (getPrincipals()) és credential-okhoz való hozzájutást támogatja. A másiknagy metóduscsoportja az authorizációt segíti

(doAs() metódusok), de erre csak később térünkki.

Tekintettel arra, hogy egy saját, új Login-Module-t szeretnénk készíteni, ezért nézzük megennek a „gyári” interface-ét is, amit a 23. prog-ramlista mutat!

33


// 23. p rograml i s t a : LoginModule i n t e r f a c e

package javax . s e c u r i t y . auth . s p i ;

import java . u t i l .Map;

import javax . s e c u r i t y . auth . Subject ;import javax . s e c u r i t y . auth . c a l l b a ck . Cal lbackHandler ;import javax . s e c u r i t y . auth . l o g i n . LoginException ;

public interface LoginModule{

// Megszak í t j a az a z ono s í t á s i f o l yamato tboolean abort ( ) throws LoginException ;// Jóváhagyja az a z ono s í t á s i f o l yamato tboolean commit ( ) throws LoginException ;// I n i c i a l i z á l j a a LoginModule−tvoid i n i t i a l i z e ( Subject sub ject , Cal lbackHandler handler ,

Map<Str ing , ?> sharedState , Map<Str ing , ?> opt ions ) ;// Ez i n d í t j a e l a b e j e l e n t k e z é s i f o l yamato tboolean l o g i n ( ) throws LoginException ;// K i j e l e n t k e z é sboolean l ogout ( ) throws LoginException ;

}

Az egyes metódusok szerepét rövid megjegy-zésekben adtuk meg a 23. programlistán. EgyPAM azonosító modul olyan objektum, ami imp-lementálja ezt a LoginModule interface-t.

Egy LoginModule konfigurációját egyolyan külső config file-ba lehet elhe-lyezni, aminek a pontos elérhetőségét ajava.security.auth.login.config Java környezetiváltozó mondja meg. Ez azért ilyen közvetett,mert a LoginModule-t (PAM modult) sohasemhasználjuk közvetlenül, helyette a programjain-ban a LoginContext osztály objektumaival dol-

gozunk, amit a 21. programlistán láthattunk,de ebben a példában a későbbiekben is bemuta-tunk.

Most „pihenésképpen” készítsünk el egyPrincipal-t, aminek a neve legyen TestPrinci-pal ! Minden komolyabb filozófiát mellőzve, ezaz „azonosság tároló” csak visszaadja a nevet,amivel létrehoztuk. A megvalósítása egyszerű,ahogy a 24. programlistán is látható. Az osztályalig tud annál többet, mint a konstruktorban ka-pott és eltárol név visszaadása a getName() me-tódussal.

1 // 24. p rograml i s t a : Egy t e s z t Pr inc i pa l23 package t e s t . j a a s ;45 import java . s e c u r i t y . P r i n c i pa l ;

34


67 public class Tes tPr inc ipa l implements Pr in c i pa l8 {9 private f ina l St r ing name ;1011 public Tes tPr inc ipa l ( S t r ing name)12 {13 i f (name == null )14 {15 throw new I l l ega lArgumentExcept ion ( "Nul l ␣name" ) ;16 }17 this . name = name ;18 }1920 public St r ing getName ( )21 {22 return name ;23 }2425 public St r ing toS t r i ng ( )26 {27 return "Az␣ ident i tásom : ␣ : ␣" + name ;28 }2930 public boolean equa l s ( Object obj )31 {32 i f ( obj == null )33 {34 return fa l se ;35 }36 i f ( obj == this )37 {38 return true ;39 }40 i f ( ! ( obj instanceof Tes tPr inc ipa l ) )41 {42 return fa l se ;43 }44 Tes tPr inc ipa l another = ( Tes tPr inc ipa l ) obj ;45 return name . equa l s ( another . getName ( ) ) ;46 }4748 public int hasCode ( )

35


49 {50 return name . hashCode ( ) ;51 }52 }

Az azonosítási folyamat egy párbeszéd azazonosítást végző és az azonosítást kérő között.Ezt szokták „chat scenario”-nak (chat script) isnevezni és ahhoz hasonlít, ahogy az igazoltatórendőr (esetünkben a LoginModule) kérdezgetés várja rá a válaszokat. Ezeknek a válaszok-nak az absztrakcióját valósítja meg a Callback-Handler interface (25. programlista), aminekegyetlen handle() metódusa a kérdésre adott vá-laszreakció. Például a „kérem a jelszót” kér-désre, a jelszó megszerzése valahonnan (például

a konzolról). Az 25. programlistán látható az„üres” Callback interface is, aminek csak az a fel-adata, hogy a meghívandó visszahívások tömb-jét a handle() metódus átvehesse. A Calback -ra ezek szerint semmilyen megkötés nincs, majdlátni fogjuk a példa CallbackHandler -nél, hogymindegyik callback-en végig kell menni és azokatminden ágon egyedileg kezelni. A példánkbancsak a NameCallback class szerepel a for ciklus-ban, így a „minden” esetünkben most csak egy 1elemű callback tömböt jelent.

1 // 25. p rograml i s t a : A Cal lbackHand ler i n t e r f a c e23 package javax . s e c u r i t y . auth . c a l l b a ck ;45 public interface CallbackHandler6 {7 void handle ( Cal lback [ ] c a l l b a c k s )8 throws java . i o . IOException , UnsupportedCallbackException ;9 }1011 package javax . s e c u r i t y . auth . c a l l b a ck ;12 public interface Cal lback { }

Írjunk egy TestCallbackHandler nevű osz-tályt és remélhetőleg minden megvilágosodik!A forráskódját a 26. programlista mutatja (ésa hozzá használt NameCallback class-t, amit a27. programlista tartalmaz). A NameCallbackegyébként csak egy egyszerű 3 mezős tároló osz-tály, ahol a mezők szerepét a kommentekbe ír-

tuk be. A TestCallbackHandler.handle() ese-tünkben annyit csinál, hogy az átvett Name-Callback paraméter alapján kiteszi a konzolra aprompt-ot és vár egy karaktersorozat begépelé-sére, amely értéket utána elmenti a NameCall-back.inputName mezőbe (a setName() metódus-sal).

1 // 26. programl i s ta : Egy s a j á t Cal lbackHandler23 package t e s t . j a a s ;45 import java . i o . ∗ ;6 import javax . s e c u r i t y . auth . ∗ ;7 import javax . s e c u r i t y . auth . c a l l b a ck . ∗ ;89 public class TestCal lbackHandler implements CallbackHandler

10 {

36


1112 public TestCal lbackHandler ( )13 {14 }1516 public void handle ( Cal lback c a l l b a ck s [ ] ) throws IOException , UnsupportedCallbackException17 {18 for ( int i = 0 ; i < ca l l b a ck s . l ength ; i++)19 {20 i f ( c a l l b a c k s [ i ] instanceof NameCallback )21 {22 NameCallback nc = (NameCallback ) c a l l b a c k s [ 0 ] ;23 System . e r r . p r i n t ( nc . getPrompt ( ) ) ;24 System . e r r . f l u s h ( ) ;25 St r ing name = (new BufferedReader (new InputStreamReader ( System . in ) ) ) . readLine ( ) ;26 nc . setName (name ) ;27 } else28 {29 throw (new UnsupportedCallbackException ( c a l l b a c k s [ i ] , "Cal lback ␣ handler ␣not␣ support " ) ) ;30 }31 }32 }33 }

1 // 27. programl i s ta : NameCallback23 package javax . s e c u r i t y . auth . c a l l b a ck ;456 public class NameCallback implements Callback , java . i o . S e r i a l i z a b l e {78 private stat ic f ina l long se r ia lVers ionUID = 3770938795909392253L ;9

10 private St r ing prompt ; // k i í r j a a konzo l ra e z t a promptot11 private St r ing defaultName ; // a l ap é r t é k12 private St r ing inputName ; // ide k e rü l a megadott név1314 public NameCallback ( St r ing prompt ) {15 i f ( prompt == null | | prompt . l ength ( ) == 0)16 throw new I l l ega lArgumentExcept ion ( ) ;17 this . prompt = prompt ;18 }1920 public NameCallback ( St r ing prompt , S t r ing defaultName ) {21 i f ( prompt == null | | prompt . l ength ( ) == 0 | |22 defaultName == null | | defaultName . l ength ( ) == 0)23 throw new I l l ega lArgumentExcept ion ( ) ;2425 this . prompt = prompt ;26 this . defaultName = defaultName ;27 }2829 public St r ing getPrompt ( ) {30 return prompt ;31 }3233 public St r ing getDefaultName ( ) {34 return defaultName ;35 }3637 public void setName ( St r ing name) {38 this . inputName = name ;39 }4041 public St r ing getName ( ) {

37


42 return inputName ;43 }44 }

Ennyi előzmény és tudás birtokában végremegírhatjuk az első JAAS LoginModule-unkat(28. programlista), aminek adjuk a TestLogin-Module class nevet! A feladat az, hogy imp-lementáljuk az összes metódust, amit a Login-Module interface megkövetel. Nézzük át együttezt az osztályt, hiszen ennek a megértése a leg-fontosabb! A 27-34 sorok initialize() metódusaa LoginModule objektum inicializálását végzi el.Itt még nem ismert az identity, így azt null -raállítja, ezzel együtt a status is NOT lesz. Be-állításra kerül a használt callback handler (azaza kérdez-felelek játék lebonyolításának módja),valamint a LoginModule-t hívó (ez LoginContextobjektum) program Subject objektumának a re-ferenciája.

A login() metódus megvalósítása a 36-66 so-rok között található. A 44. sorban beállítjuk azegyetlen callback-ünket, amit a 48-49 sorokban

használunk. Mivel itt NameCallback használa-tos, ezért tőle válaszként egy String-et kapunk,amit a name változóban tárolunk el. Ez a névegy titkos karaktersorozat, ami private creden-tial szerepkörben van és a billentyűzetről gépel-jük be. A 57-60 sorok a beléptetést valósítjákmeg. Nincs user adatbázisunk, így az egyet-len érvényes titkos jelszót az 57. sor feltételébe„égettük” be. Amennyiben a user ezt, azaz a123456 szót adta meg, úgy az 59. sorban beál-lítjuk az egyszem (mert lehetne sokkal több is!)principálunkat, valamint a status-t OK-ra bil-lentjük.

A commit() és abort() megvalósítása szintemindegyik LoginModule típusban ugyanaz. A103-109 sorokban lévő logout() hasonlít az inici-alizálásra, nem véletlenül, hiszen a célja a login()előtti állapot visszaállítása, azaz a kiléptetés.

1 // 28. programl i s ta : A s a j á t TestLoginModule23 package t e s t . j a a s ;45 import java . i o . ∗ ;6 import java . u t i l . ∗ ;7 import java . s e c u r i t y . P r i n c i p a l ;8 import javax . s e c u r i t y . auth . Subject ;9 import javax . s e c u r i t y . auth . c a l l b a ck . ∗ ;

10 import javax . s e c u r i t y . auth . s p i . LoginModule ;11 import javax . s e c u r i t y . auth . l o g i n . LoginException ;1213 public class TestLoginModule implements LoginModule14 {1516 public TestLoginModule ( )17 {18 }19 private Subject sub j e c t ;20 private Tes tPr inc ipa l i d e n t i t y ;21 private CallbackHandler ca l l backhand l e r ;22 private stat ic f ina l int NOT = 0 ;23 private stat ic f ina l int OK = 1 ;24 private stat ic f ina l int COMMIT = 2 ;25 private int s t a tu s ;2627 public void i n i t i a l i z e ( Subject subject , Cal lbackHandler //28 ca l lbackhand l e r , Map state , Map opt ions )29 {30 s t a tu s = NOT;

38


31 i d e n t i t y = null ;32 this . s ub j e c t = sub j e c t ;33 this . c a l l ba ckhand l e r = ca l l backhand l e r ;34 }3536 public boolean l o g i n ( ) throws LoginException37 {3839 i f ( ca l l ba ckhand l e r == null )40 {41 throw new LoginException ( "No␣ ca l l ba ck ␣ handler ␣ i s ␣ a v a i l a b l e " ) ;42 }43 Cal lback c a l l b a ck s [ ] = new Cal lback [ 1 ] ;44 c a l l b a c k s [ 0 ] = new NameCallback ( "Mi␣az␣ön␣ t i t k o s ␣ kódja ?␣" ) ;45 St r ing name = null ;46 try47 {48 ca l l ba ckhand l e r . handle ( c a l l b a c k s ) ;49 name = ( ( NameCallback ) c a l l b a c k s [ 0 ] ) . getName ( ) ;50 } catch ( java . i o . IOException i o e )51 {52 throw new LoginException ( i o e . t oS t r i ng ( ) ) ;53 } catch ( UnsupportedCallbackException ce )54 {55 throw new LoginException ( "Error : ␣" + ce . getCa l lback ( ) . t oS t r i ng ( ) ) ;56 }57 i f (name . equa l s ( "123456" ) )58 {59 i d e n t i t y = new Tes tPr inc ipa l ( " i n y i r i " ) ;60 s t a tu s = OK;61 return true ;62 } else63 {64 return fa lse ;65 }66 }6768 public boolean commit ( ) throws LoginException69 {70 i f ( s t a tu s == NOT)71 {72 return fa lse ;73 }74 i f ( sub j e c t == null )75 {76 return fa lse ;77 }78 Set e n t i t i e s = sub j e c t . g e tP r i n c i p a l s ( ) ;79 i f ( ! e n t i t i e s . conta in s ( i d e n t i t y ) )80 {81 e n t i t i e s . add ( i d e n t i t y ) ;82 }83 s t a tu s = COMMIT;84 return true ;85 }8687 public boolean abort ( ) throws LoginException88 {89 i f ( ( sub j e c t != null ) && ( i d e n t i t y != null ) )90 {91 Set e n t i t i e s = sub j e c t . g e tP r i n c i p a l s ( ) ;92 i f ( e n t i t i e s . conta in s ( en t i t y ) )93 {94 e n t i t i e s . remove ( i d e n t i t y ) ;95 }

39


96 }97 sub j e c t = null ;98 i d e n t i t y = null ;99 s t a tu s = NOT;

100 return true ;101 }102103 public boolean l ogout ( ) throws LoginException104 {105 sub j e c t . g e tP r i n c i p a l s ( ) . remove ( i d e n t i t y ) ;106 s t a tu s = NOT;107 sub j e c t = null ;108 return true ;109 }110 }

Van egy TestLoginModule osztályunk, de va-jon, hogyan kell használnunk? A 29. prog-ramlista egy ProbaLogin.conf nevű file tartalmátmutatja. A jelenleg érvényesnek hagyott (a töb-

bit megjegyzésbe tettük) egyetlen PAM modu-lunk éppen a TestLoginModule. A required je-lentését lásd lentebb.

// 29 . p rograml i s ta : A LoginModule kon f i gu r á l á s aProbaLogin{

t e s t . j a a s . TestLoginModule r equ i r ed ;//com . sun . s e c u r i t y . auth . module . UnixLoginModule r equ i r ed ;//com . sun . s e c u r i t y . auth . module . NTLoginModule r equ i r ed ;//com . sun . s e c u r i t y . auth . module . Krb5LoginModule r equ i r ed ;

} ;

Az egyes LoginModule-ok lehetséges opciói:

• REQUIRED : Az authentikáció csak akkorlehet sikeres, ha minden így jelölt modulsikeresen azonosította a klienst. Egy ilyenmodul esetleges sikertelensége nem sza-kítja meg a hitelesítési folyamatot – azaztöbb modul esetén folytatódik –, azonbana hitelesítés végeredménye ekkor más nemlesz sikeres.

• REQUISITE : Az authentikáció csak akkorlehet sikeres, ha minden így jelölt modul si-keresen azonosította a klienst. Itt azonbanegy modul sikertelensége az egész authen-tikációs folyamat leállítását is jelenti, azazekkor nem megy végig, mint az előző eset-ben.

• SUFFICIENT : Az így jelölt modulnak

nem kötelező sikeresnek lennie, azonban haaz, akkor a teljes hitelesítési folyamat issikeres lesz és az esetleges további modu-lok nem hajtódnak végre. Ezt az esetethasználjuk jellemzően, amikor a user-ekettöbb helyen is tároljuk és azt akarjuk biz-tosítani, hogy mindenütt végignézze az au-thentikációs folyamat, az esetleges siker re-ményében. Például van pár címtárunk ésegy helyi /etc/password jellegű file-unk.

• OPTIONAL: Közömbös ennek a modul-nak a sikeressége vagy sikertelensége,mindkét esetben az authentikációs folya-mat folytatódik.

A 30. programlista a TestLoginModule-t tesz-telő kliens programot mutatja. A 20. sorbanlévő System.setProperty() beállítással konfigu-

40


ráljuk be, hogy ez a kliens – amennyiben authen-tikálni akar – milyen konfigurációt használjon.

Természetesen használhattuk volna a -Djava.security.auth.login.config=ProbaLogin.confparancssori beállítást is. A 26. sorban hozunklétre egy LoginContext objektumot, ahol para-méterül megadjuk, hogy a ProbaLogin konfigu-rációs szekciót (mint input String paramétert)használjuk a ProbaLogin.conf file-on belül és

ehhez a TestCallbackHandler forgatókönyvvelszerezzük meg a credential-t. A 39. sorban lévőctx.login() szerepét már ismerjük.

Lefuttatva ezt a kliens programot, megjele-nik a Mi az ön titkos kódja? prompt, ahol az123456 beírása beléptet (más kód most termé-szetesen nem jó!), majd a kliens kiírja a frissenazonosított alany principáljait, ami esetünkbencsak az inyiri.

1 // 30. programl i s ta : A TestLoginModule−t t e s z t e l ő k l i e n s23 package t e s t . j a a s ;45 import java . u t i l . Hashtable ;6 import java . u t i l . I t e r a t o r ;7 import java . u t i l . P rope r t i e s ;8 import javax . s e c u r i t y . auth . Subject ;9 import javax . s e c u r i t y . auth . l o g i n . LoginContext ;

10 import javax . s e c u r i t y . auth . l o g i n . LoginException ;1112 public class TestCl i ent13 {1415 public TestCl i ent ( )16 {17 }1819 public stat ic void main ( St r ing argv [ ] )20 {21 System . se tProper ty ( " java . s e c u r i t y . auth . l o g i n . c on f i g " ,22 "/opt/ netbeans /myprojects / Tes tPro j e c t s / Te s z t e l e s e kPro j e c t / s r c /ProbaLogin . conf " ) ;2324 LoginContext ctx = null ;25 try26 {27 ctx = new LoginContext ( "ProbaLogin" , new TestCal lbackHandler ( ) ) ;28 }29 catch ( LoginException l e )30 {31 System . e r r . p r i n t l n ( "LoginContext ␣ cannot ␣be␣ c rea ted . ␣"+ l e . getMessage ( ) ) ;32 System . e x i t (−1);33 }34 catch ( Secur i tyExcept ion se )35 {36 System . e r r . p r i n t l n ( "LoginContext ␣ cannot ␣be␣ c rea ted . ␣"+ se . getMessage ( ) ) ;37 }38 try39 {40 ctx . l o g i n ( ) ;41 }42 catch ( LoginException l e )43 {44 System . out . p r i n t l n ( "Authent icat ion ␣ f a i l e d . ␣" + l e . getMessage ( ) ) ;45 System . e x i t (−1);46 }47 System . out . p r i n t l n ( "Authent icat ion ␣ succeeded . " ) ;4849 I t e r a t o r p = ctx . ge tSub jec t ( ) . g e tP r i n c i p a l s ( ) . i t e r a t o r ( ) ;50 while ( p . hasNext ( ) )

41


51 {52 System . out . p r i n t l n ( "−−−>" + (( Pr i n c i pa l )p . next ( ) ) . getName ( ) ) ;53 }54 }55 }

Amennyiben a 29. programlistában a Unix-LoginModule-t állítjuk be (és a TestLoginMo-dule-t megjegyzésbe tesszük), úgy a Linux-bavaló bejelentkezést veszi át a Java programunk.Ez 2 dolgot jelent. Az egyik az, hogy itt a login()hatására a chat forgatókönyv némán lejátszódika háttérben, átvéve a Subject-et az operációsrendszertől. A másik az, hogy ilyenkor a kon-figurációt (esetünkben a ProbaLogin.conf nevűfile-t) az operációs rendszer szinten kell védeni,különben bárki átírhatná. A TestClient class fu-tási eredménye a következő (a user neve inyirivolt, az utána jövő számok a unix csoportok azo-nosító számai, ahova az inyiri user tartozik):Authent icat ion succeeded .−−−>i n y i r i−−−>1000−−−>1000−−−>4−−−>20−−−>24−−−>25−−−>29. . .

Ezzel a módszerrel olyan vastag Java progra-mokat készíthetünk, amik az operációs rendszer-től veszik át az azonosítást. Az eljárás természe-tesen Windows-on is működik, mely esetben azNTLoginModule class-t kell bekonfigurálni. Ek-kor a saját Windows XP gépemre bejelentkezveés a klienst futtatva a következő eredményt kap-tam:Authent icat ion succeeded .

−−−>i n y i r i−−−>S−1−5−21−796063269−1865366272−2249723920−39659−−−>MOL−−−>S−1−5−21−796063269−1865366272−2249723920−−−>S−1−5−21−796063269−1865366272−2249723920−513−−−>S−1−1−0−−−>S−1−5−32−544−−−>S−1−5−32−547−−−>S−1−5−32−555−−−>S−1−5−32−545−−−>S−1−5−14−−−>S−1−5−4

−−−>S−1−5−11−−−>S−1−5−5−0−1443760−−−>S−1−2−0−−−>S−1−5−21−796063269−1865366272−2249723920−23303−−−>S−1−5−21−796063269−1865366272−2249723920−23112−−−>S−1−5−21−796063269−1865366272−2249723920−41976. . .

Érdekes lehetőség a Kerberos bekonfigurá-lása, amihez a Krb5LoginModule szükséges. AJVM indítási környezete ekkor ezt a 3 környe-zeti paramétert kapja meg.−Djava . s e c u r i t y . krb5 . realm=CEG.SYS .CORP−Djava . s e c u r i t y . krb5 . kdc=cegdc02 . ceg . sys . corp−Djava . s e c u r i t y . auth . l o g i n . c on f i g=ProbaLogin . conf

Az első a kerberos domain vagy realm neve.A második a domainhez tartozó KDC (keydistribution center) szerver neve. A harma-dik a már ismert authentikáció konfigurációsfile-unk használata felőli rendelkezés. A beje-lentkezés ilyenkor 2 körös kérdés-válasz forga-tókönyv szerinti. Az egyikben a username, amásikban a password kerül bekérésre, majd aKrb5LoginModule beléptet bennünket. A pél-dában szereplő CEG.SYS.CORP egy Windowsdomain, a cegdc02.ceg.sys.corp pedig ennek adomain-nek egy domain controllere, ami definí-ció szerint egy KDC is, ugyanis a Windows 2000óta a Windows első helyen támogatott hitelesí-tési módszere a kerberos.

Kerberos username [ i n y i r i ] :Kerberos password f o r i n y i r i : xxxxxxxAuthent icat ion succeeded !−−−>inyiri@CEG .SYS .CORP

3.4. A Java authorizáció

Az authorizáció használatához egy újabb konfi-gurációs file-ra van szükségünk, ami a példánk-ban a test.policy file lesz. Tesztprogramunkat a31. programlista tartalmazza.

42


1 // 31. programlista : Authorizációs t e s z t Linux a l a t t23 package t e s t . j a a s ;45 import java . i o . F i l e ;6 import java . i o . FileNotFoundException ;7 import java . i o . IOException ;8 import java . s e c u r i t y . P r i n c i pa l ;9 import java . s e c u r i t y . Pr iv i l e g edAct i on ;10 import java . u t i l . I t e r a t o r ;11 import java . u t i l . l ogg ing . Level ;12 import java . u t i l . l ogg ing . Logger ;13 import javax . imageio . stream . FileImageInputStream ;14 import javax . s e c u r i t y . auth . Subject ;15 import javax . s e c u r i t y . auth . l o g i n . LoginContext ;16 import javax . s e c u r i t y . auth . l o g i n . LoginException ;1718 public class TestCl ientUnix19 {20 public stat ic void main ( St r ing argv [ ] ) throws FileNotFoundException , IOException21 {22 System . setProperty ( " java . s e c u r i t y . auth . l o g i n . c on f i g " ,23 "/opt/ netbeans /myprojects / Tes tPro j ec t s / Te s z t e l e s ekPro j e c t / s r c /MOLLogin . conf " ) ;2425 LoginContext ctx = null ;26 try27 {28 ctx = new LoginContext ( "MOLLogin" , new TestCal lbackHandler ( ) ) ;29 }30 catch ( LoginException l e )31 {32 System . e r r . p r i n t l n ( "LoginContext ␣ cannot␣be␣ created . ␣"+ l e . getMessage ( ) ) ;33 System . e x i t (−1);34 }35 catch ( Secur i tyExcept ion se )36 {37 System . e r r . p r i n t l n ( "LoginContext ␣ cannot␣be␣ created . ␣"+ se . getMessage ( ) ) ;38 }39 try40 {41 ctx . l o g i n ( ) ;42 }43 catch ( LoginException l e )44 {45 System . out . p r i n t l n ( "Authent icat ion ␣ f a i l e d . ␣" + l e . getMessage ( ) ) ;46 System . e x i t (−1);47 }48 System . out . p r i n t l n ( "Authent icat ion ␣ succeeded . " ) ;4950 I t e r a t o r p = ctx . ge tSubjec t ( ) . g e tP r i n c i p a l s ( ) . i t e r a t o r ( ) ;51 while ( p . hasNext ( ) )52 {53 System . out . p r i n t l n ( "−−−>" + (( Pr i n c i pa l )p . next ( ) ) . getName ( ) ) ;54 }555657 Pr iv i l e g edAct i on ac t i on = new Pr iv i l e g edAct i on ( ) {5859 public Object run ( )60 {61 //A f i l e62 St r ing fn = "/opt/ netbeans /myprojects / Tes tPro j ec t s / Te s z t e l e s ekPro j e c t / s r c / e g y f i l e . txt " ;63 F i l e f i l e = new F i l e ( fn ) ;64 try65 {66 FileImageInputStream f i s = new FileImageInputStream ( f i l e ) ;67 System . out . p r i n t l n ( "Méret : " + f i s . l ength ( ) ) ;68 } catch ( FileNotFoundException ex )69 {70 Logger . getLogger ( TestCl ientUnix . class . getName ( ) ) . l og ( Level .SEVERE, null , ex ) ;71 } catch ( IOException ex )72 {73 Logger . getLogger ( TestCl ientUnix . class . getName ( ) ) . l og ( Level .SEVERE, null , ex ) ;74 }75 return f i l e ;76 }7778 } ;7980 Subject . doAsPr iv i l eged ( ctx . ge tSubjec t ( ) , act ion , null ) ;8182 }838485 }

43


A program a Linux hitelesítést veszi át, ígya username és annak group principáljai is onnanjönnek. A 60. sorban látható az egyfile.txt file,aminek a méretét a program a képernyőre sze-retné írni, azonban ezt csak az inyiri teheti mega test.policy file-ban lévő konfiguráció miatt. Aprogram az 52. sorig ismerős, a login() műveletfut le, megszerezve a Subject-et is. Az 55-76 so-rok között egy PrivilegedAction objektumot ho-zunk létre, ez a Java szabványos authorizációnkeresztül való működési mechanizmusa, ugyanisennek a run() metódusához lesz vagy nem leszjogunk futáskor. A 78. sorban futtatjuk a Sub-ject.doAsPrivileged() metódust, ami azt a kódotfuttatja, ami a file méretének megállapítását és

kiírását csinálja. Természetesen csak akkor, haaz azt megelőző hitelesítés során kapott princi-pál megfelelő, amit a test.policy file 20. sorábanláthatunk.

A tesztprogram indítása:

# A −Djava . s e c u r i t y . manager :# bekapc so l j a a s e c u r i t y a l r e nd s z e r t# −Djava . s e c u r i t y . p o l i c y :# A po l i c y l e í r á s ának he lye# Lásd : t e s t . p o l i c y f i l e

$ java−Djava . s e c u r i t y . manager−Djava . s e c u r i t y . p o l i c y =./ t e s t . p o l i c y−cp . . / bu i ld / c l a s s e s t e s t . j a a s . TestCl ientUnix

// t e s t . po l i c y f i l e : Authent ikác ió kon f i gu rá c i ógrant{

// permiss ion java . s e c u r i t y . Al lPermiss ion ;permiss ion javax . s e c u r i t y . auth . AuthPermission " createLoginContext .MOLLogin" ;permiss ion javax . s e c u r i t y . auth . AuthPermission " getLog inConf igurat ion " ;

permiss ion javax . s e c u r i t y . auth . AuthPermission "mod i fyPr inc ipa l s " ;

permiss ion javax . s e c u r i t y . auth . AuthPermission "modi fyPubl i cCredent ia l s " ;permiss ion javax . s e c u r i t y . auth . AuthPermission "mod i fyPr ivateCredent ia l s " ;permiss ion javax . s e c u r i t y . auth . AuthPermission "doAs " ;permiss ion javax . s e c u r i t y . auth . AuthPermission " doAsPr iv i l eged " ;permiss ion java . s e c u r i t y . Secur i tyPermis s i on " s e tPo l i c y " ;permiss ion java . s e c u r i t y . Secur i tyPermis s i on " ge tPo l i cy " ;

permiss ion java . u t i l . PropertyPermiss ion " java . s e c u r i t y . auth . l o g i n . c on f i g " , " read , wr i t e " ;} ;

grant codebase " f i l e : / opt/ netbeans/−" , p r i n c i p a l com . sun . s e c u r i t y . auth . UnixPr inc ipa l " i n y i r i "//com . sun . s e c u r i t y . auth . UnixPr inc ipa l ""// t e s t . j a a s . Tes tPr inc ipa l " i n y i r i "{

permiss ion java . i o . F i l ePe rmi s s i on "/ opt/ netbeans /myprojects / Tes tPro j ec t s / Te s z t e l e s ekPro j e c t / s r c / e g y f i l e . txt " , " read " ;} ;

44

Technológia Session replikációs alternatívák

4. Session replikációs alternatívák

Az olyan nagyméretű és összetett infrastruktúrák, mint a SOA esetében a túlterhelés miatt las-sulások, leállások jelentkezhetnek. Erre a problémára számos megoldás lehetséges, melyek közülaz egyik leghatékonyabb a session replikáció. Ebben a cikkben az Oracle WebLogic környezetbenvizsgáljuk meg ezt a lehetőséget.

Portál session replikáció

Az olyan nagyméretű és összetett infrastruktú-rák, mint a SOA esetében a portálfelületekena túlterhelés miatt lassulások, leállások jelent-kezhetnek. A megoldást a portál processz me-móriájának bővítése jelentené, de sok esetbenez nem lehetséges. Erre a problémára számosmegoldás lehetséges, amely közül az egyik leg-hatékonyabb a session replikáció. A session rep-likációhoz a rendszert két részre kell vágnunk,ami egyben megoldja a clusterben futás kérdé-sét is. Első lépésben meg kell vizsgálnunk, mi-lyen feltételekkel tehetjük alkalmassá a portá-lalkalmazást a session replikációra. A legfonto-sabb, hogy a replikációhoz szükséges szerializál-hatósági követelményt teljesítse. Azoknál a ré-szeknél, ahol ez nem lehetséges - mint a BPM-folyamatazonosítónál -, meg kell oldanunk a rep-likáció utáni minél zavartalanabb működést. Kö-vetkező feladatunk a session replikáció bekapcso-lása. Fontos, hogy a felhasználók úgy indíthas-sák újra a portált, hogy ne kelljen ismételten be-jelentkezniük, így érdemes megoldani, hogy azegy gépen futó portálszerverek között történjena session replikáció.

WebLogic HttpSession kezelés

A munkamenet (session) kezeléssel kap-csolatos beállításainkat webalkalmazásunkWEB-INF/WebLogic.xml leírójának, session-descriptor szekciójában tudjuk végrehajtani, sennek megfelelően azok szállító (vendor) speci-fikusak. WebLogic alkalmazásszerver környezet-

ben öt különböző http session állapotkezelési ésnyomkövetési (track and store) sémát különböz-tetünk meg:

1. In Memory (Single Server Not Replicated)

2. JDBC Based

3. File Based

4. In Memory Replication

5. Cookie Based

A fenti lista első négy eleme a munkamenet álla-potkezelését szerver oldalon valósítja meg, s csaka megvalósítás módjai különböznek egymástól,az ötödik viszont kliens oldali megoldást nyújt.Az azonosításhoz az első kliens-kérés alkalmávala WebLogic szerver egy munkamenetazonosítóttartalmazó session cookie-t állít össze, és küld ela kliensnek. A kliens, kérései során ezzel a ses-sion cookie-val azonosítja majd magát a szerverszámára. A session cookie szerkezetileg háromrészre bontható, a munkamenetazonosítóra (ses-sionid), az elsődleges szerver azonosítójára (pri-mary_server_id), valamint a másodlagos szer-ver azonosítóra (secondary_server_id).

In Memory séma

Ez az alapértelmezett munkamenet-kezelésiséma. A HttpSessionben levő felhasználói ada-tok ebben az esetben a kiszolgáló szerver me-móriájában tárolódnak. A munkamenet élettar-tamát a timeout-secs paraméterrel állíthatjuk a

45


kívánt értékre. A szerver ezeket periodikusan el-lenőrzi, és amennyiben lejárt munkamenetet ta-lál, felszabadítja a hozzá tartózó, használaton kí-vüli erőforrásokat. A megoldás hátránya, hogyfüggetlenül a munkamenet élettartamától, a Htt-pSessionben tárolt adatok elvesznek a szerver új-raindítását, nem tervezett leállását követően.

JDBC Based séma

JDBC Based Session Persistance séma ese-tén a munkamenet-perzisztenciát adatbázistábla írásával biztosítjuk. Az adatbázis-kapcsolat kialakításához létrehozunk egy nemXA-s JDBC adatforrást. A munkamenetadatai bináris formátumban (BLOB) táro-lódnak a wl_session_values mezőben. Awl_access_time mező tartja nyilván az utolsóhozzáférés időpontját. Ezt a mezőt akkor ismódosítja a szerver, ha csak olvassák a munka-menetet. A munkamenet adatainak írásakor awl_session_values és a wl_access_time is mó-dosul. A JDBC-megoldásnál a szerver átmenetitárolóban tárolja az utoljára használt munkame-netek adatait az optimális elérés érdekében. Amegoldás előnye, hogy a munkamenet életciklusanem ér véget a szerver újraindításával, tartalmaújraépíthető az adatbázisban tárolt adatok alap-ján, sőt a munkamenet állapotának replikálásárais felhasználhatjuk ezt a megoldást. Természete-sen a pertisztálásnak ára van, az adatbázis táblafolyamatos írása/olvasás költséges művelet, amimegnöveli a kliens kérések válaszidejét.

File Based séma

A File Based Session Persistence séma esetébena munkamenet adatai egy natív fájlba íródnaka szerver oldalon. A tároláshoz használt állo-mányok helyét a persistent-store-dir paraméter-rel tudjuk meghatározni. Klaszteres környezet-ben valamennyi tagszervernek írnia/olvasnia kelltudnia ezt a könyvtárat. A helyet adó tárolónak

magas rendelkezésre állást és gyors válaszidőtkell biztosítania. A gyakorlatban SAN-hálózatrakötött disk-alrendszeren található tároló egysé-get használnak erre a célra. A memória alapúmegoldáshoz képest a fájl alapú megoldásnális magasabb válaszidővel kell számolnunk, cse-rébe a munkamenetünk adatai nem vesznek ela kiszolgáló szerver leállása esetén. Hasonlóana JDBC-alapú megoldáshoz, ez is használhatómunkamenetünk állapotának replikálására.

In Memory Session Replication séma

A memóriában végzett munkamenet replikálásesetén a WebLogic másolatot készít a munkame-net állapotáról a klaszter egy másik szerverére.Munkamenetünk állapota így két helyen talál-ható meg, azon a szerveren ahová a kérés beér-kezett (elsődleges szerver) és azon, ahova a We-bLogic átmásolta az állapot-adatokat (másod-lagos szerver). Az állapotok szinkronban van-nak, így ha az elsődleges szerver valamilyen ok-ból leáll, vagy nem elérhető, akkor a másod-lagos szerver veszi át szerepét. A kliens szá-mára a szerepátvétel transzparens, az első alka-lommal tapasztalható megnövekedett válaszidő-től eltekintve nem vehető észre a változás. Ah-hoz, hogy teljes képünk legyen a WebLogic általnyújtott replikációs lehetőségekről, meg kell is-merkednünk a Replication Group funkcióval ésaz általa nyújtott lehetőségekkel. Alapértelme-zésként a WebLogic a munkamenet-kezelésnél akülönböző fizikai gépek (machine) közötti repli-kálást részesíti előnyben. Ez érthető is, hiszencsak így biztosítható a fizikai gép leállása eseténa munkamenet állapotának megőrzése. A Repli-cation Group használatával a WebLogic szerverpéldányokat logikailag csoportosíthatjuk, befo-lyásolva ezzel a munkamenet-állapot másolatokhelyét. A replikáció beindításához a persistent-store-type paramétert kell replicated vagy repli-cated_if_clustered értékre állítani. A szerverpéldányokat replication grouphoz és preferred

46


secondary replication grouphoz rendeljük. Ami-kor beérkezik egy kérés valamelyik szerverpél-dányhoz, és annak el kell döntenie, hogy a mun-kamenet állapotot hova replikálja, akkor előszöra preferred secondary replication group beállítá-sát nézi meg, majd megvizsgálja, hogy a klasz-terben van-e olyan, tőle különböző szerverpél-dány, aminek a replication group értéke meg-egyezik ezzel az értékkel. Ha van ilyen szer-ver, akkor az lesz a másodlagos szerver (secon-dary server), oda kerül a munkamenet-állapotmásolat. Találat hiányában arra a szerverpél-dányra esik a választás, amelyik a kérést kiszol-gáló szervert futtató fizikai géptől eltérő fizikaigépen fut. Több találat esetében is a fizikaigép különbözősége dönt. A memóriában tároltmunkamenet példányok élete véget ér, amint aklaszter valamennyi tagját újraindítjuk. Időn-ként szükség van a munkamenet állapotánakmegtartására függetlenül a szerverek életciklu-sától. Ebben az esetben valamilyen külső cacheszerver megoldást szoktunk alkalmazni. Ebbennyújt segítséget az Oracle Coherence terméké-nek http session kezelésért felelős modulja (Co-herence*Web), mely az alkalmazások számáratranszparens módon veszi át a session állapotokkezelését.

Cookie based

A WebLogic lehetőséget biztosít munkamene-tünk állapotának kliens oldali tárolására is, coo-kie formájában. Kisméretű munkamenet eseténhasználhatjuk ezt a megoldást, akkor, ha vala-mennyi kliensünk böngészője engedi a cookie tá-rolását. A gyakorlatban ritkán alkalmazzák, mi-vel biztonsági kérdéseket vet fel, ezen kívül ennéla megoldásnál csak szöveges (string) tartalmatadhatunk a munkamenetünkhöz.

Terhelés elosztás és Failover

laszteres környezetben a webes erőforrások(Servlet, JSP) terhelés-elosztása megoldható aWebLogic szerver saját proxy plug-in megoldá-sával vagy külső, nagy teljesítményű hardver esz-közzel egyaránt. Most a WebLogic saját proxyplug-in megoldását mutatjuk be. WebLogic kör-nyezetben a proxy plug-in komponens feladataa kliensektől érkező http kérések továbbításaa nyilvántartásában szereplő szerverpéldányokfelé. A proxy plug-in működését tekintve reverseproxy, azaz a kliens nem közvetlenül a szervert,hanem a proxy plug-int címzi meg. A szerverpéldányok közötti választás alapértelmezésbenkörbeforgó (Round Robin) algoritmus alapjántörténik. A proxy plug-in folyamatosan figyeli aszerver példányok elérhetőségét, és amennyibenvalamelyik szerver elérhetetlenné válik, arra apéldányra nem küld további kéréseket. A leállá-sok detektálásán felül a plug-in, session repliká-ció használata esetén képes a kliens http sessionállapot replikáját kezelő szerverpéldányra átirá-nyítani a kéréseket. A másodlagos szervert ahttp kérésben megkapott session cookie-ban ta-lálható secondary_server_id alapján azonosítjabe. A munkamenet nyomon követését megold-hatjuk URL rewriting segítségével is. Ez abbanaz esetben jön jól, ha alkalmazásunk kliensei kö-zött van olyan, amely nem támogatja a cookie-kezelést. URL rewriting esetén mind az elsőd-leges mind a másodlagos szerver azonosítóját azURL kódolja.

Coherence*Web

Az Oracle Coherence termékének Cohe-rence*Web modulja a http session állapot ke-zelést oldja meg klaszteres környezetben. Le-hetőséget biztosít különböző webalkalmazásokközötti munkamenet-megosztásra, akár hete-rogén környezetben is. WebLogic szerverhezillesztése a Coherence*Web SPI-vel már nem

47


igényli a WebLogic.jar és a webalkalmazásokinstrumentálását. Telepítéséhez alkalmazásszer-ver oldalon csak a coherence/lib könyvtárbantalálható coherence-web-spi.war library-t kelltelepíteni a WebLogic szerverre, klaszterünk va-lamennyi szerverpéldányára targetálva. Alkal-mazás oldalon a coherence/lib könyvtár alattlévő coherence.jar-t kell bemásolnunk a WEB-INF/lib könyvtárba, valamint a coherence-web-spi-t felvenni a WebLogic.xml-ben. Környezettőlfüggően többféleképen konfigurálhatjuk a Cohe-rence Web modulját, ezeket a lehetőséget nézzükát a fejezet további részében.

Coherence klaszter tagok izolációja

A Coherence*Web modul telepítéséhez több le-hetőség is rendelkezésünkre áll. Ezek az opciókalapvetően meghatározzák a Coherence*Webmodul hatáskörét az alkalmazásszerveren belül.Application Server Scoped Cluster Nodes Ezesetben az alkalmazásszerverre telepített vala-mennyi webalkalmazás Http session kezelését át-veszi a Coherence*Web. Az alkalmazásszerve-ren belül egy Coherence klaszter csomópont jönlétre, ehhez kapcsolódnak a webalkalmazások.

EAR Scoped Cluster Nodes Telepíthet-jük a coherence.jart az alkalmazásunk (EAR)classpath-ára is. Ekkor alkalmazásonként jönlétre egy-egy coherence klaszter csomópont azalkalmazásszerveren belül. Az EAR-ban talál-ható valamennyi webalkalmazás egységesen eh-hez a csomóponthoz csatlakozik, és delegálja aHttp sessionkezelést a Coherence felé.

WAR Scoped Cluster Nodes Végül mód vana Coherence*Web modul webalkalmazásonkénti(WAR) izolációjára is. Ebben az esetben a co-herence.jart a webalkalmazásunkba csomagolvatelepítjük. Valamennyi alkalmazás a számáradedikáltan rendelkezésre álló coherence klasztercsomópont felé delegálja Http session kezelését.

Session Modellek

A session modell meghatározásával szabályoz-hatjuk a munkamenet-állapot fizikai reprezentá-ciójának és tárolásának módját a coherence szer-veren belül. A munkamenet állapot kezeléséért aHttpSessionModel objektum, a munkamenet ál-lapotok tárolásáért a HttpSessionCollection ob-jektum felel a Coherence*Web modulján belül.

Traditional Model

A munkamenet állapota ez esetben egy entitás-ban tárolt, de a session attribútumok sorosí-tása (serialization) és visszaállítása (deserializa-tion) attribútumonként történik. Ezt a megol-dást kisméretű (<=10KB) session esetében ja-vasolt használni, ahol nincs olyan session objek-tum, amelyre több különböző session attribútumis hivatkozik.

Monolithic Model

A munkamenet állapota egy entitásban kerültárolásra, és a session attribútumok sorosítása(serialization) és visszaállítása (deserialization)egyszerre, egy lépésben történik.

Split Model

Ez a megoldás a Traditional Model lehetőségeitterjeszti ki azzal, hogy a nagyméretű session att-ribútumokat fizikailag önálló entitásban tároljael. Egy-egy nagyméretű objektum módosításaígy nem igényli a teljes munkamenet-állapot fris-sítését, elég csak a tároló entitást szinkronizálni,ez pedig kisebb hálózati forgalmat fog generálni.

Nagyméretű munkamenetek esetén a SplitModel a javasolt megoldás.

Session Scoping

A Coherence*Web modul használatával meg-oszthatjuk a munkamenet adatait a webalkalma-

48


zások között akár akkor is, ha ezek az alkalmazá-sok különböző webkonténerekben futnak. Kon-téneren belüli megosztásnál a coherence-session-cookie-path paramétert kell beállítani a kontex-tusoknak megfelelően. Például ha két alkalma-zás között kell megosztani session adatokat ésaz egyiknek a /web/behajtas a másiknak pe-dig /web/szamlazas a kontextusa, akkor a /weblesz a coherence-session-cookie-path helyes ér-téke. Különálló web konténerek esetén, ahol akonténerek ráadásul külön fizikai szerveren fut-nak, a közös sessionelérés érdekében be kell állí-tani a coherence-session-cookie-domain paramé-tert is.

Cache topológiák

Replicated Cache Service

A Coherence szerver replicated módban a cash-ben tárolt adatokat átmásolja a klaszter vala-mennyi tagjára, és szinkronban tartja azokat.Mivel az adatok minden tagon megvannak, ezérthozzáférésük nagyon gyors, gyakorlatilag az al-kalmazásszerver JVM-ből történik az adatok el-érése, minimális késleltetéssel. Ennek a megol-dásnak éppen ezért az olvasás intenzív felhaszná-lás esetén van előnye a többi megoldással szem-ben. A cashben tárolt adatok módosítása vi-szont költséges művelet, mivel a klaszter vala-mennyi tagjára át kell másolni a változásokat.Tervezéskor figyelembe kell venni ennek a topo-lógiának a skálázhatósági korlátait. Új tagokklaszterbe vonásával ugyanis mindegyik klasz-tertagnál növelni kell a java heap méretét, amijelentősen leronthatja a teljesítményt (gc over-head). Továbbá update intenzív esetben a ská-lázhatóság nem nő lineárisan a klaszter növeke-désével együtt, mivel az update-ek válaszidejecsökkeni fog egy-egy új tag klaszterbe állításá-val.

Partitioned Cache Service

Ez esetben nem a teljes adatot másolják át aklasztertagokra, hanem annak csak egy részét,egyenletesen, azonos méretű darabokban szét-osztva. Ezt a megoldást ezért Distributed Cash-nek is hívják. A megoldás jellemzői:

• Mivel az adatok ez esetben egyenletesenszét vannak ”kenve” a klaszteren belül,ezért a terhelés szétosztási lehetőség (LoadBalanced) természetes velejárója e megol-dásnak.

• A kliensek mindig ugyanazt az API-t hasz-nálják az adatok eléréséhez, az API a kli-ens számára ugyanúgy viselkedik, bárhon-nan is kelljen előbányászni klaszteren belülaz adatokat (Location Transparency).

• Konfigurálhatóan tudjuk meghatározni azadatmásolatok számát a klaszteren belül.Ha a másolatok száma egy vagy több, ak-kor valamelyik klasztertag leállásakor azátirányítás (Failover) adatvesztés nélkültörténik meg.

• A klaszteren belül egy adat kezeléséértmindig egyetlen tag felel. Ebből követ-kezően a kommunikáció – legyen az olva-sás (get) vagy írás (put) –, point-to-pointjellegű lesz, így nem okoz kommunikációsoverhedet újabb tagok bevonása a klasz-terbe. A skálázhatóság tehát a klaszter bő-vítésével együtt lineárisan növelhető (Li-near Scalability).

• A local storage paraméterrel szabályoz-hatjuk, hogy a klaszteren belül egy tagkezeljen-e adatokat. Ennek akkor van je-lentősége, ha az alkalmazásszerver JVM-jét nem akarjuk tovább terhelni a cashklaszter adatkezelési teendőivel.

49


Near Cache

Ez a megoldás a Partitioned Cache megoldástegészíti ki a legutoljára (MRU) vagy a leggyak-rabban (MFU) használt objektumok alkalmazásoldali, azaz lokális cache-ben tárolásával, a jobbperformancia érdekében. A lokális cache mére-tét és kezelésének algoritmusát paramérterezés-sel szabályozhatjuk. Valójában az adatok eléré-sét gyorsíthatjuk fel e megoldással, azon az áron,hogy az alkalmazás JVM-jéből kell feláldoznunkterületet.

Coherence*Web konfiguráció

A konfigurációs állományok a coherence-web-spi.war állományban találhatóak. A WEB-INF\classes\session-cache-config.xml állomány-ban tudjuk megadni az alkalmazni kívánt cachesémákat és azok paraméterezését. A WEB-INF/web.xml állományban további paramétere-zési lehetőségre van mód.

Rácz ImreAlerant Informatikai Zrt.

50

Üzleti informatika Az üzleti informatikai rendszerek fejlődése és típusai

5. Az üzleti informatikai rendszerek fejlődése és típusai

A számítógépes informatika az 1950-es évektől indult el hódító útjára, azóta sokféle üzleti infor-matikai rendszer bukkant fel. Ebben a cikkben arra vállalkozunk, hogy áttekintjük a fejlődés főbbmérföldköveit, illetve felvázoljuk az egyes rendszertípusok legfontosabb jellemzőit.

Amikor szeretnénk megérteni az üzleti infor-mációs rendszereket (továbbiakban: ÜIS), akkorelőbb egy általánosabb fogalmat, az üzleti rend-szer fogalmát kell tanulmányoznunk. A termelő

vagy szolgáltató vállalkozások nyílt rendszerek,azaz ezt a sémát követik: INPUT→ transzfor-máció→OUTPUT (termék vagy szolgáltatás).

7. ábra. Az üzleti körforgás

51


Az üzleti tevékenység lényegét az üzleti kör-forgás mutatja (7. ábra). Ez egy olyan absz-trakció, ami mindenfajta vállalatra igaz, az ábraönmagáért beszél. Az üzleti tevékenységek egymásik megközelítési lehetősége az értéklánc mo-dell. Itt a hangsúly az egymáshoz kapcsolódóalaptevékenységek (beszerzés, logisztika, terme-lés, marketing, értékesítés, ...) láncolatán van,célfüggvényként megjelölve az egyes tevékeny-ségek hozzáadott értékének maximalizálását, aköltségek optimális szinten tartása mellett. Azüzleti rendszerek ellátási láncokba szerveződnek,azaz az egyik vállalat (vagy egy vállalaton be-lüli részleg) outputja a másik vállalat (vagy rész-leg) inputja. Emiatt az INPUT és az OUT-PUT menedzsmentje fontos, az előbbit CRM(Customer Relationship Management), az utób-bit pedig SRM (Supplier Relationship Manage-ment) néven emlegeti a szakirodalom. A tel-jes ellátási lánc menedzsmentjét pedig SCM-nek(Supply Chain Management) nevezzük. Az In-ternetes korszakkal az SCM-nek egy magasabbszerveződési szintje alakult ki, az elektronikuskereskedelem, amit kicsit kitágított értelembene-business-nek hívunk. Ennek legfontosabb ka-tegóriái:

• B2B (Business to Business): vállalatok kö-zötti e-kereskedelem

• B2C (Business to Customer): a vállalatokés fogyasztók közötti e-kereskedelem

• C2C (Customer to Customer): az egyé-nek egymás közötti e-kereskedelme (gon-doljunk olyan rendszerekre, mint a világ-méretű eBay vagy a magyar Vatera)

• B2A (Business to Administration): a vál-lalatok és a hivatalos szervek közötti e-kapcsolat

Az eddigi modellek mellett a vállalkozások üz-leti informatikáját azok szervezeti struktúrája ésannak jellege (hierarchikus, mátrix), valamint a

szervezeti kultúra is alapvetően meghatározza.A mai gazdálkodó szervezetekben az IT straté-giai szerepet kap, ami azt jelenti, hogy az ITszervezetek által nyújtott szolgáltatások előnytnyújtanak (vagy csökkentik a fennálló hátrányo-kat) a versenytársakkal szemben. A gyakorlat-ban ez azt jelenti, hogy az üzleti folyamatokat fo-lyamatosan tökéletesíteni kell, ahol lehet és értel-mes, ott célszerű az IT megoldások használata.Ez sokszor a folyamatok újratervezését igénylik,amit BPR-nak (Business Process Reenginering)nevezünk.

Az informatikai rendszerek adatbázisai ki-váló lehetőséget adnak a vezetői döntések meg-hozatalához, sőt manapság már olyan rendsze-rek készülnek, amiknek ez az elsődleges céljuk.A döntéselmélet mára egy külön közgazdaságidiszciplína lett, itt most azt szeretnénk csak ki-emelni, hogy az informatikai rendszerek a külön-féle vezetői szintek (politikai, stratégiai, taktikai,operatív) eltérő igényeit egyaránt igyekeznek ki-elégíteni.

5.1. Rövid áttekintés

Az üzleti rendszerek nagyon vázlatos áttekinté-sére építve tekintsük át röviden az üzleti infor-matikai rendszerek fejlődését és típusait. A do-bozos információs rendszerek folyamatosan vál-toznak, közben újabb típusok is jelennek mega piacon. A régi szemléletű rendszerek szabvá-nyosodnak, beolvadnak egy korszerűbb felfogásúmegoldásba vagy eltűnnek.

Üzleti információs rendszer : Olyan forma-lizált számítógépes rendszer, amely különbözőforrásokból gyűjt adatokat, feldolgozza, tároljaazokat, majd információkat szolgáltat a felhasz-nálói számára.

Az alábbiakban összefoglaljuk az üzleti in-formatikai rendszertípusokat, ahogy azt az üz-leti informatika jelenleg osztályozza (forrás: Ka-csukné Dr. Bruckner Lívia, Kiss Tamás: Beve-zetés az üzleti informatikába, Akadémia Kiadó):

52


• 1950-es évek: TPS (Transaction Proces-sing System)

• 1960-as évek: MIS (Management Informa-tion System)

• 1970-es évek: DSS (Decision SupportSystem), PPS (Production Planning andScheduling), MRP (Materials Require-ments Planning)

• 1980-as évek: EIS (Executive Informa-tion System), ES (Expert System), GDSS(Group Decision Support System)

• 1990-es évek: ERP (Enterprise ResourcePlanning), BI (Business Intelligence),CRM, SRM, SCM, KM (Knowledge Ma-nagement)

• 2000-es évek: EPM (Enterprise Perfor-mance Management), Business Suite

Mi jellemzi az egyes rendszertípusokat? Próbál-juk meg röviden összefoglalni!

TPS. Látható, hogy az üzleti életben elő-ször ezek a tranzakciókezelő rendszerek jelen-tek meg. Feladatuk az elemi üzleti eseményekrögzítése, feldolgozása. A tranzakció fogalmaazt jelenti, hogy az egyik konzisztens állapot-ból egy másikba visz az üzleti esemény keze-lése. A konzisztencia adott szituációban valópontos meghatározása mindig kulcskérdés. Ve-gyünk például egy töltőállomást, ahol az üzletiesemény az, hogy valaki 50 litert tankolt. Apénztári rendszer ekkor megnyit egy új tranz-akciót és rögzíti az 50 litert, de ez egyből in-konzisztens állapotba teszi a tranzakciót, ami-nek ez az első elemi művelete. Ezután a 2. mű-velet a fizetés, ami logikailag helyrehozza a kon-zisztenciát, így kiadható a COMMIT (jóváha-gyás) az egész tranzakcióra. Egy tranzakciót ál-talában több úton is konzisztenssé lehet tenni.Amennyiben nincs fizetés, úgy felveszünk egyjegyzőkönyvet és COMMIT. Lehet persze az is

a végeredmény, hogy a benzint visszajuttatjuka tartályba, amit az esemény visszagörgetésé-nek nevezünk (ROLLBACK). A TPS rendsze-rek tehát a napi üzletmenettel (számlák kifize-tése, eladások, bérkifizetések, megrendelések fo-gadása, áttárolás raktárak között, stb.) kapcso-latos adatok gyűjtésével, tárolásával, feldolgozá-sával foglalkozik. Ugyanakkor az egyik legfonto-sabb adatforrása a magasabb szintű rendszerek-nek.

A technikai adottságok miatt ezek a rendsze-rek először batch feldolgozású megoldások vol-tak, off-line működéssel. Ebben az időben azüzleti emberek csak „távolról” találkoztak a szá-mítástechnikával. A bizonylatokat eljutatták aGAF-ba (Gépi AdatFeldolgozás), ahonnan vas-tag tablókat kaptak vissza. Ezek között voltakolyanok, mint a készletelszámolás vagy számlá-zás, azaz a tényleges manuális munkát jelentő-sen csökkentette. Később a technika egyre kö-zelebb hozta a felhasználót a rendszerhez (pél-dául SAP R/2 CICS), aki emiatt egyre hatéko-nyabban használta azt, már magában a valós üz-leti folyamatban (tranzakciók lebonyolításában)is számítógépes terminált használhatott. Ezt amódszert hívjuk OLTP -nek, azaz OnLine Tran-saction Processing-nek.

MIS. Egy idő után felmerült annak az igé-nye, hogy a rendszerek ne csak a tranzakciók ke-zelésében segítsenek, hanem a menedzserek in-formációigényét is elégítsék ki. Ezeket hívjukVezetői Információs Rendszereknek (VIR=MIS).Itt jellemzően előredefiniált jelentések készülnek,valamilyen időközönként. Az is gyakran előfor-dul, hogy valamilyen különleges esemény vagyigény esetén alkalmi riport készül. Jellegénélfogva a MIS típusú rendszerek jól meghatáro-zott scope-ra vonatkozóan adnak információt,főleg operatív, kisebb mértékben taktikai szin-ten, azaz magasabb vezetői döntésekhez általá-ban már nem elég hatékonyak.

DSS. A döntéstámogató rendszerek a MISgondolatának természetes továbbfejlesztéseként

53


főleg a taktikai szint számára készített, adottproblémára koncentráló megoldások. A legna-gyobb előrelépést az ad-hoc lekérdezések sokkaljobb támogatása jelenti. Az interaktív termi-nálhasználat bevezetése lehetővé teszi, hogy arosszabbul strukturált döntési helyzetekben istámogatást adjon.

GDSS: A csoportos döntéstámogató rend-szerek a DSS fejlesztései, ahol a csoportos (tes-tületi) döntések támogatása a fő cél, emiatt abeépített kommunikációs megoldásokon (közösmappa, e-mail, stb.) nagy hangsúly van.

EIS: A felsővezetői információs rendszerekösszegzett, grafikus, a legfontosabb tényezőkrekoncentráló információkat nyújtanak. Persze le-hetőséget adnak a részletekbe való betekintésreis. Alapelve az intuitív, könnyen kezelhető GUIbiztosítása. A DSS, GDSS és EIS rendszerekkialakulásával jelent meg az OLTP fogalommalszemben meghatározott OLAP (Online Analy-tical Processing) kezdetleges fogalma is, ami akésőbbi BI rendszerekben teljesedik ki.

ERP: A vállalati erőforrás-tervező rendszer-rel tipikusan a 90-es évek terméke. Alapgondo-lata a termelés és a hozzá kapcsolódó erőforrások(pénz, humán) integrált tervezése. Kezdetlegesformában tartalmazza a CRM, SRM és SCM csí-ráit is. Az ERP rendszerek a 2000-es évekbenkiteljesedtek, így ma már próbálják támogatniaz operatív szintű feladatok egy részét is. Jel-lemzően moduláris szerkezetűek, amit az ismert8. ábra is mutat.

CRM: Az ügyfélkapcsolati rendszerek azügyfelekkel kapcsolatos operatív feladatokat tá-mogatják, segítik ezzel a marketing és ügyfélszol-gálat munkáját. Taktikai, kisebb részben straté-giai szinten információkat adhat a termékfejlesz-téshez és marketing irányokhoz is.

SRM: A beszállítóikapcsolat-kezelő rendsze-rek a beszállítókkal és beszerzésekkel foglalkoz-nak, eközben főleg operatív és taktikai szintennyújtanak döntéstámogatást.

BI: Az üzleti intelligencia rendszerek a dön-

téstámogató rendszerek bármelyikét tartalmaz-hatják. Az OLAP kiteljesedik, online elemzé-sekre alkalmas. Jól átgondolt felépítése van,melyek közül az alapvető részek a következőek:ETL (Extract, Transform, Load), Reporting(minden formában, grafikus dashboard is van),Planning és adatbányászat. Az ETL rétegbenmegjelenik az adattárház (Datawarehouse), aholtisztított, előfeldolgozott adatokat tárol, többdi-menziós kockákban. Itt jelent meg legtisztábbformában az un. multidimenzionális adatbá-ziskezelő fogalma is. Ezekben a rendszerekbena legkritikusabb dolgok a kockák dimenzióinak(adatszerkezet) jó eltalálása, az adatforrásokbólszármazó hiteles adatok átvételi lehetőségénekkialakítása. A kockák „töltése” során fontos sze-repet kap a transzformáció, hiszen a tranzakcio-nális input adatokat össze kell vonni, megfelelőalakra kell hozni. A BI reporting rétege felelősaz adatokhoz való hozzájuthatóságért. Tipikuspélda erre a rétegre a Business Objects, ami ariportozás összes statikus és dinamikus módjáttámogatja, kiváló dashboard grafikus felületet isnyújt. A tervezés (planning) funkció egy termé-szetes alkalmazása a BI -nak, hiszen a vállalatitervtáblák egy az egyben olyanok, amit a több-dimenziós kockákba le lehet képezni. Az adat-bányászat érdekes lehetőséget ad a vezetői dön-tésekhez, kutatásokhoz. Különféle matematikai(például regresszió számítás) és nem matema-tikai eszközökkel mutatja az OLAP adatbázist,amiben nem triviális összefüggések megtalálásátsegíti.

EPM: A vállalati teljesítménymenedzsmentrendszerek új szemléletű megoldások, amik KPI-kat definiálnak, figyelnek. Képesek ezen mutató-számokat hierarchikusan is kezelni, emiatt mind-három döntési szintet átfogják. Jelenleg mégnem annyira szabványosak, mint a kiérlelt ko-rábbi rendszertípusok, amiatt még további je-lentős fejlődés várható ezen a fronton.

KM: A tudásmenedzsment rendszer egygyűjtőfogalom, különféle altípusai vannak,

54


amikben az közös, hogy a vállalati tudás össze-gyűjtése és szétosztása az alapfeladat. Nem kö-tődik egyik vezetői szinthez sem.

ES: A szakértői rendszerek (Expert System)végigkísérik a teljes informatika történelmet, akor adta lehetőségeken belül mindig az volt a

feladatuk, hogy valamely speciális szakmai terü-let munkájához adjon informatikai támogatást(példa: szeizmika az olaj-kutatásban). Itt amesterséges intelligencia is komoly szerephez jut,tényeket és szabályokat tárol, ezekből következ-tetéseket von le.

8. ábra. SAP modulok

55


A továbbiakban néhány érdekesebb gondo-latot szeretnénk összefoglalni az egyes főbbrendszertípusokról, kitérve az új kihívásokra is,amikre az integráció adja meg az egyik lehetsé-ges választ.

5.2. Operatív szintű információsrendszerek

Ezen rendszerek a vállalat funkcionális terüle-teinek (marketing, gyártás, pénzügy, könyvelés,HR) napi munkáját támogatják. Nézzük megezek közül a legfontosabb részterületeket, amikcsak kiragadott példák!

Marketing: Értékesítés, piackutatás, eladá-sok elemzése, előrejelzése, piacbefolyásolás (hir-detések).

Gyártás: készletgazdálkodás (nyersanyag,félkésztermékek, késztermékek), termelésterve-zés, termelésirányítás, minőségellenőrzés.

Könyvelés: vevő és szállító oldali számlákkezelése, naplófőkönyv, bérszámfejtés.

Pénzügy: pénzügyi tervezés, ellenőrzés, elő-rejelzés, készpénzforgalom (készpénz és hitelgaz-dálkodás) menedzsment, költségvetés.

HR: munkakör tervezés, felvétel és elbocsá-tás, bérelszámolás, továbbképzések kezelése, amunkaerő ráfordítások hatékonyságának elem-zése, tervezése.

Az operatív szintű rendszerek emiatt általá-ban TPS, MIS, ERP, CRM, SRM és SCM rend-szerek.

A kifejezett cél az, hogy az egyes területekenjelentkező nagyszámú üzleti eseményeket bizton-ságosan kezeljék. Az üzleti események rögzítésemaguk is tranzakciók, azonban a tárolt adatokfeldolgozása (például a vevőszámlák elkészítése)is tranzakcionális. Régebben a kötegelt (batch)feldolgozás volt jellemző, mára egyre elterjed-tebbek a valós idejű (real-time) feldolgozások.A TPS rendszerek adatmodellje tipikusan 2 féleadatot tartalmaz: törzs (egyik típusa a paramé-ter táblák) és tranzakcionális adatokat.

A MIS rendszerek elsősorban a TPS adat-bázisokra épülve az operatív szintű döntésekhezadnak segítséget. A TPS az adatok biztonsá-gos kezelését és feldolgozását oldják meg, így azadatokból való információk kinyerésével csak alegszükségesebb mértékben foglalkoznak. Ezt ahiányt pótolják a MIS rendszerek, amikben ariportozási feladatokat lehet megoldani. Jellem-zője, hogy a riportok statikusak, nem biztosítjákaz alternatívák lekérdezésének dinamikus lehető-ségeit.

Az ERP rendszerek a TPS és MIS megoldá-sok egy „nagy” közös csomagba történő tovább-fejlesztései, ahol az új paradigma az integráció.Lefedi a TPS rendszereknél már említett funk-cionális modulokat, közöttük interface kapcsola-tokat alakít ki. Ezzel párhuzamosan a MIS igé-nyeit is igyekszik – kezdetlegesen szinten – kielé-gíteni.

A CRM és SRM rendszerekről már volt szó.Az SRM több fontos részfeladatot megold a vál-lalat üzleti körforgásában: beszállítók értékelése(felkutatása), a beszállítási feltételek menedzse-lése, keret-szerződések megkötése, ajánlatkéré-sek és azok kiértékelése, a beszerzési workflow,beérkeztetés.

Az SCM megoldások kezelik az ellátási lánc-ban lévő vevő-szállító kapcsolatokat, a láncbanlévő vállalatok közötti termelési és logisztikai ko-ordinációt.

5.3. Döntéstámogató rendszerek

A DSS és GDSS rendszerek tartoznak ide, amikkülönféle döntési modelleket ismernek, mindeh-hez adatbázisokat használnak. A döntéshozósaját ítéletalkotó képességét egészítik ki ezekaz interaktív szoftverek, amik képesek segítenia programozható (példa: lineáris programozás)vagy csak részben programozható döntések meg-hozatalában. A DSS a taktikai és startégiaszint – nem jól strukturált – döntéseit támo-gatja (példa: milyen befektetési csomagot vá-

56


lasszunk?). A DSS rendszerek ugyanakkor képe-sek alacsonyabb szintű döntések támogatásárais, erre jó példa egy fuvarszervező program. EgyDSS rendszer igazi értéke az a modell, ami jóműködést eredményező válaszokat adhat kérdé-seinkre. A GDSS rendszerek a modelleket cso-portok számára teszik elérhetővé, leküzdve ezzela térbeli és időbeli távolságokat is.

5.4. Az üzleti intelligencia

Az adatbázisok növekedtek és egyre világosabblett az a felismerés, hogy a vállalat adatai a vál-lalati vagyon része, amit ki kell használni. Ez-zel párhuzamosan jelentkezett egy új fogalom:diszparát adat. Alapvetően a vállalati adatokkaltöbb probléma is van, ami nehezíti az adatva-gyon jó „forgatását”:

• az adatok formátuma és jelentése változó

• az adatok pontossága nem ismert, kezelé-sükre nincsenek mindig világos szabályok

• az adatok időszerűsége nem megfelelő

• az adatok egyes részei csak különbözőadatbázisokból szedhetők össze

• az adatok nem „tiszták”, azaz azokat lo-gikai elemzésnek alávetve inkonzisztensek-nek találhatjuk

• egy adat egzisztenciája (létezik-e) is egyfontos megoldandó feladat

Az információs adatbázisok jelenleg legfejlettebbformája az adattárház (DW – Data Warehouse)koncepciója. A DW adatbázisok már jó mi-nőségű és feldolgozott adatokat tartalmaznak

OLAP kockákban. Ezt az adatraktározást per-sze nem kapjuk ingyen, a szakirodalom szerinta következő jól megtervezett lépések szüksége-sek hozzá, amit a már korábban is említett ETLkifejezéssel szoktunk illetni:

• az adatok összegyűjtése különböző forrá-sokból

• másolat készítése az adattisztás előtt

• adattisztítás, a tisztított adatok tárolásaaz előre definiált struktúrákba

• katalogizálás

A jó minőségű DW adatbázisokra építve a maiBI rendszerek (9. ábra) már nagyon fejlett infor-máció kinyerési technikákat alkalmaznak, amitreporting-nak nevezünk. Érdekes lehetőség azun. adatbányászat. Itt az elemzőnek van egyhipotézise, ennek megfelelően megfogalmaz egykérdést. Az adatbázis vizsgálatával 2 kimenetelelehet a hipotézisnek: elvetjük vagy elfogadjuk.A BI szoftverekben a klasszikus DSS és GDSSeszköztárak is megtalálhatóak.

Tágabb értelemben a 2000-es években megje-lent EPM rendszereket is a BI részeként szoktáktekinteni, hiszen hozzájárul az adatok elemzésé-vel a teljesítmények elemzéséhez. A terv és tény-adatok kezelésével a BI rendszerek a controllingkiváló támogatói. Az EPM -ben is előre tervezettKPI-ok vannak, amiket a mért adatokkal lehetösszevetni.

Az EIS rendszerek is integrálódtak a BI -ba,azaz a reporting funkcióknak van egy olyan felü-lete, ami kifejezetten a felső vezetők igényeinekkiszolgálását célozza meg.

57


9. ábra. A Business Objects felépítése

5.5. Tudásmenedzsment

A tudásmenedzsment rendszerek mások, mintaz eddig tárgyaltak, azok nagy része nem is aTPS adatokra épülnek. Ezek a programok tá-mogatják az információk összegyűjtését, tárolá-sát, szétosztását. Egyik fontos eszköztára a kol-laboratív tartalom-menedzsment (CM=ContentManagement). Manapság a portál technológiákfelé tolódik a hangsúly, erre a 4.6 pontban térünkki.

A tudásmenedzsment részeként tekintik aszakértői rendszerek bizonyos moduljait, a mes-terséges intelligencia megoldásokat (kézírás fel-ismerés, elektronikus dokumentumfeldolgozás és

scannelés, robottechnológia, stb...) és a már em-lített felsővezető ES rendszereket is.

5.6. Az integráció szerepe

Az eddigiekben sokféle információs rendszertí-pust vizsgáltuk meg röviden. Ugyanakkor ezek arendszerek térben szétosztva, különféle üzleti tu-lajdonosok számára működnek. Az alkalmazotttechnológiák száma is sokrétű, néha már alig-alig tudunk kiigazodni a technológiák „dzsunge-lében”. Mi az ami ebben a szituációban min-den vállalatnál előbb-utóbb jelentkezni fog? Azintegráció. Ezek a megoldások ugyanis nem a„holdon”, önmagukban működnek, hanem egy-

58


egy konkrét üzleti környezetbe kell ágyazni őket.Az integrációnak több aspektusa van, rövidennézzük meg őket!

10. ábra. SAP NetWeaver

A rendszerek közötti kommunikáció(EAI). A 2000-es évek elején jelent meg azEAI (Enterprise Application Integration) fo-galma. Addig a rendszerek között olyan alacsonyszintű volt az adatkommunikáció mennyisége,hogy ilyen eszközre nem volt szükség. A mostanifejlett informatika kiköveteli, hogy erre különeszközöket alkalmazzunk. A feladat technikailagnehéz, jelenleg az informatikai piacon ezen tevé-kenységnek az egyik legmagasabb a díja. Ma-napság egyre inkább üzenetkezelő rendszereketés adaptereket alkalmazunk ezen feladat megol-dására. Az EAI rendszerekkel a vállalatoknális tért hódít az elosztott számítástechnika, amia tranzakciókezelés egy magasabb szintjét is je-lenti (elosztott tranzakciókezelés). A technikainehézségek közül csak egy példát szeretnék ki-emelni. Tegyük fel, hogy A és B rendszerek (pél-dául adatbázisuk van) is képesek tranzakcióbanműködni. Amikor azonban A→B között adat-

mozgás akarunk megvalósítani, akkor a COM-MIT műveletét egyszerre kell kiadni A-ra és B-re, így a hagyományos megközelítés nem alkal-mazható. Miért? Amennyiben külön COMMITvan A-ra és B-re, akkor vagy adatot vesztünk,vagy duplázzuk azt.

MDM. A Master Data Management. A vál-lalatok gyakran több különböző, esetleg összesem kapcsolt informatikai rendszerben, adatbá-zisban tárolják adataikat. Ennek eredménye-képpen a vállalat tevékenységéhez kapcsolódótörzsadatok nincsenek összhangban, ábrázolásukpontatlan, redundáns, és az egyes példányok kö-zött eltérések is lehetnek. A probléma főkénta termékorientált, azaz termelő vagy kereskedővállalatok esetében jelentős, hiszen fő értékte-remtő folyamatuk a termék köré szerveződik, ígybármely pillanatban naprakész termékkatalógus-sal kell rendelkezniük. Ez mind a belső szereplők(beszerzés, gyártás stb.), mind a külső szereplők(szállítók, vevők stb.) számára alapvető fontos-ságú. Egy jó MDM szoftver az említett prob-lémák kezelése érdekében lehetőséget biztosít akövetkezőkre:

• általános és rugalmas adatmodell kialakí-tására

• törzsadatok importálására különböző for-rásokból

• adatok konszolidálására (duplikátumok ke-resése, hasonlóságok keresése, transzfor-mációs szabályok megadása által)

• törzsadatok szinkronizálására különbözőrendszerek között

• könnyen használatba vehető, skálázhatómegoldás kialakítására

• az adatkarbantartási költségek csökkentése

59


11. ábra. Az MDM felépítése

A törzsadatkezelési forgatókönyv részei:

• Törzsadat-konszolidáció (Master-dataconsolidation). Egyező törzsadatobjektu-mok azonosítása különböző informatikairendszerekben, a megfelelő objektumokközponti egyesítése és a megfelelő kulcs-leképezések létrehozása a további üzletifolyamatokban történő felhasználás céljá-ból.

• Törzsadatok harmonizálása (Master-dataharmonization). A cikkek, szállítók, ügy-felek stb. törzsadatainak tisztítása, rendbetétele, majd ezek visszajuttatása a kliens-rendszerekbe, az üzleti folyamatok feljaví-tására a jobban használható törzsadatokrévén.

• Központi törzsadatkezelés (Centralmaster-data management). A konszolidá-ció után a törzsadatok központilag kezelhe-tők, a logikailag összetartozó objektumokés attribútumaik változatásai és mozga-tásai is egyszerre, egy helyen végezhetőkel. Mindez az erre vonatkozó házirendekés vállalati szabványok felállítása után azújonnan létrejövő törzsadatok egységes,szabályozott kezelését is jelenti.

Portál. A rengetek alkalmazás, az információkés a hírek elérése komoly kihívás elé helyezi afelhasználókat, így gyorsan megfogalmazódik aUser Integration, azaz a portál igénye. Itt egysé-ges felületen lehet igénybevenni (vagy legalábbisaz elérését kezdeményezni) a vállalati informa-tikai szolgáltatásokat. A tudásmenedzsmentnekmegjelennek az új perspektívái: wiki, blog.

BPM (Business Process Management). Avállalat egyik értéke az üzleti folyamatai. A gya-korlatban olyan üzleti folyamatok is megfogal-mazódnak, amik rendszereket és szervezeti egy-ségeket (sőt SCM esetén vállalatokat is) átfog-nak. Egyre jobb BPM eszközök jelennek meg,amik új, érdekes kiegészítő szolgáltatásokkal isrendelkeznek. Ilyen például a Business RulesEngine, ami lehetővé teszi az üzleti szabályokkiemelését az egyes alkalmazásokból, így azokata továbbiakban több alkalmazás is használhatja.Az előny nyilvánvaló, csak két fontosat említünkmeg: költségtakarékosság az újrahasznosítás mi-att, de talán ennél is fontosabb az üzleti szabá-lyok konzisztenciája.

B2B. A vállalatok vagy azok ügyfelei közöttikommunikáció alapjait valósítja meg, legfonto-sabb szolgáltatásai: titkos és megbízható csa-torna az Internet és intranet között, digitális alá-írás, időpecsét, archiválás.

5.7. Irodaautomatizálás

Szinte mindenki találkozik ezekkel az eszközök-kel, aki irodában dolgozik. Főbb témái a doku-mentum menedzsment köré csoportosulnak:

• Az iratok és dokumentumok rendszerezett,biztonságos központi tárolása és visszake-resése

• üzleti és szervezeti folyamatok automatizá-lása, szabályozása (dokumentum központúmunkafolyamatok)

60


• az egész cég egyesített információs, doku-mentációs adatbázisának létrehozása

• a vezető hatékonyságának emelése, átte-kintési és ellenőrzési lehetőségeinek több-szörözése.

Ezekre a feladatokra alkalmas például azSPS+Nintex páros (http://www.nintex.com/en-US/Pages/default.aspx).

5.8. A jövő - ami már itt van(SOA, Cloud Computing)

A cloud computing mindmáig a kis cégek kö-rében volt népszerű, de a globális vállalatok ésaz egyéb nagy szervezetek félreteszik majd agátlásaikat és belevágnak a cloud-szolgáltatásokhasználatába, hiszen mostmár megtehetik, meg-éri nekik. A vállalati szintű menedzsment esz-közök, az adatintegrációs technológiák elérhe-tővé váltak, és válnak majd egyre gyorsabban.Az előfizetéses árazás ráadásul sokkal szimpa-tikusabb a cégek számára, mert jobban testre-szabható, pontosan annyit kell rászánni egy fel-adatra, amekkora igény van a cégen belül, nemkell felesleges kapacitásokat telepíteni.

A cloud, azaz felhő, az internet metaforája,arra utalva ahogyan ábrázolni szokás a világhá-lót diagramokon, illetve kifejezve azt a komp-lexitást, amivel a modern hálózatok rendelkez-nek. A cloud computing pedig az internetes fe-lületen alapuló technológiai megoldások, melyeklényege a valós-időben skálázhatóság, a szoftve-rek "szolgáltatásként" való megjelenítése, illetvea gyakorlatban eddig csak desktop verzióban el-képzelhető alkalmazások átköltöztetése a böngé-szőablakba.

A "Software as a Service" (SaaS), a web 2.0és egyéb jelenleg jól csengő technológiai tren-dek befogadásából és a meglévő rendszerekbe il-lesztéséből összeálló egésznek a célja, hogy kü-lönösebb erőforrások és befektetések nélkül fo-lyamatosan ki lehessen elégíteni a felhasználók

igényeit. Cél, hogy eközben a lehető legkeve-sebb helyen kelljen belenyúlni a helyi, meglévőrendszerekbe, illetve, hogy a felhasználók ne szo-ruljanak oktatásra.

A legismertebb példa a cloud computingratalán a Google Apps, ahol a levelek, fotóalbu-mok és egyéb információk, tartalmak a központiszervereken tárolódnak, böngészőn keresztül ér-hetőek el, de a funkcionalitás inkább egy asztaliszoftverére emlékeztet.

61

Üzleti informatika SOA – Service Oriented Architecture

6. SOA – a jövő üzleti és architekturális modelljeA cégek áttekinthetetlen informatikai rend-

szereire a megoldás nem az IT-költségvetés nö-velése, hanem a szemléletváltás az irányításban.Az elmúlt időszakot az jellemezte, hogy a vál-lalatok az egyes üzletágak bizonyos feladatainakellátására vásároltak rendszerek, amelyek aztánIT-részleg többnyire csak üzemeltetett. Így ala-kultak ki a szigetrendszerek vagy silók. Ezek arendszerek különböző platformokra, különbözőtechnológiával készültek, és adott üzleti területe-ket csak a "bedrótozott" folyamat szerint támo-gatnak, nincsenek felkészítve a folyamatok mó-dosítására és más üzleti folyamatokhoz kapcso-lására.

A szükségessé váló alkalmazásintegrációttöbbnyire pont-pont alapon, sokféle egyedi tech-nikával oldották meg, tovább növelve a komp-lexitást. De nemcsak a funkciók és folyama-tok vannak silókba zárva, hanem az adatok is,amelyek heterogén formájúak és inkonziszten-sek, ami rendkívül megnehezíti azok egységesvállalati szintű kezelését.

Ebben a környezetben a "visszapillantó tü-kör" jellegű IT-költségvetés a jellemző: a költ-ségek nagy része az üzemeltetésre és karbantar-tásra megy el, kevés jut stratégiai célokra, a ver-senyképességet javító új fejlesztésekre. Ugyan-akkor napjaink üzleti elvárásai lényegesen meg-változtak az IT-vel szemben.

Mit várunk az IT-től?

• Gyors, rugalmas reagálást a piaci változá-sokra (time to market).

• Vállalati szintű és a vásárlókra, partne-rekre kiterjesztett folyamatok automati-zálását/informatikai támogatását, pl. azelektronikus értékesítési csatornák kiszol-gálását.

• Átlátható, rugalmasan alakítható, mér-

hető üzleti folyamatok kialakítását.

• Egységes vállalati adatnézetek és törzsada-tok biztosítását.

• Az IT-költségek szinten tartását és éssze-rűbb felhasználását

• Az IT-beruházások üzleti prioritások sze-rinti megvalósítását

• Meglévő rendszereinket a kockázatok ésköltségek miatt csak indokolt esetben cse-réljük le.

• Nem akarunk hosszú ideig tartó, kockáza-tos, nagy átalakításokat.

Ezek az elvárások erősen függenek az IT rugal-masságától, hatékonyságától, és jelzik, hogy ameglévő architektúrával, illetve irányítási meg-közelítéssel ezen üzleti célok nem érhetők el. Aproblémák elsősorban a folyamatok, alkalmazá-sok és adatok integrációja, valamint a fejlesz-tés és üzemeltetés hatékonysága körül jelennekmeg. Mivel az üzleti igények általánosak és sür-getők, az IT-iparág kialakította válaszát: a SOA(Service Oriented Architecture), magyar termi-nológiával Szolgáltatás Alapú Architektúra, aza megközelítés, ami a fenti elvárásokat biztosí-tani képes, és az informatikai ipar fejlődésénekhajtóerejévé vált.

A SOA informatikai stratégia

Technikai megközelítésben a SOA egy architek-túra és technológiai modell, amely lehetővé teszi,hogy különböző alkalmazásokban (alkalmazás-csomagok, egyedi fejlesztésű alkalmazások stb.)megvalósított különálló üzleti és technikai funk-ciókból, szolgáltatásokból üzleti folyamatokat

62


megvalósító alkalmazásokat állítsunk össze. Tá-gabb megközelítésben a SOA informatikai stra-tégia, amely irányítja az egységes SOA alapú vál-lalati architektúra kialakítását és a vállalati al-kalmazásokban található diszkrét üzleti és tech-nikai funkciók együttműködő, szabványokon ala-puló szolgáltatásokká szervezését, azaz meghatá-rozza az IT működési és megvalósítási folyama-tait és előírásait.

A SOA stratégiának két, egymással szo-rosan összefüggő része van, a szolgáltatás-infrastruktúra (SOA architektúra) vagy máskép-pen a működtető technológia és a SOA irányítás(SOA Governance).

Szolgáltatás-infrastruktúra

A SOA nyílt, szabványos komponens techno-lógia, amelynek építőelemei a szolgáltatások.A szolgáltatások önállóan is működőképesek,platform- és eszközfüggetlenek (tetszőleges tech-nológiával készülhetnek), szabványos, jól defi-niált interfésszel rendelkeznek, és szabványosadatcsere- és kommunikációs protokollokkal ér-hetők el az elosztott hálózatokban.

A szolgáltatások két alapvető típusát külön-böztetjük meg. Az üzleti szolgáltatások teljesvagy rész üzleti funkciókat valósítanak meg (ügy-félkezelés, számlakezelés stb.). Az üzleti szol-gáltatások megvalósításához az egységesítés ésújrafelhasználás érdekében nélkülözhetetlenek atechnikai szolgáltatások, amelyek alacsonyabbszintű építőelemek, és az üzleti felhasználók szá-mára nem láthatók. Technikai szolgáltatás pél-dául a naplózás, az archiválás, a dokumentumtá-rolás, a megjelenítési szolgáltatások stb. A szol-gáltatások összekapcsolásából úgynevezett kom-pozit alkalmazásokat építhetünk kódolással vagydinamikus láncolással, utóbbit üzleti folyamat-kezelő eszközök segítségével.

A szolgáltatásokra alapozott alkalmazásokmegvalósításához azonban nem elegendő a kom-ponens alapú architektúra - még akkor sem, ha

a szolgáltatások mint üzleti logika egységek van-nak megvalósítva - mert egyrészt a nagy számúszolgáltatás tervezési és végrehajtási szintű ke-zelése speciális megoldásokat igényel, másrészta hagyományos komponenstechnológiában a fo-lyamatvezérlés, az integrációs mechanizmusok ésa szükséges adattranszformációk bele vannak kó-dolva a komponensekbe. Komoly gondok forrásaaz egységes, közös törzsadatok hiánya is. Ezérta Szolgáltatás Alapú Rendszerek kialakításáhozés működtetéséhez az erre a célra szolgáló SOAarchitektúrára van szükség.

A SOA infrastruktúra részei

Szolgáltatások: a SOA alapú IT-működés ese-tén a fejlesztők a projektekben monolit alkalma-zások helyett önállóan is életképes technikai ésüzleti szolgáltatásokat hoznak létre, alakítanakki, és azokat szabványos interfészen keresztülpublikálják. Az alap üzleti és technikai szolgál-tatások összekapcsolásával építhetők fel az üzletifolyamatokat támogató összetett, illetve folya-matcentrikus szolgáltatások.

Folyamatszolgáltatások (Business Pro-cess Management): a folyamatok vezérlését, au-tomatizálását megvalósító szolgáltatások, ame-lyeket a SOA architektúrában üzleti folyamatve-zérlő eszközök biztosítanak, amelyek lehetővé te-szik a humán feladatok támogatását (workflow)és a folyamatok automatizálását a folyamatele-meket megvalósító szolgáltatások láncolásával,továbbá lehetővé teszik a folyamatok szüntelenmonitorozását. A BPM motorok és az üzleti ak-tivitást monitorozó modulok (BAM) a SOA ar-chitektúra fontos elemei, hiszen a SOA megköze-lítés alapvető célja a rugalmas, könnyen módosít-ható üzleti folyamatok megvalósíthatóságának atámogatása.

Üzletialkalmazás-szolgáltatások: azújonnan fejlesztett üzleti szolgáltatások futtatókörnyezete. Célszerűen Java J2EE vagy .NETalkalmazásszerveren futó szolgáltatások, de min-

63


den más olyan környezet is lehet, amelyben lehe-tőség van szabványos interfészekkel és kommu-nikációs felülettel szolgáltatásokat publikálni.

Szolgáltatásbusz (ESB): a SOA alapú IT-infrastruktúra idegrendszerként funkcionál; egy-séges, központilag menedzselt kommunikációs ésbiztonsági szolgáltatásokat nyújt a szolgáltatá-sok és SOA infrastruktúra elemeinek az össze-kapcsolására, valamint a szolgáltatáshoz kapcso-lódó szabályzatok és nem funkcionális követel-mények érvényesítésére.

Szolgáltatástár (Registry-Repository): aSOA alapú IT-működés és irányítás a szolgál-tatásdefiníciók és a kapcsolódó követelményekközponti tárolásával lehetővé teszi a szolgáltatástervezési és fejlesztési ciklusának hatékony me-nedzselését, beleértve a publikálást, újrafelhasz-nálást, a függőségek, verziók és követelményekkezelését.

Elérési (access) szolgáltatások: azokata technikai szolgáltatásokat soroljuk ebbe a ka-tegóriába, amelyek segítségével biztosíthatjuk ameglévő alkalmazáscsomagokban (ERP, CRM,SCM stb. ) és egyedi fejlesztésekben találhatófunkciók szolgáltatásként való publikációját.

IT Service Management: monitorozza,menedzseli és biztosítja a szolgáltatásokat, al-kalmazásokat és erőforrásokat. A SOA alapú IT-működés nagyon fontos része, hogy a szolgálta-tások különböző aspektusait mérni tudjuk, bele-értve a szolgáltatás felhasználásának mértékét, anem funkcionális követelmények teljesülését, azadatforgalmat, a SOA infrastruktúra komponen-seinek a rendelkezésre állását stb. A folyamatosmérések lehetővé teszik a hibák gyors elhárításátés a hatékony üzemeltetést, sőt az üzleti folya-matok optimalizálását is.

Üzleti monitorozás, dashboard: a SOAmegközelítés egyik alappillére a rugalmas, átlát-ható és mérhető üzleti folyamatok biztosítása.Ezért a SOA architektúra az üzleti vezetés szá-mára is biztosít üzleti szemléletű monitorozásiés beavatkozási felületeket, ahol az üzleti telje-

sítménymutatók figyelemmel kísérhetők, és lehe-tőség van a beavatkozásra.

Front-end rendszerek, a szolgáltatásokfelhasználói: a szolgáltatásokat különféle al-kalmazások használhatják, amelyek közül a leg-fontosabbakat emeljük ki. A Business ProcessManagement Solution (BPMS) segítségével szol-gáltatásokból üzleti folyamatokat lehet felépíteniakár az IT bevonása nélkül is - így ezek a folya-matok rugalmasan, gyorsabban és kisebb költ-séggel módosíthatók, hiszen a központi folya-matvezérlés megszünteti a fejlesztés és működ-tetés redundanciáit. Az egységes vállalati int-ra/internet Portál biztosítja az alkalmazottak-nak és az ügyfeleknek az egységes, de személyreés szerepkörre szabható, több csatornán elérhetőfelhasználói felületet. A B2B/B2C megoldások-kal a szolgáltatások biztonságosan elérhetővé te-hetők az üzleti partnereknek és ügyfeleknek. Afelhasználói felületek kialakítását a prezentációsés kollaborációs szolgáltatások teszik gyorsabbáés egységesebbé.

SOA-irányítás

A SOA infrastruktúra, a szolgáltatások és azezekre épülő üzleti alkalmazások megtervezése,megvalósítása és működtetése a korábbi silóküzemeltetéséhez képest gyökeresen új megkö-zelítést igényel. A SOA előnyei csak meg-felelő irányítás mellett érhetők el. A SOA-irányítás az IT-irányítás kiterjesztését jelenti aszolgáltatások teljes életciklusára a tervezéstőla megvalósításon és tesztelésen át az üzemel-tetésig. A SOA-irányítás feladata nem a si-lók, hanem a szolgáltatások és a szolgáltatások-ból épülő alkalmazások fejlesztése és üzemelte-tése, másrészt a szigetszemlélet helyett a tel-jes IT-infrastruktúrában, szolgáltatatás- és al-kalmazás portfólióban mint egy virtuális egész-ben kell gondolkodni. Ugyanez igaz az üzleti fo-lyamatokra is, a helyi üzletági folyamatok mel-lett a teljes vállalaton átívelő és sok esetben azon

64


túlnyúló folyamatokban kell gondolkodni.Az SOA-irányítás fő alkotóelemei a követke-

zők:SOA irányítási modell: meghatározza a

szerepköröket, a döntési jogokat, a kapcsolódómérési és ellenőrzési mechanizmusokat és folya-matokat, amelyek az IT-döntések előkészítésé-hez, meghozatalához és végrehatásához szüksé-gesek. A döntési és végrehajtási mechanizmu-suk szabályzatokon (policy) alapulnak, amelyekmeghatározzák pl. az alkalmazások architektu-rális szabályait vagy a csomagalkalmazások ki-választási szempontjait. Az irányítási modellnekfontos eleme a projektfinanszírozási szabályzat,valamint a folyamattulajdonosok és -szponzorokmeghatározása. Az irányítási modellben el kellhelyezni a SOA kompetenciaközpont feladataités felelősségi körét is.

SOA referencia-architektúra: ez írja leteljes vállalati SOA architektúra tervét teljes ki-építés esetén. A referenciamodell meghatározzaaz alkotóelemeket, azon belül is a modulok szét-választását és kapcsolódását, ami lehetővé teszia SOA infrastruktúra lépcsőzetes, inkrementá-lis fejlesztését. Az izoláció és a kapcsolódás azESB-n keresztül történik. Mivel a referencia-architektúra kialakítása hosszú távra szól, a be-ruházás értékállósága és későbbi módosítható-sága végett célszerű nyílt szabványokat alkal-mazni. A SOA architektúra komponens alapúfejlesztést tesz lehetővé oly módon, hogy a kom-ponensek, azaz szolgáltatások üzleti feladatokatvalósítanak meg, a folyamatvezérlés, biztonságielemek és az integrációs/kommunikációs funkci-ókat nem kell és nem is szabad a szolgáltatá-sokba bekódolni, azokat egységes, újrafelhasz-nálható módon a SOA infrastruktúra biztosítja.

SOA ütemterv (Roadmap): ez a a SOAinfrastruktúra kialakításának terve, amely areferencia-architektúra teljes kiépítéséhez szük-séges lépéseket és azok várható ütemezését tar-talmazza. Fő területei: alap infrastruktúra(ESB, BPM, Registry stb. bevezetése), üzleti

funkció típusú szolgáltatások (pl. hitelezési vagyügyfélszolgálati folyamatok elemei), információ-elérési szolgáltatások (pl. központi dokumen-tumkezelő szolgáltatásainak publikálása), közösIT-szolgáltatások (egységes logolás, felhasználóazonosítás stb.). A referencia-architektúrát és azütemtervet az üzleti célok és megszerzett tapasz-talatok alapján rendszeres felül kell vizsgálni!

Metrikák: a SOA metrikák és siker krité-riumok felállítása és bevezetése vállalatonkéntváltozó, egyedi és nem feltétlenül egyszerű fel-adat. A SOA sikerességét három fő szempontalapján lehet talán a legjobban mérni: üzletielőnyök, IT-előnyök, továbbá szolgáltatások éskapcsolódó erőforrások újra felhasználásának aszempontjából.

Az irányítási modell és az ütemterv tervezé-séhez el kell végezni az aktuális IT-környezet ésa vállalati üzleti folyamatok nagyvonalú felmé-rését, valamint az aktuális IT-irányítási képes-ségek és irányítási struktúra részletes felmérésétés figyelembe kell venni a vállalat üzleti terveités prioritásait.

A SOA bevezetésének egyik leginkábbhangsúlyozott előnye az újrafelhasználhatóság.Ugyanakkor fontos megjegyezni, hogy nem min-den vállalatnak egyforma fontosságú és jelen-tésű az újrafelhasználás. Ez jelentheti egyrészta meglévő alkalmazás silókba zárt szolgáltatásokújrahasznosítását, illetve az újonnan kifejlesz-tett szolgáltatások, törzsadatok képességét arra,hogy későbbi projektekben újra lehessen hasz-nosítani őket. Mindkét esetben igaz, hogy azújrafelhasználást igen jól lehet mérni: hány pro-jektben lett hasznosítva egy adott szolgáltatás,hány meglévő szolgáltatást sikerült a SOA rend-szerbe integrálni és felhasználni.

A SOA másik, sokszor emlegetett előnye azagilitás, amely már sokkal absztraktabb, nehe-zebben mérhető fogalom. Az agilitásnak sok ol-dala van, ezekből talán a következők a legfonto-sabbak:

65


• Üzleti vagy IT-igény megvalósításáhozszükséges idő.

• SOA rendszer toleranciája; üzleti igé-nyek szintje, amelyeket a SOA, illetve IT-architektúra jelentős változtatása nélkülmeg lehet valósítani.

• Az üzleti igények száma, amelyeket a SOArendszer képes gyorsan kielégíteni.

A fejlesztési és az üzemeltetési költségek csökke-nése azok a további területek, ahol az előnyökmegjelennek. Itt az összehasonlíthatóság érde-kében a korábbi és az új projektekben is szük-ség van az összehasonlításhoz megfelelő részle-tezettségű ráfordításmérésekre, ami általában akorábbi időszakokra nem áll rendelkezésre, debevezetésük is ellenállásba ütközik.

Befejezésként a SOA alapú IT-működést sze-retnénk érzékeltetni néhány fontos kérdés kieme-lésével. A SOA architektúra és a szolgáltatásokkialakítása lépésekben, az üzleti prioritásokat fi-gyelembe vevő, a szolgáltatásokat felhasználó üz-leti projektekben történik. A projektek tervezé-sét és irányítását SOA-irányításban meghatáro-zott folyamatok mentén és az érvényes szabály-zatoknak megfelelően kell végrehajtani. A ter-vezés során, a tervezés alatt álló projekt igé-nyei, a SOA ütemterv és a rendelkezésre állószolgáltatás katalógus alapján a felelős üzleti ésIT-szakértőknek el kell dönteni, hogy a projektsorán milyen SOA infrastruktúra- és irányításielemeket kell bevezetni vagy módosítani, milyenúj üzleti és technikai szolgáltatásokat fejleszte-nek ki és milyen meglévő szolgáltatásokat hasz-nálnak fel a projektben készülő alkalmazáshoz.Ugyancsak határozni kell a projektfinanszírozás-ról. A projekt során újonnan fejlesztendő közösszolgáltatásokat lehet pl. az üzleti projekt költ-ségvetéséből vagy részben/teljes egészében köz-ponti SOA költségvetésből finanszírozni. A SOAinfrastruktúra- és irányítási elemek bevezetését aSOA kompetenciaközpont végzi. Ugyancsak az ő

feladatuk az üzleti projektekben folyó szolgálta-tásfejlesztés ellenőrzése és szakmai támogatása.

A SOA előnyei

• Az üzlet és az IT hatékonyabban képesegyüttműködni: az IT hatékonyabban ésgyorsabban ki tudja szolgálni a gyorsanváltozó üzleti igényeket. Az üzleti folya-matokban és szolgáltatásokban gondolko-dás biztosítja a közös nyelvet az Üzlet ésIT között.

• Átfogó, a teljes vállalati IT-t és üzleti fo-lyamatokat egységben kezelő, az üzlettelszorosabban együttműködő IT-irányításalakítható ki.

• Rugalmas, átlátható, mérhető, monitoroz-ható vállalati és kiterjesztett üzleti folya-matok alakíthatók ki.

• Rövidül a piacra jutás átfutási ideje (timeto market).

• Az IT-alkalmazások konszolidációja jel-lemzi. A szolgáltatásokba szervezéssel, atörzsadatok egységes kezelésével hosszú tá-von megszüntethetők a redundáns alkal-mazások.

• Inkrementális, üzleti prioritások szerint,lépésenként alakítható ki az új SOA archi-tektúra, a technikai és üzleti szolgáltatá-sok, új üzleti folyamatok, illetve végezhetőel az alkalmazáskonszolidáció.

• Csökkennek az üzemeltetési és adminiszt-ratív költségek. Az alkalmazáskonszolidá-ció miatt kevesebb alkalmazást kell üze-meltetni. Az üzleti folyamatok és törzsa-datok, szolgáltatásközpontú megközelítéseradikálisan csökkenti az operátorok napiadminisztratív teendőit, illetve egy hiba el-hárításához jóval kevesebb időre van szük-ség.

66


• Egységes fejlesztési és üzemeltetési mód-szertant lehet bevezetni, ezáltal mind csök-kenthetők a külső és a belső erőforrások,illetve javul a tervezhetőség.

• Szabványok alkalmazása jellemzi. Így le-hetővé válik, hogy az egyes szolgáltatáso-kat a funkcionális és nem funkcionális, il-letve egyéb követelményeknek legmegfele-lőbb szállító biztosítsa. Emellett elkerül-hetővé teszik, hogy a cég csak egy beszállí-tótól függjön, ráadásul a kiélezett verseny-helyzet jobb és költséghatékonyabb megol-dásokat biztosít.

• A fejlesztési költségek csökkentésének há-rom fő forrása van: egyrészt lehetővéválik a kód-újrafelhasználás az üzleti éstechnikai szolgáltatások újrahasznosításá-val, másrészt nő a kódolási hatékonyság.A folyamatok vezérlését, biztonsági szol-gáltatásokat, a törzsadatkezelést és az in-tegrációs/transzformációs logikát a SOAinfrastruktúra biztosítja, és itt jelentkezika költségcsökkentés harmadik forrása, azegységes fejlesztési módszertan és joggya-korlat.

Kovács AndrásIgazgató

IQSYS ZRt.

67

Informatikai szilánkok Tippek és trükkök

7. Informatikai szilánkok - tippek és trükkök

Az Informatikai Navigátor állandó rovata a szilánkok, aminek célja az, hogy minden érdekes, apróvagy elgondolkodtató dolgot feljegyezzen, leírjon. A mindennapok során sűrűn találkozunk egy-egy érdekes, ötletes megoldással, amiket a továbbiakban igyekszünk ebben a rovatban mindenkiszámára közkinccsé tenni. Minden kedves olvasó saját érdekes feljegyzését is várjuk abban areményben, hogy egyszer a Te írásod is megjelenik itt. Az írásokat erre az e-mail címre várjuk:[email protected].

7.1. Folyamatábrák készítése - aflow értelmező

A tanulmányainkat sokszor szeretnénk ellátniegyszerű, hagyományos folyamatábrákkal. Egykellemes és kézhezálló eszköz a flow programazoknak, akik szövegesen szeretnék leírni a folya-matábrák kinézetét, majd a LATEXhasználatávallegeneráni annak képét. Az eszköz webhe-lye: http://www.ctan.org/pub/tex-archive/support/flow/. Innen letölthető egy teljesenszabványos C program, amit minden C fordí-tóval le lehet fordítani. Mi a gcc-ét használtukubuntu linuxon. A kapott futtatható programarra képes, hogy egy egyszerű flow nyelven le-írt folyamatábra definícióból legenerálja azt aLATEXrészletet, amiből már kép is generálhatóvagy beszúrható bármely dokumentumba, mintpicture környezet. A fenti webhelyen egy tömörés hasznos flow nyelvi dokumentáció is található.

Nézzünk egy egyszerű flow leírást, amitmentsünk el egy test.flow file-ba!

Right 0

Choice . . N YKész vagy?

TagChoice . . Right Down

Jobbra vagy Le?TagRight 1Box

Jobbra menve . . .ToTagDownBox

Le f e l é menve . . .ToTagDownOval

STOP

Ezt így f o r d í t j u k l e :. / f low t e s t . f low

A kimenetre ez a LATEXprogramrészlet gene-rálódik:

\ begin { p i c tu r e }(16 .000000 ,7 .000000)(0 .000000 , −5 .000000)% p i c t u r e environment f l owcha r t genera ted by f l ow 0.99 f\put (0 . 0000 , 0 . 0000 ){\ l ine (1 , 0 ){0 .0000}}\put (0 . 0000 , 0 . 0000 ){\ vec to r (1 ,0 ){1 .0000}}\put (1 . 0000 , 0 . 0000 ){\ l ine (1 , 1 ){2 .0000}}\put (1 . 0000 , 0 . 0000 ){\ l ine (1 ,−1){2.0000}}\put (5 . 0000 , 0 . 0000 ){\ l ine (−1 ,−1){2.0000}}\put (5 . 0000 , 0 . 0000 ){\ l ine (−1 ,1){2.0000}}

68


\put (1 .0000 ,−2.0000){\makebox ( 4 . 0 0 0 0 , 4 . 0 0 0 0 ) [ c ] {\ sho r t s t a ck [ c ] {Kész vagy?}}}\put (5 . 0000 , 0 . 6000 ){\makebox ( 0 , 0 ) [ l t ] {N}}\put (3 .6000 ,−2.0000){\makebox ( 0 , 0 ) [ lb ] {Y}}\put (5 . 0000 , 0 . 0000 ){\ vec to r (1 ,0 ){1 .0000}}\put (6 . 0000 , 0 . 0000 ){\ l ine (1 , 1 ){2 .0000}}\put (6 . 0000 , 0 . 0000 ){\ l ine (1 ,−1){2.0000}}\put (10 . 0000 , 0 . 0000 ){\ l ine (−1 ,−1){2.0000}}\put (10 . 0000 , 0 . 0000 ){\ l ine (−1 ,1){2.0000}}\put (6 .0000 ,−2.0000){\makebox ( 4 . 0 0 0 0 , 4 . 0 0 0 0 ) [ c ] {\ sho r t s t a ck [ c ] {Jobbra vagy Le?}}}\put (10 . 0000 , 0 . 6000 ){\makebox ( 0 , 0 ) [ l t ] { Right }}\put (8 .6000 ,−2.0000){\makebox ( 0 , 0 ) [ lb ] {Down}}\put (10 . 0000 , 0 . 0000 ){\ l ine (1 , 0 ){1 .0000}}\put (11 . 0000 , 0 . 0000 ){\ vec to r (1 ,0 ){1 .0000}}\put (12.0000 ,−1.0000){\ framebox ( 4 . 0 0 0 0 , 2 . 0 0 0 0 ) [ c ] {\ sho r t s t a ck [ c ] {Jobbra menve . . .}}}\put (8 .0000 ,−2.0000){\ vec to r (0 ,−1){1.0000}}\put (6 .0000 ,−5.0000){\ framebox ( 4 . 0 0 0 0 , 2 . 0 0 0 0 ) [ c ] {\ sho r t s t a ck [ c ] {L e f e l é menve . . .}}}\put (3 .0000 ,−2.0000){\ vec to r (0 ,−1){1.0000}}\put (3 .0000 ,−4.0000){\ ova l ( 4 . 0000 , 2 . 0000 )}\put (1 .0000 ,−5.0000){\makebox ( 4 . 0 0 0 0 , 2 . 0 0 0 0 ) [ c ] {\ sho r t s t a ck [ c ] {STOP}}}\end{ p i c tu r e }

Amennyiben ezt a picture2 környezetet beszúrjuk dokumentumunkba, megkapjuk a következőkis folyamatábra részletet:

2A latex rendszerbe egy kiemelkedő képességű grafikus környezet van beépítve, amit így érünk el.

69


-��

@@@@@

��

��

@@

@@@

Kész vagy?N

Y

-��

@@@@@

��

��

@@@

@@

Jobbra vagy Le?Right

Down

- Jobbra menve...

?

Lefelé menve...

?'&

$%STOP

A latex2png paranccsal természetesen egybőlpng kép is készíthető.

A Terry Brown által készített flow generátordokumentációja (flowdoc.pdf ) 9 oldal, ajánlommindenkinek elovasára. Könnyen érthető és min-dent tartalmaz, ami egy hagyományos folyamat-ábra elkészítéséhez szükséges. Bizonyos esetek-ben sokkal hatékonyabb lehet ezzel a módszerrelfolyamatábrákat készíteni, például, ha sok ha-sonlót kell készíteni vagy nincs annyi időnk, hogyrajzoljunk. A flow nyelve annyira egyszerű, hogyazt egy program kimenetével is generálni lehet,így egy „kettős” generálási eljárással viszonylagjó kinézetű folyamatábrákhoz jutunk, kevés idő-ráfordítással.

7.2. Weblogic ejb3 készítése Net-Beans alatt

Ez a rövid recept azoknak szól, akik ismerik azejb technológiát és Weblogic környezetben is sze-retnék azt használna, miközben egy hatékonyjava fejlesztőkörnyezetben dolgoznak. A forrás-kódot NetBeans (esetleg eclipse) környezetbenlehet elkészíteni, a kérdés csupán annyi, hogymi módon készítsük el a lefordított, telepíthetőbinárist? Nézzük meg a lépéseket!

(1) New EJB projektet létrehozni NetBeans-ben.

(2) New message-driven bean létrehozása eb-ben a projectben (32. programlista)

(3) Az ejb java fájlnak így kell kezdődnie,természetesen valamilyen xxx csomagban (a javaprogram első sora: package xxx;)

1 // 32. programl i s ta : Message Driven Bean23 import javax . e jb . MessageDrivenBean ;4 import javax . jms . Message ;5 import javax . jms . MessageListener ;6 import javax . jms . TextMessage ;7 import javax . naming . I n i t i a lCon t e x t ;8 import org . apache . l o g 4 j . Logger ;9 import weblog ic . e jb . GenericMessageDrivenBean ;

10 import weblog ic . e jbgen . MessageDriven ;1112 @MessageDriven ( ejbName = "EventProcessor " , dest inat ionJndiName = "HU.MOL.EAI .FILE_CONNECTOR_JMSQ" ,13 dest inat ionType = " javax . jms . Queue" , i n i t i a lBean s InFr e ePoo l = "1" , maxBeansInFreePool = "1" )14 public class EventProcessor extends GenericMessageDrivenBean implements MessageDrivenBean , MessageListener15 {16 private stat ic f ina l long se r ia lVers ionUID = 1L ;

3Enterprise JavaBean

70


17 private stat ic f ina l Logger LOGGER = Logger . getLogger ( EventProcessor . class ) ;1819 /∗∗20 ∗21 ∗ @param message22 ∗/23 public void onMessage (Message message )24 {25 LOGGER. i n f o ( "START: ␣onMessage ( . . . ) " ) ;26 }27 }

A fordításhoz ant scriptet használhatunk,ami egy olyan taskot használ, amit a weblogicfejlesztői környezet biztosít számunkra. Az ant

build.xml így néz ki, egy példán kereszül meg-mutatva:

<pro j e c t name=" ejbgen_f i l eConnectorEjb " default="run−ejbgen "><taskde f name=" ejbgen " classname="com . bea . wls . e jbgen . ant . EJBGenAntTask"

c l a s spa th=" ejbgen . xml␣com . bea . core . ejbgen_1 . 0 . 0 . 0 . j a r " /><ta rge t name="run−ejbgen ">

<ejbgen source=" 1 .5 " outputDir = " s r c \ conf " d e s c r i p t o rD i r = " s r c \ conf " fo rceGenerat ion = " true "><f i l e s e t d i r=" s r c \ java \hu\mol\ ea i \ f i l e c o n n e c t o r \ p roc e s so r " i n c l ude s="EventProcessor . java " />

</ ejbgen></ ta rg e t>

</ pro j e c t>

(4) A NetBeans projekthez hozzá kell adniezeket:wls-api.jar, com.bea.core.ejbgen_1.0.0.0.jar

(5) Az ejbgen.xml -t be kell másolni a bu-ild.xml mellé.

(6) Természetesen implementálni kell java azonMessage() metódust, hiszen ebben lesz az üze-netfeldolgozó logika

(7) Futtatni a weblogic ejb-gen-t: setDomai-nEnv.sh, utána ant -f ejbgen.xml

(8) Build a NetBeans-ben, ami a telepíthetővégeredményt adja (egy jar file)

7.3. Seession cookie nevének beál-lítása Weblogic környezetben

Amikor 1-nél több web alkalmazást érünk elegy konkrét Weblogic környezetből, akkor a java

előre beállított JSESSIONID session cookie-jamindig felülíródik az utolsónak használt (azURL-ben hivatkozott) alkalmazáséval. Ez aztjelenti, hogy elromlik a session kezelés, azazebben a formában az alkalmazás használhatat-lanná válik. Ez egy biztonsági funkció, azaznem felesleges, ugyanakkor emiatt biztosítanikell, hogy minden web alkalmazás egyedi nevűsession cookie-val rendelkezzen. Ezt a problé-mát a web.xml mellé csomagolt weblogic.xml filehasználatával oldhatjuk meg, ahogy a példa ismutatja. A lényeg a CookieName paraméterbenvan, aminek az értékét most BEKISESSION-raállítottuk, így ez az alkalmazás ezt a nevet fogjahasználni a JSESSIONID helyett.

<!DOCTYPE weblogic−web−app PUBLIC "−//BEA␣Systems ,Inc . //DTD␣Web␣Appl i ca t ion ␣ 8 .1//EN" "weblogic810−web−j a r . dtd"><weblogic−web−app>

<se s s i on−d e s c r i p t o r><se s s i on−param>

<param−name>CookieMaxAgeSecs</param−name>

71


<param−value>−1</param−value></ se s s i on−param>

<se s s i on−param><param−name>Inva l i d a t i o n I n t e r v a l S e c s</param−name><param−value>60</param−value>

</ se s s i on−param><se s s i on−param>

<param−name>TimeoutSecs</param−name><param−value>3600</param−value>

</ se s s i on−param><se s s i on−param>

<param−name>CookieName</param−name><param−value>BEKISESSION</param−value>

</ se s s i on−param></ se s s i on−d e s c r i p t o r>

</weblogic−web−app>

7.4. Webservice kliens proxy gene-rálás Weblogic környezetben

A világon valaholt publikált soap alapúwebszolgáltatásokat nagyon egyszerűen hasz-nálatba tudjuk venni weblogic környezet-

ből is. A lenti build.xml egy minta antscript, ami a http://molszhbits01:8080/jaxrpc-MOLAgent/agent?WSDL URL-en lévőszolgáltatásból generál kliens proxy-t. A script-hez nem fűzünk magyarázatot, annyira egyszerű,feltéve, ha ismerjük az ant építő eszközt.

webse rv i c e_c l i en t s / order $ cat bu i ld . xml<pro j e c t name=" s t a t i c " default=" a l l " based i r=" . ">

<!−− set g loba l propert ies for th i s bui ld −−><property environment="env"/><property f i l e="my. p r op e r t i e s "/><property name=" bu i ld . compi ler " value="${ compi ler }"/><property name=" source " value=" . "/><property name=" bu i ld " value="${ source }/ bu i ld "/>

<taskde f name=" c l i e n t g en "classname="weblog ic . ant . t a skde f s . webse rv i ce s . c l i e n t g en . ClientGenTask">

<c la s spa th><pathelement path="/bea/weblog ic81 / s e r v e r / l i b / webse rv i ce s . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b /weblog ic . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b /xmlstream . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b / wsc l i en t81 . j a r "/>

</ c l a s spa th></ taskde f>

<ta rge t name=" a l l " depends=" clean , ␣ bu i ld "/>

<ta rge t name=" c l ean " ><de l e t e d i r="${ bu i ld }"/>

</ ta rg e t>

<ta rge t name=" bu i ld "><mkdir d i r="${ bu i ld }"/><c l i e n t g en wsdl=" ht tp : // c eg s zhb i t s 01 : 8080 / jaxrpc−CEGAgent/ agent ?WSDL"

autotype="True"overwr i t e="False "useServerTypes="False "packageName=" i d s s e r v i c e "c l i e n t J a r="${ bu i ld }"/>

<javac s r c d i r="${ source }" d e s t d i r="${ bu i ld }" in c l ude s="Main . java "><c la s spa th>

<pathelement path="/bea/weblog ic81 / s e r v e r / l i b / webse rv i ce s . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b /weblog ic . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b /xmlstream . j a r "/><pathelement path="/bea/weblog ic81 / s e r v e r / l i b / wsc l i en t81 . j a r "/>

</ c l a s spa th></ javac>

72


</ ta rge t>

<ta rge t name="makejar"><ja r d e s t f i l e=" . / i d s s e r v i c e . j a r ">

<f i l e s e t d i r="${ bu i ld }"/></ j a r>

</ ta rg e t>

<ta rge t name="run"><java classname="Main" fo rk=" true " >

<c la s spa th><pathelement path="${ bu i ld } ;${ ex . c l a s spa th }"/>

</ c l a s spa th></ java>

</ ta rg e t>

</ pro j e c t>

A példában keletkezett idsservice.jar proxykönyvtárat a programunkhoz kell linkelni. Awebservice proxy agent (ez reprezentálja a

webservice-t Java oldalról) megszerzését, illetveannak sendData() metódusának meghívását akövetkező programrészlet mutatja.

MOLLLESXMLService s e r v i c e = new MOLLLESXMLService_Impl( "http :// cegbudalldm01 :8080/ jaxrpc−CEGAgent/ agent ?WSDL" ) ;AgentIF agent = s e r v i c e . getAgentIF ( ) ;wsResult = agent . sendData ( xmlObject . t oS t r ing ( ) ) ;

7.5. Amikor a CPU „túlpörög”

Előfordul, hogy egy Weblogic server túlpörgeti aprocessor-t és szeretnénk tudni, hogy mi az oka,de legalább azt, hogy melyik szálon (Thread-en)történt a „baleset”. A ps -mp <WLSpid> -o TH-READ paranccsal megkereshetjük a gyanús szá-lat. A <WLSpid> az operációs rendszerszintűPID (process ID). A parancs listázza a thread-eket, így kikereshető a kritikus szál. A kill -3<WLSpid> parancs egy thread dump-ot készít.

Képesek vagyunk használni a java debugger-t is:dbx -a <WLSpid>.

A dbx -ben lekérhető „list of all threads” hasz-nálva a thread command -ot. Az output threadlist-ben megkereshetjük a CPU intenzív TID-ünket (formátuma: $t<num>). A dbx th info<num> parancsával részletesebb információt iskaphatunk a kérdéses szálról (output find the :pthread_t (hexadecimal) value).

Fontos : leszedés a processről : detach.

73

3. szám

Documents

Transcript of 3. szám