Elosztott rendszerek

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata 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.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

<style> ol ol li { line-height: 15px; margin-bottom: 2px; } </style>

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. 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
2. .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
3. 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
   Fájl:Http://kepfeltoltes.hu/130322/j2ee appserver www.kepfeltoltes.hu .png
   Forrás: http://uml2006.infojarda.hu/EJB_1.pdf

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