WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 |

Курс "Обзор перспективных технологий Microsoft.NET"

Лекция 4. Архитектура SOA, вебсервисы, WCF и стандарты WS*

(2 лекции)

Распределенное исполнение

Как всегда, для начала мы обсудим историю и прагматику вопроса. Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна WCF. Мы рассмотрим предшествующие и существующие технологии, и поймем, а есть ли действительно нужда в новой технологии Microsoft, или же мы вполне обошлись бы существующими старыми.

Как уже отмечалось в предыдущих лекциях, кроме лени и стремления программистов к гармонии, развитием технологий в основном движет жажда наживы. J Более политкорректно – стремление к удешевлению разработки.

Каким образом распределенное исполнение может удешевить разработку? Прежде всего, переиспользованием кемто (возможно, вами) написанного кода. Этот код может работать на той же машине, но реалии сегодняшнего дня таковы, что он может быть как в локальной сети, так и на другой стороне земного шара, доступным через интернет. Общая идея такова, что если вам не придется писать чтото, написанное кемто другим, то это хорошо. Пусть даже для этого чужой код придется исполнять через интернет.

Второй, не менее естественной причиной для обоснования необходимости распределенного исполнения является необходимость передавать данные через интернет. Это может быть обмен данными между филиалами вашей компании в рамках одного приложения, может быть интерактивное общение вашего серверного приложения с заокеанским пользователем, а может быть общение с совершенно «левым» сервисом, который нашел ваш сервис с помощью загадочного механизма UDDI или еще более загадочных стандартов WS*.

История распределенного исполнения Итак, какие же вехи в истории распределенного исполнения мы знаем? В первой лекции мы обсуждали COM и DCOM, которые были первыми технологиями Microsoft для распределенного исполнения (DDE не в счет). В отличие от COM, рассчитанного на взаимодействие внутри одной машины, DCOM позволял приложениям общаться по сети, хоть и делать это с помощью этой технологии было весьма непросто. Чем неудобен DCOM? Попробуйте управлять форматом и каналами передачи сообщений Попробуйте трассировать и журналировать вызовы DCOM Попробуйте использовать DCOM в Internet и с разными клиентами Попробуйте быстро поменять конфигурацию приложения, например, используемые порты и каналы У DCOM существовали (существуют) альтернативы, из мира неMicrosoft, среди них можно упомянуть CORBA (Common Object Request Broker Architecture консорциума Open Management Group), RMI (Java Remote Method Invocation от компании Sun Microsystems), EJB и DCE (Distributed Computing Environment, предложенная ассоциацией Open Group). У этих технологий есть свои достоинства и недостатки, которые мы обсуждать не будем.

В мире же Microsoft DCOM, плавно перешедший в COM+ и Enterprise Services, сменила технология Remoting, хорошо знакомая вам по первому релизу Microsoft.NET. Кроме того, что Remoting позволяет общаться между собой приложениям на managed коде (что уже является большим плюсом), он гораздо гибче в настройках каналов и протоколов, в том числе, что важно, в «post deployment», т.е. после развертывания. В стиле.NET это делается с помощью cfgфайлов. По умолчанию Remoting поддерживает http и tcp, и имеет различные форматтеры (упаковщики сообщения в поток) – по умолчанию бинарный и xml.

Недостатком технологии является то, что NET Remoting не стандартизирован, платформенно и вендорнозависим, кроме того, технология требует.NET Framework на клиенте (и, естественно, на сервере). У Remoting есть и другие недостатки, которые будут лучше видны в сравнении этой технологии с технологией вебсервисов, к которым мы с вами плавно и перейдем.

SOA Архитектура, ориентированная на сервисы (SOA), реализацией которой являются вебсервисы, является модной темой уже не менее пяти лет. В последнее время моднее обсуждать AJAX, но SOA пока не совсем сдала позиции. J В рамках этой архитектуры совершенно различные программы (сервисы) могут общаться между собой как на одном компьютере, так и в локальной сети, и даже в среде интернет, несмотря на имманентную гетерогенность последней. Эти сервисы могут быть реализованы на любом языке программирования и работать на любой платформе, что не препятствует возможности их общения, покуда они используют набор стандартизованных открытых механизмов. Такой набор для вебсервисов – это «святая троица» WSDL, SOAP и UDDI, работающие поверх HTTP как транспортного протокола и XML как формата передачи данных.



В основе SOA лежит понятие сервисов, являющихся базовыми элементами для построения бизнесприложений и обеспечения взаимодействия между ними В архитектуре SOA приложение рассматривается как сервис, который можно найти, и далее получить доступ к нему через локальную сеть или интернет Приложение может реализовать некую функцию или набор функций как самостоятельно, так и путем обращения к другим сервисам Сервисы являются автономными, но для того, чтобы их можно было найти и использовать, они снабжены соответствующими интерфейсами Основу SOA составляет взаимодействие трех участников:

Поставщика сервиса Потребителя сервиса Реестра сервисов Где находится нофелет? Вопросы:

Где находится реестр сервисов? Как вы "связываетесь" с этим реестром? Как вы поймете, что некий сервис выполняет то, что вам надо? Как вызвать сервис? Как передавать параметры и принимать возвращаемые значения? Зависит ли формат общения от реализации сервиса? Вашей программы? Используемой ОС? Протоколов передачи данных? Фазы луны? Для реализации SOA необходимы следующие соглашения:

Транспортное соглашение – о форматах и протоколах взаимодействия Соглашение об описании функциональности сервиса в виде, пригодном для автоматической генерации кода, который определяет процесс взаимодействия между клиентом и поставщиком сервиса Соглашение о способе обнаружения сервиса Стандарты вебсервисов (тезисно) Основные стандарты – транспортный, SOAP; описание интерфейса, WSDL; обнаружение сервиса, UDDI.

Simple Object Access Protocol Позволяет обмениваться структурированной информацией Каждое сообщение помещается в «конверт» SOAP – единицу обмена сообщениями:

Web Services Description Language Специфицирует интерфейс вебсервиса:

Форматы сообщений Типы данных Протоколы Точки подключения (endpoints) WSDLфайл – контракт между сторонами Universal Description, Discovery and Integration Опубликование и обнаружение вебсервисов «register once, published everywhere» (напоминает DNS) http://uddi.org http://uddi.microsoft.org Русский uddi http://www.uddirussia.org Регистр: белые, желтые и зеленые страницы. Сервис: discoфайл Альтернатива UDDI/SOAP – протокол ebXML Что такое WSE Web Services Enhancements – addon (class library) к Visual Studio.NET, последняя версия – 3. Поддержка механизмов безопасности, надежной доставки, координации распределенного выполнения для вебсервисов и т.д.

Мы обсудим с вами WS* стандарты, часть из которых поддержана в WSE 3.0 и будет поддержана в WCF, на отдельной лекции.

Предпосылки появления WCF Мы обсудили вкратце предыдущие технологии; в основном, все они всё еще широко применяются в сельском хозяйстве. Так зачем же нужна новая? Чем плохи предыдущие технологии? Вместе с.NET Framework Microsoft предоставляет две конкурирующие технологии распределенного исполнения – Remoting и Webservices. Вообще говоря, сервис Remoting может быть представлен как вебсервис, если его хостом является IIS, и выбраны соответствующие каналы (HTTP) и форматтеры (SOAP). Однако при этом Remoting не подпадает под WS* стандарты, которые жизненно необходимы для реализации нетривиального взаимодействия сервисов. Remoting требует.NET Framework на клиенте. Вебсервисы же плохи тем, что реализуют лишь один способ взаимодействия – через HTTP/SOAP и лишены гибкости Remoting в выборе средств коммуникации. Кроме того, хостом вебсервиса может быть только IIS (или другой вебсервер, поддерживающий ASP.NET).

Кроме отдельных недостатков этих технологий, у них есть как минимум один общий недостаток – то, что их две. Это соображение (а как мы говорили, соображения всеобщей унификации и интеграции являются сейчас очень модными) и привело к созданию единой технологии, объединяющей все лучшее из remoting и вебсервисов, дающей вашим приложениям гибкость в выборе средств общения, оставляя в то же время возможности interoperability, проще говоря – взаимодействию, основанному на открытых стандартах WS*.

Итак, технология WCF – это единый фреймворк и единое API для интероперабельных сервисов.





Составные части WCF Технология Windows Communication Foundation (WCF), ранее носившая кодовое название Indigo, является одной из частей нового API будущих версий Windows. Это API носит название.NET Framework 3.0 (бывший WinFX).

WCF – это модель программирования и среда исполнения для создания, конфигурации и развертывания распределённых сервисориентированных приложений. WCF, аналогично WPF, состоит из фреймворка (рантаймподдержки или среды времени исполнения), и соответствующего API для создания.NET приложения с использованием этой технологии.

Вот основные лозунги Microsoft относящиеся к WCF:

Унификация. WCF – универсальная технология, объединяющая в себе достоинства предыдущих подходов. Работает как на одной машине, так и в сетях – локальных или интернете Ориентация на сервисы. Microsoft постаралась собрать лучшие приемы для создания распределенных решений Интеграция. Возможность взаимодействия с приложениями на других платформах за счет поддержки открытых стандартов WS*.

Действующие лица WCF Здесь и в дальнейшем сервисы, реализованные с помощью WCF, мы будем называть WCFсервисами или, короче, сервисами, чтобы не путать с «обычными» вебсервисами. Под «обычными» вебсервисами мы будем подразумевать ASP.NET вебсервисы в интерпретации Microsoft. Все это не надо путать с сервисами Windows, которые мы так и будем называть.

Итак, основным действующим лицом в WCF является WCFсервис, работающий на сервере. В отличие от вебсервисов, хостом которых мог быть только IIS (и другие ASP.NETсовместимые вебсервера), хостом WCFсервиса может быть любое.NET приложение Windows – Windows Forms, консольное, ASP.NETприложение, сервис Windows. Кроме того, в Vista появляется загадочный хост WAS (Windows Activation Services), который, по утверждению Microsoft, обеспечивает всю функциональность IIS без самого IIS (новый IIS 7 построен поверх WAS).

Другим основным лицом является, само собой, клиент, который может быть как другим WCFсервисом, так и простым приложением, не обязательно работающим в.NET и вообще на Windows. Некоторые возможности, доступные при этом.NETприложениям под WCF, не будут доступны остальным приложениям. Общение между клиентом и сервером происходит посредством сообщений, передаваемых по сети (если они не на одной машине). Не станет сюрпризом, что при этом возможно как синхронное, так и асинхронное взаимодействие.

Для того чтобы определить WCFсервис, нужно создать так называемую «точку доступа» (endpoint). Точка доступа характеризуется тремя параметрами, которые в Microsoft называют «алфавитом» (ABC):

Адрес (Address) – где находится сервис. Адрес представляет из себя обычный URI Связывание (Binding) – каким образом соединяться с сервисом. Аналогично Remoting, Microsoft предоставляет как стандартные реализации для связывания, так и custom binding Контракт (Contract) – интерфейс сервиса и описание типов данных, с которыми он работает. Вспоминаем WSDL. J Создание WCFсервиса Создание WCFсервиса начинается с разметки класса, реализующего требуемую функциональность. Разметка класса специальными атрибутами поможет WCF создать за нас контракт сервиса. Итак, чтобы подсказать WCF, что некоему классу судьбой предназначено стать WCFсервисом, мы используем атрибут ServiceContractAttribute:

[ServiceContract] public class HelloWCF { } Далее нам надо создать метод, реализующий некоторую функциональность будущего endpoint’а. Это мы делаем с помощью атрибута OperationContractAttribute:

[OperationContract] public string GetPreved() { return “Preved, WCF!” } Заметим, что методы класса, у которых атрибут OperationContract отсутствует, «выставляться наружу» не будут. Важно также, что на видимость метода как метода сервиса не влияют атрибуты видимости (типа public/private).

Надо всем над этим надо не забыть написать using System.ServiceModel – главный namespace WCF.

Собственно, теперь у нас есть полная реализация контракта сервиса! Осталось только «захостить» его, выбрав любой один из возможных вариантов хостприложения, которые перечислены выше. Таким образом, нам осталось A и B. Предлагается для начала создать консольное приложение:

static void Main(string[] args) { ServiceHost helloHost = new ServiceHost();

Pages:     || 2 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.