Разработка сервиса с применением Windows Communication

Национальный Исследовательский Университет
МОСКОВСКИЙ ЭНЕРГЕТИЧЕСКИЙ ИНСТИТУТ
Институт автоматики и вычислительной техники
Кафедра прикладной математики
Курсовая работа
Разработка сервиса с применением
Windows Communication Foundation
Курс «Проектирование программного обеспечения автоматизированных систем»
Выполнил
студент 5 курса
группы А-13-08
Захаров Антон
Преподаватель
Меньшикова
Ксения Георгиевна
Научный руководитель
Чибизова
Наталья Владимировна
Москва, 2012
2
ВВЕДЕНИЕ
Windows Communication Foundation (WCF) – платформа нового поколения
для построения распределенных систем, выпущенная в составе .NET Framework
3.0. Класс службы WCF не может существовать самостоятельно. Каждая служба
WCF должна находиться под управлением некоторого процесса Windows, называемого хостовым процессом.
WCF делает возможным построение безопасных и надёжных транзакционных систем через упрощённую унифицированную программную модель межплатформенного взаимодействия. Комбинируя функциональность существующих
технологий .NET по разработке распределённых приложений (ASP.NET XML
Web Services – ASMX, WSE 3.0, .NET Remoting, .NET Enterprise Services и
System.Messaging), WCF предоставляет единую инфраструктуру разработки, при
умелом применении повышающую производительность и снижающую затраты на
создание безопасных, надёжных и транзакционных Web-служб нового поколения.
Заложенные в неё принципы интероперабельности позволяют организовать работу с другими платформами, для чего используются технологии взаимодействия
платформ, разрабатываемые на базе открытого исходного кода.
Возможность взаимодействия и интеграция различных API-интерфейсов –
это только два важных аспекта WCF. В дополнение WCF предлагает развитую
фабрику программного обеспечения, которая дополняет технологии удаленной
разработки, представленные WCF.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) –
модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
Команда разработчиков WCF пользовалась четырьмя принципами проектирования SOA. Хотя данные принципы реализуются автоматически, просто при
построении приложения WCF. понимание этих четырех кардинальных правил
дизайна SOA может помочь применять WCF в дальнейшей перспективе.
3
Принцип 1: Явное задание границ.
Этот принцип подчеркивает тот факт, что функциональность службы WCF
выражается через четко определенные интерфейсы (т. е. описания каждого члена,
его параметров и возвращаемых значений). Единственный способ, которым
внешний клиент может связаться со службой WCF, – через интерфейс, при этом
оставаясь в неведении о деталях её внутренней реализации.
Принцип 2: Автономность служб.
Говоря о службах, как об автономных сущностях, имеется в виду тот факт,
что каждая служба WCF является (насколько возможно) отдельным «островом».
Автономная служба должна быть независимой от проблем с версиями, развертыванием и установкой. Чтобы помочь в продвижении этого принципа, мы опять
возвращаемся к ключевому аспекту программирования на основе интерфейсов.
Как только интерфейс внедрен, он никогда не должен изменяться (или вы рискуете разрушить существующие клиенты). Когда требуется расширить функциональность службы WCF, просто напишите новый интерфейс, который моделирует необходимую функциональность.
Принцип 3: Взаимодействие служб через контракт, а не реализацию.
Третий принцип – еще один побочный продукт программирования на основе интерфейсов – состоит в том, что реализация деталей службы WCF (на каком
языке она написана, как именно выполняет свою работу, и т. п.) не касается вызывающего её внешнего клиента. Клиенты WCF взаимодействуют со службами
исключительно через их открытые интерфейсы. Более того, если члены службы
представляют сложные специальные типы, они должны быть полностью детализированы в виде контракта данных, гарантируя, что клиенты смогут отобразить
содержимое на определенную структуру данных.
4
Принцип 4: Совместимость служб базируется на политике.
Поскольку интерфейсы CLR предоставляют строго типизированные контракты всем клиентам WCF (и также могут быть использованы для генерации соответствующего документа WSDL на основе выбранной привязки), важно понимать на то, что интерфейсы и WSDL сами по себе недостаточно выразительны,
чтобы детализировать аспекты того, что способна делать служба. Учитывая это,
SOA позволяет определять политики, которые еще более проясняют семантику
службы (например, ожидаемые требования безопасности, применяемые для общения со службой). Используя эти политики, можно отделять низкоуровневые
синтаксические описания службы (предоставляемые интерфейсы) от семантических деталей их работы и способов их вызова.
5
1. АРХИТЕКТУРА ПРИЛОЖЕНИЙ WCF
1.1. Основы WCF
При построении распределенной системы WCF обычно создаются три взаимосвязанных сборки.
1. Сборка службы WCF. Эта библиотека *.dll содержит классы и интерфейсы,
представляющие некую функциональность, которая предлагается внешним
клиентам.
2. Хост службы WCF. Этот программный модуль – сущность, которая принимает в себе сборку службы WCF.
3. Клиент WCF. Это приложение, которое обращается к функциональности
службы через промежуточный прокси-класс.
Рис. 1.1. Общая схема взаимодействия хоста WCF и приложения клиента.
Хосты и клиенты взаимодействуют друг с другом, согласовывая так называемые «АПК» («ABC», address, binding, contract) – условное наименование для запоминания основных строительных блоков приложения WCF, таких как адрес,
привязка и контракт.
1. Адрес. Описывает местоположение службы. В коде представлен типом
System.Uri, однако значение обычно хранится в файлах *.сonfig.
2. Привязка. WCF поставляется с множеством различных привязок, которые
указывают сетевые протоколы, механизмы кодирования и транспортный
уровень.
3. Контракт. Предоставляет описание каждого метода, представленного
службой WCF.
6
1.2. Конечные точки
В мире WCF термин конечная точка (endpoint) представляет адрес, привязку и контракт, объединенные вместе в один пакет. В XML конечная точка выражается элементом <endpoint> и элементами address, binding и contract.
Каждая конечная точка состоит из следующего.
1. Адрес однозначно определяет конечную точку и указывает потенциальным
потребителям на место расположения службы. В объектной модели WCF
адрес представлен классом EndpointAddress. Класс EndpointAddress содержит свойство Uri, представляющее адрес службы, и свойство Identity, представляющее удостоверение безопасности службы и коллекцию необязательных заголовков сообщений. Необязательные заголовки сообщений используются для вывода дополнительной и более подробной информации,
необходимой для идентификации конечной точки или взаимодействия с
ней.
2. Привязка задает способ связи клиента с конечной точкой. В том числе следующее: используемый транспортный протокол (например, TCP или HTTP);
используемую в сообщениях кодировку (например, текст или двоичное кодирование); необходимые требования безопасности (например, безопасность сообщений SSL или SOAP). Привязка в объектной модели WCF представлена абстрактным базовым классом Binding. В большинстве сценариев
пользователи могут использовать только одну из предусмотренных системой привязок. Дополнительные сведения см. в разделе Привязки, предоставляемые системой.
3. Контракты показывают, какие функциональные возможности дает клиенту
конечная точка. В контракте задается следующее: операции, которые могут
быть вызваны клиентом; форма сообщения; тип входных параметров или
данных, требуемых для вызова операции; тип обработки или ответного сообщения, который может ожидать клиент.
4. Поведения конечной точки можно использовать для настройки локального
поведения конечной точки службы. Поведения конечной точки выполняют
7
это путем участия в процессе создания среды выполнения WCF. Примером
поведения является свойство ListenUri, позволяющее указывать отличный
от адреса SOAP или WSDL адрес прослушивания.
1.3. Контракты
Контракт представляет собой описание сообщений, передаваемых оконечным точкам службы и возвращаемых ей. Каждая оконечная точка определяется
своими АПК: Адресуемым местом в сети, куда посылаются сообщения; Привязкой, описывающей способ передачи сообщений, и Контрактом, в котором оговорены форматы сообщений. Служба можно рассматривать как набор оконечных
точек, которые реализуют те или иные программно-закодированные алгоритмы.
Это может быть бизнесфункция высокого уровня, например ввод заказа в
систему, или более специализированная функция, как, скажем, поиск адреса клиента.
Для высокоуровневых функций обычно требуются сложные структуры данных, тогда как для более простых часто хватает базовых типов. В любом случае
оконечная точка должна специфицировать, какие операции она может выполнять,
и формат ожидаемых данных. В совокупности эти спецификации и составляют
контракт.
В WCF есть контракты трех видов:
1. Контракт о службе описывает функциональные операции, реализуемые
службой. Он отображает методы класса .NET на описания служб, типов
портов и операций на языке WSDL. Внутри контракта о службе имеются
контракты об операциях, которые описывают отдельные операции службы,
то есть методы, реализующие ее функции.
2. Контракт о данных описывает структуры данных, используемые службой
для взаимодействия с клиентами. Он описывает все данные, получаемые и
отправляемые операциями службы.
3. Контракт о сообщениях описывает формат сообщений протокола SOAP,
что находит отражение в определениях сообщений на языках WSDL. Контракт о сообщениях позволяет точно контролировать состав заголовков и
тел SOAP сообщений.
8
Понятие контракта является ключевым при построении службы WCF. Хотя
это и не обязательно, подавляющее большинство приложений WCF будут начинаться с определения типов интерфейсов .NET, используемых для представления
набора членов, которые поддерживаются данной службой WCF. В частности, интерфейсы, которые представляют контракт WCF, называются контрактами служб.
Классы (или структуры), которые реализуют их, носят название типов служб.
Контракты служб WCF оснащаются различными атрибутами, наиболее часто
используемые
из
которых
определены
в
пространстве
имен
System.ServiceModel. Когда члены контракта службы (методы в интерфейсе) содержат только простые типы данных (такие как числовые, булевские и строковые), полную службу WCF можно построить, используя одни только атрибуты
[ServiceContract] и [OperationContract].
Как только контракт (или набор контрактов) определен и реализован внутри
библиотеки службы, следующий логический шаг состоит в построении агента хостинга для самой службы WCF. Как уже упоминалось, на выбор доступно множество возможных вариантов хостов, и все они должны указывать привязки, используемые удаленными клиентами для получения доступа к функциональности типа
службы. Выбор из набора привязок – это область, которая отличает разработку
WCF от .NET Remoting и/или разработки веб-служб XML. На выбор в WCF доступно множество возможных привязок, каждая из которых ориентирована на
определенные потребности. Если ни одна из готовых привязок не удовлетворяет
существующим требованиям, можно создать собственную привязку, расширив
тип CustomBinding. Привязка WCF может описывать следующие характеристики:
1. Транспортный уровень, используемый для передачи данных (HTTP, MSMQ,
именованные каналы и TCP);
2. Каналы, используемые транспортом (однонаправленные, запрос-ответ и
дуплексные);
3. Механизм кодирования, используемый для работы с данными (XML и двоичный);
4. Любые поддерживаемые протоколы веб-служб (если разрешены привязкой), такие как WS-Security, WS-Transactions, WS-Reliability и т.д.
9
Как только контракты и привязки установлены, финальный элемент мозаики состоит в указании адреса для службы WCF. Это важно, поскольку удаленные
клиенты не смогут взаимодействовать с удаленными типами, если им не удастся
найти их. Подобно большинству аспектов WCF, адрес может быть жестко закодирован в сборке (с использованием типа System.Uri) или вынесен в файл *.config.
В любом случае точный формат адреса WCF отличается в зависимости от
выбранной привязки (на основе HTTP, именованных каналов, TCP или MSMQ).
На самом высоком уровне адреса WCF могут указывать перечисленные ниже
единицы информации.
1. Scheme. Транспортный протокол (HTTP и т.п.).
2. MachineName. Полностью квалифицированное доменное имя машины.
3. Port. Во многих случаях не обязательный параметр. Например, привязка
HTTP по умолчанию использует порт 80.
4. Path. Путь к службе WCF
Эта информация может быть представлена следующим обобщенным шаблоном (значение Port необязательно, поскольку некоторые привязки его не используют):
Scheme://<MachineName>[:Port]/Path
10
1.4. Атрибуты
В WCF атрибуты применяются ради упрощения и ускорения процесса написания служб. При определении контракта пишется класс, который делает нечто
полезное, после чего он снабжается атрибутами WCF. Атрибут ServiceContract
помечает класс, как контракт. В терминах языка WSDL ServiceContract определяет тип порта PortType. Атрибут OperationContract определяет методы класса, которые можно вызывать через интерфейс службы. Одновременно он определяет,
какие сообщения можно передать этим методам и получить от них.
Атрибут ServiceContract.
Чтобы интерфейс CLR участвовал в службах, предоставленных WCF, он
должен быть оснащен атрибутом ServiceContract. Подобно многим другим атрибутам .NET, тип ServiceContractAttribute поддерживает набор свойств для дальнейшего прояснения его назначения. Два свойства – Name и NameSpace – могут
быть установлены для управления именем типа службы и именем пространства
имен XML, определяющим тип службы. Если используется привязка, специфичная для веб-служб, эти значения применяются для определения элементов <portType> связанного документа WSDL.
Свойство
CallbackContract
ConfigurationName
ProtectionLevel
SessionMode
Назначение
Устанавливает функциональность обратного вызова для двустороннего обмена сообщениями.
Это имя используется для нахождения элемента службы в
конфигурационном файле приложения. По умолчанию представляет собой имя класса, реализующего службу.
Позволяет указать степень, до которой привязка контракта
требует шифрования, цифровых подписей или того и другого
для конечных точек, представленных контрактом.
Используется для установки разрешения сеанса, запрета сеанса или обязательности сеанса для данного контракта службы.
Таблица 1.1. Назначения свойств атрибута ServiceContract.
11
Атрибут OperationContract.
Методы, которые планируется использовать внутри WCF, должны быть
оснащены атрибутом OperationContract, который также может быть сконфигурирован с помощью различных именованных свойств.
Свойство
Назначение
AsyncPattern
Указывает, реализована ли операция асинхронно с использованием пары методов Begin/End службы. Это позволяет службе передавать обработку другому потоку серверной стороны.
IsInitiating
Указывает, может ли операция быть начальной операцией
сеанса
IsOneWay
Указывает, состоит ли операция только из одного входного
сообщения (без какого-либо ассоциированного вывода)
IsTerminating
Указывает, должна ли исполняющая среда WCF пытаться завершить текущий сеанс после выполнения операции
Таблица 1.2. Назначения свойств атрибута OperationContract.
12
2. РАЗРАБОТКА WCF ПРИЛОЖЕНИЯ
В данной работе предложена реализация сервиса хеширования по различным алгоритмам (MD5, SHA-1, SHA-256, SHA-512) с применением WCF и
Microsoft Visual Studio 2010. Для демонстрации работы механизма передачи событий сервиса на клиент реализовано уведомление клиентов в режиме реального времени об общем числе клиентов, использующих сервис.
2.1. Создание проекта
Создадим библиотеку классов «CryptService», в которой определим саму
службу, консольное приложение «ConsoleHost», которое будем использовать в
качестве хоста, и приложение-клиент Windows Forms «Client».
Рис. 2.1. Создание библиотеки классов CryptService.dll.
13
Рис. 2.2. Добавление консольного приложения ConsoleHost.
Рис. 2.3. Добавление приложения клиента Client.
14
2.2. Создание контракта
Добавим в проект файл IStringCrypt.cs, в котором определим два интерфейса IStringCrypt и IClientCallback, образующие в совокупности контракт будущего
WCF сервиса:
using System.ServiceModel;
namespace CryptService
{
[ServiceContract(SessionMode = SessionMode.Required,
CallbackContract = typeof(IClientCallback))]
public interface IStringCrypt
{
[OperationContract]
string md5(string str);
[OperationContract]
string sha1(string str);
[OperationContract]
string sha256(string str);
[OperationContract]
string sha512(string str);
[OperationContract(IsOneWay = true)]
void join();
[OperationContract(IsOneWay = true)]
void leave();
}
public interface IClientCallback
{
[OperationContract(IsOneWay = true)]
void count(int count);
}
}
Необходимо сообщить WCF, что это наш контракт. Делаем это путем добавления атрибутов (ServiceContract и OperationContract). Кроме того, нужно добавить ссылку на System.ServiceModel.
15
Рис. 2.4. Добавление ссылки на System.ServiceModel.
2.3. Реализация службы
Добавим файл StringCrypt.cs и напишем в нём реализацию созданных ранее
интерфейсов:
using
using
using
using
using
System;
System.Text;
System.Security.Cryptography;
System.ServiceModel;
System.Collections.Generic;
namespace CryptService
{
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class StringCrypt : IStringCrypt
{
public static int count = 0;
private static List<User> users = new List<User>();
private User user;
class User
16
{
public IClientCallback callback;
public User(IClientCallback callback)
{
this.callback = callback;
}
}
public string md5(string str)
{
MD5 md5Hasher = MD5.Create();
byte[] buffer = Encoding.Default.GetBytes(str);
byte[] data = md5Hasher.ComputeHash(buffer);
return bytes2string(data);
}
public string sha1(string str)
{
SHA1 sha1Hasher = SHA1.Create();
byte[] buffer = Encoding.Default.GetBytes(str);
byte[] data = sha1Hasher.ComputeHash(buffer);
return bytes2string(data);
}
public string sha256(string str)
{
SHA256 sha256Hasher = SHA256.Create();
byte[] buffer = Encoding.Default.GetBytes(str);
byte[] data = sha256Hasher.ComputeHash(buffer);
return bytes2string(data);
}
public string sha512(string str)
{
SHA512 sha512Hasher = SHA512.Create();
byte[] buffer = Encoding.Default.GetBytes(str);
byte[] data = sha512Hasher.ComputeHash(buffer);
return bytes2string(data);
}
17
public void join()
{
count++;
IClientCallback callback = OperationContext.Current.
GetCallbackChannel<IClientCallback>();
User u = new User(callback);
users.Add(u);
user = u;
foreach (User x in users)
x.callback.count(count);
}
public void leave()
{
count--;
users.Remove(user);
foreach (User x in users)
x.callback.count(count);
}
private string bytes2string(byte[] data)
{
StringBuilder sBuilder = new StringBuilder();
for (int i = 0; i < data.Length; i++)
sBuilder.Append(data[i].ToString("x2"));
return sBuilder.ToString();
}
}
}
2.4. Приложение службы
Теперь, когда контракт и его реализация полностью написаны, можно переходить к написанию приложения службы (файл Program.cs). В нашем случае это
будет просто консольное приложение, запуск которого запускает службу по адресу http://localhost:8080/.
using System;
18
using
using
using
using
System.Text;
System.ServiceModel;
CryptService;
System.ServiceModel.Description;
namespace ConsoleHost
{
class Program
{
const string URI = "http://localhost:8080/";
static void Main(string[] args)
{
// Тип сервиса
Type serviceType = typeof(StringCrypt);
// URI сервиса
Uri serviceUri = new Uri(URI);
ServiceHost host = new ServiceHost(serviceType, serviceUri);
host.Open();
Console.ForegroundColor = ConsoleColor.Green;
foreach (Uri uri in host.BaseAddresses)
Console.WriteLine(uri.ToString());
Console.ResetColor();
Console.ForegroundColor = ConsoleColor.DarkGray;
Console.Write("Нажмите ENTER, чтобы закрыть хост");
Console.ReadLine();
host.Close();
}
}
}
2.5. Конфигурация службы
Наконец, осталось правильно сконфигурировать наш сервис. Напомню, что
планируется реализация механизма уведомления клиентов. То есть общение клиентов и сервиса должно быть двусторонним, поэтому в качестве типа привязки
возьмём wsDualHttpBinding.
Приведём содержимое файла конфигурации нашего сервиса App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
19
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="wsDualHttpBinding" />
</protocolMapping>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="False" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
Рис. 2.5. Внешний вид приложения для запуска службы.
20
2.6. Получение WSDL сервиса
Теперь можно запустить консольное приложение-хост (в противном случае,
конечные точки будут недоступны) и перейти к URI службы http://localhost:8080/
Вы увидите экран со ссылкой на WSDL сервиса http://localhost:8080/?wsdl.
WSDL (англ. Web Services Description Language) – язык описания вебсервисов и доступа к ним, основанный на языке XML. Каждый документ WSDL
можно разбить на следующие логические части:
1. определение типов данных (types) – определение вида отправляемых и получаемых сервисом XML сообщений;
2. элементы данных (message) – сообщения, используемые сервисом;
3. абстрактные операции – список операций, которые могут быть выполнены
с сообщениями;
4. тип порта (PortType) – именованный набор абстрактных операций и абстрактных сообщений. Оконечная точка службы реализует некий тип порта,
группирующий взаимосвязанные операции.
5. служба определяет набор взаимосвязанных портов;
6. связывание сервисов (binding) – способ, которым сообщение будет доставлено.
Поскольку контракты описываются на языке WSDL, а программа обычно
работает с типами CLR, возникает необходимость отобразить одну систему типов
на другую. В WCF эта задача решается в три этапа. Сначала при написании кода
службы вы снабжаете класс определенными в WCF атрибутами [ServiceContract],
[OperationContract], [FaultContract], [MessageContract] и [DataContract]. Затем при
написании клиентского кода вы запрашиваете у службы детали контракта. Это
делается с помощью Visual Studio или утилиты svcutil.exe, которая вызывает инфраструктурную оконечную точку службы, возвращающую метаданные, необходимые для генерации WSDL документа, получая их от атрибутов. Наконец, на
этапе исполнения, когда клиент вызывает какой-то метод, определенный в интерфейсе службы, WCF сериализует типы CLR и вызов метода в формат XML и посылает сообщение в сеть в соответствии с привязкой и схемой кодирования, согласованным посредством WSDL.
21
2.7. Приложение клиента
Перейдём от написания сервиса к написанию приложения клиента. Сначала
необходимо создать прокси-класс, который будет находиться между нашим клиентом и службой. Один из способов создания прокси-класса – воспользоваться
генератором прокси svcutil.exe. Для этого необходимо ввести в командной строке
Visual Studio следующую команду, находясь в папке расположения «Client»:
> svcutil http://localhost:8080/ /o:ServiceProxy.cs /config:App.Config /n:*,Client
Эта команда сгенерирует два файла: прокси службы и файл конфигурации
приложения, которые необходимо включить в проект.
Когда мы запустили svcutil.exe мы передали ему в качестве первого аргумента место расположения нашей службы, как указано в хосте. Это и есть базовый адрес. Вторым аргументом является прокси. Третий аргумент указывает, что
мы также хотим обновить конфигурацию приложения, а если она не доступна, создать её. Последний аргумент – пространство имён для прокси.
Сам код приложения клиента довольно прост:
using
using
using
using
using
using
using
using
System;
System.Collections.Generic;
System.ComponentModel;
System.Data;
System.Drawing;
System.Text;
System.Windows.Forms;
System.ServiceModel;
namespace Client
{
public partial class
{
const int MD5
const int SHA1
const int SHA256
const int SHA512
ClientForm : Form
=
=
=
=
0;
1;
2;
3;
StringCryptClient client;
22
public class CallbackHandler : IStringCryptCallback
{
ClientForm form;
public CallbackHandler(ClientForm form) {
this.form = form;
}
public void count(int count) {
form.infoLabel.Text = "Общее число клиентов " + count;
}
}
public ClientForm() {
InitializeComponent();
algComboBox.SelectedIndex = MD5;
try {
InstanceContext instanceContext =
new InstanceContext(new CallbackHandler(this));
client = new StringCryptClient(instanceContext);
client.join();
}
catch (Exception e) {
MessageBox.Show(e.Message); return;
}
}
private void hashRefresh()
{
const string defaultText = "";
string str = strTextBox.Text;
if (string.IsNullOrEmpty(str)) {
hashTextBox.Text = defaultText; return;
}
string hash;
try {
switch (algComboBox.SelectedIndex) {
case MD5: hash = client.md5(str); break;
case SHA1: hash = client.sha1(str); break;
23
case SHA256: hash = client.sha256(str); break;
case SHA512: hash = client.sha512(str); break;
default: hashTextBox.Text = defaultText; return;
}
}
catch (Exception e) {
MessageBox.Show(e.Message);
hashTextBox.Text = defaultText;
return;
}
hashTextBox.Text = hash;
}
private void strTextBox_TextChanged(object sender, EventArgs e) {
hashRefresh();
}
private void algComboBox_SelectedIndexChanged
(object sender, EventArgs e) {
hashRefresh();
}
private void ClientForm_FormClosed
(object sender, FormClosedEventArgs e) {
client.leave();
client.Close();
}
}
}
24
Рис. 2.6. Внешний вид приложения WCF клиента.
25
ЗАКЛЮЧЕНИЕ
В данной работе мною были разработаны клиент и сервис Windows
Communication Foundation. Не смотря на то, что создание простых web-служб с
помощью WCF не представляет особого труда, WCF унифицирует модель создания служб и предоставляет программисту одинаковые механизмы по созданию
служб, передающих сообщения в формате SOAP через HTTP, или служб, взаимодействующих по бинарному протоколу. Более того, WCF активно использует все
передовые решения, которые накапливались с 2001 года, когда появилась первая
реализация .NET Framework, а соответственно и web-служб. Так, за последние 5
лет появилось множество концепций и реализаций, решающих различные проблемы, которые возникали при передаче данных, связанных с безопасностью или
протоколами. Теперь все эти реализации были собраны вместе и стали доступны
для программиста максимально удобным способом.
26
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Герберт Шилдт. C# 4.0: полное руководство – М.: «Вильямс», 2010. – 1056 с.
2. Дж. Лёве. Создание служб Windows Communication Foundation. – Спб.: Питер,
2008. – 592 с.: ил.
3. Пабло Сибраро, Курт Клайс, Фабио Коccолино, Йохан Грабнер WCF 4: Windows Communication Foundation и .NET 4 для профессионалов – М.:
«Диалектика», 2011. – 464 с.
4. Слинкина А. А. Основы Windows Communication Foundation для .NET
Framework 3.5: Пер. с англ. – М.: ДМК Пресс, 2008. – 480 с.: ил.
27
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ............................................................................................................ 2
1. АРХИТЕКТУРА ПРИЛОЖЕНИЙ WCF ......................................................... 5
1.1. Основы WCF ............................................................................................... 5
1.2. Конечные точки .......................................................................................... 6
1.3. Контракты ................................................................................................... 7
1.4. Атрибуты................................................................................................... 10
2. РАЗРАБОТКА WCF ПРИЛОЖЕНИЯ........................................................... 12
2.1. Создание проекта ..................................................................................... 12
2.2. Создание контракта.................................................................................. 14
2.3. Реализация службы .................................................................................. 15
2.4. Приложение службы ................................................................................ 17
2.5. Конфигурация службы ............................................................................ 18
2.6. Получение WSDL сервиса....................................................................... 20
2.7. Приложение клиента................................................................................ 21
ЗАКЛЮЧЕНИЕ ................................................................................................... 25
БИБЛИОГРАФИЧЕСКИЙ СПИСОК ............................................................... 26