Többrétegű architektúra

A Wikipédiából, a szabad enciklopédiából

A többrétegű architektúra (vagy n rétegű architektúra) a szoftverfejlesztésben alkalmazott kliens-szerver architektúra, melyben a megjelenítés, az adatkezelés és az üzleti logika különálló folyamatokra van bontva. Az alkalmazás rétegekre bontásával a fejlesztők könnyen karbantartható és fejleszthető rendszereket hozhatnak létre, mivel elegendő egy-egy réteget javítani illetve bővíteni az egész alkalmazás módosítása helyett. A leggyakrabban alkalmazott rétegelés a háromrétegű architektúra.

A réteges szerkezetben minden réteg csak a szomszédaival kommunikál, az egyiktől szolgáltatásokat vesz igénybe, a másiknak szolgáltatást nyújt. Azt mondják, hogy egy réteg egy másik felett van, ha a másik szolgáltatásait veszi igénybe. Egy réteg működhet a felette levő rétegek nélkül, és az alatta levő rétegek szükségesek a működéséhez. Nyílt rétegű rendszerben a rétegek több alattuk levő réteg szolgáltatásai is igénybe vehetik. Az architektúrát több publikációban is leírták.[1]

Háromrétegű architektúra[szerkesztés]

Egy háromrétegű alkalmazás szerkezete

A háromrétegű architektúra egy szoftvertervezési minta is, a szoftverarchitektúrán felül. John J. Donovantól származik. A modell legnagyobb előnye, hogy lehetővé teszi az egyes rétegek egymástól függetlenül történő fejlesztését, sőt, akár teljes cseréjét is, lépést tartva így a folyamatosan változó követelményekkel és az egyre újabb technológiákkal. Ez biztonságosan megtehető, mert egy réteg módosítása nincs hatással a többi réteg működésére. Egymástól független modulokként tartalmazza a felhasználói felületet, az üzleti logikát és az adatbázist a szükséges hozzáférési műveletekkel. Például ha a megjelenítésért felelős szerverre új operációs rendszer kerül, akkor elég csak a megjelenítést vezérlő modulokat frissíteni az alkalmazásunkban, az új körülményeknek megfelelően.

Függetlenségük miatt különböző gépekre is telepíthetők, amelyek különböző platformot nyújtanak.[2] Tipikusan a felhasználói interfész grafikusfelületű PC-n vagy munkaállomáson fut, és szabványos felhasználói felületet használ. Az üzleti modul vagy modulok munkaállomáson vagy alkalmazásszerveren, míg az adatbázishoz RDBMS-t használnak egy adatbázisszerveren vagy nagyszámítógépen. Az egyes rétegek akár klaszterre is kerülhetnek.

Rétegek[szerkesztés]

Háromrétegű architektúra esetén az alkalmazást az alábbi 3 rétegre bontjuk:

  • Megjelenítés: a társ rendszer felé nyújt interfészt (gyakran ez a felhasználói interfész), és az ehhez kapcsolódó eseményeket kezeli le. Ennek a leggyakoribb megvalósítása a weboldal és az előállító logika.
  • Üzleti logika: ezen réteg feladata az üzleti folyamatok futtatása, hosszú életű tranzakciók kezelése. Itt kerül sor az adatok szélesebb hatókört, több adattípust átölelő szabályainak kikényszerítésére is.
  • Perzisztencia: az adatok tartós tárolásával foglalkozik. Itt történik meg a szűkebb hatókörrel rendelkező adatszabályok kikényszerítése és gyakran az objektum és relációs adatmodellek közötti leképezés is.

Ha a megjelenítést és az üzleti logikát összevonjuk, akkor a hagyományos kétrétegű szerver-kliens modellhez jutunk.

Használata webalkalmazásoknál[szerkesztés]

A webfejlesztés területén belül a "háromrétegű" kifejezéssel gyakran weboldalakra, azon belül is általában e-commerce weboldalakra utalnak. Ezek a weboldalak leggyakrabban az alábbi struktúra alapján épülnek fel:

  • 1. Front-end szerver: Egy webszerver, ami a felhasználói felületet alkotó (statikus vagy dinamikusan előállított) weboldalakat szolgáltatja.
  • 2. Alkalmazásszerver: Az alkalmazásszerver a dinamikus tartalmak előállítását és feldolgozását végzi. Tipikusan itt kapnak helyet a Java EE, PHP, ASP.NET, stb. alkalmazások.
  • 3. Adatbázisszerver: Az adatok tárolását és hozzáférését végzi, tipikusan egy relációs adatbázis-kezelő rendszer, mint például a MySQL, PostgreSQL, stb.

A háromrétegű architektúra és az MVC architektúra[szerkesztés]

A háromrétegű architektúrát gyakran keverik a megjelenítésben használatos MVC (Model-View-Controller) architektúrával. Fontos megemlíteni, hogy míg az MVC-nél a View és a Controller egyaránt kommunikál a Modellel addig a három rétegű architektúránál ez nem történik meg. A megjelenítés réteg csak az üzleti logikán át érheti el a perzisztenciát. A három réteg jelenti alapesetben azokat a választóvonalakat, amelyek mentén a horizontális skálázás megoldható. Amennyiben skálázhatóság, robusztusság vagy egyéb szempontok miatt nem elegendő a három réteg, akkor a három réteget újabb rétegekre lehet bontani. Ennek egy gyakori példája, amikor a perzisztencia réteget két rétegre bontjuk: az egyik az ORM (objektum-relációs leképezés) által megvalósított DAO (Data access object) tervezési minta mentén megvalósított réteg, míg alatta a hagyományos adatbázis réteg helyezkedik el.

Kommunikáció[szerkesztés]

A rétegek közötti kommunikáció az architektúra lényegéhez tartozik. A felhasznált protokollok sokfélék, mint SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation, socketek, UDP, webszolgáltatások, vagy szabványos vagy saját protokollok. Gyakran middleware-ok gondoskodnak a kommunikációról.

Négy- és többrétegű architektúra[szerkesztés]

Négyrétegű esetben a megjelenítés és az üzleti logika rétegek közé egy alkalmazás réteget iktatnak be. A Domain Driven Design a négyrétegű architektúráról ír, de a tartomány rétegre összpontosít.[3]

A négyrétegű architektúra rétegei:

  • Megjelenítés
  • Alkalmazás, nevezik szolgáltatás rétegnek[4][5] vagy GRASP vezérlő rétegnek is[6])
  • Üzleti logika
  • Perzisztencia

Az alkalmazás réteg további rétegekre osztható, amelyek felelősségei elkülöníthetők. Például a modell-nézet-vezérlő használata esetén a vezérlő plusz rétegként fogható fel a megjelenítés és az alkalmazás rétegek között.

Egyesek üzleti infrastruktúra réteget is beillesztenek az üzleti és az adatbázis rétegek közé. Nevezik üzleti szolgáltatás rétegnek vagy alacsony szintű üzleti rétegnek. Több alkalmazói rétegben is használatos, például tartalmazhat konvertereket.[7]

Az adatbázis réteg szintén felosztható, mint magas és alacsony szintű technikai szolgáltatások.[7] A fejlesztők gyakran csak a perzisztenciára koncentrálnak, ezért is nevezik perzisztencia rétegnek adatbázis vagy infrastruktúra réteg helyett. A további technikai szolgáltatásokra nem gondolnak úgy, hogy azok is ennek a rétegnek a feladatai.

Jegyzetek[szerkesztés]

  1. ↑ Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael (1996-08). Pattern-Oriented Software Architecture, Volume 1, A System of Patterns. Wiley, August 1996. ISBN 978-0-471-95869-7. Retrieved from http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html.
  2. ↑ Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications." Open Information Systems 10, 1 (January 1995): 3(20)
  3. ↑ Domain-Driven Design, the Book pp. 68-74. Retrieved from http://www.domaindrivendesign.org/books#DDD Archiválva 2015. december 25-i dátummal a Wayback Machine-ben.
  4. ↑ Martin Fowler's Service Layer
  5. ↑ Martin Fowler explains that Service Layer is the same as Application Layer
  6. ↑ Comparison/discussion of the GRASP Controller Layer vs. Application/Service Layer. [2012. július 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. szeptember 1.)
  7. ↑ a b Applying UML and Patterns, 3rd edition, page 203 ISBN 0-13-148906-2

Források[szerkesztés]

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Multitier architecture című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Többrétegű_architektúra&oldid=26887228”