A Forrás s rendszer sa. GriffSoft Zrt

A Forrás rendszer SOA-sítása Dr. Dányi Gábor GriffSoft Zrt. 2008. 05. 21.

Mi a Forrás? „ „ „

„Ügyviteli operációs rendszer” Szabványos és specifikus üzleti modulok Intézményi felhasználók „

„

Oktatási Min., Közl. és Vízügyi Min., Belügymin., Igazságügyi Min., MNV, Pécs, Székesfehérvár, …

Vállalati felhasználók „

Lombard Lízing, Tisza Volán, Galicoop, Erdért, Albacomp, Pécsi Sör, Csemege-MATCH, …

Miről lesz szó? „ „ „ „

A Forrás rendszer eredeti architektúrája Forrás SOA felhasználói követelmények Forrás SOA megvalósítása Üzemeltetési tapasztalatok

Az eredeti Forrás architektúra „

Klasszikus kliens-szerver architektúra Visual C++ / MFC „ SQL Server „

„

Saját nyelv (Forrás-SQL), futtató Az üzleti logika nagyrészt ebben, kisebb részt T-SQL tárolt eljárásokban „ Felhasználói felület kezelése és üzleti logika nincs elkülönítve „

„

A futtató és a Forrás-SQL programok nincsenek felkészítve többszálú működésre

Az eredeti Forrás architektúra „

Zárt rendszer Nincs programozható, csak interaktív felület „ Interaktív felhasználó azonosítás és szerepválasztás „ Futtató környezet inicializálása felhasználó szerepe és jogosultságai alapján (nagy erőforrásigény!) „

„

Hosszú futásidejű - akár 20 percen túli – funkciók („kávészünet”)

Az eredeti Forrás architektúra

Forrás futtató Forrás adatbázis

SOA követelmények „

Üzleti logikai funkciók legyenek elérhetőek webszolgáltatáson keresztül IS Egy funkció csak egyszer legyen implementálva „ A korábbi kódok a lehető legkevesebb módosítással (és újrateszteléssel!) felhasználhatók legyenek „

„ „

SSO (Single Sign-On) támogatása Felhasználói felületek célzott elérése workflow feladatkosárból

SOA követelmények „

A webszolgáltatás felülete legyen szabványos, de maradjon a Forrás-SQL nyelv „RAD” előnye Új funkció felvételéhez ne legyen szükség bináris modulok publikálására (és tesztelésére!) „ Legyen behatárolható egy módosítás hatása (mit kell újratesztelni?) „

„ „ „

Legyen mód aszinkron végrehajtásra A szolgáltatás oldalra jól skálázható legyen Mindezt olcsón, gyorsan, kevés kockázattal

Felhasználói igény Forrás SOA kiszolgáló SOA kliens

Forrás futtató

Forrás futtató Forrás adatbázis

Megvalósítás „

Forrás-SQL futtató out-process COM kiszolgálóvá alakítása Interaktívan és alkalmazásból is vezérelhető: eredeti felhasználásra tramszparens „ Azonosítás COM hívással is: SSO támogatása „ Futtatás COM hívással: webszolgáltatásból és workflow kliensből is elérhető „

„

Minőségbiztosítás: Columbus „

C++

Megvalósítás „

Üzleti funkciók felkészítése „

T-SQL általában nem gond „ Modularizálás a kiajánlandó funkciók szerint

„

Forrás-SQL gond (korábban 2 rétegű tervezés) „ Modularizálás a kiajánlandó funkciók szerint „ Felhasználói felület és üzleti logika szétválasztása „ „Állapotmentesítés”

„

Minőségbiztosítás: Columbus T-SQL „ Forrás-SQL „

Megvalósítás „

Forrás webszolgáltatás (ForrasWS) „

Standard eszközök alkalmazása „ .NET Framework 2.0, WSE 3.0, Enterprise Library

„

Forrás-SQL futtató COM kiszolgálóként „ Minden kéréshez külön példány: többszálúsítás megúszva „ Performancia: nem használt futtatópéldányok gyorsítótára

„

„RAD” funkcióbővítési lehetőség „ Általános végrehajtó metódus sorosítási szabállyal „ Funkciók sémái adatbázisban tárolva

„

Aszinkron végrehajtás „ Feladatsor, Windows service alapú ügynök

„

Minőségbiztosítás: Columbus „

C#, OO Design Metrics, Best Practices

Forrás SOA Forrás SOA adatbázis Forrás SOA felület (web service)

Forrás SOA ügynök (Windows service)

COM felület Forrás futtató Forrás adatbázis

Tapasztalatok „

A webszolgáltatás lazán csatolt Ha egy hívásra nincs válasz, nem tudhatjuk mi az állapot a másik oldalon „ A sorrendérzékeny folyamatokra jobban kell figyelni, különösen aszinkron végrehajtáskor „ Hibakeresés, nyomkövetés új módszereket igényel „

„ „

Csak rövid futásidejű funkciókat szabad szinkron módon elérhetővé tenni Az aszinkron feladatsorban hangolhatóvá kell tenni a prioritásokat és a sikertelen végrehajtások ismétlését