Com technológia a centura csapatfejlesztőben egyszerű és minden programozó - szoftver számára elérhető

Tartalomjegyzék

Hosszú távúak azok az idők, amikor a program egy számítógépen dolgozott, amikor egyetlen szoftver modul megoldott minden feladatot; Természetesen nem voltak nagyon összetettek ... Jelenleg a programozási technológiák olyan gyors ütemben fejlődnek, hogy a programok szűkültek egy számítógépen. Másrészt szinte lehetetlen elképzelni, hogy egy programozó, akár egy átlagos összetettséget is, egy programozó hozta létre, így a feladatok bonyolultabbá váltak, így az információs rendszerek működésének technikája bonyolultabbá vált. Régóta megszoktuk azt a tényt, hogy a programok az "ügyfél-kiszolgáló" architektúrájában dolgoznak: lehetetlen nélkül bemutatni a DBMS (adatbázis-kiszolgáló) munkáját és az internetszolgáltatás (WEB szerverek) működését. A COM technológiák és szabványok megérkezésével az információs rendszerek létrehozásának gyakorlatában az egyes programozók és a programozók kis csoportjai számára elérhetővé válik a különböző alkalmazások szervereinek létrehozása.

COM technológia A Centura három fő tulajdonsággal rendelkezik:

• Többszintű szoftverrendszerek (N-Tier) megépítése, COM-szervereken alapulva.
• Csatlakoztassa az ActiveX objektumokat és konfigurálja azokat.
• Az OLE mechanizmusok használatával jelentősen bővítheti az olyan alkalmazások képességét, amelyek minimalizálják a szoftverrendszerek fejlesztésének költségeit, és kifinomultabbá teszik azokat.

A COM két utóbbi lehetőségét egy másik cikkben tárgyalja - a Centura Team Developer ActiveX komponensei: alapelvek és alkalmazási technológia. Ezért itt elsősorban a COM szerverek és az alkalmazások közötti kommunikáció kérdéseivel foglalkozunk.

COM technológia és COM objektumok

A komponens objektummodell (COM) egy specifikáció (szabvány), amelyet a Microsoft kifejlesztett objektumorientált koncepció alapján komplex szoftverrendszerek építéséhez. Az összetevőket "fekete doboz" képviseli, ezek teljes mértékben elegendők a pozíciókból: beállítások, viselkedési módok, attribútum tulajdonságok, súgórendszer, kivételek kezelése stb. A COM objektumok az ügyfélalkalmazásokba integrálódnak, vagy távoli feldolgozásukat biztosítják, és az ügyfél nem tudja, hogy a feldolgozás más számítási erőforrásokon történik.

Ez a megközelítés biztosítja az adatok elosztott feldolgozását, a szoftver termék jelentős részének önálló fejlesztését és hibakeresését, valamint a létrehozandó szoftver magas szintű felcserélhetőségét és módosíthatóságát. Így a jelentős szellemi erők vonzzák a szinte minden szoftverrendszer fejlesztését, amely végső soron biztosítja az információs technológia gyors fejlődését. Tudomásul veszem, hogy a COM-összetevők megszerezzék a szoftver termék tulajdonságait, és kétségtelenül hamarosan meglátjuk azokat a szoftvertermékek piacán egy külön verzióban, és nem csak más szoftver termékek összetételében. Az interneten már nagy számban megtalálhatók.

A COM számos előnye közül megkülönböztethető a következő legfontosabb előnyök:

• A szoftverrendszerek többszintű architektúrájának kiépítésének lehetőségei (N-Tier). Az ilyen architektúra legegyszerűbb eleme kétszintű: "kliens-kiszolgáló". Az ügyfél lehetőségeinek kibővítése, amely más programok számára is szerverként működik, bármely szoftvercsalád architektúráját tetszőleges számú hivatkozással (például alkalmazáskiszolgálóval vagy WEB alkalmazásokkal) felépítheti. Ebben az esetben elosztott adatfeldolgozás végezhető, az egyetemes protokollok, valamint a hálózatok és az internet esetében a szoftverrendszerek legösszetettebb architektúrája. A CTD ezt a képességet a COM mechanizmusok alapján biztosítja.
• A programozási nyelvek függetlensége. A COM kiszolgálók és ügyfelek különböző nyelveken írhatók, de a köztük lévő interakció szabványos felületen keresztül történik. Így például az ügyfelet az ASP alapján lehet építeni, és egy CTD alapú kiszolgálót.
• A bináris fájlok COM-hez való használata lehetővé teszi számukra, hogy ismételten hívják, frissítsék a verziókat anélkül, hogy befolyásolnák a futó rendszereket. Az ilyen rendszerek karbantartása egyszerűsített: elegendő frissíteni a COM-összetevőt, és az alkalmazás együttműködik az új interfésszel, és még új funkciókkal is ellátja a COM-t.

Interfészek és CoClass

Egy COM szerver programban való létrehozásához két összetevőt kell definiálni: az objektum felületének és osztályának COM - CoClass. Az interfész tartalmazza a kiszolgáló funkcionalitását, azaz a funkciókészletet és az objektumok COM adatkészletét. Az adatok között allokálható változók (objektumváltozók) és közös változók az összes objektumhoz (osztályváltozók). Az utóbbiak valójában statikus osztályváltozók. A kezelőfelületen definiált függvények az alkalmazás ügyfélrészének használói számára állnak rendelkezésre. Az adatok be vannak ágyazva a szerveren generált objektumba, de elérhetők a speciális osztályfüggvényekkel, amelyeket a felhasználó leírhat. Az interfész egy globális egyedi azonosítójú GUID-IID.

Az észak-interakció engedélyezéséhez a CoClass definiált, amelyet az interfészosztály örököl. A CoClass valójában az objektumot képviseli a kiszolgálón, és biztosítja a kiszolgálón az alkalmazás ügyfélrészén előforduló események kezelését. A CoClass egy globális egyedi GUID-CLSID-t is tartalmaz. A CoClass leírása megegyezik a Proxy osztály ügyfélrészével, amelyet automatikusan generál. Létrehozhat CoClass-ot és több örökséget az interfészosztályokból, ebben az esetben kombinált COM szervert kaphatunk. Egy szerveralkalmazásban tetszőleges számú interfészosztályt és COM objektumosztályt tudunk létrehozni.

Az Interface és a CoClass-ok leírásának egységesítése a CTD-ben, speciális célzási mechanizmusok és varázsló (Wizadr). Az osztályváltozók, az objektumváltozók és az osztálymódszerek beállításai automatizáltak. Az OUTLINE-ban a szöveg kézi kódolásának lehetősége nem kizárt.

COM kiszolgálók építése és azok jellemzői

A következő a CTD tervezőablak töredéke, amikor egy interfészosztályt hoz létre a legegyszerűbb alkalmazáspéldához. Ez a COM szerver két egész számot hoz létre.

Ábra. 1 A COM szerver interfészosztályának leírása.

Az interfészosztály IISerge néven ismert, tartalmaz egy automatikusan generált GUID-t (definiálhatja sajátját) és leírja azokat a függvényeket, amelyek közül az egyik (summa) két teljes paraméter közvetlen összegzését végzi. Amikor az összegzés befejeződött, az evEndSum esemény az ügyfélalkalmazásban aktiválódik (lásd az alábbi feldolgozást). Ezenkívül az interfészosztály meghatározza: egy osztályváltozót - az nServerContact, amely tárolja a kapcsolódó ügyfelek számát, és egy objektumváltozót - nSumm, amely tartalmazza az összeg értékét.

Az alábbi ábra a CoClass-ot az interfész osztályból örökölte. Ebben a leírásban van egy generált vagy meghatározott GUID - CLSID és az események leírása, amelyeket az ügyfél fog feldolgozni: evEndCum és evEndObj. Ezeket az eseményeket a felületosztály-függvény-metódusok kezdeményezik, ezért az öröklés és a CoClass miatt.

Ábra. 2 Az ISerge osztály és az evEndCum és evEndObj események leírása.

Események létrehozásakor a módszerekhez hasonlóan automatikusan hozzárendelnek egy speciális küldési számot (Dispath Number). A módszerek, változók és események leírása után a COM szerver készen áll a fordításra.

Regisztráció, összeállítás és hibakeresés

A COM szerver futtatható moduljának összeállítása és létrehozása a szokásos módon történik, néhány kivétellel. A COM létrehozásakor meg kell adnia a kiszolgáló típusát. Három lehetőség közül választhat:

• A COM-t DLL-ként hozták létre a folyamatban történő megosztás során.
• A COM-t EXE-ként hozták létre a helyi használatra, mint folyamat (out-of-process)
• A COM-t EXE-ként hozták létre a hálózathoz az MST (Microsoft Transaction Server) használatával.

Ezek a módok a Build mód ablakban vannak beállítva. A sikeres létrehozás után a kiszolgálót regisztrálni kell, és ha változások készülnek, és az osztályok és a felhasználói felület GUID-je automatikusan létrejön, akkor újra kell regisztrálnia és újra kell fordítania az ügyfélalkalmazást. A COM-kiszolgáló számára egy univerzális azonosítót, az úgynevezett univerzálisan egyedi azonosítót (UUID) neveznek. Mindezen műveletek után a COM szerver üzemkész. Futtathatja CTD vagy off-line módban. A második esetben meg kell adnia egy paramétert, amely meghatározza a felhasználók számát. A kiszolgáló hibakereséséhez fáradságos kliensalkalmazást létrehozni és önállóan futtatni.

Az ügyfélalkalmazások és azok tulajdonságainak felépítése

Ügyfélalkalmazás létrehozásához létre kell hoznia egy interfész APL-t. A generáció az Exprorer CTD beépített segédprogrammal történik. Az ezzel kapcsolatos részletes munkát egy másik cikk írja le (Centura Team Developer - ActiveX komponensek: alapelvek és alkalmazási technológia), így itt nem fogunk foglalkozni. Csak azt tudom megjegyezni, hogy a generáció a típuskönyvtár (* .tlb) választásán alapul, amely automatikusan létrejön a COM szerver futtatható létrehozásával együtt, és ugyanabba a könyvtárba kerül. Miután kiválasztotta a megfelelő típusú könyvtárat a generációhoz, minden osztály, esemény és számlálás teljes generációját végre kell hajtani. Az újonnan létrehozott ügyfélalkalmazásban ezt az APL-t hozzá kell adni a könyvtárhoz. Az alábbi ábra bemutatja a legegyszerűbb ügyfélalkalmazás ablakát, amely a COM főbb jellemzőinek bemutatására szolgál. Ez a program két egész számot ad a COM-kiszolgálóhoz, amelyek szerepelnek az űrlapmezőkben.

Ábra. 3 Példa egy szerverre tömörülő ügyfélalkalmazásról.

Az alkalmazásablak összegző gombján kívül az osztályváltozó, az objektumváltozó és a csatlakoztatott felhasználók száma jelenik meg. Amikor az alkalmazásgombokra kattint, a COM szerver funkciók hívásra kerülnek, a munka eredményei a megfelelő mezőkben jelennek meg. A fenti ábra egy felhasználó munkáját mutatja. Az alábbi ábra két ügyfélalkalmazás munkáját mutatja. Ebben az esetben azt látjuk, hogy az osztály általános változói (a felhasználók száma és az osztályváltozó) azonosak, és az objektumváltozók eltérőek.

Ábra. 4 Két ügyfélalkalmazás, amelyek a kiszolgálóval dolgoznak.

Vegye fontolóra a COM-technológián alapuló ügyfélalkalmazások építését. Az APL összekapcsolása után, ehhez a COM szerverhez osztályok kerülnek a osztályobjektumhoz, amely megfelel a kiszolgáló objektumok leírásainak. Ezek a következő osztályok: funkcionális osztály - samplCom_IISerge egy interfész (függvényhívás) és a Com Proxy osztály létrehozásához - samplCom_Iserge az eseményfeldolgozáshoz. Az osztályok az alábbi ábrán láthatók a CTD tervezőablak bal oldalán.

Ábra. 5 COM osztály és eseménykezelés az evEndSumm programban.

Ha meg kell határoznod az eseménykezelőket, létre kell hoznod egy Com Proxy osztály örököst, és létre kell hoznod egy ilyen objektum elérhető objektumát. Az ábra egy új App_Serge osztályt mutat be, amely az evEndSumm esemény feldolgozását biztosítja. Az alábbi ábra bemutatja az interfészosztály létrehozásának eredményeit. A rendelkezésre álló függvény-módszerek listáját (az ablak bal oldalán) és a summa összegzés funkciót (az ablak jobb oldalán) bővítik ki.

Ábra. 6 Az interfész osztály a samplCom_IISerge és az summa módszer.

Amint azt a példaből láthatjuk, mielőtt a módszer az univerzális INVOKE függvény használatával hívható meg, az átvitt paraméterek a kötegre kerülnek (PushNumber), és a függvény végrehajtása után hívják őket a stackből (PopNumber). A köteg ezután törlődik (FlushArgs). Ezt a függvényt (summa) az AX Explorer segítségével automatikusan generálják, és ez a kötés statikusnak nevezik. Azonban a szükséges osztályok és objektumok létrehozásával a felhasználó képes a dinamikában végrehajtani a hívófunkciók működését. Ebben az esetben dinamikus összekapcsolást is biztosíthat. A dinamikus kötéshez VARIANT típusú változót lehet használni, amely lehetővé teszi a funkciók hívását a paraméterek típusától függetlenül.

Osztály- és objektumváltozók, COM hibakeresés

A COM-kiszolgálóban, ahogy már említettük, osztályváltozók és objektumváltozók is biztosíthatók. Az objektumváltozók az egyéni rejtett adatok, amelyek a funkció-metódusok segítségével érhetők el. Az osztályváltozók (statikus változók) közösek az osztály összes objektumában, és tárolják értékeiket a kiszolgáló futása közben. Ezek a változók funkcionális módszerekkel érhetők el. Ezenkívül a CTD alkalmazásban közös változók is deklarálhatók, ami közös lehet a COM-kiszolgálók egy csoportjában. Az ilyen változókat az alkalmazás globális része tartalmazza. Az alábbi ábra bemutatja az ügyfélalkalmazás töredékét, amelyben a COM függvényeket hívják, és különösen az osztályváltozók és objektumváltozók elérésének funkcióit.

Elvileg a COM szerver oldalán nincs szükség a felület ablakainak leírására. A szerver hibakeresése során azonban szükség lehet ilyen ablakokra. Ebben az esetben leírhatjuk az ablakokat, és használhatjuk őket a kiszolgálóalkalmazások hibakeresésére, az ügyfélalkalmazásokkal együtt. Ha elegendő számítógépes erőforrással rendelkezik, a CTD két verzióját futtathatja, és mind az ügyfélalkalmazás, mind a COM szerverprogram egyidejű hibakeresését elvégezheti.

Ábra. 7 Call summa, GetObjVar, GetClassVar és GetCountUser módszerek a programban.

Ha objektumokat akarunk elkülöníteni egymástól, a CTD lehetőséget nyújt a futómű technológiákra épülő COM szerver létrehozására. Ehhez elegendő a COM-kiszolgáló létrehozása során speciális módot megadni. Ebben az esetben különböző beállítások lehetségesek, attól függően, hogy a szerver helyi vagy távoli üzemmódban van-e.

A CTD COM-kiszolgálójának kényelmes munkája érdekében lehetőség van osztályok és objektumok létrehozására a gyűjtemény típusánál. A gyűjtemények listázott konstansok (enum) tárolására vagy minták tárolására használhatók (például lista szótárak). Ennek az osztálynak a módszereit meghatározza a hangolási lehetőségek. A gyűjteményosztályok felhasználhatók más osztályok örökségére, és az objektum interfészrészében is szerepeltethetők. A gyűjtemények feldolgozását részletesen ismertetjük a dokumentációban, speciális példák a gyűjtemények használatával a példák könyvtárában találhatók.

Speciális WEB-osztályok használatával (Centura WEB kiterjesztés) COM-alkalmazások épülnek WEB alatt. Ezek az alkalmazások gyors hozzáférést biztosítanak az adatbázishoz, a WEB Application Manager alatt működnek. Az ügyfél- és kiszolgálóalkalmazások építésének folyamata sok tekintetben megismétli a hagyományos alkalmazások építésének folyamatát, és annak jellemzői a CTD dokumentációjában találhatók. A mintakészlet tartalmaz egy speciális COM alkalmazást, amely automatikus üzemmódváltást biztosít a WEB módban és normál üzemmódban történő működtetéshez.

Megjegyzem, hogy ennek a cikknek a keretében nehéz a COM technológiák használatával kapcsolatos összes kérdést és problémát lefedni. Úgy gondolom azonban, hogy ez az információ hasznos lesz az összetett információs rendszerek fejlesztőinek, hogy meghatározzák az építésükre vonatkozó stratégiát és a végrehajtási eszközök megválasztását. Véleményem szerint a CTD-ben kínált lehetőség egyszerû, és nagyfokú szakmai hozzáértést biztosít a programozásban.