Elosztott rendszerek NGM_IN005_1 World Wide Web mint elosztott rendszer World Wide Web Globális, elosztott hipertext rendszer Dokumentum alapú elosztott rendszer Web: URI + HTTP + HTML ( + XML) eredetileg az egyszer!ség fontos tervezési szempont interakció: állapotmentes átviteli protokoll konzisztens er"forrás azonosítás szabványosított dokumentum reprezentáció szabványosított médium típusok 2
Elvek, korlátozások Azonosítás globális azonosítás -> globális rendszer linkek, bookmarkok, cache, indexelés különböz" er"forrásokhoz különböz" URI-k URI által hordozott információ (átlátszóság) URI-k tulajdonlása URI sémák 3 Elvek, korlátozások (folyt.) Interakció dereferencing an URI: er"forrás (doku reprezentáció) elérése a megfelel" módszerekkel (interakció protokoll) alkalmazás kontextus névterek séma protokoll el"írások Content-Type 4
Elvek, korlátozások (folyt.) Reprezentáció típusok (Internet Media Type) protokollok - szállítási reprezentáció verzió kezelés? fragment identifiers reprezentáció függ" szemantika content negotiation (http-ben van) hibakezelés meta adatok (Content-Type, encoding) 5 Elvek, korlátozások (folyt.) Biztonságos interakció er"forrás állapotát nem változtatja meg hipertext linkkövetés - feltételezhet"en biztonságos URI perzisztencia, bookmarking nem biztonságos eset - tranzakció eredménye "Content-Location" header 6
Elvek, korlátozások (folyt.) Reprezentáció menedzsment er"forrást azonosító URI-hoz autoritatív reprezentáció biztosítása megbízható és prediktív referencia nem mindig jár dereferenciálással URI perzisztencia biztosítása HTTP redirection hozzáférés korlátozás 7 Elvek, korlátozások (folyt.) Dokumentum (adat) reprezentáció text és bináris formátumok teljesítmény vs. portabilitás verziókezelés, kib"víthet"ség kiterjesztés eredeti specifikációval konform módon kompozit formátumok 8
Elvek, korlátozások (folyt.) Tartalom, megjelenítés, és interakció szeparálása heterogén ágens környezet újra felhasználhatóság, platform függetlenség rekombinálás helye (kliens...szerver) Webes reprezentációkban hipertext linkelés biztosítása 9 Elvek, korlátozások (folyt.) Általános architektúrális elvek ortogonális specifikációk azonosítás, interakció, reprezentáció egymástól független koncepciók kiterjeszthet"ség és interoperabilitás biztosítása hibajavítás és felépülés 10
Egyszer!ség Komponensek szoros (szigorú) vagy laza csatolása független fejlesztések, potenciálisan kevesebb hiba Takarékosság vs. optimalizálás egyirányú linkek nyílt rendszerek: hibák és innováció Programozási nyelvek és keretrendszerek egyszer! script nyelvek bonyolult keretrendszerek nem igazán innovatív (nem új technológiák) 11 Alkalmazott technológiák Web architektúra plusz kényszereket jelent az alkalmazásfejlesztéskor Hipermédia jelleg figyelmen kívül hagyása Alkalmazások átvitele vagy integrálása alkalmazkodás a web architektúrához sokszor nincs igazi integráció http protokoll használata kommunikációra 12
Megfelel" hozzáállás Nyíltság és kiterjeszthet"ség meg"rzése Webes szabványok legszélesebb kör! betartása Evolúciós szoftver folyamat Tartalom láthatóságának, elérhet"ségének, használhatóságának és újra hasznosíthatóságának biztosítása 13 Nem megfelel" tervezés Alapelvek megsértése architektúrális problémák Kényszerek megsértése technikai problémák Good practices megsértése használhatósági problémák 14
Állapot kezelés HTTP-ben nincs session koncepció kérés/válasz párok HTTP 1.1 perzisztens kapcsolat csak optimalizálás kliensek azonosítása szerveroldalon nem lehetséges Session és er"forrás állapot er"forrás állapot ne függjön a kliens állapotától alkalmazás állapot függhet a kliens állapotától A Web laza csatolását biztosítja a HTTP állapotmentessége 15 Kliens oldali állapot kezelés Session nyílvántartása a kliens oldalon minden releváns infoval rendelkezik er"források perzisztenciája meg"rzend" Szerver oldalon csak rövid idej! állapot kezelés Közös állapot biztosítása állapot infok küldése az interakcióban szerver oldali állapot tárolás, kliens hivatkozik állapot függ" URI-k 16
Állapot kezelési módszerek Állapot HTML-ben vagy HTTP autentikációval State in HTTP Client Application Resources Server 17 Állapot kezelési módszerek (folyt.) Állapot az alkalmazásban, sessionhöz kötve Session identified state Client Application Resources Server 18
Állapot kezelési módszerek (folyt.) Állapottárolás er"forrásként Client Application Resources Application state Server State 19 Session követés Cookie használat válaszban SetCookie, er"forrásra vonatkozó kérésben Cookie Cookie állapotra vonatkozó információ kliens nem értelmezi Felhasználás alkalmazás állapot - OK er"forrás állapot - problémás 20
3rd party cookie Tartalom és hírdetés ellátók oldalba ágyazott hírdetések, küls" forrásból ad tracking fogyasztói profilok különböz" tartalom ellátókon keresztül is (azonos hírdetés ellátó) 21 Session követés (folyt.) URI átírás cookie-k tiltása állapot info URI részeként (question part) hosszú URI-k bookmarkolás? servletek automatizált session kezelése átkapcsol cookieról 22
Session követés (folyt.) Rejtett!rlap mez"k form alapú interakció input elemek beállított értékekkel oldal (form) újra generálandó minden kéréshez 23 REpresentional State Transfer Elosztott rendszer architektúrális megoldás A Web egy példa erre a típusú rendszerre Más technológiákkal is lehet REST rendszert kialakítani Er"forrás orientált állapot és funkcionalitás kezelés Nyílt, skálázható, könnyen érthet" rendszerek 24
REST definíció Er"forrásokat URI-k azonosítják Er"források kezelése a reprezentációjukkal történik Az üzenetek önhordók és állapotmentesek Egy er"forráshoz több reprezentáció is tartozhat Az alkalmazás állapotát az er"forrás manipuláció határozza meg 25 Er"források Er"forrás reprezentációk csak URI-kon keresztül manipulálhatók weben f"leg dokumentumok (strukturált info) Er"források különböz" kontextusokban használhatók különböz" alkalmazások akár közös reprezentációkkal 26
Állapot Állapot leírások a szállított tartalommal együtt átvitelre kerülnek kliens eltárolhatja az állapot infot Adatátvitel nem állapot specifkus (nincs kapcsolat menedzsment) 27 Közös modell Elosztott rendszerek komponenseinek együttm!ködéséhez közös modell kell hagyományosan közös jól definiált API REST esetén egyszer!sített megegyezés f"nevek: er"forrás megnevezés igék: alkalmazható m!veletek tartalom típusok: használható info reprezentációk (formátumok) 28
F"nevek Er"forrás URI-k URI tervezési kérdések Minden érdekes dolgot meg kell nevezni M!veletek és reprezentációk elválasztása új m!veletek és tartalom típusok vezethet"k be 29 Igék Er"forrásokra alkalmazható m!veletek REST: univerzális m!veletek minden f"névvel használható igék HTTP alap m!veletek GET PUT POST DELETE Adatbázis kontextus: CRUD (create, read, update, delete) 30
POST Finomabb update lehet"ség, mint egyszer! felülírással Hatások állapot változtatás vagy új er"forrás létrehozása (http 200 vagy 201 válasz) új er"forrás létrehozása, ha a hozzáadott információt egyedileg kell elérni Navigálhatóság, kapcsolatok a reprezentációban 31 Tartalom Géppel feldolgozható reprezentációk de m!ködik nem átlátszó reprezentációkkal is Kliensek igényeiknek megfelel"en adott er"forrást különböz" reprezentációk formájában érhetik el dinamikus tartalom egyeztetés HTTP: Accept, Accept-Charset, Accept-Encoding, Accept- Language 32
REST vs. webszolgáltatás REST tervezési elv, rendszer nézet fókusz az er"forrásokon Web Services HTTPszállítást használó szolgáltatások normál web funkcionalitáson túli specifikációk fókusz az üzeneteken (m!veletek) 33 REST technológiák REST megoldás nem technológiákhoz kötött Weben f"nevek: URI-k igék: HTTP metódusok Tartalom típus: HTML (emberi fogyasztás), XML (gépi feldolgozás) HTTP REST: alkalmazás réteg protokoll Web Services: szállítási protokoll (t!zfalak átjárása) 34
Web Services Szállítási middleware Gép-gép interakció XML üzenetek (SOAP) Címzési modell Alkalmazáson belüli er"források azonosítása nem URIkkal történik pl. SOAP végpontok alkalmazások, funkciók 35 SOAP Simple Object Access Protokoll XML-RPC Web Services protokoll stack Szállítási protokollok HTTP SMTP Üzenet protokoll SOAP Szolgáltatás leírás WSDL Szolgáltatás felderítés UDDI 36
SOA Service Oriented Architecture rendszer fejlesztési, integrálási megközelítés (architektúrális stílus) lazán csatolt, autonóm szolgáltatások mint komponensek nem technológiák gy!jteménye, nem csak Web After looking at these misconceptions let s now re-examine the SOA definition I provided above. I said Service Oriented Architecture is an architectural style. Being an architectural style means that SOA defines components, Servicekkel relations and valósítható constraints about meg the component s usage and interactions (see the definition of software architecture & architecture style below for more details on their meaning in this book). 6 Definition: Architecture & Architecture Style. There are many definitions for software architecture 1. The definition used in this book is: 37 Software architecture is the collection of fundamental decisions about a software product/solution designed to meet the project's quality attributes, or architectural requirements. The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction, where the number of levels depends on the project's size. In order for a system s architecture to be intentional, rather than accidental, it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders. As for architectural styles - Simply put, an architectural style to architecture is what a design SOA (folyt.) pattern is for design. The Software Engineering Institute defines an architectural style as "A specialization of element and relation types, together with a set of constraints on how they can be used." SOA komponensek Following the definition above - the SOA style defines the following components: Service, End Point, Message, Contract, Polity & Service Consumer. SOA also defines certain interactions that the components can have. Figure 1.1 lists SOA s components and their relations:! "#$%&'!()(!*+,!-./0.1'123!415!26'#&!&'742#.13)!,04&2!8&./!26'!.9:#.%3!-./0.1'12;!26'!*'&:#-')!*+,!643!3':'&47!.26'&! -./0.1'123;!-.12&4-2!2642!26'!3'&:#-'!#/07'/'123<!=15!0.#123<!>6'&'!26'!3'&:#-'!-41!9'!-.124-2'5<!/'334$'3!2642!4&'! /.:'5!94-?!415!8.&26!9'2>''1!26'!3'&:#-'!415!#23!-.13%/'&3@!0.7#-#'3!2642!26'!3'&:#-'!456'&'!2.!415!-.13%/'&3!2642! #12'&4-2!>#26!26'!3'&:#-'!! 38 1 If you feel you need a to software architecture you can read appendix C: introduction to software architecture. (sentence is incomplete)