Основи віддаленої взаємодії об'єктів. Net (. Net remoting) 2006-2009 Зміст


НазваОснови віддаленої взаємодії об'єктів. Net (. Net remoting) 2006-2009 Зміст
Дата конвертації27.03.2013
Розмір445 b.
ТипПрезентации


Основи віддаленої взаємодії об'єктів .NET (.NET Remoting)

  • 2006-2009


Зміст

  • Типи об'єктів для віддаленої взаємодії. Домени.

  • Типи marshal-by-value. Серіалізація.

  • Типи marshal-by-reference.

  • Порівняння активізації віддалених об'єктів у COM та .NET. Хост-сервери .NET.

  • Серверна активізація. Режим Singleton.

  • Серверна активізація. Режим SingleCall.

  • Клієнтська активізація.

  • Канали. Стандартні типи каналів: TcpChannel та HttpChannel.

  • Конфігурування інфраструктури .NET Remoting:

    • програмне;
    • з використанням конфігураційних файлів.
  • Управління часом життя об'єктів. Загальні положення.

  • Ліцензії. Диспетчери (менеджери) та спонсори ліцензій.

  • Доступ до ліцензії об'єкта. Управління часом життя та config-файли.



Типи об'єктів для віддаленої взаємодії. Кордони .NET Remoting

  • Тип вважається типом для віддаленої взаємодії (remotable-типом) при виконанні хоча б однієї з наступних умов:

    • дані типу здатні перетинати кордони .NET Remoting;
    • можна звертатися до даних типу ззовні (з-за кордону .NET Remoting), тобто ззовні ці дані є доступними.
  • Найчастіше кордони .NET Remoting пов'язуються з процесами та доменами.



Домени

  • Домен (домен програми) можна розглядати як деякий логічний процес, при цьому код і об'єкти одного домену не мають безпосереднього доступу (тільки Remoting!) до коду й об'єктів іншого домену. На цьому ґрунтується захист: збій в одному домені не впливає на інші домени, навіть у тому ж процесі. (Зауважимо, що реальний процес здатний підтримувати одразу кілька програмних доменів).

      • (Загалом, віддалена взаємодія може розглядатись не тільки на рівні процесів чи доменів, але й для контекстів. З точки зору CLR домен може підрозділятись на окремі контексти. Контекстом гарантуються єдині обмеження на всі об'єкти у межах даного контексту. Наприклад, контекст синхронізації дозволяє виконуватись у будь-який момент максимум одному потоку.)


Категорії remotable-типів

  • Категорії remotable-типів:

    • типи, що передаються за значеннями (marshal-by-value);
    • типи, що передаються за посиланнями (marshal-by-reference).


Типи, що передаються за значеннями (marshal-by-value). Серіалізація

  • Екземпляри типів, що передаються за значеннями, перетинають кордони .NET Remoting за допомогою серіалізації.

  • Серіалізація — це процес представлення поточного стану об'єкта у вигляді послідовності даних.

  • Після серіалізації об'єкта інфраструктура .NET Remoting здатна пересилати такі дані, долаючи кордони .NET Remoting, та одержувати (після десеріалізації) точну копію первісного об'єкта в іншому домені чи процесі.

  • Тип вважається серіалізованим, якщо він описаний з атрибутом Serializable:

  • [Serializable]

  • class TheSerializableClass.

  • (Тип з атрибутом Serializable може реалізовувати інтерфейс ISerializable з метою запровадження нестандартної серіалізації).



Типи, що передаються за посиланнями (marshal-by-reference)

  • Для типів, що передаються за посиланням (такі типи мають успадковуватися від System.MarshalByRefObject), NET Remoting передає посилання на екземпляри, а не серіалізовані копії об'єктів.

  • Потреба у такому варіанті передачі даних виникає, наприклад, коли потрібно використовувати ресурси, доступні тільки на конкретному комп'ютері чи коли серіалізація призводить до значних втрат в ефективності.

  • Приклад типу, що передається за посиланням (marshal-by-reference): class TheMarshalByReferenceClass:

  • MarshalByRefObject



Активізація віддалених об'єктів

  • Створення та ініціалізація віддалених об'єктів marshal-by-reference типу пов'язується з так званою активізацією.

  • У .NET Remoting підтримуються два види активізації: серверна та клієнтська.

    • Зауважимо, що типи, які передаються за значеннями (marshal-by-value), не вимагають спеціального механізму активізації, тому що після десеріалізації можна мати "точні" копії первісних об'єктів.


Порівняння активізації віддалених об'єктів у COM та .NET. Хост-сервери .NET

  • На відміну від COM при віддаленій взаємодії у .NET клієнтський додаток сам по собі не запускає серверний додаток. Це, зокрема, означає, що при розробці серверних проектів потрібно орієнтуватись на використання програм-хостів.

  • Хостами віддаленої взаємодії можуть бути:

    • консольні (“текстові”) програми;
    • віконні програми (додатки Windows Form);
    • служби Windows;
    • процеси IIS (Internet Information Services);
    • додатки ASP.NET.


Спрощена архітектура .NET Remoting (www.msdn.microsoft.com)



Канали

  • Канали виступають транспортним механізмом при пересиланні серіалізованих об'єктів-повідомлень, долаючи кордони .NET Remoting.

  • Об'єкти-канали з інфраструктури .NET Remoting інкапсулюють задачі низького рівня, пов'язані з мережною взаємодією: відкриття мережного підключення, форматування повідомлення, запис у потік, передача даних по мережі серверній програмі з використанням якогось транспортного протоколу тощо.

  • .NET Remoting використовує два стандартних типи каналів: TcpChannel та HttpChannel, але можна створювати і власні канальні типи.



Стандартні типи каналів: TcpChannel та HttpChannel

  • Тип TcpChannel (із простору імен System.Runtime.Remoting.Channels.Tcp) використовує для серіалізації об'єктів-повідомлень за замовчуванням двійковий формат, для транспортування – протокол TCP і, загалом, забезпечує максимальну ефективність передачі даних на основі сокетів.

  • Тип HttpChannel (із простору імен System.Runtime.Remoting.Channels.Http) використовує для серіалізації об'єктів-повідомлень за замовчуванням мережний формат SOAP , для транспортування – протокол HTTP. Цей тип каналу забезпечує відкритість даних, дозволяє використовувати для їхньої передачі Інтернет і брандмауери. (Проте при потребі підвищити ефективність передачі даних можна використати двійковий форматувальник).



Двоспрямовані та односпрямовані канали

  • Типи TcpChannel і HttpChannel дозволяють створювати двоспрямовані канали, зручні для підтримки не тільки прямих, але й зворотних викликів, що, наприклад, вимагається при використанні подій.

  • Іноді можна обмежитися типами односпрямованих каналів – клієнтських чи серверних: TcpClientChannel, TcpServerChannel, HttpClientChannel, HttpServerChannel.



Основи використання .NET Remoting



Приклад віддаленої (remoting) взаємодії (із серверним, remotable, класом ServerObject) (1/5)



Приклад віддаленої (remoting) взаємодії (із серверним, remotable, класом ServerObject) (2/5)



Приклад віддаленої (remoting) взаємодії (із серверним, remotable, класом ServerObject) (3/5)



Приклад віддаленої (remoting) взаємодії (із серверним, remotable, класом ServerObject) (4/5)



Приклад віддаленої (remoting) взаємодії (із серверним, remotable, класом ServerObject) (5/5)



Клієнтська активізація віддалених об'єктів

  • Пригадаємо …

  • Клієнтська активізація забезпечує кожному клієнту можливість взаємодіяти з окремим екземпляром віддаленого типу: для кожного клієнта створюється віддалений об'єкт, який обслуговує тільки “свого” клієнта (із збереженням стану між окремими викликами методів).



Режими Singleton та SingleCall серверної активізації віддалених об'єктів

  • Режим Singleton означає, що у будь-який момент може бути активним максимум один віддалений об'єкт, який активізується при зверненні до нього (не важливо яким саме клієнтом). Після активізації такий віддалений об'єкт обробляє всі запити від усіх клієнтів, зберігаючи поточний стан у паузах між окремими викликами методів.

  • У режимі SingleCall віддалені об'єкти створюються для обробки кожного окремого “запиту” — виклику будь-якого метода — і після виконання запиту (окремого виклику) відповідний об'єкт “знищується” (формально він стає доступним для “збирача сміття”).



Активізація віддалених об'єктів та конфігурування .NET Remoting

  • Вид активізації (серверна чи клієнтська), а також можливий режим (Singleton чи SingleCall для серверної активізації) визначаються не типом (класом), а налаштовуванням (конфігуруванням) інфраструктури .NET Remoting.

  • Отже, один і той самий тип (клас) може в одних програмах використовуватись (“конфігуруватись”) з Singleton-серверною активізацією, в інших — з SingleCall-серверною активізацією, а ще в інших — з клієнтською активізацією.



Дослідження різних варіантів активізації (1/5) (клас Server.ServerObject, модуль SObj.cs)



Дослідження різних варіантів активізації (2/5) (клас Server.ServerObject)



Дослідження різних варіантів активізації. Серверна активізація. Режим Singleton (3/5)



Дослідження різних варіантів активізації. Серверна активізація. Режим SingleCall (4/5)





Конфігурування інфраструктури .NET Remoting. Загальні положення

  • Конфігурування застосовується, як на боці сервера, так і на боці клієнта;

  • Можна використовувати (і на боці сервера, і на боці клієнта) один з наступних двох варіантів конфігурування: (1) програмний та (2) із використанням конфігураційних файлів.



Конфігурування інфраструктури .NET Remoting. Отже, варіанти, варіанти . . .

  • конфігурування застосовується, як на боці сервера, так і на боці клієнта;

  • можна використовувати (і на боці сервера, і на боці клієнта) один з наступних двох варіантів конфігурування: (1) програмний та (2) із використанням конфігураційних файлів;

  • конфігурування передбачає вибір серверної (режим Singleton або SingleCall) чи клієнтської активізації віддалених об'єктів;

  • конфігурування передбачає обрання канального типу та порту.



Remoting-конфігурування на боці сервера (приклад конфігураційного файлу Serv.exe.config)

  • Загалом, конфігуруванням на боці сервера визначаються:

    • канал (найчастіше Tcp чи Http) та порт;
    • вид активізації клієнтська чи серверна (з обраним режимом Singleton або SingleCall);
    • URI віддаленого об'єкта;
    • тип (клас) віддаленого об'єкту та ім'я збірки, яка містить цей тип;


До файлового конфігурування .NET Remoting. Приклад та деякі варіації

  • activated



Серверна активізація віддалених об'єктів. Додаткові штрихи

  • Типи, що активізуються сервером при налагоджуванні (конфігуруванні) .NET Remoting трактуються як загальновідомі (wellknown).

  • Терміном wellknown підкреслюється, що серверна програма насамперед зобов'язана віддалений тип "опублікувати”, використовуючи загальновідомий уніфікований ідентифікатор ресурсузагальновідомий URI (Uniform Resource Identifier). Лише після публікації об'єкти такого віддаленого типу можуть бути активізовані.



Файлове Remoting-конфігурування на боці клієнта у порівнянні з конфігуруванням на боці сервера

  • Конфігуруванням на боці клієнта, загалом, визначаються:

    • канал (найчастіше Tcp чи Http) та порт;
    • вид активізації серверна (з режимом Singleton або SingleCall) чи клієнтська;
    • “адреса” - URL віддаленого об'єкта (з URI у випадку серверної активізації);
    • тип (клас) віддаленого об'єкту та ім'я збірки, яка містить цей тип;


Файлове конфігурування .NET Remoting на боці клієнта. Приклад

  • Конфігуруванням на боці клієнта, загалом, визначаються:

    • канал (найчастіше Tcp чи Http) та порт;
    • вид активізації серверна (з режимом Singleton або SingleCall) чи клієнтська;
    • “адреса” - URL віддаленого об'єкта (з URI у випадку серверної активізації);
    • тип (клас) віддаленого об'єкту та ім'я збірки, яка містить цей тип;




Програмне конфігурування на боці сервера



Програмне конфігурування на боці клієнта





Створення проксі-об'єктів

  • Віддалений клас клієнтам не обов'язково “знати” повністю при створенні проксі (захист know how!):

    • можна клієнтам клас надавати з “порожніми” реалізаціями методів;
    • можна надавати тільки інтерфейси, навіть з обмеженою функціональністю (проксі за інтерфейсом).
  • Можливі “статичний” та “динамічний” варіанти створення проксі (як “створення” віддалених об'єктів у клієнтській програмі):

    • “статичний” варіант — віддалені об'єкти “створюються” традиційним чином, а саме за “наперед відомим” іменем класу з використанням конструкції new;
    • “динамічний” варіант — коли віддалений об'єкт “створюється” з використанням класу Activator. Тут важливо, що тип створюваного об'єкту може динамічно “обчислюватись”, наприклад, використовуючи метод GetType.


Створення проксі з використанням класу Activator (основа “динамічних викликів”)



Активізація віддалених об'єктів. Додаткові зауваження

  • У випадку серверної активізацієї виклик клієнтом оператора new не призводить до активізації об'єкта – у цей момент на боці клієнта створюється тільки об'єкт-проксі. Сам віддалений об'єкт буде створюватися у серверній програмі лише у відповідь на виклик деякого метода віддаленого об'єкта. Така особливість створення віддаленого об'єкта пояснює, чому об'єкт із серверною активізацією не може створюватися конструкторами з параметрами (а, отже, доводиться задовольнятися конструктором без параметрів, тобто конструктором за замовчуванням).

  • Зазначимо, що об'єкти з клієнтською активізацією створюються на сервері у момент виклику клієнтом newnew забезпечує створення як проксі, так і власне серверного (віддаленого ) об'єкта.



Активізація віддалених об'єктів. Додаткові зауваження (приклад із серверною активізацією)

  • У випадку серверної активізацієї виклик клієнтом оператора new не призводить до активізації об'єкта – у цей момент на боці клієнта створюється тільки об'єкт-проксі.



Активізація віддалених об'єктів. Додаткові зауваження (приклад із клієнтською активізацією)

  • Зазначимо, що об'єкти створюються на сервері у момент виклику клієнтом newnew забезпечує створення як проксі, так і власне серверного (віддаленого ) об'єкта.









Проект Fond . Ще один підхід. “Клас-пустушка” (class stand in – клас-дублер)







Управління часом життя об'єктів. Загальні положення

  • Управління часом життя об'єктів:

    • CAO;
    • SAO Singleton;
    • SAO SingleCall. (Тут ситуація із часом життя проста. Такі об'єкти створюються при кожному виклику будь-якого з методів і із завершенням виконання метода “ліквідовуються “ – формально вони позначаються призначеними для вилучення "збирачем сміття”. Отже, якісь додаткові форми управління часом життя таких об'єктів просто не потрібні.)
  • Загалом управління часом життя об'єктів ґрунтується на поняттях ліцензій, спонсорів та диспетчерів ліцензій.



Управління часом життя об'єктів. Основні властивості (properties) інтерфейсу ILease



Диспетчери (менеджери) ліцензій. Спонсори ліцензій

  • При активізації віддаленого об'єкту CLR отримує (і передає диспетчеру для реєстрації) дані стосовно ліцензії цього об'єкта.

  • Диспетчер ліцензій (lease manager) є у кожному домені. Він періодично перевіряє зареєстровані об'єктні ліцензії, чи не завершився їх термін. Періодичність опитування можна визначати (за замовчуванням – 10 секунд):

  • LifetimeServices.LeaseManagerPollTime =

  • System.TimeSpan.FromMinutes(1)



Деякі можливості управління часом життя об'єктів

  • Управління часом життя віддалених об'єктів “закладене” у типі MarshalByRefObject . Ключовими є наступні методи:

  • Ще одна можливість встановлення початкових умов життєдіяльності об'єктів — у файлі конфігурації (config) сервера. Проте у цьому випадку умови будуть стосуватись усіх віддалених об'єктів у серверному процесі.



Управління часом життя об'єктів. Приклад



Додаток



MarshalByRefObject. Public Methods (www.msdn2.microsoft.com/en-us/)



MarshalByRefObject. Public Methods (www.msdn.microsoft.com/library/rus/)



Віддалені об'єкти з використанням IIS (Internet Information Services)

  • IIS можна використовувати в якості хоста та агента активізації віддалених об'єктів.

  • IIS, по-перше, є звичайною службою Windows і, по-друге, застосовується на багатьох Web-серверах.









Internet Information Services



Створення віртуального каталога

  • Control Panel ->Administrative Tools -> Internet Information Services



Wizard



Віртуальний каталог створено



Схожі:

Основи віддаленої взаємодії об\Основи віддаленої взаємодії об'єктів. Net (. Net remoting) 2009 Зміст

Основи віддаленої взаємодії об\Основи віддаленої взаємодії об'єктів. Net (. Net remoting) 2008 Зміст

Основи віддаленої взаємодії об\Основи віддаленої взаємодії об'єктів. Net (. Net remoting) 2007 Зміст

Основи віддаленої взаємодії об\Основи віддаленої взаємодії об'єктів. Net (. Net remoting) 2006 Зміст
На цьому ґрунтується захист: збій в одному домені не впливає на інші домени, навіть у тому ж процесі. Зауважимо, що реальний процес...
Основи віддаленої взаємодії об\Net remoting. Час життя об'єктів 2006-2009 Зміст
Тут ситуація проста. Такі об'єкти створюються при кожному виклику будь-якого з методів і з завершенням виконання метода ліквідовуються...
Основи віддаленої взаємодії об\Основи платформи. Net framework 2006-2012 Зміст

Основи віддаленої взаємодії об\Net remoting. Час життя об'єктів 2007 Зміст
Тут ситуація проста. Такі об'єкти створюються при кожному виклику будь-якого з методів і з завершенням виконання метода ліквідовуються...
Основи віддаленої взаємодії об\Перенесення рішень із платформи. Net на платформу com 2006 Зміст

Основи віддаленої взаємодії об\Основи платформи. Net framework 2007 Зміст

Основи віддаленої взаємодії об\Основи платформи. Net framework 2006 Зміст
Розробка платформи почалася у 1998 році. Перша робоча назва Project 42, потім була назва com object Runtime чи, скорочено, cor, пізніше...

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка