WWW.DISSERS.RU

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

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


Pages:     || 2 | 3 |

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

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

(2 лекции)

SOA

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

На прошлой лекции мы обсуждали вебсервисы и их основные стандарты: HTTP, XML, WSDL, SOAP и UDDI. Это прекрасные стандарты, которые приняты всем миром, и которые работают. Вернее сказать, они прекрасны именно тем, что работают, а в остальном они (особенно последний) имеют и некоторые недостатки. Но, несмотря на недостатки, именно этот способ взаимодействия является последним словом в нелегкой науке создания интероперабельных приложений, работающих в сети.

Однако, для серьезных задач, для организации нетривиального взаимодействия вебсервисов, только WSDL/SOAP/UDDI недостаточно. Почему, как с этим справиться, и, причем тут WCF, мы и обсудим на этой лекции.

Принципы SOA В основе архитектуры, ориентированной на сервисы, лежат следующие принципы:

SOA является распределенной строится с использованием слабосвязанных интерфейсов базируется на общепринятых отраслевых стандартах (таких как XML, HTTP, WSDL, SOAP и UDDI) проектируется с ориентацией на процессы (processcentric) с использованием сервисов, каждый из которых ориентирован на решение отдельных задач (taskcentric) При этом стоит подчеркнуть отличия SOA от ООподхода:

Разделение схемы, а не класса. В SOA клиенты общаются с сервисами только через стандартный XMLинтерфейс Сервисы автономны. Сервисы гарантируют контракт, но в остальном сервисы и клиенты независимы. Они могут быть написаны на разных языках, работать на разных платформах (CLR или JVM, Windows или Linux) и различаться прочими деталями Границы задаются явно, в отличие от предыдущих технологиях (таких как DCOM), где главной целью было скрыть различие локальных и удаленных объектов. В качестве комментария к этому пункту предлагается вспомнить атрибуты контракта WCFсервиса – мы явно помечаем, что и как должно передаваться. В WCF ничего не становится элементом контракта сервиса или контракта данных по умолчанию.

Почему недостаточно святой троицы Почему же недостаточно просто WSDL/SOAP/UDDI? Ответ прост: попробуйте, скажем, сделать сервис, который, общаясь с другим сервисом, шифрует сообщения. Зашифроватьто вы его зашифруете, а как другие сервисы поймут, какой алгоритм использовать для дешифрации? Конечно, можно использовать самый распространенный алгоритм шифрации (DES), но, к сожалению, этот алгоритм официально рекомендуется не использовать ввиду слабой защищенности. Поэтому вашему и другим сервисам надо договориться: кто какой вид шифрации понимает, и каков наилучший алгоритм, поддерживаемый вашим и конкретным другим сервисом. Как это сделать, если вы заранее не представляете, какие сервисы будут к вам обращаться? Никак. Собственно, этим вопросом и занимается один из WS* стандартов под названием WSSecurityPolicy.

Понятно, что таких инфраструктурных проблем при создании вебсервисов возникает большое количество – все то, что давно решено в пределах одного компьютера, теперь надо перенести в гетерогенную среду интернета.

WS* Итак, WSстандарты. Эти стандарты изначально не были стандартами, а были спецификациями. Придумала эти спецификации организация под названием «Webservices interoperability organization» (WSI, http://wsi.org), организация, в которую входят ведущие игроки мирового ITрынка, такие как Microsoft, HewlettPackard, IBM, BEA Systems, Oracle, Sun Microsystems и прочие. По ходу выработки консенсуса между этими компаниями (что не всегда просто, т.к. интересы их весьма различны) эти спецификации потихоньку стандартизуются (через такие организации как OASIS) и становятся открытыми всеобщими стандартами.

На данный момент WSспецификаций больше 50, часть из них стандартизована, часть еще только разрабатывается. Многие из разрабатываемых (и обсуждаемых на этой лекции) спецификаций защищены авторскими правами, поэтому в каждом конкретном случае надо смотреть на статус документа и условия лицензирования. Зачастую в одной и той же области действия спецификации существуют несовместимые конкурирующие стандарты (зачастую это противостояние компаний вокруг Microsoft и компаний вокруг Sun Microsystems) WS* и WCF Было бы крайне утомительно рассматривать все стандарты WS*, к тому же одной лекции на это явно недостаточно. Поэтому мы рассмотрим в той или иной степени подробности только те стандарты, которые поддержаны в WCF:



WSBasicProfile WSReliableMessaging и WSRM Policy WSAddressing WSSecurity WSPolicy и WSPolicyAttachments WSMetadataExchange WSTrust WSSecureConversation WSCoordination WSTransaction WSAtomicTransaction SOAP Message Transmission Optimization Mechanism (MTOM).

Текущая поддержка WS* Пока мы не перешли непосредственно к рассмотрению стандартов, обсудим текущую их поддержку. В самом деле, WCF еще не вышла, а интероперабельные вебсервисы с нетривиальной логикой взаимодействия хочется писать уже сейчас. Конечно же, реализовывать эти стандарты руками, формируя пакеты SOAP самостоятельно (что теоретически и практически возможно), дело неблагодарное и не всегда стоящее. Разные вендоры предлагают свои решения этой проблемы. Так, Microsoft предлагает аддон к Visual Studio под названием WebServices Enhancements, последняя версия имеет номер 3.0 (http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx?pull=/library/enus/dnwse/html/newwse3.asp). IBM разработала продукт ETTKWS (Emerging Technologies Toolkit for WebServices, http://www.alphaworks.ibm.com/tech/ettkws). Эти продукты поддерживают некое подмножество WSстандартов и облегчают разработчику создание вебсервисов, выполняя за него некоторую работу по реализации вебсервиса с этими стандартами.

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

Текущая версия этого стандарта – WSBasicProfile 1.1 – включает в себя:

SOAP 1. XML 1.0 Second EditionML 1.0 second edition HTTP/1. WSDL 1. UDDI Version 2 XML Schema UDDI Version 2.04 API Specificaion UDDI Version 2.03 Data Structure В данный момент ведется работа над версиями 1.2 и 2.0, которые будут включать в себя расширенный набор WSспецификаций (в частности WSAddressing и MTOM).

WSReliableMessaging Основная цель этого стандарта – создать механизм для надежной доставки сообщений, что не гарантируется используемым вебсервисами протоколом HTTP. WSReliableMessaging («надежный обмен сообщениями») определяет протокол сообщений, предназначенный для идентификации, отслеживания и управления доставкой сообщений между сервисом и клиентами. WSReliableMessaging предоставляет гибкую схему подтверждения, с помощью которой получатель может описать ряд сообщений, которые были или не были доставлены. Кроме того, эта технология поддерживает эффективный механизм упорядочивания, который гарантирует, что адресат получает сообщения точно в том порядке, в котором они были отосланы, даже в случае многоканальной пересылки или изменения порядка вследствие повторения отправки.

Итак, WSReliableMessaging обеспечивает независимое от транспортного протокола качество обслуживания (quality of service) – сообщения получаются ровно один раз и в том порядке, в котором были посланы.

Для того чтобы ваш WCFсервис поддерживал надеждую доставку сообщений, вы должны использовать связывание WsHttpBinding.

У WSReliableMessaging есть конкурирующий стандарт WSReliability, который является свободно используемым.

WSAddressing WSAddresing – спецификациянаследник WSRouting. Этот стандарт описывает механизм адресации сообщения в зависимости от его содержания, но вне зависимости от транспортного протокола. Зачем это надо? Предположим, вам нужно с помощью вебсервиса отправить сообщение, какимлибо образом защитив его от чужих глаз. На данный момент у нас есть такие транспортные механизмы, как, например. SSL. Однако, этот способ годится, если ваш сервис общаетесь с клиентом напрямую. Если же по пути сообщения от сервиса к клиенту возникают дополнительные пункты назначения, задача усложняется. Каждый дополнительный пункт назначения должен открыть новое SSLсоединение со всеми неотъемлемыми накладными расходами на кодирование.





С помощью WSAddressing можно обеспечить так называемую “endtoend” безопасность общения. Используя WSAddressing можно кодировать только чувствительные части сообщения, а не все сообщение, так что промежуточные пункты могут просматривать остальные, открытые части сообщения, и на их основе решать, куда дальше отправить сообщение, а также осуществлять какието дополнительные действия както: протоколирование/логгирование информации, добавление своих заголовков и т.п. WSAddressing при этом не полагается на транспортные протоколы (такие как SSL) и может работать с разными протоколами.

WSSecurity WSSecurity – самый большой из стандартов WS*. Это даже не один стандарт, а целый набор стандартов, каждый из которых отвечает за отдельный аспект безопасности:

WSTrust WSSecurityPolicy WSPolicy WSSecureConversation WSAuthorization WSFederation WSPrivacy WSSecurity описывает основные механизмы для достижения целостности (когда получатель может быть уверен, что принятые им данные не изменялись при передаче) и конфиденциальности, гарантирующей защиту передаваемой информации от несанкционированного прочтения. Он также определяет порядок отправки маркеров защиты, например комбинации имени пользователя и пароля, билета Kerberos или сертификата X.509. Более специализированные стандарты наподобие WSTrust уточняют основной стандарт. Как и в случае с Basic Profile, существует Basic Security Profile, который объединяет в себе несколько стандартов в качестве базового набора.

Спецификация Basic Security Profile довольно небольшая, т.к. опирается на существующие стандарты криптографии: так, скажем, для подписывания сообщения ключом используется стандарт W3C, называемый XML Signature. Подписанные таким образом сообщения имеют в заголовке тег Signature, описывающий, в частности, алгоритм шифрации и само значение подписи.

WSSecurity предлагает потрясающе гибкий подход к передаче и проверке идентификаторов, который, однако, накладывает одно важное ограничение: две системы, отвечающие требованиям WSSecurity, могут оказаться неспособными аутентифицировать друг друга. Так, одна система может поддерживать только Kerberos, другая — только аутентификацию с цифровой подписью на основе сертификатов X.509. Соответствия спецификации WSSecurity недостаточно — необходимо прийти и к соглашению по поводу использования конкретных типов маркеров защиты.

Как это реализовано Любое SOAPсообщение может быть дополнено необязательной частью – заголовками. Элементы заголовка передают информацию, которая является частью протокола инфраструктуры. Заголовки SOAP строго типизированы и роль каждого из них определена именем его элемента, определяемым пространством имен. Заголовки могут быть обязательными и не обязательными, обязательность определяется с помощью атрибута soap:mustUnderstand.

Информация, которая описывает поддержанные вебсервисом стандарты содержится в заголовке SOAPконверта. Например, для WSSecurity это может выглядеть так:

...

...

...

...

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

Теги наподобие могут включать параметр mustUnderstand. Если этот параметр равен "true" то получатель должен сгенерировать ошибку SOAP, если он не не поддерживает данную спецификацию (в нашем случае WSSecurity). «Поддерживает» значит то, что получатель может интерпретировать соответствующую xmlсхему и следовать требованиям к обработке правил, которые описаны в соответствующей спецификации.

WSPolicy и WSSecurityPolicy Как же взаимодействующим сторонам «договориться» об используемой политике безопасности? Для этого служит спецификация WSSecurityPolicy. Пользуясь этой спецификацией, ваш сервис указывает, какие механизмы безопасности он поддерживает, и, если есть предпочтения, какой из этих механизмов он использовал бы в первую очередь.

WS SecurityPolicy не специфицирует, КАК ваш сервис должен реализовывать безопасность, он только позволяет вашему сервису и его клиентам договориться об использовании механизмов безопасности, понятных обеим сторонам.

Pages:     || 2 | 3 |










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

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