Введение в WCF 4.0. SOA

Сегодня я сдал экзамен 73-569. Тут то я и понял что с технологией WCF у меня серъезный прокол:)

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

Итак, для того чтобы понять что такое WCF , для начала надо понять для каких целей это можно использовать. Основные места использования WCF:

В первую очередь это конечно же  SOA — Service Oriented Architecture — это архитектурный подход в котором программа состоит из едениц с заданным поведением которые называются сервисами.

Сервисы — это такие черные ящички, в которых для пользователя происходит магия — чтобы использовать сервисы, клиенту необходимо знать только название самого сервиса, навзвание метода, параметры которые необходимо передать методу и формат данных который вернет данный метод. Больше нету никаких зависимостей между потребителем сервисов и собственно сервисами.  К тому же этот подход позволяет иметь ситуацию где не обязательное использование одного языка программирования для клиента и сервиса. Допустим у Вас может быть ситуация когда клиент написан на Java, а сервисы на .Net. Все это безобразие возможно с использованием ещё одного прекрасной вещи — SOAP. SOAP — это всего лишь XML язык который описывает структуру сообщения для обмена между сервисами и клиентами. Сообщение которое посылается от клиента к сервису, или же ответ сервиса клиенту называется SOAP пакет. В данном пакете описывается какой метод дернуть, какие типы и значение передать сервису, и что ответить клиенту. Ещё одна радость в том — что SOAP есть в любой платформе разработки, потому Вы можете быть увернным что сервис написанный Вами может быть легко использован системами которые написанны на разныех языках программирования.

 

Ещё одно из чудес использования этого подхода — разделение интересов. Представте что Вы пишете крупную систему состоящую из 10 — 15 сервисов. Вы можете разделить работу так, что одна комманда программистов будет писать одни сервисы, а другая другие. И что самое главное — никто не будет никому мешать:) К тому же Вы можете разделить комманды таким образом, что одна команда может писать только сервисы с исполнением необходимой бизнесс логики на них, а другая может писать пользовательский интерфейс. Так же, сервисы могут быть переиспользованы в будущем. Допустим у Вас есть аппликация, которая пользуется сервисами для получения курса валют, в определенный момент Вы решили выпустить мобильный клиент для своей аппликации — Все что Вам надо будет написать — это собственно мобильный клиент, так как вся бизнесс логика хранится на сервисе, написанном ранее.

Конечно же, среди такой огромной кучи плюсов , есть минусы — интерфейсы ваших сервисов не длолжны меняться в идеале, потому что если поменятеся инетерфейс даже одного метода, одного сервиса — вам необходимо будет сделать изменения во все программы которые используют Ваш сервис. Потому, интерфейсы сервисов должны быть определенны в начале проекта, и меняться должны только в САМЫХ крайних случаях.

4 столпа SOA

Граници определенны! Когда клиент работает в SOA среде — он практически ничего не знает о том где расположен сервис — ни в какой комнате, ни даже в какой стране. Потому, клиенту надо точно знать каким образом он может коммуницировать с сервисом. Такими необходимыми элементами являются — аддресс и контракт. Также нужно быть уверенным что сервис может перестать работать ТОЛЬКО выдав ответ или детализированную ошибку. Сервис не может перестать работать не сказав почему.

Сервисы автономны! Все сервисы это атомарные еденицы. Они не должны быть завязанны на  то как функционируют другие сервисы. Инсталляция новое версии сервиса не должна никак повлиять на работу других сервисов которые его спользуют.

Сервисы разделяют схему и контрак, не класс! Контрак — это просто описание сервиса с его инетерфейсом , а схема — описание структуры параметров.

Совместимость определяется на основе политик. Политики должны определять какой протокол использовать для коммуникации, какой формат данных возрващать, и т.д.

Екосистема сервиса

Чудесно данный пункт описывает книга: «WCF 4: Windows Communication Foundation и .NET 4 для профессионалов». Я постараюсь рассказать в двух словах:

Система состоит из сервисов.
Сервисы это те строительные кубики из которых должна состоять Ваша система. Вы можете создавать программы которые используют вашу систему: например одна программа может использовать 5 сервисов Вашей системы, а другая — 3 сервиса. Причем вся бизнесс логика должна быть реализованна иммено в сервисах.

Сервис управляет состоянием
Собственно не сохранаяют никаких данных в памяти, чаще всего используется база данных в которых сервисы могут хранить данные, а потом при первой необходимости вытаскивают эти данные из базы. Важно понимать, что сервисы не должны помнить о промежуточных данных, потому как если сервис будет использован большим количеством клиентов — промежуточные данные могут попатсть не к тому аддрессату:) А мы ведь не хотим никому отдать номер нашей кредитки?

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

Политики соблюдают эксплаутациооные требования
Политики соблюдают требования платформы которая использует сервис.

Сервисы связанны контрактами
Сервисы это суперзвезды, без контракта их использовать нельзя:) Контракт — это описание сигнатур операций которые можна использовать клиентом на сервисе.

Контракт описывает шаблом обмена сообщениями
Контракт описывает как клиент — сервис, сервис — сервис обмениваются данными.
а. Request — response: получите — распишитесь. Самый широкоиспользуемуые шаблон — на запрос от клиента — сервис отвечает.
б. One — way: ответа нет и не будет.
в. Duplex: сервис может дергать клиент во время выполнения операции, для того чтобы получить больше данных перед тем как ответить.

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

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

Сервисы обмениваются сообщениями
Это самый главный пункт. Сервисы как с клиентами так и между собой обмениваются сообщениями. Собственно вызов сообщения — это единственный способ дернуть операцию на сервисе, или получить ответ от него.

Какие же технологии позволяют реализовать SOA подход:
Во первых это конечно же SOAP. SOAP — это просто по определенному шаблону структурированный XML. Как уже было сказанно сервисы обмениваются так называемыми SOAP пакетами. Такой пакет состоит из двух частей — заголовок и тело.
В заголовке находится информация для инфраструкуры и коммуникации, в тоже время, в теле же этого пакета находится информация более связанная с функционалом. И самое приятное что SOAP не привязан ни к одной из технологий — именно это один из фактов кросс платформенности сервисов.

WS-* protocol. Это такие звери которые прекрасно понимают что находится в заголовке SOAP пакета, и знают как обмениваться сообщениями быстро, защищенно, ну и вообще:) В WCF это реализуется с помощью WsHttpBinding биндинга.

WSDL — а вот это уже те самые контракты. Именно с помощью WSDL — который является просто XML сформированным описанием интерфейса сервиса. Благодаря тому что это XML контракты могут быть использованны любой технологией, которая вообще понимает что такое XML:)

 

Принцип — вначале контракт!

Как уже было сказанно в SOA — инетерфейсы сервисов не должны меняться, потому работа должны начаться с глубокого анализа нужд клиентов которые будут использовать сервисы.

Для примера можна взять обычное 3-х уровненвое приложение.

Какие уровни мы имеем:

а. Пользовательский интерфейс.

б. Бизнесс логика

в. База данных, объекты доступа, и тд.

Как видим, задача сервисов реальзовать именно вот тот второй пункт. Сервисам все равно как храняться данные : пусть то будет база MS SQL Server, или же XML. Тем более сервисам совсем все равно как данные отображаются:) Сервисы даже понятия зеленого не имеют кто их дергает  и кому они отдают данные, лиш бы политики соблюдались.

Больше информации о том что такое SOA вы можете получить использую следующие ссылки:

http://en.wikipedia.org/wiki/Service-oriented_architecture — Wiki:)

http://www.soa-manifesto.org/ — SOA Manifesto

http://en.wikipedia.org/wiki/WS-Security — один из WS-* протоколов

http://www.dialektika.com/books/978-5-8459-1713-3.html — тут можно купить книгу которую в данный момент читаю я.

В следующих статьях я начну писать больше именно о WCF. В любом случае я уверен что вводный курс в SOA — совсем не помешал:)