Elosztott rendszerek

A VIK Wikiből
A lap korábbi változatát látod, amilyen Symunona (vitalap | szerkesztései) 2013. május 27., 17:29-kor történt szerkesztése után volt.
Elosztott Rendszerek
Tárgykód
VIAUM124
Általános infók
Szak
InfoMsc - AlkInfo
Kredit
4
Ajánlott félév
tavasz
Keresztfélév
nincs, és nem is kell
Tanszék
AUT
Követelmények
Jelenlét
nincs
Minimális munka
ZH+Vizsga
Labor
ősszel
KisZH
0
NagyZH
1
Házi feladat
0
Vizsga
Van
Elérhetőségek
Levlista

Kérdések, amik (szinte) mindig szerepelnek a ZH-ban

  • elosztott rendszerek előnyei a központosított rendszer előnyeivel
  • GIOP protokoll (General Inter ORB Protocol) üzenet típusai, üzenet tartalma
  • COM objektum típusok

2006.04.24. minta zh

  1. Kifejteni miért fontos az elosztott rendszer (centralizált/elosztott rendszer összehasonlítása).
    • centralizált rendszer előnyei
      • könnyen adminisztrálható
      • nagy megbízhatóság redundáns hardverrel biztosítható
      • szakértőket biztosít a szállító
    • elosztott rendszer előnyei
      • rugalmas
      • horizontálisan is skálázható
      • nagy teljesítményű
      • dinamikus feladatelosztással megbízhatóvá tehető
      • jó ár/teljesítmény
      • a rendszer bizonságkritikus részei jól szeparálhatók
  1. Komponens alapú fejlesztés előnyei és hátrányai.
    • komponensek külön fejleszthetők
    • interfész és implementáció külön van választva
    • interfész is bővíthető (örökléssel vagy aggregációval)
    • elég csak a bináris kódot kiadni a megrendelőnek
    • konténer biztosítja a middleware-t szabványos felületen keresztül
    • deklaratív leíró file, adminsztrációs felület biztosított hozzá
    • komponens technológiák egymás között nem átjárhatók
  1. Milyen típusú servereket ismer a COM-ban?
    • in-process: komponens a kliens processzében fut. Gyors, de csak szinkron hívás van és egy hibás komponens magával ránthatja a klienst is. Pl. VB
    • in-process handler: felüldefiniálható a standard marshalling. Pl. .NET Application Domains
    • local server (out-process): a szerver (tipikusan .dll) külön processzben fut, ha elszáll, a kliens csak timeoutot kap. Stabil, de lassabb, mint az in-process
    • remote server: a szerver távoli gépen is futhat, a hozzáférés transzparens. Ez jelenti a legnagyobb overheadet. Pl. DCOM
  1. Middleware szolgáltatások (10 db), ezek közül néhányat kifejteni.
    • névfeloldás, security, tranzakciókezelés, object pooling, perzisztencia, load balancing, életciklus management, szálkezelés, event/notify, messaging
  1. GIOP protokoll.
    • GIOP Fejléc: magic string, verzió, byte sorrend, üzenet típus (1-7), üzenet méret
    1. RequestMessage (K->S) — kérés: GIOP header, Message header (objektum azonosító, metódus, szolgáltatások, aszinkron kérés azonosító), Body (metódus paraméterek)
    2. ReplyMessage (S->K) — válasz a kérésre: GIOP header, Reply header (válasz azonosító (mire válasz?), státusz kód), Body (visszatérési érték, hibainfó)
    3. CancelRequest (K->S) — aszinkron kérés megszakítása: GIOP header, kérés ID
    4. LocateRequest (K->S) — objektum megpingelése: GIOP header, objektum ID
    5. LocateReply (S->K) — ping válasz
    6. CloseConnection (S->K) — kapcsolat befejezése
    7. MessageError (K<->S) — hiba
  1. .NET framework fő részei (esetleg volt szó .NET remotingról, de erre pontosan nem emlékszem).
      Subsystems:
      Web services WinForms ADO.NET XML ...
      Base Class Library: ~5000 osztály
      CLR:
      Garbage collector Type checker Debugging Threading Code checker
      InterOp COM Remoting JIT compiler  
      ClassLoader
      Bővebb infó angolul itt
  2. Web service, milyen célra használható?
    • integráció különböző platformok között
    • külső cég által fejlesztett komponensek felhasználása
    • üzleti folyamatok tervezése
    • fejlesztési paradigma
  1. J2EE architektúra ábrával
    [1]
    Forrás: http://uml2006.infojarda.hu/EJB_1.pdf

Feladatok: -- Ekler Péter - 2006.04.25.
Megoldások: -- Peti - 2006.04.25.