Laza kötés
A számítástechnika és a rendszertervezés során egy lazán összekapcsolt rendszer az, amelyben minden egyes alkotóelem alig vagy egyáltalán nem ismeri a különálló részek definícióit. Az alterületek magukban foglalják az osztályok, interfészek, adatok és szolgáltatások összekapcsolását.[1] A laza kötés ellentéte a szoros kötésnek.
Előnyök és hátrányok
[szerkesztés]A lazán összekapcsolt rendszer alkotórészei alternatív megvalósításokkal helyettesíthetők, amelyek ugyanazt a funkciót nyújtják. A lazán összekapcsolt rendszer összetevői kevésbé vannak ugyanarra a platformra, nyelvre, operációs rendszerre vagy futtatási környezetre korlátozva.
Ha a rendszereket időben leválasztják, nehéz a tranzakció integritását biztosítani, tehát további koordinációs protokollokra lesz szükségünk. A különböző rendszerek közötti adatreplikáció laza összekapcsolást biztosít (elérhetőség esetén), de problémákat vet fel az egységesség fenntartásában.
Az integrációban
[szerkesztés]A laza kötést az elosztott rendszertervezésben a tranzakciók, az üzenetorientált köztes rétegek által biztosított sorok és az interoperabilitási szabványok segítségével érik el.[2]
A függetlenség négy típusa, amelyek elősegítik a laza összekapcsolódást, a következők: referenciaautonómia, időautonómia, formátumautonómia és platformautonómia.[3]
A laza kötés kialakítási és tervezési elv a szolgáltatásorientált architektúrákban. Tizenegy formája és azok szoros összekapcsolódású megfelelői vannak felsorolva alább:[4]
- fizikai kapcsolatok közvetítőn keresztül,
- aszinkron kommunikációs stílus,
- egyszerű általános típusok csak az adatmodellben ,
- gyenge típusú rendszer,
- adatközpontú és önálló üzenetek,
- a folyamatlogika elosztott vezérlése,
- dinamikus kötés (a szolgáltatást igénybe vevők és szolgáltatók számára),
- platformfüggetlenség,
- üzleti szintű kompenzáció, rendszerszintű tranzakciók helyett,
- alkalmazás különböző időpontokban,
- implicit frissítések a verziókban.
Az Enterprise Service Bus (ESB) köztes szoftvert azért találták ki, hogy több dimenzióban elérjék a laza kötést;[5] a túlbonyolított és rosszul elhelyezett ESB-k azonban ellenkező hatást is eredményezhetnek, és nemkívánatos szoros összekapcsolást, valamint architektúra-központi hotspotot hozhatnak létre.
Az eseményvezérelt architektúra is céljának tekinti a laza összekapcsolódás elősegítését.[6]
Módszerek a lazább kötés kialakítására
[szerkesztés]Az interfészek összekapcsoltságának lazasága javítható az adatok szabványos formátumban (például XML vagy JSON) történő közzétételével.
A programkomponensek közötti laza kötés javítható szabványos adattípusok alkalmazásával a paraméterekben. A sajátos adattípusok vagy objektumok átadásához mindkét összetevőnek ismernie kell az egyedi adatok felépítését.
A szolgáltatások laza összekapcsolása javítható azáltal, hogy a szolgáltatásnak továbbított információt csak a kulcsadatokra redukáljuk. Például egy levélküldő szolgáltatás akkor használható fel leginkább, ha csak az ügyfél-azonosító kerül átadásra, és az ügyfél címét a szolgáltatáson belül kezelik. Ez elvonatkoztatja a szolgáltatásokat, mert a szolgáltatásokat nem kell meghatározott sorrendben hívni (pl GetCustomerAddress, SendLetter).
Alkalmazása a programozásban
[szerkesztés]A kötés a közvetlen tudás mértékére utal, amelyet az egyik komponens birtokol egy másikról. A laza kötés a számítástechnikában az egységbe zárás vs. nem egységbe zárás kérdéseként van jelen.
A szoros kötés példája akkor fordul elő, amikor egy függő osztály mutatót tartalmaz egy konkrét osztályhoz, amely implementálja a szükséges viselkedést. A függőség nem helyettesíthető, vagy "aláírása" nem változtatható meg, a függő osztály megváltoztatása nélkül. A laza kötés akkor következik be, amikor a függő osztály csak egy interfészre mutat, amelyet aztán egy vagy több konkrét osztály megvalósíthat. A függő osztály függése az interfész által meghatározott "szerződésben" található, azon metódusok és / vagy mezők listája, amelyeket az osztályok implementációjának biztosítania kell. Bármely, az interfészt megvalósító osztály kielégítheti egy függő osztály függőségét az osztály módosításának kényszere nélkül. Ez lehetővé teszi a szoftver bővíthetőségét; egy interfészt megvalósító új osztály írható az aktuális függőség helyettesítésére néhány vagy minden helyzetben, anélkül, hogy változtatni kellene a függő osztályon; az új és a régi osztályok szabadon felcserélhetőek. A szoros kötés ezt nem teszi lehetővé.
Ez egy UML- diagram, amely a függő osztály és a konkrét osztályok közötti laza kötést szemlélteti, amelyek biztosítják a szükséges viselkedést:
Összehasonlításképpen, ez a diagram az előző alternatív kialakítását szemlélteti, erős kötéssel a függő osztály és implementálója között:
Egyéb formái
[szerkesztés]A laza kötéssel való programozásra kiváló példákat kínálnak azok a számítógépes programozási nyelvek, amelyekben megtalálhatók az alapvető modulok (lásd: Funkcionális programozás) vagy a függvények, mint objektumok. A funkcionális nyelveknek vannak erre irányuló speciális megoldásai. Lásd a Clojure és a Lisp funkcionális programozási nyelvek esetén. Az olyan objektumorientált nyelvek, mint a Smalltalk és a Ruby, kódblokkokkal rendelkeznek, míg az Eiffel ügynökökkel rendelkeznek. Az alapötlet az, hogy objektumként zárjon egységbe egy olyan függvényt, amely független minden más objektumtól (pl. Egy objektumfüggvény leválasztása az egységbe záró objektum közvetlen ismeretéről). Lásd: Első osztályú függvény, amely további információkat nyújt az objektum-függvényekről, amelyek az első osztályú függvények egyik formájának minősülnek.
Tehát például egy objektumorientált nyelvben, amikor egy objektum függvényére objektumként hivatkozunk (megszabadítva a körülvevő objektum ismeretétől), akkor az új függvényobjektum átadható, tárolható és meghívható később. A meghívó objektumok (akiknek ezeket a funkcionális objektumokat megadják) biztonságosan végrehajthatják (meghívhatják) a benne foglalt funkciót a saját feladatukra, anélkül, hogy közvetlen tudomásuk lenne a befogadó objektumról. Ily módon a program képes végrehajtani a funkcionális objektumok sorozatát vagy csoportjait, miközben biztonságosan leválasztva arról, hogy bármilyen közvetlen hivatkozás legyen a gazdaobjektumra.
A telefonszámok kiváló példák, és könnyen szemléltethetik a leválasztás mértékét.
Például: Egyes entitások átadnak egy másiknak egy telefonszámot, hogy azt felhívja a feladat egy részek elvégzése érdekében. A szám hívása folyamán, a hívó entitás gyakorlatilag azt mondja: "Kérem, végezze el ezt a munkát helyettem." A leválasztás vagy a laza kötés azonnal nyilvánvaló. Előfordulhat, hogy a hívni kívánt számot fogadó entitásnak nincs tudomása arról, honnan származik a szám (pl. Hivatkozás a szám forrására). A másik oldalon a hívó fél nem ismeri pontosan a hívás továbbításának útját és a hívástovábbítók belső működését.
A példát egy lépéssel tovább véve a hívó azt mondhatja a hívás címzettjének: "Kérem, végezze el ezt a munkát helyettem. Amikor végzett, hívjon vissza ezen a számon. " A vevőnek felajánlott „számot” „visszahívásnak” nevezzük. Ismét nyilvánvaló ennek a funkcionális objektumnak a laza összekötöttsége vagy leválasztása. A visszahívás vevője nincs tudatában annak, hogy mit vagy kit hívnak. Csak azt tudja, hogy képes hívni, és maga dönti el, hogy mikor tegye azt. A valóságban előfordulhat, hogy a visszahívás nem is annak szól, aki eleve a visszahívást biztosította. Ez az indirekciós szint teszi a funkció-objektumokat kiváló technológiává a lazán kötött programok megvalósításához.
Adatelem-kötöttség mérése
[szerkesztés]A laza kötés mértékét úgy lehet mérni, hogy feljegyezzük az adatelemekben bekövetkező változások számát, amelyek a küldő vagy a fogadó rendszerben előfordulhatnak, és az alapján eldöntjük, hogy a számítógépek továbbra is megfelelően kommunikálnának-e. Ezek a változások olyan elemeket tartalmaznak, mint:
- Új adatelemek hozzáadása az üzenetekhez
- Az adatelemek sorrendjének módosítása
- Az adatelemek nevének megváltoztatása
- Az adatelemek struktúrájának megváltoztatása
- Az adatelemek kihagyása
Jegyzetek
[szerkesztés]- ↑ Loosely Coupled: The Missing Pieces of Web Services by Doug Kaye
- ↑ Pautasso C., Wilde E., Why is the Web Loosely Coupled? Archiválva 2021. október 12-i dátummal a Wayback Machine-ben, Proc. of WWW 2009
- ↑ F. Leymann Loose Coupling and Architectural Implications Archiválva 2016. október 2-i dátummal a Wayback Machine-ben., ESOCC 2016 keynote
- ↑ N. Josuttis, SOA in Practice. O'Reilly, 2007, ISBN 978-0-596-52955-0.
- ↑ M. Keen et al, Patterns: Implementing an SOA using an Enterprise Service Bus, IBM, 2004
- ↑ How EDA extends SOA and why it is important Jack van Hoof
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Loose coupling című angol Wikipédia-szócikk ezen változatának 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.