Koncepció: Web architektúra minták. Vállalati webalkalmazások tervezése és fejlesztése

Amikor a modern információs rendszerek A fejlesztők számos problémába ütköztek.

Az első annak a ténynek köszönhető, hogy jelenleg az információs rendszereknek általában biztosítaniuk kell egy vállalat több irodájának vagy részlegének együttműködését. Egy cég külön irodájának, részlegének informatizálása, beleértve az elektronikus dokumentumkezelést, ügyfél-könyvelést, könyvelést, a hagyományos „kliens-szerver” technológián keresztül meglehetősen egyszerű. A rendszer magja általában egy megfelelő interfésszel rendelkező adatbázissá válik, és egy speciális alkalmazási modullal egészül ki. De ha a rendszer telepítése után probléma merül fel egy vállalat több irodája vagy részlegének interakciójának megszervezésében, akkor egy ilyen rendszer fejlesztésre szorul, mivel nem biztosít mechanizmusokat és protokollokat a rendszerek közötti interakcióhoz, és nincs modul a menedzsmenthez. osztályok közös akciói.

A második probléma az internettel való integráció, hiszen az e-kereskedelem fejlődése azt mutatja, hogy anélkül, hogy jó minőségű ill hatékony megoldások a cég nem fog fennmaradni ezen a területen verseny vállalkozóbb cégekkel.

Jelenleg a vállalatok internetes működésének technológiája alapvetően megváltozott. Most minden internetes erőforrás a hálózathoz csatlakoztatott számítógépek lemezein található, azaz. hálózati meghajtók. Ez azt jelenti, hogy elosztott hálózati erőforrásokkal van dolgunk. Szükség esetén bármely számítógépről hozzáférhet a számítógépen lévő információkhoz anélkül, hogy kapcsolatba lépne a szerverrel, hálózati szolgáltatások segítségével, amelyek viszont szintén távoli helyen találhatók. hálózati erőforrások. Az ilyen szolgáltatásokat webszolgáltatásoknak nevezzük. A „kliens-szerver” modell átviteléről beszélünk hálózati modell, Hol hálózati szolgáltatás maga is objektummá válik saját funkcióival (módszereivel) és attribútumaival (tulajdonságaival). E szolgáltatás módszereinek meghívásával az alkalmazásokból különféle problémákat oldhat meg. A speciális internetes szolgáltatások (szolgáltatások) megjelenésének tendenciája a jövőben oda vezethet, hogy a helyi szoftverek iránti igény gyakorlatilag megszűnik. Példa erre a felhőalkalmazás-fejlesztő IDE-k (Integrált Fejlesztési Környezet), amelyek lehetővé teszik alkalmazások fejlesztését különböző programozási nyelveken mobileszközről (okostelefonról vagy táblagépről). Ilyen IDE például az EclipseOrion, a Cloud 9 IDE, az eXoCloudIDE. A fejlesztés „felhőbe” való átállása az információs rendszerek felületének megváltozásához vezet - webes felületté válik. A fentiekből következő általános következtetés: a lényeg az, hogy a rendszer fogalmilag ne avuljon el, hanem szoftver- és hardverszinten folyamatosan történjen változások, amelyek a rendszer ciklikus újratervezését eredményezik a modern alapokon. technológiákat.

Ha a modern információs rendszerekről beszélünk, két új tulajdonságukat érdemes megjegyezni: többfelhasználóssá és elosztott erőforrásúvá váltak, így a modern információs rendszerek architektúrája jelentősen megváltozott. Az információs rendszer összetevői közötti interakció tipikus sémája nagyszámú felhasználó jelenlétében megfelel a rendszerfelhasználók közötti interakciónak webes felületen keresztül.

Ez az architektúra akkor lehetséges, ha a rendszer felhasználói természeti okok miatt földrajzilag megoszlanak. Például a szolgáltatások fő fogyasztói az interneten keresztül érhetők el (különösen a különféle segítő szolgáltatások). Egy másik példa egy rendszer a belső használatra vállalat, a felhasználók is terjeszthetők, de eltérő okokból. Ma a „mobil munkavállalók” és az „otthoni iroda” fogalmak, amelyek magukban foglalják távmunka nagyobb vállalati rendszerekkel. Vagyis az ERP osztályú alkalmazásoknak támogatniuk kell a webes felületet. Jelenleg telik az idő a hagyományos alkalmazások és rendszerek tömeges migrációja webes felületekre. Ez történhet további komponensek vagy az alkalmazás teljes újratervezése formájában. Mivel az elosztott felhasználókkal való munka forgatókönyvét minden webes felülettel rendelkező rendszer támogatja, az ilyen alkalmazásokat webalkalmazásoknak nevezzük.

A webalkalmazás egy kliens-szerver alkalmazás, amelyben a böngésző az ügyfél, a webszerver pedig a szerver. A webalkalmazás logikája megoszlik a szerver és a kliens között, az adatok elsősorban a szerveren tárolódnak, az információcsere a hálózaton keresztül történik. Ennek a megközelítésnek az egyik előnye, hogy a kliensek nem függenek a felhasználó konkrét operációs rendszerétől, így a webalkalmazások többplatformos szolgáltatások. A webes alkalmazásokra való áttérés az 1990-es évek végén és a 2000-es évek elején vált nagyon népszerűvé.

Tekintsük az ilyen webes alkalmazások architektúráját néhány absztrakt példa segítségével, amely specifikus szoftverés derítse ki, hogy az egyes komponensek milyen szerepet töltenek be (1.3. ábra). Az alkalmazás kliens részében nincsenek speciális komponensek, webböngészőt és irodai programcsomagot használnak.

Rizs. 1.3. Az információs rendszerelemek interakciós sémája internetes technológiákat használva 1

A szerver oldalon minden bonyolultabb. Szerkezetileg három nagy komponensből áll:

1) webszerver (HTTP szerver);
2) adatbázis-kiszolgáló (DB);
3) szoftvertolmács.

A webszerver a kapcsolat a webalkalmazás és a kliens között. A HTTP protokollon keresztül adatkészlet formájában fogadja el az ügyféltől érkező kéréseket, és válaszul dokumentumokat küld vissza HTML nyelvés további szükséges fájlok (képek, stíluslapok, egyéb objektumok). Ebben az esetben a dokumentumok és egyéb fájlok lehetnek statikusak (ahol találhatók fájlrendszer szerver), és dinamikus, azaz. kialakult szoftver rész. A leggyakoribb webszerver az Apache, az esetek több mint 70%-ában weboldalak rendszerezésére használják (és az internet orosz részén ez az arány eléri a 90%-ot).

Ezenkívül speciális webszervereket fejlesztettek ki a nagy komplexumokba tartozó különféle alkalmazásokhoz, például vállalati technológián alapuló webalkalmazások használatakor. Microsoft használat Internet információs szerver(IIS). A szerver kiválasztása meghatározza az információs rendszer fejlesztéséhez használt programozási nyelvek képességeit.

A webszerver szerepe kettős: egyrészt kommunikációt hoz létre a kliens és a szerver rész között, másrészt elszigeteli a programkód végrehajtásától és a távoli erőforrásokhoz való hozzáféréstől. A leírt elv megvalósításához sokféle megoldás született, de a gyakorlati használat során felmerül néhány kérdés, köztük a biztonság kérdése, amelyet az egyik legfontosabbnak tartanak. Szintén fontos paraméterek a működés megbízhatósága és a meghibásodások elleni védelem.

A szoftvertolmács a rendszer szíve. Szoftver értelmező segítségével a rendszer logikáját (algoritmusait) tartalmazó kódot hajtják végre. Magyarázzuk meg, miért nevezik ezt az elemet így. A webes környezet különféle programozási nyelveken írt alkalmazásokat futtathat. Két csoportra oszthatók: lefordított (végrehajtás, mint rendszeres programok számítógépen) és tolmácsolják (a futtatásához tolmács szükséges). A webes alkalmazások fejlesztése során mindkét típust használják, de különösen népszerűek az értelmezett nyelvek: Perl, PHP, Ruby, Python. Az értelmezett programok lassabban futnak, de a fejlesztési folyamatuk sokkal egyszerűbb és gyorsabb. Figyelembe véve az egyre növekvő üzleti követelményeket a változások végrehajtásának sebességével kapcsolatban szoftver termékek(információs rendszerek), a gyors szoftverfejlesztési ciklus döntő tényezővé válik. Emellett a számítógépek teljesítménye folyamatosan növekszik, így bizonyos mértékig megfeledkezhetünk az alkalmazások teljesítményéről a kényelem és a fejlesztés gyorsasága érdekében.

A látható ábrán. Az 1.3-as példában a Reg1 értelmezett nyelv hatékony és alkalmas a legtöbb projekthez webes felülettel rendelkező információs rendszerek létrehozására. A rendszerkód modulokból és szkriptekből áll. Ez a két komponens valósítja meg a rendszer végrehajtási logikáját és alapvető funkcióit.

A Reg1 nyelv kiválasztását a következő tényezők határozzák meg:

tetszőleges szöveges adatok feldolgozásának képessége különféle módokon, beleértve a reguláris kifejezések feldolgozását is. Ez fontos szempont az adatbázis-programozásnál, mert az adatbázisokban tárolt információk nagy része szöveges jellegű;
A Reg1-szkriptek lényegesen rövidebbek, mint az egyenértékű C-programok, és általában más operációs rendszerekre is átvihetők, ahol a Reg1-programok csekély módosítással vagy módosítás nélkül futnak;
A Reg1 környezetet ingyenesen biztosítjuk.

A Reg1 fordító ugyan tolmácsként valósult meg, de a szövegfeldolgozással kapcsolatos feladatoknál nem működik sokkal lassabban, mint a C fordítóval rendelkező programok. A Reg1 nyelv előnye a C nyelv használatához képest a tízszer rövidebb kód. A Reg1 nyelv jó a létrehozáshoz kis programokés szövegintenzív forgatókönyvek.

Az adatbázis-kiszolgáló strukturált információkat gyűjt, és a webalkalmazás kérései alapján ki is bocsátja. Ebben az esetben a rendszer szoftveres része és az adatbázisszerver között különféle (standard és speciális) interfészek használhatók. Nem minden webalkalmazás-programozási nyelv rendelkezik megbízható és funkcionális interfésszel a különböző fejlesztők adatbázis-kiszolgálóihoz. Az adatbázis-kiszolgáló adatszempontból határozza meg az alkalmazás teljesítményét és funkcionalitását. Például a kifejlesztett DBMS-ek lehetővé teszik az elosztott adattárolás használatát, és hatékony képességekkel rendelkeznek a meghibásodások elleni védelemre és az azokból való helyreállításra. ábrán. Az 1.3-as verziót a webfejlesztés világában komoly hírnévnek örvendő MySQL DBMS példájaként mutatjuk be.

A webalkalmazás kliensoldalának központja a böngésző. Minden internetre csatlakozó számítógép tartalmaz egy böngészőprogramot, amelyen keresztül elkezdhet dolgozni egy webalkalmazással. Probléma van azonban a webes alkalmazások böngészőkkel és operációs rendszerekkel való kompatibilitásával kapcsolatban. A böngészők esetében ez helytelen megjelenítést és a kezelőszervek helytelen működését eredményezi. Az operációs rendszerek esetében ez a további modulok (bővítmények, bővítmények) telepítésére vonatkozó követelmények megjelenése.

Probléma hibás megjelenítés amiatt, hogy a böngésző kompatibilitás a nemzetközi szabványokkal nem teljes, i.e. Az oldalak és alkalmazások HTML-kódjának létrehozásakor figyelembe kell vennie a piacon használt fő webböngészők (MS Internet Explorer, Chrome, Opera, FireFox, Safari). Azonban nincs garancia arra, hogy a főbb böngészőtípusokon tesztelt alkalmazások megfelelően működnek más, ritkább termékeken.

A vezérlők helytelen működésével kapcsolatos probléma lényege, hogy a legtöbb böngésző rendelkezik bővítmények (további modulok, úgynevezett pluginok) telepítésével. Egyes webalkalmazások úgy vannak felépítve, hogy működésükhöz bizonyos böngészőbővítményekre van szükség. A weboldalak világában tipikus példa erre a Flash objektumok (animált minialkalmazások fejlett képességekkel). Egészen a közelmúltig Flash-támogatás operációs rendszer A Linux sok kívánnivalót hagyott maga után, így a plugin technológiával készült webhelyek és alkalmazások nem működhettek ott.

Mobil eszközök használata. Napjainkban a mobil eszközök megjelenésével webszerver kliens nem csak egy hagyományos webböngészővel felszerelt személyi számítógép lehet, hanem maga a mobileszköz is. A mobileszközök jellemzői eltérnek azoktól személyi számítógépek. Korlátozott képernyőmérettel, kis memóriakapacitással rendelkeznek, és gyakran képtelenek néhány soros fekete-fehér szövegnél többet megjeleníteni. Jelenleg más adatátviteli protokollok is léteznek számukra, mint például a WAP ( Vezeték nélküli hozzáférési protokoll), és a megfelelő jelölőnyelvek, mint például a WML ( Vezeték nélküli jelölőnyelv)

és CHTML (Kompakt HTML). Az adatok megfelelő formátumú mobileszközre történő átviteléhez speciális webhelyeket használnak, amelyek támogatják a WAP-ot és a WML-t. A legígéretesebb alkalmazások azok, amelyek a kliens típusától függően egy vagy másik kódot tudnak generálni. pontban ezt a megközelítést alkalmazzák Microsoft technológiák ASP.NET.

Üzleti logika és interfész szétválasztása. A felhasznált adatok mennyiségének és az oldal látogatóinak növekedésével a webalkalmazások megbízhatóságával, teljesítményével és skálázhatóságával szemben támasztott követelmények is növekednek. Ezen követelmények teljesítése érdekében a webes alkalmazásokban megvalósított üzleti logika leválasztásra kerül az alkalmazási felületről, és független üzleti objektumok formájában kerül át az alkalmazásszerverre, amelyek a jól ismert technológiák egyikében implementálhatók: COM, Microsoft. NET stb. Az ilyen üzleti objektumok gyakran egy információs rendszer funkcionalitásának egy részét valósítják meg (nem egy konkrét rendszert, hanem olyan modult vagy modulrészt biztosítanak, amely bármely információs rendszerbe „beültethető”). Az ilyen üzleti objektumok webszolgáltatásokat képviselhetnek.

Amint azt korábban említettük, szinte minden ma kifejlesztett üzleti alkalmazás terjesztett. ábrán. Az 1.4. ábra az internetes webhelyek interakcióját mutatja be egy elosztott webalkalmazás segítségével.

Lásd: A teljes Runet áttekintése: statisztika a .sh, .рф és .su domainekről a StatOnline-on.

A világhálót (WWW) eredetileg „információmegosztó térként képzelték el, amelyben az emberek és a számítógépek kommunikálhatnak egymással”. Ezért az első webes alkalmazások primitívek voltak fájlszerverek, amely statikus HTML-oldalakat adott vissza az azokat kérő ügyfeleknek. Így a web dokumentum-orientáltnak indult.

A web fejlődésének következő állomása az alkalmazások koncepciójának megjelenése volt, amelyek olyan interfészeken alapultak, mint a CGI (vagy FastCGI), majd később az ISAPI. A Common Gateway Interface (CGI) egy szabványos kiszolgálói interfész, amely lehetővé teszi a szerveralkalmazások URL-en keresztüli futtatását. Az ilyen alkalmazások bemeneti információja a HTTP-fejléc tartalma (és a POST protokoll használata esetén a kérés törzse). A CGI-alkalmazások HTML-kódot hoztak létre, amelyet visszaküldtek a böngészőnek. A CGI-alkalmazások fő problémája az volt, hogy minden kliens kérésnél a szerver valós időben hajtotta végre a CGI-programot, külön címtérbe töltve azt.

Az Internet Server API (ISAPI) megjelenése nemcsak a CGI-alkalmazásokkal kapcsolatos teljesítményproblémákat oldotta meg, hanem gazdagabbá tette a fejlesztőket. szoftver interfész. Az ISAPI DLL-ek egy speciális metabázison keresztül társíthatók fájlnév-kiterjesztésekkel. Ez a két mechanizmus (CGI és ISAPI) szolgált alapul az első típusú webalkalmazások létrehozásához, amelyekben a kliens műveleteitől függően kiszolgálókódot hajtottak végre. Így lehetővé vált a weboldalak tartalmának dinamikus generálása, és a web tartalma megszűnt pusztán statikus lenni.

Az ISAPI interfész egy szolgáltatás Microsoft Internet Információs szerver. Az ISAPI-alkalmazások dinamikus betöltési könyvtárak (DLL-ek), amelyek a webszerver címterében futnak. Idővel más webszerverek is képessé váltak könyvtárként megvalósított alkalmazások futtatására. A Netscape webszerverek esetében ezt a programozási felületet NSAPI-nak (Netscape Server API) hívták. A meglehetősen népszerű Apache webszerver képes könyvtárként megvalósított webalkalmazások futtatására is; az ilyen könyvtárakat Apache DSO-nak (Dynamic Shared Objects) nevezik.

Természetesen mind a CGI, mind az ISAPI alkalmazások használatakor a fejlesztők alapvetően ugyanazokat a problémákat oldották meg, így természetes lépés volt egy új, magas szintű interfész megjelenése, amely leegyszerűsítette a HTML kód generálásának feladatait, lehetővé tette a komponensek elérését és az adatbázisok használatát. Ilyen interfész lett az ISAPI szűrőre épülő Active Server Pages (ASP) objektummodell.

Az ASP fő gondolata az alkalmazási felület létrehozása szempontjából, hogy egy weboldalon olyan kódrészletek találhatók, amelyeket a webszerver értelmez, és amelyek helyett a felhasználó megkapja ezen kódrészletek végrehajtásának eredményét.

Nem sokkal az ASP megjelenése után más technológiákat hoztak létre, amelyek megvalósították azt az ötletet, hogy egy webszerver által végrehajtott kódot helyezzenek el egy weboldalon. Ezek közül manapság a leghíresebb a JSP (Java Server Pages) technológia, melynek alapötlete a Java kód (servlet) egyszeri összeállítása az első eléréskor, a servlet metódusainak végrehajtása, ill. a módszerek végrehajtásának eredményeit a böngészőnek küldött adathalmazba helyezi.

Az Active Server Pages technológia legújabb verziója az ASP .NET, amely kulcsfontosságú a Microsoft architektúrában. NET-keretrendszer. Az ASP .NET segítségével olyan webalkalmazásokat és webszolgáltatásokat hozhat létre, amelyek nem csak a HTML oldalak dinamikus generálásának megvalósítását teszik lehetővé, hanem a szerverkomponensekkel is integrálhatók, és megoldhatók. széles körűüzleti kihívások, amelyekkel a modern webalkalmazások fejlesztői szembesülnek.

IN általános eset A webszerver kliense nem csak egy normál webböngészővel felszerelt személyi számítógép lehet. A mobil eszközök széles körű elterjedésével párhuzamosan felmerült a webszerverek ezen eszközök által értelmezhető adatokkal való ellátásának problémája is. Mivel a mobileszközök jellemzői eltérnek a személyi számítógépekétől (korlátozott képernyőméret, kis memória, és gyakran képtelenség néhány soros fekete-fehér szövegen kívül mást megjeleníteni), léteznek számukra más adatátviteli protokollok (WAP - Wireless Access Protocol) és a megfelelő jelölőnyelvek (WML – Wireless Markup Language, СHTML – Compact HTML stb.). Ebben az esetben felmerül a feladat, hogy a megfelelő formátumban adatokat vigyünk át egy mobileszközre (és erre vannak speciális oldalak), vagy ami kényelmesebbnek tűnik, az eszköz típusát felismerjük, amikor kapcsolatba lép a szerverrel és a forrásdokumentum átalakításra kerül (például: XML formátum) az ehhez szükséges formátumba mobil eszközön(például XSLT transzformáció használatával).

A támogatás másik módja különféle típusok Az ügyfeleknek az a feladata, hogy "intelligens" szerverkomponenseket hozzanak létre, amelyek a kliens típusától függően különböző kódok generálására képesek. Ez a megközelítés különösen a Microsoft ASP .NET-ben valósul meg.

A webalkalmazások kliens részei fejlesztésének másik iránya az alkalmazáslogika egy részének (például a bemeneti adatok helyességének ellenőrzése) elhelyezése magában a webböngészőben. A modern webböngészők különösen képesek a szkriptnyelvek (VBScript, JavaScript) értelmezésére, amely kód az ASP-kódhoz hasonlóan be van ágyazva egy weboldalba, de nem a webszerver, hanem a böngésző és , ennek megfelelően a kliens eszközön végrehajtva. Ezenkívül a modern böngészők képesek Java kisalkalmazások megjelenítésére és végrehajtására - speciális Java alkalmazások, amelyeket a felhasználó egy weboldal részeként kap, és néhány böngésző elemtárolóként is szolgálhat. ActiveX vezérlők– a böngésző címterében futó speciális COM szerverek, amelyek szintén a weblap részeként kerülnek fogadásra. Mind a Java kisalkalmazások, mind az ActiveX-vezérlők szinte bármilyen funkciót megvalósíthatnak.

Vegye figyelembe, hogy a felhasznált adatok mennyiségének és a webhelylátogatók számának növekedésével a webalkalmazások megbízhatóságára, teljesítményére és méretezhetőségére vonatkozó követelmények is növekednek. Az ilyen alkalmazások fejlődésének következő lépése a webalkalmazásban megvalósított üzleti logika, és gyakran az adatfeldolgozási és tranzakciós szolgáltatások elválasztása volt a felületétől. Ebben az esetben az úgynevezett prezentációs rész általában magában a webalkalmazásban marad, és az üzleti logika, az adatfeldolgozás és a tranzakció végrehajtása átkerül alkalmazásszerverüzleti objektumok formájában. Típustól függően alkalmazásszerver Ezek az üzleti objektumok lehetnek önvégrehajtó COM-kiszolgálók, CORBA-kiszolgálók vagy szolgáltatások használatával futó COM+-objektumok. Windows összetevők 2000, vagy EJBs (Enterprise Java Beans) végrehajtható fájl alkalmazásszerver, támogatja a J2EE specifikációt (Java 2 Enterprise Edition). Mint adathozzáférési mechanizmus az ilyen objektumok használhatják az OLE DB-t, ODBC-t, JDBC-t (ez az üzleti objektum megvalósításától függ).

Az ilyen üzleti objektumok gyakran hozzáférést biztosítanak a vállalati információs rendszerek adataihoz, vagy megvalósítják funkcióik egy részét. Gyakran lehetővé teszik például a Weboldal integrálását CRM rendszerekkel (Customer Relationship Management) vagy ERP rendszerekkel (Enterprise Resource Planning), megtakarítást eredményezve. vállalati rendszerek tájékoztatás a webhely látogatóiról, valamint a potenciális ügyfelek tájékoztatása az elérhető termékekről a rendelések leadásához.

Mert modern internet- ez nem annyira a vállalat piaci jelenlétének demonstrálása vagy marketing eszköz, mint inkább az ügyfelekkel való internetes kapcsolatok szervezésének eszköze, mivel az áruk és szolgáltatások értékesítése nagyon fontossá válik . És itt igen fontossá válnak a „vállalkozás-vevő” típusú (B2C – business-to-consumer) e-kereskedelem megoldásai. Nem kevésbé fontosak a webalkalmazások integrálása a partnerek adataival és alkalmazásaival a vállalkozások közötti (B2B - business-to-business) séma megvalósítása érdekében, amely lehetővé teszi a vállalkozások közötti kereskedelmi tranzakciók megkötését, termékkatalógusok cseréjét, lebonyolítását. aukciók, elektronikus kereskedési platformok létrehozása.

Jegyezd meg, hogy lévén szerves része ilyen döntés,A webszervernek képesnek kell lennie nem csak alkalmazások futtatására és interakcióra alkalmazásszerver, hanem integrációs szolgáltatásokat, alkalmazás- és adatkezelési szolgáltatásokat, valamint fejlesztőknek szóló szolgáltatásokat is igénybe vehet.

A webalkalmazások fejlődésének következő lépése a vállalati és partneradatok elérése mellett a vállalati alkalmazásokhoz való hozzáférés megszerzése. A webes alkalmazásoknak a vállalatok belső információs rendszereivel, valamint az ügyfelekkel és partnerekkel való interakciót biztosító alkalmazásokkal való integrálásának problémájának megoldására speciális megoldásokat használnak, amelyeket vállalati portáloknak neveznek.

A portálmegoldások egy része gyakran tartalmaz egy weboldal tartalmának kezelésére szolgáló eszközöket – elvégre a nagyvállalatok és portálok weboldalait használó felhasználók rendelkezésére álló adatok mennyisége ma már akkora, hogy ezen adatok „kézi” kezelése nem lehetséges.

A fentieket összefoglalva kiemelhetjük a webarchitektúra főbb jellemzőit [, ]:

nincs szükség további szoftver használatára a kliens oldalon - ez lehetővé teszi az ügyfélrész automatikus megvalósítását minden platformon;
szinte korlátlan számú ügyfél csatlakoztatásának képessége;
az egyetlen adattárolási helynek és az adatbázis-kezelő rendszer meglétének köszönhetően az adatintegritás megőrzésének minimális követelményei biztosítottak;
elérhetőség, amikor a szerver és a kommunikációs csatornák működnek;
elérhetetlenség, ha a szerver vagy a kommunikációs csatornák nem működnek;
elég alacsony sebesség Webszerver és adatátviteli csatornák;
Ami az adatmennyiséget illeti, a webes rendszerek architektúrájának nincsenek jelentős korlátai.

Sematikusan egy ilyen architektúra (háromszintű változatban) az ábrán látható módon ábrázolható. 5.9.

Rizs. 5.9.

5.1.8. Szolgáltatás-orientált architektúra

A modern webalkalmazások készítése során felmerülő számos fent leírt probléma megoldását most kezdik hozzárendelni a webszolgáltatásokhoz – platformtól, objektummodelltől és klienstől függetlenül. szoftver komponensek, amely a kliens webalkalmazásokból (valamint magukból a webszolgáltatásokból) HTTP alapú ill XML nyelv SOAP protokoll. Az XML-szerű WSDL nyelv a webszolgáltatások leírására szolgál, az UDDI felület pedig a webszolgáltatási nyilvántartások rendszerezésére szolgál, amelyekben a fejlesztők és a cégek kereshetik a számukra szükséges szolgáltatásokat, valamint közzétehetik szolgáltatásaik adatait.

A webszolgáltatások támogatása sok termék előállítására szakosodott vállalat egyik fő stratégiai irányává vált alkalmazásszerverek, adatbázis-kezelő rendszerek és alkalmazásfejlesztő eszközök.

(SOA, szolgáltatás-orientált architektúra)– a szoftverfejlesztés moduláris megközelítése, amely szabványosított interfésszel ellátott szolgáltatások használatán alapul.

Az OASIS (Organization for Open Standards for Structured Information) a következőképpen határozza meg a SOA-t (OASIS Referencia Model for Service Oriented Architecture V 1.0): Szolgáltatás-orientált architektúra az elosztott rendszerezés és használat paradigmája információs források mint például: alkalmazások és adatok, amelyekért a különböző tulajdonosok felelősek, hogy a fogyasztó elérje a kívánt eredményt, amely lehet: a végfelhasználó vagy más alkalmazás.

A SOA az újrafelhasználhatósági elveken alapul funkcionális elemek IT, a funkcionalitás duplikációjának megszüntetése a szoftverekben, a szabványos működési folyamatok egységesítése, a vállalati működési modell centralizált folyamatokba való áthelyezésének biztosítása, ill. funkcionális szervezet ipari integrációs platformon alapul.

A programkomponensek eloszthatók különböző hálózati csomópontok között, és független, laza csatolású, cserélhető alkalmazásszolgáltatásként kínálják őket. Szoftverrendszerek A SOA-val összhangban kifejlesztett, gyakran jól ismert szabványos protokollokkal (SOAP, WSDL stb.) integrált webszolgáltatások halmazaként valósul meg.

A SOA-programok komponens-interfésze egy adott komponens (OS, platform, programozási nyelv, szállító stb.) megvalósítási részleteit más komponensekből zárja be. Így a SOA rugalmas és elegáns módot biztosít az összetevők kombinálására és újrafelhasználására komplex elosztott szoftverrendszerek felépítéséhez.

A SOA jól bevált a nagyvállalatok felépítésében szoftveralkalmazások. Számos fejlesztő és integrátor kínál SOA-alapú eszközöket és megoldásokat (pl. IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Kommunikációs Alapítvány, SAP NetWeaver, IVK Jupiter, TIBCO, Diasoft).

A SOA használatának fő céljai nagy információs rendszerekben, vállalati szinten és magasabb szinten a következők:

az alkalmazásfejlesztés költségeinek csökkentése a fejlesztési folyamat egyszerűsítésével;
a kód újrafelhasználásának javítása;
függetlenség a használt platformoktól, eszközöktől és fejlesztési nyelvektől;
a létrehozott rendszerek skálázhatóságának növelése;
a létrehozott rendszerek irányíthatóságának javítása.

SOA alapelvek:

az építészet, mint olyan, nem kötődik egyetlen technológiához sem;
a rendszerszervezet függetlensége a használttól számítástechnikai platform(platformok);
a rendszer szervezetének függetlensége a használt programozási nyelvektől;
konkrét alkalmazásoktól független, egységes hozzáférési felülettel rendelkező szolgáltatások igénybevétele;
szolgáltatások szervezése az épületrendszerek lazán összekapcsolt elemeiként.

Az architektúra nem kötődik semmilyen konkrét technológiához. segítségével valósítható meg széles körű technológiák, beleértve az olyan technológiákat, mint a REST, RPC, DCOM, CORBA vagy a webszolgáltatások. A SOA ezen protokollok egyikével valósítható meg, és például az adatcseréhez egy fájlrendszer-mechanizmust is használhat.

A SOA-ban a legfontosabb a független szolgáltatások használata, világosan definiált interfészekkel, amelyeket feladataik ellátása érdekében egyesek meghívhatnak. szabványos módon, feltéve, hogy a szolgáltatások nem tudnak előre semmit az őket hívó alkalmazásról, és az alkalmazás nem tudja, hogy a szolgáltatások hogyan látják el feladatukat.

A SOA egy információs rendszer architektúra stílusnak is tekinthető, amely lehetővé teszi olyan alkalmazások létrehozását által épített lazán összekapcsolt és kölcsönhatásban álló szolgáltatások kombinációi. Ezek a szolgáltatások valamilyen szigorúan meghatározott platform- és nyelvfüggetlen interfészen (például WSDL) alapulnak. Az interfész definíció elrejti a szolgáltatás nyelvspecifikus megvalósítását.

Így a SOA alapú rendszerek függetlenek lehetnek a fejlesztési technológiáktól és platformoktól (például Java, .NET stb.). Például a .Net platformon futó C#-ban írt szolgáltatásokat és a Java EE platformokon futó Java-ban írt szolgáltatásokat egy közös kompozit alkalmazás ugyanolyan sikerrel hívhatja meg. Az egyes platformokon futó alkalmazások hívhatják a más platformokon futó szolgáltatásokat, megkönnyítve az összetevők újrafelhasználását.

, , terminál, Alkalmazásszerver, Adatbázis szerver, Elosztott rendszerek architektúrája, , Szolgáltatás-orientált architektúra.

A webalkalmazások általában kliens-szerver architektúra alkalmazásként épülnek fel, de a szerveroldal eltérő architektúrákkal rendelkezik.

A világhálót (WWW) eredetileg „információmegosztó térként képzelték el, amelyben az emberek és a számítógépek kommunikálhatnak egymással”. Ezért az első webalkalmazások primitív fájlszerverek voltak, amelyek statikus HTML-oldalakat küldtek vissza az azokat kérő ügyfeleknek. Így a web dokumentum-orientáltnak indult.

Az Internet Server API (ISAPI) megjelenése nemcsak a CGI-alkalmazásoknál felmerült teljesítményproblémákat oldotta meg, hanem gazdagabb programozási felületet is biztosított a fejlesztőknek. Az ISAPI DLL-ek egy speciális metabázison keresztül társíthatók fájlnév-kiterjesztésekkel. Ez a két mechanizmus (CGI és ISAPI) szolgált alapul az első típusú webalkalmazások létrehozásához, amelyekben a kliens műveleteitől függően kiszolgálókódot hajtottak végre. Így lehetővé vált a weboldalak tartalmának dinamikus generálása, és a web tartalma megszűnt pusztán statikus lenni.

Az ISAPI felület a Microsoft Internet Information Server szolgáltatása. Az ISAPI alkalmazások dinamikus betöltési könyvtárak (DLL-ek), amelyek a webcímtérben futnak. szerverek. Idővel más webszerverek is képessé váltak könyvtárként megvalósított alkalmazások futtatására. A Netscape webszerverek esetében ezt a programozási felületet NSAPI-nak (Netscape Server API) hívták. A meglehetősen népszerű Apache webszerver képes könyvtárként megvalósított webalkalmazások futtatására is; az ilyen könyvtárakat Apache DSO-nak (Dynamic Shared Objects) nevezik.

Az ASP fő gondolata az alkalmazási felület létrehozása szempontjából az, hogy egy weboldalon kódrészletek találhatók, amelyeket a web értelmez. szerverés amely helyett a felhasználó ezeknek a kódrészleteknek a végrehajtásának eredményét kapja meg.

Az Active Server Pages technológia legújabb verziója - ASP .NET, amely kulcsfontosságú építészet Microsoft .NET-keretrendszer. Az ASP .NET használatával webalkalmazásokat és webszolgáltatásokat hozhat létre, amelyek nemcsak dinamikus HTML-oldalgenerálást tesznek lehetővé, hanem integrálhatók a kiszolgáló összetevőivel, és számos olyan üzleti probléma megoldására használhatók, amelyek a modern fejlesztők előtt felmerülnek. Webes alkalmazások.

Általánosságban elmondható, hogy a webszerver-kliens nem csak egy normál webböngészővel felszerelt személyi számítógép lehet. A mobil eszközök széles körű elterjedésével párhuzamosan felmerült a webszerverek ezen eszközök által értelmezhető adatokkal való ellátásának problémája is. Mivel a mobileszközök jellemzői eltérnek a személyi számítógépekétől (korlátozott képernyőméret, kis memória, és gyakran képtelenség néhány soros fekete-fehér szövegen kívül mást megjeleníteni), léteznek számukra más adatátviteli protokollok (WAP - Wireless Access Protocol) és a megfelelő jelölőnyelvek (WML - Wireless Markup Language, СHTML - Compact HTML stb.). Ilyenkor felmerül a feladat, hogy a megfelelő formátumban adatokat vigyünk át egy mobileszközre (és erre a célra vannak speciális oldalak), vagy ami kényelmesebbnek tűnik, az eszköz típusát a rendszer felismeri a hozzáférés pillanatában. szerverés a forrásdokumentum átalakítása (pl. XML formátumban) egy adott mobil eszköz által megkívánt formátumba (pl. XSLT transzformáció segítségével).

A különböző típusú kliensek támogatásának másik módja az "intelligens" szerverkomponensek létrehozása, amelyek a kliens típusától függően eltérő kódot tudnak generálni. Ez a megközelítés különösen a Microsoft ASP .NET-ben valósul meg.

A webalkalmazások kliens részei fejlesztésének másik iránya az alkalmazáslogika egy részének (például a bemeneti adatok helyességének ellenőrzése) elhelyezése magában a webböngészőben. A modern webböngészők különösen képesek a szkriptnyelvek (VBScript, JavaScript) értelmezésére, amely kód az ASP-kódhoz hasonlóan be van ágyazva egy weboldalba, de nem a webszerver, hanem a böngésző és , ennek megfelelően a kliens eszközön végrehajtva. Ezenkívül a modern böngészők képesek a speciális COM-kiszolgálók böngészőcímterében futó Java kisalkalmazások - speciális Java alkalmazások, amelyeket a felhasználó egy weboldal részeként kap, és egyes böngészők ActiveX-vezérlők konténereiként is szolgálhatnak - megjelenítésére és végrehajtására. , amelyet szintén a Web oldal részeként kaptunk. Mind a Java kisalkalmazásokban, mind az ActiveX-vezérlőkben szinte bármelyiket megvalósíthatja funkcionalitás.

Vegye figyelembe, hogy a felhasznált adatok mennyiségének és a webhelylátogatók számának növekedésével a webalkalmazások megbízhatóságára, teljesítményére és méretezhetőségére vonatkozó követelmények is növekednek. Az ilyen alkalmazások fejlődésének következő lépése a webalkalmazásban megvalósított üzleti logika, és gyakran az adatfeldolgozási és tranzakciós szolgáltatások elválasztása volt a felületétől. Ebben az esetben az úgynevezett prezentációs rész általában magában a webalkalmazásban marad, és az üzleti logika, az adatfeldolgozás és a tranzakció végrehajtása átkerül alkalmazásszerverüzleti objektumok formájában. Típustól függően alkalmazásszerver Ezek az üzleti objektumok lehetnek önfutó COM-kiszolgálók, CORBA-kiszolgálók, Windows 2000 Component Services használatával futó COM+-objektumok vagy futó EJB-k (Enterprise Java Beans). alkalmazásszerver, támogatja a J2EE specifikációt (Java 2 Enterprise Edition). Az ilyen objektumok OLE DB-t, ODBC-t, JDBC-t használhatnak adatelérési mechanizmusként (ez az üzleti objektum megvalósítási módjától függ).

Az ilyen üzleti objektumok gyakran hozzáférést biztosítanak a vállalati információs rendszerek adataihoz, vagy megvalósítják azok egy részét funkcionalitás. Gyakran lehetővé teszik például egy weboldal integrációját CRM (Customer Relationship Management) vagy ERP (Enterprise Resource Planning) rendszerekkel, a webhely látogatóiról szóló információk tárolását a vállalati rendszerekben, valamint a potenciális ügyfelek tájékoztatását az elérhető termékekről a rendelések leadásához.

Mivel a modern internet nem annyira a vállalat piaci jelenlétének demonstrálásának vagy marketingeszköznek, hanem sokkal inkább az üzleti tevékenységnek az eszköze, az ügyfelekkel az interneten keresztüli kapcsolatok megszervezésének feladatai, mint az áruk és szolgáltatások értékesítése elég fontos. És itt igen fontossá válnak a „vállalkozás-vevő” típusú (B2C – business-to-consumer) e-kereskedelem megoldásai. Nem kevésbé fontosak a webalkalmazások integrálása a partnerek adataival és alkalmazásaival a vállalkozások közötti (B2B - business-to-business) séma megvalósítása érdekében, amely lehetővé teszi a vállalkozások közötti kereskedelmi tranzakciók megkötését, termékkatalógusok cseréjét, lebonyolítását. aukciók, elektronikus kereskedési platformok létrehozása.

Vegye figyelembe, hogy egy ilyen megoldás szerves részeként a webszervernek képesnek kell lennie nemcsak alkalmazások futtatására és interakcióra alkalmazásszerver, hanem integrációs szolgáltatásokat, alkalmazás- és adatkezelési szolgáltatásokat, valamint fejlesztőknek szóló szolgáltatásokat is igénybe vehet.

A fentieket összefoglalva kiemelhetjük a webarchitektúra főbb jellemzőit:

nincs szükség további szoftver használatára a kliens oldalon - ez lehetővé teszi az ügyfélrész automatikus megvalósítását minden platformon;

szinte korlátlan számú ügyfél csatlakoztatásának képessége;

az egyetlen adattárolási helynek és az adatbázis-kezelő rendszer meglétének köszönhetően az adatintegritás megőrzésének minimális követelményei biztosítottak;

elérhetőség, amikor a szerver és a kommunikációs csatornák működnek;

elérhetetlenség, ha a szerver vagy a kommunikációs csatornák nem működnek;

a webszerver és az adatátviteli csatornák meglehetősen alacsony sebessége;

az adatok mennyiségét illetően – építészet A webes rendszereknek nincsenek jelentős korlátai.

Sematikusan így építészetábrán látható módon (három linkes változatban) ábrázolható. 5.9.

Rizs. 5.9. Webalkalmazás-architektúra

Bevezetés

Az alábbiakban felsoroljuk a három leggyakoribb mintát:

Egyszerű webes kliens- leggyakrabban olyan internetes alkalmazásokhoz használják, ahol lehetetlen kezelni a kliens konfigurációját. A kliensnek csak egy normál webböngészőre van szüksége, amely képes az űrlapok feldolgozására. Minden üzleti logika a szerveren fut.

Speciális webkliens- Az üzleti logika jelentős része a kliens rendszerben valósul meg. A kliens jellemzően dinamikus HTML-t, Java kisalkalmazásokat, ill ActiveX vezérlők. A szerverrel való adatcsere továbbra is HTTP protokoll használatával történik.

Webes szállítás- A HTTP protokoll mellett az olyan protokollok, mint az IIOP és a DCOM, használhatók elosztott objektumrendszerek támogatására, beleértve a klienst és a szervert is. A webböngésző elsősorban ügynökként működik az objektumok tárolására és eljuttatására elosztott rendszer.

Egyszerű webes kliens

Az egyszerű webes kliens architektúrát olyan internetes alkalmazásokhoz használják, amelyekben az ügyfélkonfiguráció kezelése nem lehetséges. Az összes üzleti logika a szerveren fut, amely kiszolgálja az ügyfél böngészőkéréseit.

Felhasználási feltételek

Ez a minta alkalmas az internetes webalkalmazásokhoz vagy olyan környezetekhez, ahol az ügyfél kicsi számítási erőforrások, vagy az ügyfélkonfiguráció kezelése nem lehetséges.

Ismert alkalmazások

A legtöbb internetes e-kereskedelmi alkalmazás ezzel a mintával működik, mivel helytelen lenne megtagadni az ügyfelek hozzáférését csak azért, mert nincs elegendő számítási teljesítményük. Az e-kereskedelem igyekszik minden vásárló kedvében járni, mivel a Commodore Amiga felhasználó pénztárcájában lévő pénz nem rosszabb, mint a pénz Windows felhasználó N.T.

Szerkezet

A vékony webes kliens architektúra fő összetevői a szerveren találhatók. Azt mondhatjuk, hogy ez az architektúra egy minimalista webalkalmazás-architektúra. Fő összetevői a következők:

Kliens böngésző- Bármilyen böngésző, amely támogatja HTML űrlapok. A böngésző univerzális eszközként működik felhasználói felület. Az egyszerű kliens architektúrában a cookie-k küldésének és fogadásának funkcióit is ellátja. Felhasználói böngészés a böngészőben Weboldalak . Ezek az oldalak tartalmazzák az összes felhasználói felület összetevőt, szöveget és vezérlőket, amelyeket a böngésző megjelenít a monitor képernyőjén. Minden felhasználói interakció a következővel: megy a rendszer
böngészőn keresztül.- A kliens böngésző fő partnere. A webszerver elfogadja a böngésző kéréseit, és statikus weblapokat vagy a szerveren megjelenített oldalakat küld. A kéréstől függően a webszerver műveleteket is végezhet a szerveren. Ha olyan oldalt kérnek, amely CGI-, ISAPI- vagy NSAPI-szkriptet tartalmaz, a webszerver átadja az irányítást a parancsfájl-értelmezőnek vagy a végrehajtható modulnak. Mindkét esetben az eredmény egy HTML-oldal lesz, amelyet a böngésző megjelenít.

HTTP kapcsolat- Ez a leggyakrabban használt kommunikációs protokoll a kliens böngésző és a webszerver között. Ez az elem az ügyfél és a szerver közötti kapcsolat nélküli kommunikáció típusát jelöli. Amikor az ügyfél információkat küld a szervernek, új kapcsolat jön létre.

A HTTP kapcsolatok a Secure Sockets Layer (SSL) használatával védhetők. Az ilyen kapcsolatokban a kliens és a szerver között továbbított információ nyilvános és privát kulcsú mechanizmusok segítségével titkosítva történik. HTML oldal

- A szerver által nem feldolgozott tartalmat és felhasználói felület elemeit tartalmazó weboldal. Ezek az oldalak általában szöveget tartalmaznak, például útmutatást vagy súgót, vagy HTML beviteli űrlapokat. Amikor egy HTML oldalt kérnek, a webszerver egyszerűen beolvassa a fájlt, és minden további feldolgozás nélkül elküldi a kliensnek. Forgatókönyv - Weboldal, amelyre a szerver teljesít további feldolgozás

Alkalmazásszerver. Ezek az oldalak általában szkriptnyelvű töredékeket tartalmaznak (Active Server Pages, Java Server Pages, Cold Fusion), és az alkalmazáskiszolgálón vagy a végrehajtható modulon (ISAPI vagy NSAPI) lévő szűrőhöz kerülnek. Az ilyen oldalak a szerveren lévő összes erőforrással működhetnek, beleértve az üzleti logikai összetevőket, az adatbázisokat és a fizetési rendszereket. - Az üzleti logika fő mechanizmusa a szerveren. Az alkalmazásszerver felelős a szkriptkód végrehajtásáért. Elhelyezhető ugyanazon a rendszeren, mint a webszerver, és akár ugyanabban a folyamattérben is. Az alkalmazásszerver az külön elem

architektúra, mivel csak az üzleti logika végrehajtásáért felelős, és a webszervertől függetlenül is működhet.

Az ábra egy egyszerű webes kliens architektúráját mutatja be.

Egy egyszerű webes kliens minimális architektúrája nem tartalmaz néhány olyan összetevőt, amelyeket gyakran használnak a webalkalmazásokban, például egy adatbázist. A webalkalmazások gyakran egy adatbázissal dolgoznak információtárként. Bizonyos helyzetekben az adatbázis tárolhatja magukat az oldalakat is, de ez a lehetőség más architektúrának felel meg.

Mivel a webalkalmazások sokféle tárolási technológiát használhatnak, ezt az építészeti összetevőt általánosabb kifejezésnek nevezik: tárolás. A tárolókomponens tartalmazhat egy tranzakció-feldolgozási monitort (TPM). Egyszerű módon a kiszolgálón lévő parancsfájlok közvetlenül hozzáférnek a tárolókomponenshez. A közvetlen eléréshez még ebben az opcióban is szabványos adatelérési könyvtárak szükségesek, például RDO, ADO, ODBC, JDBC, DBLib. Ezért a parancsfájloknak tisztában kell lenniük azzal, hogy melyik adatbázissémát használják. Forgatókönyvek készülnek SQL lekérdezések

és adatokat kapunk az adatbázisból. Kis webes alkalmazásokban ez elegendő lehet. Nagyobb és megbízhatóbb rendszerek esetén célszerű az üzleti logikát külön blokkra különíteni. Az üzleti logika egy üzleti objektum komponensben valósul meg. Ezt az összetevőt általában az alkalmazáskiszolgálón fordítják le és hajtják végre. Egy architekturális összetevő, például egy üzleti objektum, lehetővé teszi, hogy más rendszerek is működjenek vele, ha ugyanazt az üzleti logikát alkalmazzák. Például egy webáruház a vevői kérések feldolgozásához használhat szkripteket a szerveren és egy egyszerű webes kliens architektúráját, de ez nem lesz elég a könyvelési részlegnek, helyette kliens-szerver rendszert alkalmaznak. Ebben az esetben a számviteli osztály ugyanazokkal az üzleti összetevőkkel fog dolgozni az alkalmazáskiszolgálón, mint az ügyfél szoftver

funkcionálisabb lesz. Mivel az adatbázist a legtöbb üzleti megoldásban használják, a szerver és az adatbázis közé általában egy további építészeti komponens kerül telepítésre. Biztosítja az üzleti objektumok lefordítását adatbázis-lekérdezésekké. Ez a szint megvalósítható különféle módokon

, és erről itt nem lesz szó. Ez az architektúra gyakran más összetevőket is tartalmaz, például integrációt a régi rendszerekkel vagy fizetési rendszerekkel. Ezek a rendszerek üzleti objektumain vagy alkalmazáskiszolgálóin keresztül érhetők el, formális üzleti objektum összetevő nélkül. Az operációs rendszer lehet számviteli rendszer vagy termeléstervező rendszer. lehetővé teszi hitelkártyás fizetések elfogadását és feldolgozását az interneten. Azon kisvállalkozások számára, amelyek online szeretnének üzletet nyitni, számos különböző fizetési rendszer létezik. A nagyvállalatok számára ez az összetevő valószínűleg egy meglévő hitelkártyás fizetés-feldolgozó rendszer interfészét jelenti.

Ezeket az összetevőket figyelembe véve logikai áramkör Az egyszerű kliens architektúra teljesebbé válik. Az ábrán látható.

Egy egyszerű webes kliens logikai diagramja

A legtöbb webalkalmazásszerver-összetevő megtalálható a nem webalapú alkalmazásokhoz is. Az alapvető webes alkalmazásprogram elrendezése és architektúrája nem sokban különbözik bármely mainframe vagy kliens-szerver rendszer elrendezésétől. A webalkalmazások más rendszerekhez hasonlóan működnek az adatbázisokkal és a tranzakciófeldolgozó monitorokkal (TPM). Például az Enterprise Java Beans (EJB) és a Microsoft Transaction Server (MTS) technológiákat webalkalmazásokhoz tervezték, de ugyanúgy alkalmazhatók más alkalmazásarchitektúrákra is.

A webalkalmazások szerverösszetevőinek architektúrája minden kliens-szerver rendszerben közös. IN ezt a felülvizsgálatot csak a webalkalmazásokhoz használt összetevőket tárgyaljuk, és nem térünk ki a lehetséges architektúrákra alapprogramok a szerveren.

Dinamika

Ennek az architektúramintának a dinamikájának fő mozgatórugója az, hogy az üzleti logika csak az ügyfél kérésére válaszolva kerül végrehajtásra. A kliensek úgy dolgoznak a rendszerrel, hogy weboldalakat kérnek le egy webszervertől a HTTP protokollon keresztül. Ha az oldal normál HTML fájl a szerver fájlrendszerében a webszerver elküldi a kliensnek.

Ha az oldal olyan parancsfájlokat tartalmaz, amelyeket le kell hajtani, mielőtt választ küldene az ügyfélnek, a webszerver átadja az irányítást az alkalmazáskiszolgálónak. Az alkalmazásszerver parancsfájlokat hajt végre, és szükség esetén hozzáfér más szerver erőforrásokhoz, például adatbázisokhoz, levelekhez, élő rendszerekhez stb. A szkript kódja hozzáfér az oldalkérést kísérő speciális információkhoz. Ez az információ tartalmazza a felhasználó által megadott űrlapadatokat és a kéréshez csatolt paramétereket. A feldolgozás végeredménye egy formázott HTML oldal, amelyet elküldünk a kliensnek.

Az oldal egy végrehajtható modulnak, például ISAPI vagy NSAPI DLL-nek is átadható feldolgozás céljából. A DLL egy lefordított könyvtár, amely betölthető végrehajtásra az alkalmazáskiszolgáló által. Ez a modul ugyanazokkal a kérésadatokkal (űrlapmezőkkel és paraméterekkel) tud dolgozni, mint a szkriptek.

Így az üzleti logika csak a kérésfeldolgozás során hívódik meg. Amint a kérés feldolgozása befejeződött, az eredmény elküldésre kerül a kliensnek, és az ügyfél és a szerver közötti kapcsolat bezárul. Előfordulhat, hogy egy üzleti folyamat nem zárul le a kérés teljesítése után, de valószínűleg ez a kivétel.

Következtetések

Ez az architektúra a legalkalmasabb azokhoz az alkalmazásokhoz, amelyekben a szerver válasza ésszerű időn belül elkészül a felhasználó és az ügyfél böngészője számára egyaránt. Általában ez az idő nem több, mint néhány másodperc. Ez az architektúra nem alkalmas olyan feladatokhoz, ahol a felhasználó üzleti folyamatokat futtat és figyel hosszú ideig. A streaming technológiák azonban felhasználhatók a folyamatos folyamatok nyomon követésére. Az ilyen technológiák a legtöbb esetben az adatok frissítését a szerverhez intézett időszakos kérések révén valósítják meg.

Ennek az architektúrának egy másik következménye, hogy a felhasználói felület korlátozott. A teljes felhasználói felület a böngészőben fut, ezért csak a böngészőn keresztül elérhető elemekre korlátozódik.

Speciális webkliens

A legtöbb böngésző támogatja a HTML specifikációban meghatározott beviteli mezők és gombok kis csoportját. Ez nem feltétlenül hátrány, sőt, néha megakadályozza, hogy a fejlesztők elragadják a kifinomult felületek létrehozását, amikor az egyszerűek is elegendőek.

Felhasználási feltételek

A fejlett webes kliens architektúrája eltér az egyszerű webes kliensétől a kliensoldali parancsfájlok és aktív objektumok, ActiveX és Java kisalkalmazások használatában. A gazdag webes kliens mintát azért nevezték így el, mert a kliens az üzleti logikának egy részét futtathatja a rendszerén, így nem csupán felhasználói felület tárolója. A gazdag webes kliens architektúra a legalkalmasabb olyan webes alkalmazásokhoz, ahol kliens beállítása

Így a fejlett kliens lehetővé teszi egy funkcionálisabb felhasználói felület megvalósítását és az üzleti logika egy részének végrehajtását az ügyfélben. Ezek a felhasználói felület funkciói 3D modellek megtekintésére vagy pénzügyi diagramok animálására használhatók. Az ActiveX-vezérlők segítségével ügyfélberendezésekkel, például megfigyelőeszközökkel dolgozhat. Például a távoli területeken élő betegek vérnyomásának és vércukorszintjének napi ellenőrzése csökkentheti a személyes orvosi látogatások szükségességét.

Bizonyos helyzetekben az üzleti logika teljesen áthelyezhető az ügyfélre. Ehhez az ügyfélnek rendelkeznie kell a folyamat működéséhez szükséges összes adattal. Ez a logika meglehetősen egyszerű lehet, például a bevitt adatok ellenőrzése.

Ismert alkalmazások

Ellenőrizheti a megadott dátumok helyességét, vagy összehasonlíthatja a megadott dátumokat, hogy a születésnap ne legyen későbbi, mint a beteg első kórházi látogatásának napja. Az üzletszabályzat szerint egyes mezők a megadott adatoktól függően be- vagy kikapcsolhatók. Az interneten a kliensoldali parancsfájlok, kisalkalmazások, aktív elemek és modulok legáltalánosabb felhasználási módjai a gazdag felhasználói felületek létrehozása. JavaScript szkriptek

a gombok vagy menük színének vagy címkéjének megváltoztatására szolgálnak HTML-oldalakon. A Java kisalkalmazások és ActiveX-vezérlők lehetővé teszik vezérlők létrehozását hierarchikus listában.

A Shockwave modulokat széles körben használják interaktív animációk készítésére is, lehetővé teszik a webhelyek vonzó grafikával való díszítését, de modellek renderelésére és sportesemények figyelésére is használják. A Microsoft beviteli vezérlőjét egyes webhelyeken arra használják, hogy hangvezérlés

és parancsok bevitele a böngészőbe a webhelyen való könnyebb navigáció érdekében.

Szerkezet

Az adatcsere a kliens és a szerver között az egyszerű kliensekhez hasonlóan HTTP-n keresztül történik. A HTTP protokoll anélkül működik, hogy állandó kapcsolatot létesítene a kliens és a szerver között. Az információkat csak az ügyfelek kérésére továbbítjuk. Ez azt jelenti, hogy az ügyfélben lévő parancsfájlok, az ActiveX-vezérlők és a Java kisalkalmazások csak az ügyfélben lévő objektumokkal tudnak együttműködni.

A gazdag webes kliens architektúra olyan böngészőfunkciókat használ, mint az ActiveX-vezérlők vagy a Java kisalkalmazások az üzleti logika végrehajtására az ügyfélben. Az ActiveX-vezérlők összeállított végrehajtható programok, amelyeket az ügyfél HTTP-n keresztül tölthet le böngészőjébe. Az ActiveX-vezérlők alapvetően COM-objektumok, és minden ügyfél-erőforráson működhetnek. Kapcsolatba léphetnek magával a böngészővel és a teljes ügyfélrendszerrel. Ezért általában az Interneten az ActiveX-vezérlők hitelességét harmadik felek "tanúsítják".

IN legújabb verziói A HTML böngészők is támogatják a kliensoldali szkriptet. A JavaScript vagy a VBScript beágyazható HTML oldalakba. Ezek a szkriptek lehetővé teszik az üzleti logikai funkciók egy részének átvitelét magához a böngészőhöz, amely végrehajtja (vagy inkább értelmezi) a kódot. Azért mondjuk az "engedélyezést", mert ezek a szkriptek legtöbbször csak a felhasználói felületet fejlesztik, de üzleti logikai funkciókat nem látnak el. Mindenesetre a HTML-oldalakon található szkriptek fontos építészeti elemek.

Mivel a gazdag kliens architektúra gyakorlatilag az egyszerű kliens architektúra kiterjesztése, a legtöbb jelentős építészeti elem ugyanaz. Íme a további elemek, amelyeket a gazdag kliens architektúra bevezet:

Szkriptek a kliensben- HTML-oldalakba ágyazott JavaScript vagy Microsoft® VirtualBasic® szkriptek.

A böngésző értelmezi a szkriptet. A W3C meghatározta azt a HTML felületet és dokumentumobjektum modellt, amelyet a böngésző a szkriptek kezelésére használ. XML dokumentum

- eXtensible Markup Language (XML) formátumú dokumentum. Az XML-dokumentumok az adatokat képviselik, függetlenül attól, hogy a felhasználói felülethez milyen formázásúak.- COM objektum, amelyre egy parancsfájl hivatkozhat és betölthető a kliensbe. Mint minden COM objektum, teljes hozzáféréssel rendelkezik az ügyfél erőforrásaihoz. A kliens rendszerét védeni kell, ennek elsődleges mechanizmusa az aláírás és a hitelesítés. Előfordulhat, hogy a böngészők nem fogadnak el ActiveX-vezérlőket, vagy figyelmeztethetik a felhasználót, hogy egy ilyen elem betöltődik a kliensbe. Azonosítási és aláírási mechanizmusok segítségével harmadik felek ellenőrizhetik a vezérlőelem szerzőjének hitelességét.

Java kisalkalmazás- egy önálló összetevő, amely a böngésző kontextusában fut. Védelmi okokból megvan korlátozott hozzáférés az ügyfél erőforrásaihoz. A Java kisalkalmazások komplex felhasználói felületelemek létrehozására és egyéb feladatokra is használhatók, például XML dokumentumok elemzésére vagy üzleti logikai funkciók megvalósítására.

JavaBean- Java komponens, amely olyan interfészkészletet valósít meg, amely lehetővé teszi a nagy és összetett rendszerekbe való beágyazását. A bab kifejezés modularitást és egy meghatározott célra való alkalmasságát tükrözi. Egy csésze kávéhoz általában több szemes kávé kell, nem csak egy. Az ActiveX a JavaBean analógja a Microsoft rendszerekben.

Az ábra a fejlett webes kliens architektúrájának diagramját mutatja.

Advanced Web Client Architecture Diagram

Dinamika

A gazdag kliens architektúra kiegészíti az egyszerű kliens dinamikáját azáltal, hogy lehetővé teszi az üzleti logika futtatását az ügyfélben. Az adatcsere a kliens és a szerver között az egyszerű kliensekhez hasonlóan HTTP kérésekkel történik. Az üzleti logika egy részét azonban szkriptek, kisalkalmazások vagy az ügyfél aktív elemei hajthatják végre.

Az ügyfélböngészőnek küldött oldal szkripteket, kisalkalmazásokat vagy aktív elemeket tartalmazhat. Használhatók a felhasználói felület javítására vagy üzleti logikai célokra. A legegyszerűbb lehetőség a mezőkbe beírt adatok ellenőrzése. A kliens szkriptek ellenőrizni tudják, hogy a megadott adatok helyesek-e a weboldal minden mezőjében. Például egy e-kereskedelmi alkalmazás szkripteket használhat annak biztosítására, hogy a felhasználók csak kompatibilis beállításokat adjanak meg a rendszer konfigurálásakor.

Java kisalkalmazások és aktív elemek használatához meg kell adni azokat a HTML oldalon. Ezek az elemek az oldalszkriptektől függetlenül működhetnek, vagy azokkal vezérelhetők. A HTML-oldalon lévő szkriptek képesek kezelni a böngésző által küldött különleges eseményeket. Ezek az események azt jelezhetik, hogy egy weboldal betöltése befejeződött, vagy a felhasználó az egeret az oldal bizonyos területére mozgatta.

A szkriptek a Document Object Model (DOM) alapján működnek. Ezt a felületet a W3C szabványosítja, és lehetővé teszi a szkriptek, kisalkalmazások és aktív elemek számára a HTML-oldalak tartalmának elérését. A Microsoft és a Netscape ezt a modellt dinamikus HTML-ként (DHTML) valósította meg. A DHTML nem csupán a DOM interfész megvalósítása, hanem eseménykezelést is magában foglal, amely az írás idején nem volt része a DOM 1. szintű specifikációjának.

A Document Object Model számos interfészen alapul az XML dokumentumok feldolgozásához. Az XML egy rugalmas nyelv, amely lehetővé teszi saját címkéinek használatát. A DOM interfész lehetővé teszi az ügyfélszkriptek számára, hogy XML dokumentumokkal dolgozzanak.

Az XML-lel, mint a kliens és a szerver közötti adatcsere szabványos mechanizmusával való munkát a kliens speciális összetevői biztosítják. Az ügyfél rendelkezhet ActiveX vezérlőkkel vagy Java kisalkalmazásokkal az XML dokumentumok feldolgozásához és küldéséhez. Például egy HTML-oldalba beágyazott Java kisalkalmazás HTTP-kérést küldhet egy webszervernek, hogy lekérjen egy XML-dokumentumot. A kérésadatok alapján a webszerver megállapítja, hogy nem egy HTML dokumentumot kell visszaküldeni, hanem egy XML dokumentumot.

Az ügyfélben egy HTML-oldalon futó kisalkalmazás fogadja az XML-dokumentumot, elemzi azt, és interakcióba lép a HTML-dokumentummal a böngészőben, hogy megjelenítse a tartalmat a felhasználó számára. Mindezeket a műveleteket a böngésző ugyanazon a HTML-oldalán hajtják végre.

Következtetések Ezt az architektúrát olyan megvalósítások létrehozására használják, amelyek működnek különböző böngészők . Nem minden HTML-böngésző támogatja a JavaScriptet vagy a VirtualBasic Scriptet. Csak az ActiveX-vezérlők működnek Microsoft rendszerek

Ha parancsfájlokat vagy aktív elemeket használ az ügyfélben, a tesztelésnek ellenőriznie kell a rendszer teljesítményét minden támogatott ügyfélkonfiguráció esetében. Mivel az üzleti logika egy része az ügyfélben fut, fontos annak biztosítása, hogy ez minden böngészőben megfelelően működjön. Hiba lenne azt feltételezni, hogy minden böngésző ugyanúgy működik. A különböző böngészők nemcsak ugyanazzal a kóddal viselkednek eltérően, hanem azonos A böngésző eltérően működhet egy másik operációs rendszeren.

Webes szállítás

Ezt az architektúramintát webes kézbesítésnek nevezik, mivel a webet a hagyományos elosztott kliens-szerver rendszer átviteli közegeként használják. Bizonyos értelemben ez egy elosztott kliens-szerver alkalmazás, amely a webszervert és a kliens böngészőt tartalmazza az architektúra lényeges elemeiként. Az, hogy a rendszert elosztott objektumokkal rendelkező webalkalmazásnak vagy webes összetevőket tartalmazó elosztott objektumok rendszerének hívják, nem változtat a lényegen.

Felhasználási feltételek

Már maga az a tény, hogy egy ilyen rendszerrel kapcsolatban két nézőpont létezik, és az a tény, hogy az elosztott rendszereket mindig is gondos modellezést igénylő rendszereknek tekintették, ismét rávilágít arra, hogy a webes alkalmazásokat úgy kell modellezni és tervezni, mint bármely más szoftverrendszert. . A webes kézbesítési architektúra különösen előnyös olyan helyzetekben, ahol finomhangolás

kliens és hálózati konfigurációk.

Nem nagyon alkalmas az internetes alkalmazásokhoz, ahol a kliens konfigurációja nem kezelhető, és maga a hálózat nem túl megbízható.

Ismert alkalmazások

A CNN Interactive webhely az egyik legforgalmasabb híroldal az interneten. Tartalmának nagy része elérhető a hagyományos böngészők számára HTML 3.2-es oldalként, de a színfalak mögött a webhely bonyolult CORBA-hálózatot működtet, amely böngészőket, szervereket és elosztott objektumokat foglal magában. A Distributed Computing publikált egy tanulmányt erről a rendszerről.

Egy egészségügyi szoftvercég létrehozott egy webalkalmazást a betegrekordok és a számlázás kezelésére. A teljes felhasználói közönségnek csak egy kis része dolgozik a rendszer számlázási szempontjaival. A legtöbb régebbi számlázási rendszer FoxPro-ban készült. Új rendszer, Web alapú, továbbfejlesztett meglévő FoxPro funkcionalitás és segédprogramok dokumentumok ActiveX-komponensekké alakításához felhasználói felület és üzleti logika számára. Az így létrejövő rendszer fejlett kliens webalkalmazásként működik a beteg- és kórtörténet-feldolgozási szempontokhoz, valamint kézbesítő webes alkalmazásként a számlázási műveletekhez.

Szerkezet

A webes kézbesítési architektúrák és mások közötti legjelentősebb különbség a kliens és a szerver közötti kommunikáció módja. Más architektúrák esetében az elsődleges mechanizmus a HTTP, egy kapcsolat nélküli protokoll, amely megköti a fejlesztő kezét, amikor a felhasználó és a szerver közötti interakcióról van szó. A webes kézbesítési architektúra fontos elemei közé tartoznak az egyszerű kliensről szóló részben már felsoroltak, valamint a következők:

DCOM- Az elosztott COM a Microsoft elosztott objektum protokollja. Lehetővé teszi, hogy egy rendszer objektumai egy másik rendszer objektumainak metódusait hívják meg.

IIOP- Az Internet Inter-Orb Protocol egy OMG CORBA protokoll az interneten (vagy bármely TCP/IP hálózaton) elosztott objektumok interakciójára.

RMI (JRMP)- A Remote Method Invocation a Java módja annak, hogy interakciót biztosítson más rendszerek objektumaival. A JRMP (Java Remote Method Protocol) az RMI beépített protokollja, de nem ez az egyetlen használható. Az RMI az IIOP CORBA segítségével valósítható meg.

Az ábra a webes kézbesítési architektúra diagramját mutatja.

Webes szállítás architektúra diagramja

Dinamika

A webes kézbesítési architektúra alapvető dinamikája a böngésző használata az elosztott objektumok rendszeren belüli szállítására. A böngészőt a felhasználói felület és néhány üzleti objektum tárolójaként használják, amelyek maguk a böngészőtől függetlenül kapcsolódnak a szerveren lévő objektumokhoz. A kliens és a szerver objektumok közötti kommunikáció az IIOP, RMI és DCOM protokollok használatával történik.

A böngésző ezen elosztott rendszerben való futtatásának fő előnye az, hogy képes automatikusan letölteni a szükséges összetevőket a szerverről. Új számítógép Ha kompatibilis webböngészővel rendelkezik, akkor egyszerűen csak bejelentkezik a hálózatba. Nincs szükség más szoftverre, a böngésző maga tölti be a szükséges összetevőket a kliensbe. Az összetevőket szükség szerint telepítjük a kliensre. Mind a Java kisalkalmazások, mind az ActiveX-vezérlők automatikusan menthetők a kliensbe. Ha ezek az összetevők a megfelelő weboldal betöltésekor aktiválódnak, azonnal aszinkron kommunikációba léphetnek a kiszolgálón lévő objektumokkal.

Az ügyfélben egy HTML-oldalon futó kisalkalmazás fogadja az XML-dokumentumot, elemzi azt, és interakcióba lép a HTML-dokumentummal a böngészőben, hogy megjelenítse a tartalmat a felhasználó számára. Mindezeket a műveleteket a böngésző ugyanazon a HTML-oldalán hajtják végre.

Ez az architektúra olyan megvalósítások létrehozására szolgál, amelyek különböző böngészőkben működnek. Egy ilyen rendszer működtetéséhez megbízható hálózatra van szükség. A kliens és a szerver objektumok közötti kapcsolat lényegesen tovább tart, mint egy HTTP kapcsolat, így a véletlenszerű szerverhibák, amelyek a másik két architektúrában nem jelentenének problémát, komoly problémákat okozhatnak egy ilyen rendszerben.