якого сервер може керувати активізацією і видаленням об'єктів. Він працює таким чином. p align="justify"> Зазвичай об'єкт активізується в результаті запиту клієнта на створення екземпляра нового об'єкта даного класу. Сервер об'єкта зберігає об'єкт в пам'яті до тих пір, поки існують клієнти, що зберігають посилання на цей об'єкт. Однак при JIT-активізації сервер може видалити об'єкт тоді, коли захоче. Так, наприклад, якщо сервер виявляє, що у нього не залишилося пам'яті, він може звільнити місце для нових об'єктів, видаливши старі. p align="justify"> Коли клієнт викликає метод раніше віддаленого об'єкта, сервер негайно створює новий об'єкт того ж класу і звертається до зазначеного методу цього об'єкта. Зрозуміло, такий підхід допустимо тільки при роботі з об'єктами без фіксації стану, тобто об'єктами, які в паузах між зверненнями не зберігають жодної інформації про свій внутрішній стан. Все, що залишається для роботи з таким об'єктом, - його методи. Подібні об'єкти використовувалися для виклику бібліотечних функцій ще в ті дні, коли не придумали об'єктно програмування. Якщо ж передбачається зберігати інформацію про стан об'єкта, після кожного звернення її доведеться записувати на диск і при кожному створенні об'єкта знову завантажувати. p align="justify"> Захист
Як і в CORBA, система захисту DCOM в основному забезпечує захист звернень до об'єктів. Однак спосіб реалізації захищених звернень тут абсолютно іншою. Хоча DCOM найчастіше входить в одну з операційних систем сімейства Windows, розробники DCOM абсолютно виправдано вирішили по можливості відокремити захист DCOM від служб захисту Windows. Таким чином вони зберегли можливість реалізації DCOM на інших операційних системах із збереженням захисту звернень. p align="justify"> У DCOM існує два напрямки реалізації захисту. Важлива роль у захисті DCOM відводиться реєстром, за допомогою якого здійснюється декларативна захист. Крім того, захист може бути реалізована і програмним шляхом, в тому сенсі, що додаток може сама вирішувати питання контролю доступу і аутентифікації. br/>
1.4 Механізм роботи RPC
Перед безпосереднім викликом на клієнтської і серверної стороні повинні бути створені спеціальні структури (процедури, файли) - це так звані клієнтський стаб (stub) і серверний скелетон (skeleton), які необхідні для коректної роботи RPC. Найчастіше, вони генеруються автоматично спеціальними утилітами за основним кодом програми. p align="justify"> Ідея, покладена в основу RPC, полягає в тому, щоб зробити виклик віддаленої процедури виглядаючим по можливості також, як і виклик локальної процедури. Іншими словами - зробити RPC прозорим: викликає процедурою не потрібно знати, що викликається процедура знаходиться на іншій машині, і навпаки. досягає прозорості таким шляхом. Коли викликається процедура дійсно є віддаленою...
