Elektronikus kereskedelmi rendszer tervezése és megvalósítása IBM környezetben

BME, Automatizálási és Alk. Informatikai Tanszék

Bevezető

Napjaink web alapú alkalmazásai eltérő komplexitásúak. Megvalósításukra számos eszköz áll rendelkezésre. Az egyszerűbb alkalmazások elkészítéséhez nem szükséges hosszú tervezési folyamat, hiszen azok könnyen átláthatóak, így a régi, jól bevált rendszereket lehet alkalmazni. Ezzel ellentétben, ahogy a rendszer bonyolultsága nő nem csak egyszerű lekérdezésekről van szó -, úgy válik szükségessé a tervezés és dokumentálás. Ezt illusztráljuk egy konkrét példán keresztül.

A webes alkalmazás-fejlesztés gyakorlata

Tekintsük át a webes alkalmazás-fejlesztés eszközeit kialakulásuk sorrendjében és vizsgáljuk meg több aspektusból, mi volt a cél a kifejlesztésük során.

A statikus HTML-ek után megjelent az igény dinamikus tartalom megjelenítésére is (számlálók, egyszerű űrlapok feldolgozása, stb.). Mivel a HTTP lekérdezés-válasz alapú protokoll, ezért ezek a programok a lekérdezés, mint input alapján hoztak létre egy választ az outputon.
A CGI-k által támogatott funkcionalitás később kibővült az adatbázis-eléréssel, így perzisztens adatok kezelésére is kínálkozott megoldás: az architektúra kétrétegűvé bővült.
Hátrányai közé sorolható, hogy a CGI program minden egyes lekérdezéskor betöltődik a memóriába, és a lekérdezés feldolgozása után futása véget ér. Ennek egy következménye, hogy a perzisztens adatokat adatbázisban kell tárolni. A terhelés növekedésével a processzek indítása és az adatbázis-kapcsolatok létrehozása növeli a válaszidőt.

Speciális Alkalmazás-szerverek (Cold Fusion, Domino, Zope)

Speciális alkalmazás szerverek kialakulásához két különböző út vezetett. Vagy egy már meglévő rendszert tettek weben is elérhetővé, vagy egy teljesen új szervert hoztak létre valamely speciális igény kielégítése céljából.
Jellemzően a célfunkciót kiemelkedően jól látják el, viszont nehézséget okozhat más jellegű feladatok megoldása.
A megvalósítandó rendszer tervezése problematikus, tervezési módszertanok nem, vagy csak körülményesen alkalmazhatóak.

Java alkalmazás szerverek (Apache Tomcat, IBM WebSphere, BEA WebLogic, Allaire JRun, Orion, stb.)

Felmerült az igény kapcsolat- és alkalmazás szintű (láthatóságú) változók kezelésére, melyek a memóriában maradnak, így is csökkentve a válaszidőt. Ezzel párhuzamosan kezdett teret nyerni az objektum-orientált megközelítés a webes programozásban, a Java szervetek által. A Java technológia a nyelv rugalmasságának köszönhetően már alkalmas az időközben megjelenő új kihívások leküzdésére. Így már háromrétegű architektúra is megvalósítható, mely révén lehetőség nyílik nagy komplexitású alkalmazások implementálására.

Objektum-orientált megközelítés

Egy bonyolultsági fok fölött - ahol már nem átlátható a rendszer- szükségessé válik annak megtervezése, és dokumentálása. Erre alkalmas leíró eszköz az UML, mely lehetővé teszi a modellalkotást, az oldalstruktúra leírását és kódgenerálást a tervek alapján. Az objektum-orientáltság egyik következménye, hogy a rendszer komponens alapú, így könnyebben karbantartható és új igények esetén a régi elemeket újra felhasználhatóak.

Egy konkrét alkalmazás

A tervezés és fejlesztés során az UML alapú megközelítésnél is ismert és bevált projektlépéseket követtük.

Üzleti követelmények

Az általunk feltételezett megrendelő rendelkezik egy már létező nem feltétlenül online - eladói hálózattal. A megrendelő céljai és lehetőségei:

a marketing koncepció támogatása,
a reklámkampányok kibővítése online vásárlási lehetőségekkel,
kifutó termékek értékesítésének lehetősége,
árdiszkrimináció alkalmazása - vásárlók csoportjainak elkülönítése,
e-commerce rendszer üzemeltetése a meglévő hagyományos értékesítési hálózat veszélyeztetése nélkül,
cél egy közös adminisztrációs felülettel rendelkező többnyelvű megoldás, mely több országot is kiszolgálhat,
végül nyilvánvaló szándék új vevők megszerzése és a meglévők megtartása.

A megrendelő így kényelmes, gyors és biztonságos online vásárlási lehetőséget biztosíthat a vásárlóknak, és meglévő értékesítési hálózatát használva kézben tarthatja az internetes tartalmat és az online piacot.

Célkitűzések

A projektünk célja volt, hogy egy kellőképpen általános, többnyelvű e-commerce megoldást fejlesszünk, amely termékek egy csoportjának online értékesítését segíti elő a hagyományos eladási csatornák bevonásának lehetőségét megtartva, oly módon, hogy a rendszer működtetője (a feltételezett megrendelő) egy kézben tartja az online koncepciót.

A fő rendszerjellemzők a következők:

termékek webes megjelenítése
vásárlási folyamat kezelése
szállítási költségek számítása
online hitelkártyás fizetés
több ország - több nyelv támogatása
több viszonteladó kezelése
online raktárkészlet nyilvántartás
integrációs lehetőségek más rendszerekkel

Felhasználói csoportok

A különböző felhasználói csoportok tevékenységeinek definiálásához a használati eset (use case) megközelítést alkalmaztuk. Célunk az volt, hogy felismerjük, milyen külső szereplők (actor) állnak kapcsolatban rendszerünkkel, és hogy ezek a szereplők mire használják azt. Így meghatároztuk a rendszer határait, tisztáztuk, hogy milyen feladatokat kell a rendszernek ellátnia.

A használati esetek rendszerezése folyamán a következő diagrammhoz jutottunk:

1. Ábra A rendszer használati eset diagrammja

Tervezés

A részletes specifikációból az elemzés során készült először egy magas szintű osztálydiagram. Ez a modellnek az entitás osztálydiagramja, amely egyrészt megfelel az adatbázis terveinek, másrészt az alkalmazás középső rétegének üzleti osztályait jeleníti meg. Ezen osztályoknak tehát elsősorban tulajdonságaik vannak, és nem a metódusaik dominálnak. Ezt követően készült el a menedzser osztályok diagramja, és a megjelenítési réteg terve.

Szoftver vetület

Lotus Notes/Domino 5.0

A Lotus Notes/Domino rendszer biztosítja az adatbázis funkciókon kívül az adminisztrációs és tartalom menedzsment felületet, valamint a levelezési szolgáltatásokat. A Lotus Notes kliens egy könnyen kezelhető felhasználói felületet biztosít. Ha az adatbázisokat egy Domino szerveren helyezzük el, akkor a Notes kliens által kínált funkciók nagy része weben is elérhető lesz, tehát a Lotus Notes/Domino rendszert, mint publikációs illetve tartalom menedzsment interfészt alkalmazhatjuk.

A szerveren tárolt adatbázisokról a felhasználók munkaállomásain másolatok (Notes terminológiával élve: replikák) készíthetők. A felhasználók akár offline is dolgozhatnak a helyi adatbázisaikban, majd később a helyi replikák szinkronizálhatók a szerveren tárolt adatbázisokkal. A Lotus Notes/Domino rendszer kifinomultan képes szabályozni az adatokhoz és szolgáltatásokhoz való hozzáférést.

Java alkalmazás szerver

A középső réteg Java alkalmazása felelős a megjelenítéssel kapcsolatos üzleti logika megvalósításáért. Itt volt a legkézenfekvőbb az objektum orientált megközelítés és tervezés, melyben nagy segítséget jelent az StP-UML által biztosított környezet.

A megjelenítéshez JSP technológiát használtunk. A teljesítmény javítása céljából a sűrűn lekérdezett adatbázis rekordok paraméterezett módon cache-elve tárolódnak a memóriában, ilyenek a nyelvi rekordok, a gyakran hivatkozott termékek, stb. A termékek strukturált megjelenítéséhez tetszőleges mélységű katalógusrendszert alkalmaztunk, a termékek csoportosítására a kategóriákon kívül más lehetőség is biztosított.

Kommunikációs felület

A rendszerben szabványos kommunikációs protokollokat alkalmaztunk. A Java alkalmazás szerver HTTP-n keresztül éri el az XML formátumú adatokat szolgáltató Domino szervert. A Domino szerver és a Lotus Notes kliensek a Lotus Notes/Domino natív protokolljával, NRPC-vel (Notes Remote Procedure Call) kommunikálnak TCP szállítási réteg felett. A böngészők HTTP illetve HTTPS protokollokkal érik el a Java alkalmazás szervert.

Tesztelés

Mivel az általunk fejlesztett rendszer funkcionálisan is és architektúráját tekintve is két jól elkülöníthető részre tagolódik, a tesztelést az alábbi fázisokra osztottuk:

Lotus Notes/Domino alkalmazás tesztelése: A Lotus Notes/Domino alrendszer tesztelése arra irányult, hogy a Domino szerver a Notes adatbázis tartalmának megfelelő XML válaszokat ad-e a lekérdezésekre. A tesztelés úgy folyt, hogy manuális úton elkészítettük a helyes XML választ az adatbázis tartalom ismeretében, majd ezzel a rendszernek a lekérdezésre adott válaszát összevetettük.
Java/JSP tesztelés: A modell osztályainak illetve a rájuk épülő JSP alapú felhasználói interfésznek a tesztelésekor az adatbázis interfész rétegben egy dummy osztály szolgáltatta az XML fájlokat, melyeket a lokális fájlrendszerből olvasott.
Integrációs teszt: Az integrációs teszt a Lotus Notes/Domino alrendszerrel és a Java alkalmazás szerverrel végzett sikeres tesztelés után következhetett. Itt egy szimulált megrendelést végeztünk, és eközben figyelemmel kísértük a Domino szerver és a Java környezet közötti kommunikációt.

Telepítés

A rendszer négy jól elkülöníthető részből áll:

Lotus Domino szerver
Lotus Notes kliensek
Java alkalmazás szerver
Web böngészők

A Domino szervert és a Java alkalmazás szervert telepíthetjük ugyanazon hardverre, de teljesítmény-optimalizálási szempontból érdemes külön gépeken elhelyezni őket. Az intenzív XML/HTTP illetve CORBA/IIOP alapú kommunikáció zavartalanságának fenntartása céljából javasolt a két szervert egy dedikált lokális hálózaton üzemeltetni.

Az adminisztrátor és a viszonteladók Lotus Notes kliensei TCP/IP protokollal csatlakoznak a Domino szerverhez, és a szerveren található termék-, vásárló- és megrendelés-adatbázisokat rendszeres replikáció útján tartják a szerverrel szinkronizált, konzisztens állapotban.

A vásárlók web böngészők segítségével HTTP illetve HTTPS protokollal csatlakoznak a Java alkalmazás szerverhez. A vásárlók oldalán a web böngészőn kívül egyéb szoftver telepítésre nincs szükség.

Továbbfejlesztési lehetőségek

Munkánk témáját képező alkalmazás továbbfejlesztési lehetőségeit alapvetően két csoportba sorolhatjuk, aszerint, hogy a rendszernek a felhasználók felé nyújtott funkcionalitását vagy a rendszer architektúráját tekintjük-e a fejlesztés tárgyának.

Funkcionális fejlesztési irányok:

A projektben elsősorban elosztott publikációs és adminisztrációs rendszerként használjuk a Lotus Notes/Domino rendszert. Nyilvánvaló továbblépési lehetőségként kínálkozik, hogy kiaknázzuk fejlett levelező (messaging), csoportmunka támogató (groupware) és munkafolyamat kezelő (workflow) tulajdonságait. Tipikus példa erre egy Customer Relationship Management vagy egy direkt marketing alrendszer, illetve a megrendelés objektumok életciklusára definiált munkafolyamat (workflow) ciklus.

Architekturális optimalizálás:

A Domino szerver teljesítményének növelése érdekében különösen nagy számú termék és regisztrált felhasználó esetén megfontolandó annak a lehetősége, hogy ezen adatokat a Domino szerveren keresztül transzparensen elérhető relációs adatbázis-kezelő rendszerben tároljuk.
A Java alkalmazás szerver oldalán a rendszer megbízhatóságát és átláthatóságát növelhetjük, ha bizonyos modellbeli funkcionalitást szerveroldali komponensekben, Enterprise JavaBeans segítségével valósítunk meg. Példaképp említeném a hitelkártyás fizetés és a raktárkészlet módosítás funkciók megvalósítását, melyek kiaknázzák az EJB tranzakció kezelő tulajdonságait.
A JSP-k kiszolgálási idejét csökkenthetjük, ha a gyakran hivatkozott objektumokat egy objektum cache-ben tároljuk, így nincs mindig szükség adatbázis lekérdezésre.

Értékelés

Teljesítmény: az alkalmazott technológia következményeként, főleg a cache alkalmazása miatt a válaszidők gyorsabbak, mint egy hasonló CGI-s megoldás esetén. A használt XML alapú kommunikáció viszont nem váltotta be a hozzá fűzött reményeket.
Karbantarthatóság: A termék adatok karbantartása, és általában a rendszer üzemeltetése kényelmes.
További funkciók hozzáadása: a Java alkalmazás szerver oldalán történő módosítások gyorsan végrehajthatóak, ellenben a Lotus Notes oldalon az XML generáló ügynökök átírása hosszadalmas.