OotElosztottRendszerek2011 forrásának megtekintése

<div style="background:oldlace;padding:10px;border:1px solid lightgrey;">
'''Ez az oldal a tárgy 2011 anyagának összefoglalója. A korábbi évek anyagai lettek áthozva és kiegészítve. Az 2011 előtti változata [http://wiki.test.sch.bme.hu/OotElosztottRendszerek itt] érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.'''
</div>

__TOC__
==4.1. Általános==
* Socket vs keretrendszer (lábbalhajtós vs kézzeltekerős)
* Szerializálni kell
==4.2. Távoli eljáráshívás==
===Függvényhívás===
%ATTACHURL%/rmi.png
===Csonk===
* sorosítva elküldi a paramétereket
* meghívja a távoli függvényt
* visszaveszi a visszatérési értéket

<pre>
int foo(int x, int y, int z) {
	 Stub stub = getStub("foo");
	 Stream s = stub.getOutStream();
	 s.writeInt(x);
	 s.writeInt(y);
	 s.writeInt(z);
	 stub.invoke();
	 s = stub.getInStream();
	 int t = s.readInt();
	 return t;
}
</pre>
===Adapter===
* beolvassa a paramétereket
* meghívja az implementációt
* visszaküldi a visszatérési értéket
<pre>
void invoke(Skeleton skeleton) {
	 Stream s = skeleton.getInStream();
	 int x = s.readInt();
	 int y = s.readInt();
	 int z = s.readInt();
	 int t2 = foo(x,y,z);
	 s = skeleton.getOutStream();
	 s.writeInt(t2);
}
</pre>
===Problémakezelés===
* memóriakezelés
** primitív típusok átmennek
** összetett típusoknál deep copy
** elosztott GC
* hálózati hibák
** idempotens műveletnél nincs gond
** at_most_once, at_least_once, exactly_once
* szerver megtalálása
** bedrótozva
** NameService (hierarchikus, név szerinti keresés)
** TradeService (szolgáltatás szerint kereshető)
==4.3. Remote Method Invocation==
====Szerializálás====

(l. [[OotPerzisztencia|perzisztencia témakör]])

===4.3.1. Biztonság===
====SecurityManager osztály====
* Biztonsági szabályok kezelésére
** SecurityManager System.getSecurityManager()
** System.setSecurityManager(SecurityManager sm)
** SecurityException-t dob hiba esetén
* void check...() típusú függvényekkel lehet ellenőrizni
** file hozzáférés: Read, Write, Delete
** kapcsolat hozzáférés: Connect, Accept, Listen
** általános: Exit, Exec, Permission
* Külső policy fájlból is meg lehet adni a hozzáféréseket
====Távoli interfész====
* java.rmi.Remote leszármazott
* java.rmi.RemoteException dob
* paraméter: Serializable interfészt megvalósító objektum
===4.3.2. Szerver oldal===
%ATTACHURL%/rmi-szerver.png
====RemoteObject====
* távoli objektumok és stub-ok ősosztálya
* boolean equals(Object o) - stubok között is jó
* RemoteRef getRef()
* int hashCode()
* String toString()
* static Remote toStub(Remote obj) - távoli objektum stub-ját adja vissza
====RemoteServer====
* távoli objektum létrehozása és exportálása
* static String getClientHost()
* static void setLog(OutputStream os)
* static PrintStream getLog()
====UnicastRemoteObject====
* távoli objektum exportálása, stub elérése
* Object clone()
* static RemoteStub exportObject(Remote r)
* static Remote exportObject(Remote r, int port [RMIClientSocketFactory csf, [[RMIServerSocketFactory]] ssf])
* static boolean unexportObject(Remote r, boolean force)
* protected UnicastRemoteObject(int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf)
====Remote objektum megvalósítás====
* delegációval
** az implementáció nem származik le az UnicastRemoteObject-ből
** meghíváskor kell a stub-ot exportálni:
<pre>
	 HelloImpl hello_impl = new HelloImpl();
	 Hello stub = (Hello)UnicastRemoteObject.exportObject(hello_impl, 0);
	 Registry registry = LocateRegistry.getRegistry();
	 registry.rebind("hello", stub);
</pre>

* örökléssel
** az implementáció leszármazik az UnicastRemoteObject-ből
** ekkor automatikus az exportálás, konstruktorban megtörténik:
<pre>
	 HelloImpl hello_impl = new HelloImpl();
	 Registry registry = LocateRegistry.getRegistry();
	 registry.rebind("hello", hello_impl);
</pre>

===4.3.3. Kliens oldal===

%ATTACHURL%/rmi-kliens.png

* Stub hivatkozik a távoli objektumra, implementálja annak interfészét
* Stub megkapható: RMI paraméterként, RMI visszatérési értékként vagy NameService segítségével
<pre>
try {
	Registry registry = LocateRegistry.getRegistry();
	MyInterface intf = (MyInterface)registry.lookup("MyInterface");
	intf.myMethod("Arg1");
} catch (Exception e) {e.printStackTrace();}
</pre>

====RMIRegistry====
* név-stub párokat tárol
* void bind(String name, Remote obj) - beregisztrál
* String[] list() - kilistáz
* Remote lookup(String name) - kikeres
* void rebind(String name, Remote obj) - beregisztrál/felülír
* void unbind(String name) - kiszed
====LocateRegistry ====
* megkeresi/létrehozza a Registry-t
* static Registry createRegistry(int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf)
* static Registry getRegistry(String host, int port, RMIClientSocketFactory csf)

===4.3.4. Elosztott GC===
* referenciákat számol
* kilens oldalon is van komponense (DGCClient)
* amikor a kiens deszerializál egy távoli objektumra mutató referenciát, akkor a [[DGCClient]] egy dirty() hívással jelez
	  a szerver GC-je felé, hogy az objektumra a kliensenk szüksége van
* erre válaszul a szerver megmondja, hogy mennyi időre tudja garantálni az objektum megtartását a memóriájában
* a [[DGCClient]] feladata, hogy meghosszabbítsa ezt az idő a lejárta előtt egy újabb dirty hívással, ha a kliensnek továbbra is szüksége van az objektumra
* ha a [[SGCClient]] úgy veszi észre, hogy nincs szüksége a kliensnek tovább a távoli objektumra, akkor ezt a tényt egy clean () hívással jelzi a szerver 
	  GC-je felé
* a szerver eközben számolja, hogy hány távoli referencia van a távoli objektumokra, és ha ez 0-ra csökken, akkor weak referenciával hivatkozik rá
** Egy kliens első dirty hívására inkrementálja a számlálót
** A bérleti idő lejárta után, vagy clean() hívás hatására dekrementálja
* ekkor a GC már eltakaríthatja a távoli objektumot (ha nincs rá lokális ref.)
* sajnos lehet, hogy a kliens hálózati hiba miatt nem tudta megújítani a referenciáját, és ekkor a következő kérése nem fogja megtalálni az objektumot (NULL)
	  emiatt is szükség van arra, hogy a távoli objektum metódusai RemoteExceptiont dobjanak
	FORRÁS: http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/diag/understanding/rmi_dgc.html

	-- [[MisnyovszkiAndrasSSO]] - 2009.05.27.
	
===4.3.5 RMI során átadható paraméterek osztályozása és a paraméterátadás módja===
* Pass-by-Reference
** a metódus a paraméterre mutató referenciát kap
** a metódus a referencián keresztül éri el a paramétert, amit a hívó tart
** azok adhatóak át így, akik implementálják a Remote interfészt
* Pass-by-Value (Copy)
** a paraméter lemásolódik
** a metódus a másolatot kapja meg, és azon dolgozik
** mindenki más így adódik át

	[http://www.eli.sdsu.edu/courses/spring98/cs696/notes/rmiParameters/rmiParameters.html forrás]
-- [[KovacsAdam|Csádám]] - 2010.05.31.

==4.4. Tervezési minták==

(l. [[OotTervezesiMintak|tervezési minták]] oldal)

===Mobile agent===
* Adat és kód egybezárva utazik rendszereken keresztül. Lényegében egy olyan programrész, amelyet az Agency-k futtatni tudnak, és tovább tudják adni.
* A kliens által küldött objektum futtatható kódja nincs meg a szerveren.
* Lehet például arra használni, hogy elküldeni egy adatbázisnak, ott leszelektálja az eredményt, majd azzal visszajön, így ha valamit nem tudunk SQL-be megírni, akkor is csak minimális lesz a hálózati forgalom.

<pre>
public interface Agent extends Serializable {
	 void run();
}
</pre>
<pre>
public interface Agency extends Remote {
	 public Agent accept(Agent a) throws RemoteException;
}
</pre>

====Mitöl ügynök az ügynök?====
* Aktív és autonóm
** saját szálon fut
** a döntéseit maga hozza
** a környezet figyelembevételével
* Kapcsolatképes (reaktív)
** más ügynökökkel kommunikálhat
* Tanulékony
** a tapasztalatait összegzi
* Mobil
** képes az ügynökségek közötti közlekedésre

====Hogyan érkezik az ügynök?====
* Hogyan inicializáltjuk?
** void init() metódus
** elég-e a run() metódus ehhez?
* Hogyan regisztrál
** ügynökség automatikusan regisztrálja
** neki kell regszitrálni
* Hogyan állítja be a jogosultságokat?
** mit tehet az ügynök
** mit tehetnek vele mások


==4.5. CORBA (OMG szabvány)==
* platformfüggetlen megoldás RPC-re
* képes teljesen különböző programnyelvek között is adatátvitelre/függvényhívásra
===Interface Description Language (IDL)===
* általános interfészleíró nyelv, amiből az egyes programnyelvekre fordítunk
* primitív típusok: char, octet, boolean, short, long, double
* összetett típusok: enum, string, struct, union, sequence, array, valuetype, exception, \x{2026}
* paraméterátadás: in, out, inout
* interfészek IDL-ben, implementáció natív nyelven
===IDL -&gt; Java===
* xxxHelper: marshallinghoz (szerializáláshoz)
* xxxHolder: inout és out paraméterek kezelésére
* xxxPOA (Portable Object Adapter): Servant-ból származtatva
* kliens: natív típusokkal dolgozhatunk
===Szabványos szolgáltatások===
* beépített, szabványos megoldások gyakori problémákra
* NamingService, TradingService
* EventService, NotificationService
* Collection, Concurrency, Time, Transaction
===Naming Service===
* white pages
* név-elem párokat (név - referencia) kapcsol össze
===Trading Service===
* yellow pages
* szolgáltatás - referencia lista
* ServiceType - szolgáltatás típusa
** név, interfész, attribútumok (properties)
* Offer - ajánlat
** konkrét referencia
** konkrét attribútum-értékek
* ServiceType <-> SQL ábra
** kötelezö elem a CORBA interfész
* Offer <-> SQL tábla egy sora
** körelezö elem a referencia
* Keresés <-> SQL query
** megadható, hogy egy szolgáltatástípusban milyen konkrét attribútumértékű ajánlatokat keresünk
** pl: <pre> select REFERENCE, ATTRIBUTE* from SERVICE_TYPE where EXPRSSION </pre>
* Trader Use-casei
** ajánlatok kezelésé: insert, update, delete, select
** Trader attribútumok állítása: számosságok, kéréstovábbítás
* Különbözö helyen futó traderek összekapcsolhatóak linkkel vagy federatrion-nel, mely arra jó hogy az egyikben kezdeményezett keresés a többibe továbbadódhat. Ez a kapcsolat egyirányú. Beállításai:
** local_only: csak az aktuális traderben keresünk
** if_no_local: ha az aktuálisban nincs, mehet tovább
** always: minden elérhetö traderben keresünk
===Event Service===
* Alap CORBA kommunikáció = erös csatolás és egy-egy kommunikáció
* Event Service= nagyobb szétcsatolás, esemény-alapú kommunikáció, több-több kommunikáció.
* Szerepek: termelő (termeli az eseményeket) és fogyasztó (feldolgozza az eseményeket)
** Push kommunikációs modell: termelö kezdeményez (meghívja a termelö push metódusás), fogyasztó passzív
** Pull kommunikációs modell: termelö passzív, fogyasztó kezdeményez (meghívja a termelö pull metódusát)
* Csatorna: push-pull ment az egy-egy alapú CORBA kommunikációnál is, de a szétcsatoláshoz kell egy csatorna
** többen csatlakozhatnak rá, nincs közvetlen kapcsolat termelö és fogyasztó között, nincs szükség másik oldali szereplőre, plusz szolgáltatásokat nyújthat
** a csatlakozáshoz proxy kell, mely interfészt nyújt a termelö felé fogyasztóként és a fogyasztó felé termelőként, illetve tárolja a felgyűlt üzeneteket
** a kommunikációs modellek keverhetőek
* Proxy: a supplier proxy-k saját FIFO pufferrel rendelkezdnek
** push consumer proxy: a push hatására a csatornához továbbítja az eseményt
** push supplier proxy: a következő eseményt push hívással adja át a fogyasztónak
** pull supplier proxy: a pull hatására vagy ad egy új eseményt vagy pufferből, vagy blokkol
** pull comsumer proxy: pull hívással kér új eseményt a termelötöl
===Notification Service===
* Plusz szolgáltatások: csatorna factory, események szürése, QoS, NotifyPublish/Subscribe


-- [[MeszegetoBalazsIstvan|MeszegetoBalazsIstvan]] - 2008.05.27.

-- [[PallosTamas|Velias]] - 2009.05.26.

--[[Szerkesztő:Ferrero|Szabó Csaba]] ([[Szerkesztővita:Ferrero|vita]]) 2012. december 14., 18:09 (CET)

[[Category:Infoszak]]