|
Теперь, когда мы создали объект, нам требуется поместить этот объект на нашем сервере. Объект удаленного доступа требует наличия сервера, который предоставляет этот объект через порт клиентам. Каждый объект удаленного доступа должен быть опубликован на хосте сервера. Хостом может быть IIS, служба Windows или самостоятельно реализованный хост. Для простоты мы создадим наш собственный хост для публикации этого объекта удаленного доступа.
using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Remoting;
namespace Server
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Server started.");
RemotingConfiguration.Configure("server.exe.config");
Console.WriteLine("Server is running. Press to exit.");
Console.ReadLine();
}
}
}
Перед тем, как мы сможем запустить сервер, мы должны определить объекты удаленного доступа, которые следует опубликовать. Структура удаленного доступа позволяет нам читать конфигурацию из настроечного файла приложения. Мы могли бы «зашить» конфигурацию непосредственное приложение, но в этом случае изменение конфигурации потребовало бы перекомпиляции сервера. Настроечные файлы предлагают гораздо более гибкое решение, чем «зашивание» конфигурации в хост сервера.
Как только настроенный файл создан, мы говорим среде выполнения удаленного доступа получить конфигурацию из этого файла при помощи строки:
RemotingConfiguration.Configure("server.exe.config");
Файл server.exe.config имеет следующий вид:
Структура удаленного доступа читает узел < system.runtime.remoting > и настраивает среду выполнения удаленного доступа в соответствии с его содержимым. Этот настроечный файл должен быть размещен в той же директории, где и server.exe.
В файле указывается, какой канал необходимо открыть для объекта. Так как используется канал HTTP, тэг канала задается следующим образом:
Мы также должны открыть объект, и для этого имеется два типа создания объекта - wellknown и activated. Аналогично объектам СОМ, объекты типа activated могут иметь состояние и их время жизни определяется клиентом. Объекты типа wellknown создаются в процессе сервера и время их жизни определяется сервером.
Имеется два режима объектов wellknown - Singleton и SingleCall. В режиме Singleton создается один объект для обработки всех запросов. Объект сохраняется между запросами клиентов. Объекты SingleCall создаются для каждого запроса переданного клиентом. Каждый раз, когда приходит клиентский запрос, создается новый объект, обслуживается запрос клиента, а затем объект удаляется. Объект Singleton великолепно подходит, если вы хотите совместно использовать общие данные для всех запросов клиентов.
Объекты SingleCall не оставляют следов, так как все созданные объекты уничтожаются при завершении обработки запроса.
Вот иллюстрация использования объекта Singleton:
Свойство type говорит среде выполнения удаленного доступа, какой объект должен быть опубликован, и объявляется в формате <тип>, <сборка>. Здесь свойство type говорит, что мы хотим опубликовать объект Order из сборки Order.dll. Чтобы это всё правильно работало, сборка Order.dll должна располагаться там, где среда выполнения сможет ее найти. Мы устанавливаем Order.dll в той же физической директории, что и Server.exe. Заметьте, что расширение .dll сборки не указывается.
Свойство objectUri является идентификатором, под которым наш объект будет опубликован. Так как по одному и тому же каналу и порту может вызываться много различных объектов, мы должны дать каждому объекту уникальный идентификатор, чтобы отличать их друг от друга. Мы даем ему расширение .soap, чтобы указать, что этот объект будет использовать форматер SOAP. Так как форматер SOAP является форматером по умолчанию для канала HTTP, мы не должны указывать форматер в этом настроечном файле.
Теперь, когда мы скомпилировали сервер и создали настроечный файл, мы можем запустить Server, и он будет готов принимать входящие, запросы. Вот пример того, как будет выглядеть процесс сервера после начала его исполнения.
Do'stlaringiz bilan baham: |
