Интеграционная архитектура. Контракты.

Основная мысль этой статьи:

Контракты — важная часть интеграционных систем.
Основные требования к контрактам:

  • простая процедура создания/получения контрактов;
  • возможность простого обмена контрактами.

Успех конкретных интеграционных систем в немалой доли зависит от этих требований.

Определения

Рассмотрим несколько стандартных шаблонов обмена сообщениями (MEX — Message Exchange Patterns). Это Запрос-Ответ (Request-Response) и Pub-Sub (не знаю, как это по-русски, буду так и писать Паб-Саб).

В отношении создания, инициирования данных можно определить две роли: инициатор и получатель данных.

В шаблоне Запрос-Ответ есть две роли: клиент и сервис (client и service). Сервис «владеет» контрактами. В том смысле, что клиенты должны слать запросы в нужном формате (формат этот принято называть контракт), и формат этот задает сервис, не клиент. Клиенты должны следовать этому контракту. Задается этот контракт сервисом. В WCF веб-сервисах есть специальный адрес (mex address), по которому сервис выдает этот контракт, а клиенты могут получить этот контракт. Если, к примеру адрес (URL) веб-сервиса http://MyServer.com/MyService.svc, то mex адрес получается из этого адреса с добавлением ?wsdl, то есть в нашем примере получится  http://MyServer.com/MyService.svc?wsdl Если смотреть с точки знения инициации данных, здесь получатель данных определяет контракт.

В шаблоне Паб-Саб есть тоже две роли: издатель и подписчик (publisher и subscriber). Здесь уже не получатель данных определяет контракт, а наоборот,  инициатор данных. В данном случае это издатель. Издатель публикует сообщение ничего не зная о том кто получит его. Он даже не интересуется, а получит ли это сообщение вообще хоть один подписчик. Дело подписчика подписаться на это сообщение, получить его и обработать. И тут уж подписчик никак не может повлиять на формат этого сообщения. Он должен сам позаботиться о получении каким-либо образом контракта и далее использовать этот контракт, чтобы получить нужные данные из сообщения.

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

Если мы имеем дело с XML сообщениями, то под контрактом понимается XML схема (XML Schema), специальный стандарт, определяющий язык описания XML документов. Обычно XML схемы хранятся в файлах с расширением xsd, поэтому часто говорят об xsd, имея в виду XML схему.

С сообщениями в других форматах не все так однозначно. К примеру для JASON не существовало до последнего времени однозначного стандарта языка описания. Понятно, что так долго продолжаться не могло, поэтому уже появился JASON Schema IETF стандарт.

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

Системы могут обмениваться сообщениями напрямую, а могут использовать некую промежуточную систему. Иногда в этом контексте говорят о Point-to-Point шаблоне/архитектуре и Брокер (Broker) и ESB (Enterprise Service Bus) архитектурах.

Point-to-Point архитектура хорошо ложится на Запрос-Ответ шаблон, а  ESB — на Паб-Саб.

Основное отличие здесь в том, что исходное сообщение будет доставлено только одному получателю в Point-to-Point, а в ESB исходное сообщение может быть доставлено одновременно многим подписчикам или может быть не доставлено никому. В ESB сообщение двигается в одном направлении, от издателя к подписчику/подписчикам, обратная связь, если она существует вообще, осуществляется по другим каналам. В Point-to-Point легко реализовать двунаправленную связь, поэтому Point-to-Point — вотчина Ответ-Запроса.

И Брокер, и ESB маршрутизируют (route) сообщения. Они обладают некой информацией, которая помогает им решать куда направлять то или иное сообщение. Вы не найдете нигде точного определения ESB, но одно общее утвержение об ESB, объединяющие большинство определений, гласит, что в ESB сообщения должны двигаться асинхронно, то есть это — квинтэссенция Паб-Суб шаблона.  Сообщения просто «бросаются» в ESB, а она знает, что с ними делать.

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

Давайте посмотрим  на то, как инициаторы и получатели данных обмениваются контрактами в разных системах.

WCF

Здесь система обмена контрактами является частью технологии. Клиент делает запрос по <АдресСервиса>?wsdl адресу и в ответ сервис возвращает контракты. В этой системе нет никаких отдельных сервисов или инфраструктурных программ, которые обеспечивают обмен контрактами. Каждый сервис полностью ответственен за свои контракты. Конечно, сервисные библиотеки WCF обеспечивают автоматическую генерацию XML схем и разработчику сервиса не надо беспокоиться об этом самому.

Попытка протолкнуть в массы стандар UDDI, призванный управлять метаинформацией сервисов, в том числе и контрактами, не удалась. Массы отвергли этот стандарт. Другие подобные стандарты не возникли в силу невостребованности. Практика показывает, что существующий в веб-сервисах метов обмена контрактами получился удачным и востребованным. К примеру намного более быстрые и простые REST веб-сервисы после быстрого и шумного старта так и не стали безоговорочным победителем. Одна из главных причин, в том, что система обмена контрактами не встроена в REST сервисы, так, как это было сделано в WCF сервисах.

BizTalk Server

BizTalk Server — это по сути брокер.

Все контракты в BizTalk — это XML схемы. BizTalk хранит все схемы в конфигурационной базе данных. Дальше по тексту термин контракт будет эквивалентен термину XML схема.

Как получаются контракты?

Если собственник контракта обладает способностью выдавать их по запросу, то BizTalk предоставляет визарды для подключения и скачивания этих контрактов. К примеру, контракты можно автоматически получить от WCF веб-сервисов, от SQL Server, от Dynamics CRM, от SAP R/3 и нескольких других приложений. Практически все адаптеры из WCF Adapter Pack и WCF LOP Adapter Pack имеют визарды для генерации контрактов.

Если внешняя система или транспорт не предоставляют контракт, то в BizTalk есть обходной маневр. Берется образец сообщения и специальный визард генерирует XML схему по этому образцу. Есть визарды для XML сообщений и для текстовых сообщений, так называемых Flat File messages.

Если обмен сообщениями осуществляется по стандарту EDI (X12 или EDIFACT), то BizTalk предоставляет уже готовые контраты, более 7000, для этого стандарта. Кроме этого предоставляются контракты для стандартов HL7, HIPAA, EANCOM и некоторых других.

Как контракты предоставляются потребителям?

Обычно интегрируемые системы имеют собственные контракты, собственные форматы данных и собственные требования к транспортным протоколам. Владельцы этих систем вряд ли будут менять эти контракты. Разработчики, которые интегрируют эти системы, должны использовать эти контракты. Каки образом разработчики получают эти контракты? Иногда интегрируемые системы имеют API для автоматической выдачи контрактов. В BizTalk нет API или общего интерфейса по выдачу контрактов потребителям. Есть возможность сгенерировать WCF веб-сервис для receive port, что предоставит потребителю запрашивать и получать контракты этого порта. Но это обходной путь. Прямого пути получения контракта из конфигурационной базы данных BizTalk к сожалению не существует.

BizTalk и контракты

С одной стороны в BizTalk — мощные и разнообразные каналы генерации контрактов. С другой стороны в BizTalk мало что сделано, чтобы обеспечить простой и быстрый,  и вместе с тем организованный обмен контрактами. В результате на BizTalk довольно просто делается инеграция «по площадям», когда множество разнообразных систем хаотически интегрируются. Но большие интеграциооные проекты, где требуется системный подход к управлению контрактами, на BizTalk делать сложно.

Всегда ли контракты хранятся и передаются отдельно от данных?

Обычно контракты хранятся и передаются отдельно. Но есть системы и стандарты, где они передаются вместе с данными.

К примеру в  Google Protocol Buffers.

XML также имеет возможность «вшивать» определения типов с помощью Instance Type атрибутов, задаваемых с http://www.w3.org/2001/XMLSchema-instance namespace.

Оставьте комментарий

Filed under BizTalk, Integration Architecture, WCF

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s