Пример веб-службы с применением WCF: атрибут ServiceBehavior
Рассмотрим, от чего зависит, как создаются экземпляры объекта WeatherService и в каком режиме обслуживаются запросы. Управление этими параметрами осуществляется декларативно с помощью параметров. Атрибут ServiceBehavior описывает режим создания экземпляра (InstanceContextMode)и режим параллельного вызова (ConcurrencyMode) экземпляра.
Режимы создания экземпляра (InstanceContextMode)
| Режим | Описание |
| Single | Создается один экземпляр для всех клиентов, при этом он создается только когда приходит первый вызов службы. Если вызовов нет, то и объект экземпляра не создается. |
| PerCall | Экземпляр создается на вызов каждого метода. При любом вызове не просто объекта, а даже любого его метода, создается отдельный экземпляр объекта. Позволяет не беспокоиться о синхронизации при режиме параллельного вызова Multiple. |
| PerSession | Экземпляр объекта создается на одну сессию клиента. Когда клиент создает объект WeatherServiceClient и делает первый вызов, создается экземпляр объекта, т.е. когда клиент только создал объект, экземпляр класса с функционалом службы на серверной стороне еще не создается. WeatherServiceна стороне службы будет уничтожен, когда клиент вызовет метод Closeобъекта WeatherServiceClient. |
Режимы параллельного вызова(ConcurrencyMode)
| Режим | Описание |
| Single | Все запросы обслуживаются одним потоком последовательно. Не возникает проблемы синхронизации нескольких клиентов, вызывающих службу: они образуют очередь, их запросы последовательно обрабатываются службой. |
| Multiple | Режим параллельной обработки входящих запросов от всех клиентов с помощью пула потоков. Все эти потоки для клиентов берутся из пула. Чтобы не беспокоиться о синхронизации, можно использовать этот режим совместно с режимом создания экземпляра PerCall. |
| Reentrant | Предполагает вызов в одном потоке (аналог Single), но в этом режиме допустимы рекурсивные вызовы. Пришедший рекурсивный запрос обрабатывается тем же потоком и возвращается назад. Этот режим более сложно устроен, т.к. требует сохранения контекста, чтобы понимать, когда произошел рекурсивный вызов, и не ставить его в очередь. Поэтому этот режим не используется по умолчанию. |
|
|
|
Когда нужен режим Reentrant? Например, есть служба в режиме Single, вызывающая другую службу. Клиент делает свой вызов к первой службе, она использует для реализации своего функционала внешнюю службу и вызывает вторую, которая снова вызывает первую. Если такое произойдет, получится deadlock (бесконечное ожидание), поскольку первая служба поставит вызов второй в очередь после клиента, а вызов клиента будет ожидать окончания этого вызова, стоящего за ним в очереди. Чтобы избежать такой ситуации, нужен режим Reentrant.
|
|
|
Пример веб-службы с применением WCF: ручная конфигурация службы
Пример ручного конфигурирования службы:
staticvoidMain()
{
var host = newServiceHost(typeof(WeatherService));
var tcpBinding = newNetTcpBinding(SecurityMode.None, false);
tcpBinding.MaxBufferPoolSize = int.MaxValue;
tcpBinding.MaxBufferSize = int.MaxValue;
tcpBinding.MaxReceivedMessageSize = int.MaxValue;
tcpBinding.PortSharingEnabled = false;
tcpBinding.Security.Transport.ClientCredentialType = TcpClientCredentialType.None;
host.AddServiceEndpoint("WcfServiceLibrary1.IWeatherService", tcpBinding, "net.tcp://localhost:5555/Design_Time_Addresses/WcfServiceLibrary1/WeatherService/");
var wsHttpBinding = newWSHttpBinding(SecurityMode.Message);
host.AddServiceEndpoint("WcfServiceLibrary1.IWeatherService", wsHttpBinding, "http://localhost:8731/Design_Time_Addresses/WcfServiceLibrary1/WeatherService/");
host.Open();
Console.WriteLine("Press ENTER to stop the service");
Console.ReadLine();
}
В примере создается служба с двумя точками доступа: одна точка доступа – по протоколу HTTP через порт 8731, а вторая – по протоколу TCP в бинарном виде через порт 5555.
С помощью ручного конфигурирования можно проделать все те действия, которые выполняет система при создании службы при помощи файла App.config. Для реальных системпредпочтительнее использовать файл App.config, позволяющий переносить службу на другой компьютер без перекомпиляции. Кроме того, пример показывает возможность работы двух служб на одном порте.
|
|
|
Веб-службы на основе REST
REST
REST (Representational State Transfer, «передача состояния представления» или «передача репрезентативного состояния») — стиль построения архитектуры распределенного приложения. Был описан и популяризован в 2000 году Роем Филдингом, одним из создателей протокола HTTP. Самой известной системой, построенной в значительной степени по архитектуре REST, является современная Всемирная паутина.
Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например, HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.
Дата добавления: 2018-08-06; просмотров: 263; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!