Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс "Обзор перспективных технологий Microsoft. Net"
Скачать 162.45 Kb.
|
Курс «Обзор перспективных технологий Microsoft.NET» Губанов Ю.А., математико-механический факультет СПбГУ Курс "Обзор перспективных технологий Microsoft.NET"Лекция 4. Архитектура SOA, веб-сервисы, WCF и стандарты WS-*(2 лекции) Распределенное исполнениеКак всегда, для начала мы обсудим историю и прагматику вопроса. Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна WCF. Мы рассмотрим предшествующие и существующие технологии, и поймем, а есть ли действительно нужда в новой технологии Microsoft, или же мы вполне обошлись бы существующими старыми. Как уже отмечалось в предыдущих лекциях, кроме лени и стремления программистов к гармонии, развитием технологий в основном движет жажда наживы. Более политкорректно – стремление к удешевлению разработки. Каким образом распределенное исполнение может удешевить разработку? Прежде всего, переиспользованием кем-то (возможно, вами) написанного кода. Этот код может работать на той же машине, но реалии сегодняшнего дня таковы, что он может быть как в локальной сети, так и на другой стороне земного шара, доступным через интернет. Общая идея такова, что если вам не придется писать что-то, написанное кем-то другим, то это хорошо. Пусть даже для этого чужой код придется исполнять через интернет. Второй, не менее естественной причиной для обоснования необходимости распределенного исполнения является необходимость передавать данные через интернет. Это может быть обмен данными между филиалами вашей компании в рамках одного приложения, может быть интерактивное общение вашего серверного приложения с заокеанским пользователем, а может быть общение с совершенно «левым» сервисом, который нашел ваш сервис с помощью загадочного механизма UDDI или еще более загадочных стандартов WS-*. ^ Итак, какие же вехи в истории распределенного исполнения мы знаем? В первой лекции мы обсуждали COM и DCOM, которые были первыми технологиями Microsoft для распределенного исполнения (DDE не в счет). В отличие от COM, рассчитанного на взаимодействие внутри одной машины, DCOM позволял приложениям общаться по сети, хоть и делать это с помощью этой технологии было весьма непросто. Чем неудобен DCOM?
У 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 пока не совсем сдала позиции. В рамках этой архитектуры совершенно различные программы (сервисы) могут общаться между собой как на одном компьютере, так и в локальной сети, и даже в среде интернет, несмотря на имманентную гетерогенность последней. Эти сервисы могут быть реализованы на любом языке программирования и работать на любой платформе, что не препятствует возможности их общения, покуда они используют набор стандартизованных открытых механизмов. Такой набор для веб-сервисов – это «святая троица» WSDL, SOAP и UDDI, работающие поверх HTTP как транспортного протокола и XML как формата передачи данных.
Основу SOA составляет взаимодействие трех участников:
Вопросы:
Для реализации SOA необходимы следующие соглашения:
Основные стандарты – транспортный, SOAP; описание интерфейса, WSDL; обнаружение сервиса, UDDI. Simple Object Access Protocol
Web Services Description Language
Universal Description, Discovery and Integration
Что такое WSE
Мы обсудим с вами WS-* стандарты, часть из которых поддержана в WSE 3.0 и будет поддержана в WCF, на отдельной лекции. ^ Мы обсудили вкратце предыдущие технологии; в основном, все они всё еще широко применяются в сельском хозяйстве. Так зачем же нужна новая? Чем плохи предыдущие технологии? Вместе с .NET Framework Microsoft предоставляет две конкурирующие технологии распределенного исполнения – Remoting и Web-services. Вообще говоря, сервис Remoting может быть представлен как веб-сервис, если его хостом является IIS, и выбраны соответствующие каналы (HTTP) и форматтеры (SOAP). Однако при этом Remoting не подпадает под WS-* стандарты, которые жизненно необходимы для реализации нетривиального взаимодействия сервисов. Remoting требует .NET Framework на клиенте. Веб-сервисы же плохи тем, что реализуют лишь один способ взаимодействия – через HTTP/SOAP и лишены гибкости Remoting в выборе средств коммуникации. Кроме того, хостом веб-сервиса может быть только IIS (или другой веб-сервер, поддерживающий ASP.NET). Кроме отдельных недостатков этих технологий, у них есть как минимум один общий недостаток – то, что их две. Это соображение (а как мы говорили, соображения всеобщей унификации и интеграции являются сейчас очень модными) и привело к созданию единой технологии, объединяющей все лучшее из remoting и веб-сервисов, дающей вашим приложениям гибкость в выборе средств общения, оставляя в то же время возможности interoperability, проще говоря – взаимодействию, основанному на открытых стандартах WS-*. Итак, технология WCF – это единый фреймворк и единое API для интероперабельных сервисов. ^ Технология Windows Communication Foundation (WCF), ранее носившая кодовое название Indigo, является одной из частей нового API будущих версий Windows. Это API носит название .NET Framework 3.0 (бывший WinFX). WCF – это модель программирования и среда исполнения для создания, конфигурации и развертывания распределённых сервис-ориентированных приложений. WCF, аналогично WPF, состоит из фреймворка (рантайм-поддержки или среды времени исполнения), и соответствующего API для создания .NET приложения с использованием этой технологии. Вот основные лозунги Microsoft относящиеся к 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-сервис, нужно создать так называемую «точку доступа» (end-point). Точка доступа характеризуется тремя параметрами, которые в Microsoft называют «алфавитом» (ABC):
Создание 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.AddEndpoint( typeof(HelloWCF), // стандартное связывание, поддерживающее Basic Profile, // который мы обсудим на лекции про WS-* стандарты. // Используйте это связывание для соединения по HTTP // протоколу с использованием SOAP new BasicProfileBinding(), “http://localhost:8080/prevedService”); // Запускаем прослушивание helloHost.Open(); // Выводим подсказку и останавливаем основной поток Console.WriteLine("ПРЕВЕД, нажми Enter, чтобы МЕДВЕД"); Console.ReadLine(); // Так надо helloHost.Close(); } Все, сервис готов! Компилятор, пользуясь нашими любезно предоставленными атрибутами, не менее любезно сгенерирует нам wsdl, который мы, аналогично wsdl веб-сервиса, уже можем потестировать через браузер без написания клиента сервиса. Как всегда, для этого надо набрать Uri сервиса с параметром wsdl: http://localhost:8080/?wsdl. Кроме того, аналогично веб-сервисам, с помощью специальной утилиты (svcutil.exe) можно сгенерировать прокси для работы с WCF-сервисом и все используемые в этой работе типы. После того, как svcutil сгенерирует прокси-классы для работы с сервисом, создание клиента – дело двух строчек: HelloWCFProxy prevedProxy = new HelloWCFProxy( new EndpointAddress(http://localhost:8080/prevedService), new BasicProfileBinding() ); MessageBox.Show(prevedProxy.GetPreved()); prevedProxy.Close(); Наконец, отметим, что вы можете добавлять сколько угодно endpoints к вашему сервису (в отличие от веб-сервисов, где был только один аналог endpoint’а) – с разными Uri, связыванием и контрактами. ^ В примере выше мы указали параметры для создания endpoint’а и для соединения клиента с сервисом в самом коде. В духе Remoting мы можем аналогичным образом сконфигурировать наш сервис декларативным способом с помощью конфигурационных файлов (собственно, второй способ предпочтительней). Для этого надо заполнить секцию system.serviceModel в файле конфигурации приложения сервиса (прямой сын тэга bindingSectionName=”basicPrevedBinding” contractType=”HelloWCF”/> Как видите, мы задали все три части endpoint’а. По счастливому совпадению, класс, реализующий контракт, совпал с типом контракта, но это необязательно так всегда. Класс, реализующий контракт, может наследоваться от интерфейса, который помечен соответствующим атрибутом. Не забывайте также, что у сервиса может быть много endpoint’ов, соответственно, в этом случае без интерфейсов не обойтись. Несложно проверить в этом месте, не спит ли аудитория. Если она заметила связывание типа basicPrevedBinding, то с некоторой долей вероятности нет. Аналогично конфигурируется и клиент: bindingSectionName=”basicPrevedBinding” contractType=”HelloWCF”/> В обоих случаях (сервиса и клиента) указание их данных в конфигурационным файлах позволяет вам не писать эти данные в коде. Наверное, не стоит и обсуждать, насколько это удобно – уметь менять такие свойства после развертывания приложения, т.к. эти вопросы уже обсуждались с аудиторией на предыдущих курсах. Заметьте, что, в отличие от контрактов, endpoint’ы не описываются с помощью атрибутов – только в коде или в конфигурационном файле. ^ Прекрасно, мы уже умеем писать простые приложения с помощью WCF. В нашем сервисе единственный метод не принимал никаких параметров, и возвращал простой тип. Однако создатели более сложных сервисов обязательно столкнутся с ситуацией, когда требуется передать класс или структуру. Такие сложные типы надо описывать специальным образом с помощью атрибутов DataContract и DataMember: [DataContract] class Medved { [DataMember] public string WomanName; [DataMember] private string ManName; public string MedvedName; private DateTime MeetingTime; } При передаче такого класса с помощью сервиса передадутся только те поля, которые помечены атрибутом DataMember. Заметьте, что видимость членов не имеет значения (private поле ManName будет сериализовано наравне с WomanName). Поля же, не помеченные как DataMember, не передадутся опять-таки вне зависимости от видимости. Особо стоит подчеркнуть, что ни контракты сервисов, ни контракты данных не возникают ни в каких ситуациях автоматически, по умолчанию. Программист должен самостоятельно пометить все необходимые сущности, участвующие во взаимодействии. Это находится в согласии с принципом, гласящим, что сервисы должны иметь явные границы, когда должно быть понятно, где мы работаем с локальным объектом, а где – с объектом извне нашего домена приложения. ^ Связывание (binding) – одна из частей святой троицы ABC – определяет то, каким образом вы можете достучаться до endpoint’а: какой использовать транспортный протокол (HTTP, TCP, прочие) и каким образом происходит обмен сообщениями (обычный или бинарный SOAP, поддержка WS-*). WCF предлагает программисту набор стандартных байндингов:
Вкратце опишем другие возможности WCF-сервисов:
[OperationContract(IsOneWay = true)] void helloWCF();
[ServiceContract(CallbackContract = typeof(IHelloWCF)]
Если вы программировали веб-сервисы, WCF-сервисы во многом будут вам знакомы. Но, несмотря на их похожесть, есть и некоторые различия:
Текущая и будущая поддержка WCFWCF войдет в будущую операционную систему Microsoft – Windows Vista, но по многочисленным просьбам телезрителей WCF был также поддержан на Windows XP SP2 и Windows 2003. То же самое касается и WPF (ex-Avalon). Уже сейчас (на момент создания курса, лето 2006 года) можно скачать и посмотреть упомянутые технологии в их предварительных версиях на существующих версиях Windows (XP и 2003) и на бета-версии Vista. ^ Какими критериями надо пользоваться, чтобы выбрать правильную технологию для реализации пользовательского интерфейса в вашем приложении? Какие технологии надо рассматривать и как сделать выбор?
Ссылкиhttp://blogs.msdn.com/richardt/archive/2004/03/05/84771.aspx – Remoting не исчезнет http://www.topxml.com/WSCF-WCF/re-4947_Serialization-vs--Encoding.aspx – Сериализация и encoding http://en.wikipedia.org/wiki/Windows_Communication_Foundation – Википедия про WCF http://windowscommunication.net/Default.aspx?tabindex=0&tabid=1 – Собственно, от автора (полезный раздел «самплы») http://msdn.microsoft.com/winfx/technologies/communication/default.aspx – MSDN про WCF http://msdn.microsoft.com/windowsvista/support/faqs/communication/default.aspx – FAQ про WCF http://blogs.msdn.com/drnick/default.aspx – блог одного из создателей WCF http://staff.newtelligence.net/clemensv/PermaLink,guid,5df62c43-67fb-488e-a70e-c29b9055a984.aspx, http://staff.newtelligence.net/clemensv/PermaLink,guid,b2d3cfa1-f3c3-4aed-8ec7-503fe5c21f51.aspx и http://staff.newtelligence.net/clemensv/PermaLink,guid,41d6ef20-e3e1-4277-bd3e-2cf414d209bd.aspx – блог с интересными техническими деталями реализации сервисов WCF http://mtaulty.com/blog/(bdneuwaxcrmiowrztkaxxeud)/default.aspx – еще один блог с интересностями о WCF (например, http://mtaulty.com/blog/(yyz4yxqla3jvur551ut2tkiu)/archive/2005/04/04/1761.aspx)          |
Добавить документ в свой блог или на сайт
Похожие:
 | Итак, на прошлой лекции мы упомянули то, что не все концепции окружающего мира хорошо укладываются в объектно-ориентированное представление.... | | «На сегодня о технологии ajax (Asynchronous JavaScript and xml) широкие массы пользователей интернета знают немного. Пока эта технология... |
| Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна wcf. Мы рассмотрим предшествующие и существующие... | | Надо сказать, задолго до появления Turbo Vision уже были и графические интерфейсы (Mac) со своим инструментарием. Turbo Vision же... |
| Поэтому, продвигая платформу. Net, компания Microsoft предлагает также инструментарий для программистов — Visual Studio. Net и систему... | | Курс «Технологии Windows Communication Foundation и Windows Presentation Foundation» |
| В качестве целевой платформы для компиляторов в данном курсе используется Microsoft. Net. Подразумевается, что к моменту окончания... | | Поскольку Microsoft должна реагировать на изменяющиеся рыночные условия, ее не следует интерпретировать как обязательство со стороны... |
| Поскольку компания Microsoft должна отвечать на изменение рыночных условий, этот документ не должен интерпретироваться как обязательство... | | Дан краткий обзор процессов разработки и шаблонов проектирования. Кратко описаны варианты построения уровня пользовательского интерфейса,... |