Отдалечени извиквания с. Net remoting

Проблемът с общите типове

Изтегляне 499.7 Kb.

страница	3/3
Дата	09.06.2017
Размер	499.7 Kb.
	#23191

1 2 3

Проблемът с общите типове

Нещо, което не споменахме изрично за горните примерни сървър и клиент, е че за да се компилират и работят правилно, и клиентът и сървърът трябва да имат копие от асемблито със споделените типове, които се използват. Следващата част е посветена изцяло на този проблем.

Както видяхме в цялата тема, а и от примерите, за да може да работи едно приложение посредством Remoting, трябва и клиентът и сървърът да разполагат с описание на общите за тях типове и техните методи.

Споделено асембли с типове

В .NET Framework типовете се описват от метаданните в асемблитата и затова най-интуитивното решение на проблема с общите типове е да копираме асемблито с типовете данни в директорията на приложението както на сървъра така и на клиента. Този подход има добри и лоши страни.

Добрите са, че всеки разполага с дефинициите на типовете и е възможно е да се организира offline работа с данните.

Лошите страни са, че когато имаме проблем с някой от типовете и направим промени в него (което не е задължително да е предизвикано от проблем!), трябва не само да подменим асемблитата на сървъра, а да накараме всеки един от клиентите да подмени своите асемблита, които са засегнати от промяната. Практиката показва, че това е скъпоструващ, неприятен и сложен процес.

Споделено асембли с интерфейси

Едно частично решение на горния проблем е при клиента да не се разпространяват самите класове (типове), а само интерфейсите, които те имплементират. По този начин имаме възможност да скрием имплементацията на класовете си и всички промени, които не засягат интерфейса на класа, да окажат влияние само върху асемблито с типовете на сървъра. По този начин много по-рядко ще се налага да заставяме клиентите да обновяват своите асемблита, но губим възможността клиентът да може да работи в offline режим. Въпреки това тази практика е препоръчителната и най-често използваната.

Soapsuds.exe

Друг подход за осигуряване на клиента с метаданните, от които се нуждае, е използването на инструмента soapsuds.exe. Той се намира в <директория на VS.NET 2003>\SDK\v1.1\Bin. Чрез него от готовото асембли с типовете, които ще поставим на сървъра, можем да извлечем само метаданните и да ги компилирате отново в друго асембли, което да използваме при клиента. Този подход не се различава съществено от подхода със споделено асембли, съдържащо общите типове.

Хостинг на Remoting типове в IIS

Един въпрос, свързан с разпространяването на общи типове, който само бегло засегнахме при разглеждането на Remoting сценариите, беше хостингът на асемблита с Remoting типове в IIS.

Remoting инфраструктурата ни позволява да се възползваме от функционалността, която Internet Information Services предлага за хостинг на различни приложения. Такива приложения могат да бъдат уеб приложения, уеб услуги, Remoting приложения и др.

За да използваме IIS за хостинг на Remoting сървърни приложения, трябва да направим 3 неща:

Да създадем виртуална директория в IIS.
В нея да запишем един Remoting конфигурационен файл, който да има специално име – Web.config.
Да създадем поддиректория bin, в която да копираме асемблитата с типовете, които искаме да използваме като отдалечени.

Ограниченията, които IIS ни налага, са да използваме HTTP протокол. Хоствайки своите отдалечени типове по този начин, ние нямаме нужда да се грижим специално за сигурността и мащабируемостта на сървъра и естествено нямаме нужда да пишем приложение, което да бъде сървър, тъй като за това се грижи IIS.

Remoting приложенията в IIS работят както уеб приложенията и уеб услугите – хостват се и се управляват от сървъра и стартират заедно с него. За тях могат да се настройват сигурността, използваните ресурси и много други неща, които се предоставят от IIS.

Упражнения

Обяснете основните концепции на .NET Remoting инфраструктурата – канали, форматери, видове активация, видове маршализация и жизнен цикъл на обектите.
Реализирайте клиент-сървър приложение за разговори в реално време (chat), базирано на .NET Remoting. Използвайте TCP канал, бинарен форматер, маршализация по референция и Singleton активация от сървъра. Сървърът трябва да поддържа списък на свързаните към него потребители и да позволява няколко разговора (chat сесии) едновременно. Клиентът (Windows Forms приложение) трябва да може да започва chat сесия, да изпраща съобщения до другите потребители и да затваря chat сесия.
Реализирайте клиент-сървър приложение, базирано на .NET Remoting технологията, за обслужване на библиотека с албуми със снимки. Сървърът трябва да поддържа операциите: извличане на албумите, извличане на снимките от всеки албум, добавяне на албум, добавяне на снимка, изтриване на албум, изтриване на снимка, преместване на снимка в друг албум. Албумите не могат да бъдат вложени един в друг. Използвайте файловата система за съхранение на албумите със снимките. Клиентът трябва да е Windows Forms приложение и да предоставя интерфейс към изброените операции. Използвайте HTTP канал, SOAP форматер, активация от клиента и маршализация по стойност. Конфигурирането на клиента и сървъра трябва да става с външен XML файл.

Използвана литература

Светлин Наков, .NET Remoting (отдалечено извикване) – http://www. nakov.com/dotnet/lectures/Lecture-21-Remoting-v1.0.ppt
MSDN Library, Piet Obermeyer and Jonathan Hawkins, Microsoft .NET Remoting: A Technical Overview – http://msdn.microsoft.com/library/en-us/dndotnet/html/hawkremoting.asp
MSDN Library, Paddy Srinivasan, An Introduction to Microsoft .NET Remoting Framework – http://msdn.microsoft.com/library/en-us/dndotnet/html/introremoting.asp
MSDN Magazine (12/2003), Juval Lowy, Managing the Lifetime of Remote .NET Objects with Leasing and Sponsorship – http://msdn.microsoft.com/ msdnmag/issues/03/12/LeaseManager/default.aspx
MSDN Library, Piet Obermeyer and Jonathan Hawkins, Format for .NET Remoting configuration files – http://msdn.microsoft.com/library/en-us/dndotnet/html/remotingconfig.asp

Каталог: dotnetcourse -> Beta1
Beta1 -> Изграждане на графичен потребителски интерфейс с Windows Forms
Beta1 -> Асемблита и разпространение
Beta1 -> Управление на паметта и ресурсите
Beta1 -> Уеб услуги с asp. Net
dotnetcourse -> Кратко ръководство и полезни съвети за това как да разработим своя практически проект
dotnetcourse -> Въпрос: Кога е нужно да слагам в класовете си свойства, и кога мога да слагам публични полета? Не е ли вторият вариант по-удобен, особено когато едно поле не се валидира по никакъв начин? Отговор
Beta1 -> Сериализация на данни

Изтегляне 499.7 Kb.

Сподели с приятели:

1 2 3