Национальный исследовательский институт

Московский Энергетический Институт (Технический Университет)

Институт автоматики и вычислительной техники

Кафедра Прикладной математики

Лабораторная работа №1

по дисциплине:

Проектирование крупных распределенных программных систем и баз данных

тема: «Разработка сервиса с применением WCF »

Выполнил:

Бочаров Иван Андреевич

Проверил:

к.т.н., доц. Куриленко Иван Евгеньевич

Москва

2012 г.

Подготовка к выполнению работы

WCF (Windows Communication Foundation)

WCF - программный фреймворк, используемый для обмена данными между приложениями входящими в состав .NET Framework. До своего выпуска в декабре 2006 года в составе .NET Framework 3.0, WCF был известен под кодовым именем Indigo.

WCF делает возможным построение безопасных и надёжных транзакционных систем через упрощённую унифицированную программную модель межплатформенного взаимодействия. Комбинируя функциональность существующих технологий .NET по разработке распределённых приложений (ASP.NET XML Web Services — ASMX, WSE 3.0, .NET Remoting, .NET Enterprise Services и System.Messaging), WCF предоставляет единую инфраструктуру разработки, при умелом применении повышающую производительность и снижающую затраты на создание безопасных, надёжных и транзакционных Web-служб нового поколения. Заложенные в неё принципы интероперабельности позволяют организовать работу с другими платформами, для чего используются технологии взаимодействия платформ, разрабатываемые на базе открытого исходного кода.

Возможность взаимодействия и интеграция различных API-интерфейсов — это только два важных аспекта WCF. В дополнение WCF предлагает развитую фабрику программного обеспечения, которая дополняет технологии удаленной разработки, представленные WCF.

Команда разработчиков WCF пользовалась четырьмя принципами проектирования SOA. Хотя данные принципы реализуются автоматически, просто при построении приложения WCF. понимание этих четырех кардинальных правил дизайна SOA может помочь применять WCF в дальнейшей перспективе.

Принцип 1: границы установлены явно. Этот принцип подчеркивает тот факт, что функциональность службы WCF выражается через четко определенные интерфейсы (т.е. описания каждого члена, его параметров и возвращаемых значений). Единственный способ, которым внешний клиент может связаться со службой WCF, — через интерфейс, при этом оставаясь в блаженном неведении о деталях ее внутренней реализации.

Принцип 2: службы автономны. Говоря о службах, как об автономных сущностях, имеется в виду тот факт, что каждая служба WCF является (насколько возможно) отдельным "островом". Автономная служба должна быть независимой от проблем с версиями, развертыванием и установкой. Чтобы помочь в продвижении этого принципа, мы опять возвращаемся к ключевому аспекту программирования на основе интерфейсов. Как только интерфейс внедрен, он никогда не должен изменяться (или вы рискуете разрушить существующие клиенты). Когда требуется расширить функциональность службы WCF, просто напишите новый интерфейс, который моделирует необходимую функциональность.

Принцип 3: службы взаимодействуют через контракт, а не реализацию. Третий принцип — еще один побочный продукт программирования на основе интерфейсов — состоит в том, что реализация деталей службы WCF (на каком языке она написана, как именно выполняет свою работу, и т.п.) не касается вызывающего ее внешнего клиента. Клиенты WCF взаимодействуют со службами исключительно через их открытые интерфейсы. Более того, если члены службы представляют сложные специальные типы, они должны быть полностью детализированы в виде контракта данных, гарантируя, что клиенты смогут отобразить содержимое на определенную структуру данных.

Принцип 4: совместимость служб базируется на политике. Поскольку интерфейсы CLR предоставляют строго типизированные контракты всем клиентам WCF (и также могут быть использованы для генерации соответствующего документа WSDL на основе выбранной привязки), важно понимать на то, что интерфейсы и WSDL сами по себе недостаточно выразительны, чтобы детализировать аспекты того, что способна делать служба. Учитывая это, SOA позволяет определять политики, которые еще более проясняют семантику службы (например, ожидаемые требования безопасности, применяемые для общения со службой). Используя эти политики, можно отделять низкоуровневые синтаксические описания службы (предоставляемые интерфейсы) от семантических деталей их работы и способов их вызова.

Базовая композиция приложения WCF

При построении распределенной системы WCF обычно создаются три взаимосвязанных сборки.

• Сборка службы WCF. Эта библиотека *.dll содержит классы и интерфейсы, представляющие обитую функциональность, которая предлагается внешним клиентам.

• Хост службы WCF. Этот программный модуль — сущность, которая принимает в себе сборку службы WCF.

• Клиент WCF. Это приложение, которое обращается к функциональности службы через промежуточный прокси.

Хосты и клиенты взаимодействуют друг с другом, согласовывая так называемые ABC — условное наименование для запоминания основных строительных блоков приложения WCF, таких как адрес, привязка и контракт (address, binding, contract — ABC).

• Адрес. Описывает местоположение службы. В коде представлен типом System.Uri, однако значение обычно хранится в файлах *.сonfig.

• Привязка. WCF поставляется с множеством различных привязок, которые указывают сетевые протоколы, механизмы кодирования и транспортный уровень.

• Контракт. Предоставляет описание каждого метода, представленного службой WCF.

Понятие контракта является ключевым при построении службы WCF Хотя это и не обязательно, подавляющее большинство приложений WCF будут начинаться с определения типов интерфейсов .NET, используемых для представления набора членов, которые поддерживаются данной службой WCF. В частности, интерфейсы, которые представляют контракт WCF, называются контрактами служб. Классы (или структуры), которые реализуют их, носят название типов служб.

Контракты служб WCF оснащаются различными атрибутами, наиболее часто используемые из которых определены в пространстве имен System.ServiceModel. Когда члены контракта службы (методы в интерфейсе) содержат только простые типы данных (такие как числовые, булевские и строковые), полную службу WCF можно построить, используя одни только атрибуты [ServiceContract] и [OperationContract].

Как только контракт (или набор контрактов) определен и реализован внутри библиотеки службы, следующий логический шаг состоит в построении агента хостинга для самой службы WCF. Как уже упоминалось, на выбор доступно множество возможных вариантов хостов, и все они должны указывать привязки, используемые удаленными клиентами для получения доступа к функциональности типа службы. Выбор из набора привязок — это область, которая отличает разработку WCF от .NET Remoting и/или разработки веб-служб XML. На выбор в WCF доступно множество возможных привязок, каждая из которых ориентирована на определенные потребности. Если ни одна из готовых привязок не удовлетворяет существующим требованиям, можно создать собственную привязку, расширив тип CustomBinding (это в главе делаться не будет). Привязка WCF может описывать следующие характеристики:

• транспортный уровень, используемый для передачи данных (HTTP, MSMQ, именованные каналы и TCP);

• каналы, используемые транспортом (однонаправленные, запрос-ответ и дуплексные);

• механизм кодирования, используемый для работы с данными (XML и двоичный);

• любые поддерживаемые протоколы веб-служб (если разрешены привязкой), такие как WS-Security, WS-Transactions, WS-Reliability и т.д.

Как только контракты и привязки установлены, финальный элемент мозаики состоит в указании адреса для службы WCF. Это важно, поскольку удаленные клиенты не смогут взаимодействовать с удаленными типами, если им не удастся найти их. Подобно большинству аспектов WCF, адрес может быть жестко закодирован в сборке (с использованием типа System.Uri) или вынесен в файл *.config.

В любом случае точный формат адреса WCF отличается в зависимости от выбранной привязки (на основе HTTP, именованных каналов, TCP или MSMQ). На самом высоком уровне адреса WCF могут указывать перечисленные ниже единицы информации.

• Scheme. Транспортный протокол (HTTP и т.п.).

• MachineName. Полностью квалифицированное доменное имя машины.

• Port. Во многих случаях не обязательный параметр. Например, привязка HTTP по умолчанию использует порт 80.

• Path. Путь к службе WCF

Эта информация может быть представлена следующим обобщенным шаблоном (значение Port необязательно, поскольку некоторые привязки его не используют):

Scheme : // [ : Port] /Path

Атрибут [ServiceContract]

Чтобы интерфейс CLR участвовал в службах, предоставленных WCF, он должен быть оснащен атрибутом [ServiceContract]. Подобно многим другим атрибутам .NET, тип ServiceContractAttribute поддерживает набор свойств для дальнейшего прояснения его назначения. Два свойства — Name и NameSpace — могут быть установлены для управления именем типа службы и именем пространства имен XML, определяющим тип службы. Если используется привязка, специфичная для веб-служб, эти значения применяются для определения элементов связанного документа WSDL.

Атрибут [OperationContract]

Методы, которые планируется использовать внутри WCF, должны быть оснащены атрибутом [OperationContract], который также может быть сконфигурирован с помощью различных именованных свойств.

Конечные точки

В мире WCF термин конечная точка (endpoint) представляет адрес, привязку и контракт, объединенные вместе в один пакет. В XML конечная точка выражается элементом и элементами address, binding и contract.

Каждая конечная точка состоит из следующего.

• Адрес: адрес однозначно определяет конечную точку и указывает потенциальным потребителям на место расположения службы. В объектной модели WCF адрес представлен классом EndpointAddress. Класс EndpointAddress содержит следующее.

  • Свойство Uri, представляющее адрес службы.

  • Свойство Identity, представляющее удостоверение безопасности службы и коллекцию необязательных заголовков сообщений. Необязательные заголовки сообщений используются для вывода дополнительной и более подробной информации, необходимой для идентификации конечной точки или взаимодействия с ней.

• Привязка. Привязка задает способ связи клиента с конечной точкой. В том числе следующее:

  • используемый транспортный протокол (например, TCP или HTTP);

  • используемую в сообщениях кодировку (например, текст или двоичное кодирование);

  • необходимые требования безопасности (например, безопасность сообщений SSL или SOAP).

• Привязка в объектной модели WCF представлена абстрактным базовым классом Binding. В большинстве сценариев пользователи могут использовать только одну из предусмотренных системой привязок. Дополнительные сведения см. в разделе Привязки, предоставляемые системой.

• Контракты. Контракты показывают, какие функциональные возможности дает клиенту конечная точка. В контракте задается следующее:

  • операции, которые могут быть вызваны клиентом;

  • форма сообщения;

  • тип входных параметров или данных, требуемых для вызова операции;

  • тип обработки или ответного сообщения, который может ожидать клиент.

• Поведения. Поведения конечной точки можно использовать для настройки локального поведения конечной точки службы. Поведения конечной точки выполняют это путем участия в процессе создания среды выполнения WCF. Примером поведения является свойство ListenUri, позволяющее указывать отличный от адреса SOAP или WSDL адрес прослушивания.

Пример конфигурационного файла приведен ниже.

Выполнение лабораторной работы

Реализация сервиса

IFibonacchiDuplex.cs

using System;

using System.Collections.Generic;