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


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


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

  • 2007


Зміст

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

  • Типи 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



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



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



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

  • Створення та ініціалізація віддалених об'єктів 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



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

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

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

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



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

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

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



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

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

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



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

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

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


Приклад конфігураційного файлу (Serv.exe.config)



Конфігурування .NET Remoting на боці клієнта. Приклад програмного конфігурування

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

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


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

  • Розробка програм-клієнтів для режимів Singleton та SingleCall нічим не відрізняється



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

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

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

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


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







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

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

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



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

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

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



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

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

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

  • LifetimeServices.LeaseManagerPollTime =

  • System.TimeSpan.FromMinutes(1)



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



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

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

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



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



Приклади



Дослідження різних варіантів активізації. Віддалений тип Server.ServerObject (Модуль SObj.cs)



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

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

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

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



Серверна активізація віддалених об'єктів. Режим Singleton

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

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







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



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























Додаток



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

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

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









Internet Information Services



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

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



Wizard



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



Схожі:

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

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

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

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

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

Основи віддаленої взаємодії об\Ua-net Інтернет реклама, Україна ua-net 8 мільйонів користувачів

Основи віддаленої взаємодії об\Asp. NET asp. Net microsoft sql server 2005


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


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