BizTalk Server: уроки одного интеграционного проекта

По мотивам этого топика, я написал обобщающую статью. Она называется Domain Standards and Integration Architecture (на английском).

Хочу с вами поделитьсяч опытом. Я расскажу про один из недавних контактов. Очень хотелось бы узнать ваше мнение.

У этого заказчика BizTalk Server используется давно и успешно. Один из проектов – “Производство и поставка деталей и комплектующих”. Такой типичный интеграционный проект, состоящий из множества интерфейсов. Проект действительно большой, около 50 BizTalk Server приложений. Но что делает его действительно большим, в смысле количества кода, так это использование EDI и Oagis форматов данных.

Для примера возьму одну среднюю по размерам Oagic XML  схему, ProcessPaymentStatus. Размером она в 874К, состоит из порядка 10 тысяч элементов и атрибутов.  И это именно средняя по размерам схема, есть и много большие.

Мой проект состоял в модификации одного бизнес процесса. Изменения затронули несколько приложений. В основном пришлось менять maps – схемы преобразования данных.  Я провел дни, отыскивая элементы, подлежащие изменению, и реализуя логику переноса данных этих элементов из одной сложной схемы в другую, не менее сложную схему. На проект были брошены большие силы и все равно он не уложился в срок. Кроме того результирующий код содержит много еще не найденных ошибок, которые когда-нибудь выплывут в реальной работе. Сейчас же было просто нереально протестировать все комбинации данных, потенциально возможные в трансформациях таких больших схем.

На этапе тестирования выплыли проблемы с производительностью. Преобразования данных с такими сложными схемами неизбежно вылились в заторы в их обработке.

Приложения выводят во “внешний мир” данные в EDI формате, а для между внутренними приложениями данные передаются в формате Oagis.

Настал момент, когда менеджемент задал давно ожидаемый и фундаментальный вопрс, “Сколько можно срывать сроки? Сколько раз можно сдавать ненадежный код? Как ускорить работу?” Причем под работой понималось не только скорость работы приложений, скорость продвижения данных от системы к системе (если не забыли, мы сейчас обсуждаем интеграционную систему), но, прежде всего, скорость разработки. Любые изменения в существующих приложениях производились слишком медленно. Бизнес протребовал ускорить модификации интеграционных приложений. Разработчики не поспевали за изменениями в бизнесе. Совершеннейшая чепуха в изменениях бизнес-процессов выливалась в недели и месяцы в разработке.

И тут один из новых разработчиков удивился одному факту. Заказ детали, по идее, может состоять всего из нескольких атрибутов: номер детали, количество, дата и время заказа, идентификатор заказчика и что-то там еще. Но почему тогда по системе бродит громадный заказ, состоящих из многих сотен полей?????? Разработчик был не опытный консультант, который на его месте бы сказал «Ничего невозможного нет!» и принялся бы за работу. Разработчик был молодой и неопытный, поэтому он и задал этот глупый вопрос.

На первоначальном этапе при вводе в систему заказ дополняется всей доступной информацией. Потом этот заказ преобразутеся в некий внутренний формат, попутно обрастая еще сотнями полей. На базе этого заказа создаются другие документы, каждый их которых набивается сотнями и сотнями всевозможных значений. Благо имеющиеся EDI и Oagis схемы сделаны феноменально детальными. Про размер схем я уже говорил.

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

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

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

Есть несколько технических причин этому, но все они оказались непринципиальными. Одна из причин была в том, что разработчики следовали правилу “Чтобы системы были слабо связаны и хорошо масштабируемы, все данные должны передаваться в каждом сообщении”. Известный прннцип, которому следуют кроме интеграторов еще и веб-девелоперы и разработчики много-потоковых приложений.

В нашем случае этa причина не была подвергнута критическому анализу в самом начале разработки и, как оказалось, она оказалась довольно неубедительной. Данные в интегрируемых системах были стабильными. Списки деталей на складах, списки поставщиков и т.п., все эти данные могли храниться в разных местах, но эти данные элементарно синхронизировались раз в день или в неделю. Из-за этого при заказе детали нам достаточно пересылать минимальную информацию о самом заказе, ничего больше. Еще иногда надо синхронизировать данные, к примеру, чтобы номенклатура деталей в базах разных систем совпадала.

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

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

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

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

Что же получилось в результате нашего перепроектирования? В окончательном виде система оказалась раз в двадцать проще. Теперь схемы сообщений состоят не из тысяч элементов, а из единиц, максимум пары десятков. Это же можно сказать и про производительность интеграционных приложений. Надежность пока трудно оценить, но затраты на тестирование снизились даже больше, чем затраты на разработку.

Теперь во время разрабоки мы постоянно задаем себе вопрос “Так ли уж нужен этот элемент данных в нашем сообщении?” И только после абсолютно утвердительного ответа этот элемент становится частью сообщения.

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

Как же так случилось, что проекты с настолько явным просчетом в архитектуре удовлетворяли всех так долго?

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

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

Комментарии (7)

Filed under BizTalk, Заметки, Integration Architecture

Microsoft BizTalk Server: Что это такое?

Что такое Microsoft BizTalk Server?

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

Интеграция?

BizTalk позиционируется, как пакет для интеграции систем.

Что Microsoft вкладывает в понятие «интеграция», применительно к BizTalk?

Обмен данными

Обмен данными в разных форматах и по разным протоколам и стандартам. Имеются в виду форматы данных, такие, как многочисленные текстовые форматы, SQL, Xml. Протоколы, такие, как HTTP, SOAP, SMTP, POP3, FTP, MSMQ, которые обычно включают в себя и стандарты форматов данных. Форматы приложений, таких, как, SAP/R3, Siebel и индустриальные стандарты, такие как EDI, SWIFT, HL7, HIPPA, которые включают в себя форматы данных, протоколы, системы аудита, защищенности.
Иногда в понятие обмена данными вкладывается структурное преобразование данных между форматами (например, данные надо преобразовать из текстового формата в формат Xml) плюс использование нужного протокола обмена (пример, данные надо передать по протоколу SOAP, что означает преобразование данных в формат Xml, упаковку этих данных в SOAP-пакеты и использование протокола SOAP для отправки этих пакетов).
Иногда понятие обмена данными расширено настолько, что включает в себя стандарты безопасности, средства аудита, архивирования, синхронизации данных и т.п. К примеру, модули, ответственные за обмен EDI данными, представляют из себя целые системы, состоящие из множества частей и удовлетворяющие множествам EDI стандартов. Одних только схем EDI в составе BizTalk поставляется несколько тысяч. Для обмена данных BizTalk включает в себя большое количество адаптеров, как простых (File, SOAP, FTP), так и сложных (SAP, J.D.Edvards, HL7…).

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

Обычно операция получения схем недооценивается, особенно в BizTalk. Но попробуйте сами создать парсер для преобразования csv файла в XML. Попробуйте найти утилиту, которая это сделает корректно.  То же касается и SQL процедур и таблиц.

BizTalk делает очень много, чтобы предоставить или создать девелоперу качественные XML схемы.

Преобразование форматов

Другая сторона обмена данных – это преобразование форматов данных между системами. В BizTalk преобразование данных реализуется так: все внешние форматы данных преобразуются к одному внутреннему формату — Xml. Все адаптеры осуществляют такое преобразование, как в одну, так и в другую сторону. Сообщения в формате Xml описываются схемами — Xsd. Чтобы осуществить структурные преобразования, то есть когда требуется часть данных поменять местами, часть данных удалить и т.п, используется стандарт Xslt. Документ Xslt (карта — map) описывает, как исходный (source) XML документ преобразовывается в конечный (destination) XML документ. BizTalk имеет для этих целей два редактора: Schema Editor и Mapper. Первый редактирует и создает Xsd схемы, второй –Xslt преобразования.

Маpper – это один из лучших редакторов в мире для создания Xslt преобразований.

Бизнес процессы

Microsoft добавило в BizTalk средства, которые имеют более широкое использование, чем просто обмен данными. Это Business Process Orchestration – бизнес процессы. Эти средства влючают в себя редактор для создания бизнес процессов и среда выполнения этих процессов. К примеру, нам потребовалось создать систему, координирующую продажи товаров. Сейчас система состоит из нескольких независимых приложений. Одно приложение этой системы инициирует обработку, например выдает счет на товары. Другие приложения отвечают за утверждение счета, комплектации заявки на отгрузку товара, комплектации отгрузки, обработки сопутствующих финансовых транзакций. Все эти приложения могут быть независимы друг от друга, могут даже принадлежать разным компаниям. В BizTalk создается координирующие программы, бизнес процессы, Orchestration, которые и управляют всем бизнес процессом. Запуск бизнес процесса, а значит и Orchestration инициируется одним из внешних приложений. Orchestration запрашивает у других приложений недостающие данные, дает им задания на обработку, и таким образом интегрирует их в один бизнес процесс. Когда все данные введены и обработаны, Orchestration завершает процесс. Orchestration может ожидать данные от других программ дни, а то и месяцы. Интересно то, что одновременно могут работать многие тысячи экземляров Orchestration для многих тысяч заявок.
Возникающие при этом проблемы очень интересны и на практике бывают довольно сложны в реализации: это и обеспечение бесперебойного восстановления системы после сбоев оборудования, и обеспечение стабильной работы большого количества приложений, обеспечение синхронизации тысяч документов, программ, партнеров и т.д. Простая интеграция, когда данные берутся из одного источника, преобразуются в формат другой программы и передаются этой программе, не решает проблемы асинхронной обработки. Что будет, если принимающая данные сторона временно не работает? Что делать, если исходная системы выдала несколько комплектов данных, а принимающая сторона все еще не работает или не успевает их принять в том же темпе? Business Process Orchestration решает и эти проблемы.
BizTalk предоставляет среду, которая ответвечает за создание огромного количества процессов, за управление этими процессами. BizTalk предоставляет специальный редактор Orchestrations, позволяющий моделировать разнообразные бизнес процессы с помощью простых блок-схем.
Основное применение Orchestrations — координация обработки интегрируемых данных, а не только согласование форматов данных. Это консолидация данных из разных источников, реализация бизнес логики по промежуточной обработке данных, синхронизация данных из разных источников, поддержка транзакций и т.п. Создана теория и несколько стандартов, посвященных именно долгоживущим процессам, называющимися Long Running Transactions. Основные игроки в данном сегменте, это IBM, Microsoft, Siebel, TIBCO и ряд других.

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

Инструментарий разработчика

BizTalk можно рассматривать с двух сторон: С одной стороны — это инструментарий разработчика, включающий в себя многочисленные редакторы (схем, maps, Orchestrations…). Часть средств BizTalk работают, как независимые программы, но большая часть средств — как редакторы в Microsoft Visual Studio. Все о чем я говорил выше, относится как раз к инструментарию разработчика.

Среда выполнения

С другой стороны — это среда выполнения, обеспечивающая работу процессов обработки данных. При этом среда выполнения обеспечивает очень высокую надежность обработки данных и высокую степень масштабируемости. Оптимальные системы работают и на одном компьютере, и на серверных фермах, состоящих из десятков и сотен серверов. BizTalk Server работает в среде Windows и в качестве хранилища требует Microsoft SQL Server.

Поподробнее

Среда выполнения частично состоит из .NET кода, работающего на нескольких Windows services (это — BizTalk application servers), частично из SQL баз данных, таблиц, процедур, jobs и много другого (это — SQL Servers). Обе части могут работать в кластерах, либо все — на одном компьютере. Сервера приложений кластеризуются средствами самого BizTalk. Добавить сервер — тривиальная задача. Весь код создан для работы в полностью автоматическом режиме. Система восстанавливается автоматически после сбоев питания, сети и других неприятностей.

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

Один из нюансов использования BizTalk состоит в том, что он используется прежде всего для интеграции систем в автоматическом режиме, для интеграции программ с минимальным участием человека. Одни приложения поставляют данные, другие их потребляют. В промежутке располагается BizTalk Server, который согласовывает форматы обмена, координирует обмен данных и их обработку. Обычно система на базе BizTalk работает без участия человека. BizTalk – это типичная back-end система. Ее многочисленные и мощные средства для разработчика контрастируют с минимальным набором средств для оператора, которому надо лишь в ограниченных пределах наблюдать за работающей системой, подстраивать ее. В BizTalk есть четкое деление между средой разработки (development) и средой исполнения (runtime).

Чтобы продемонстрировать надежность BizTalk, я демонстрирую простую операцию. Я запускаю на обработку побольше данных, после чего просто выключаю сервер. Выдергиваю вилку из разетки. Еще не разу не было такого, чтобы после включения сервера пропало хоть одно сообщение. Пробовал я такое и на кластере BizTalk серверов. Результат тот же, 100% надежность.

Суммируя вышеизложенное, BizTalk — это интеграционная система, обеспечивающая обмен данными в разных форматах и протоколах, преобразование данных и выполнение бизнес процессов, плюс всеобъемлющая среда разработки.

Типичные примеры использования BizTalk:

Синхронизация данных между системами

Приложение или оператор выкладывает готовые данные в определенном формате в файлы. BizTalk процесс с заданным промежутком просматривает нужный каталог и забирает файлы. Данные из файлов преобразуются во внутренний формат (Xml). Другие приложения, подписанные на эти данные, получают их. Данные предварительно преобразовываются в формат этих приложений. Данные хранятся в BizTalk до тех пор, пока принимающая сторона не будет готова принять их.

Синхронизация данных между приложениями в реальном масштабе времени

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

Композитный распределенный сервис

Приложение обращается к Web-сервису за данными. Web-сервис запускает BizTalk процесс, который обращается к другим Web-сервисам за дополнительными данными, после чего консолидирует данные и выдает их первому приложению. (Это типичный пример создания композитных Web-сервисов.)

RFID

Складская система на базе RFID (радио кодов). BizTalk процессы получают данные с RFID считывателей установленных на воротах склада и носимых считывателей, фильтруют их и передают данные в многочисленные складские приложения для учета и мониторинга движения товара.

1 комментарий

Filed under BizTalk, BizTalk course

Копирование build файлов на все сервера

Повоторив этот код снова и снова, я подумал, что может быть кто-то делает так же самое. Может быть этот код сохранит вам немного времени.

В общем это – типичная задача. Я разрабатываю BizTalk Server приложения и, конечно же, использую великолепный(!) BizTalk Deployment Framework (BTDF) для развертывания, установки приложений. Когда приложение готово для тестирования и, в конце концов, для работы с данными, все файлы приложения надо установить. Обычно BizTalk развернут на нескольких серверах. К примеру это могут быть сервера для разработки, для тестирования, для тестовой работы, для реальной работы (Development, QA, Staging, Production). Иногда этих серверов меньше, иногда больше. Лучший метод – деражать все эти сервера изолированными друг от друга. В моем случае это означает, что фалы приложения хранятся для каждого сервера в отдельной копии. Это также значит, что мне надо эти файлы копировать одновременно в несколько мест.

Хорошим методом также будет сохранить старые файлы на случай отката, если с последней версией что-то не так.

В результате каталоги с файлами будут выглядеть наподобие этого для каждого сервера:

image

Каталог Current folder содержит файлы приложения, которые установленны в настоящее время на сервере. Каталоги с именами [YYYYMMDD_hh_mm_ss] хранят старые версии приложения.

А здесь код:


<!— Copy a new deployment build to all environment and to a Personal share.
  Before this rename a Current folder to the [CurrentDateTimeTime] to save an old build.
  —>
<Target Name=»AfterInstaller» AfterTargets=»Installer»>
  <PropertyGroup>
    <NewBuild>..\Deployment\bin\$(Configuration)</NewBuild>
    <CurrentDateTime>$([System.DateTime]::Now.ToString(«yyyyMMdd_hh_mm_ss»))</CurrentDateTime>
    <Shares>\\fileshares.domain.com\Shares\</Shares>
    <SourceCodeShare>\BizTalk\Deployment\$(ProjectName)</SourceCodeShare>
    <PersonalShare>Z:\Projects\BizTalk\GLD\Samples\Deployment\$(ProjectName)</PersonalShare>
  </PropertyGroup>
  <!— Rename Current shares to the [CurrentDateTime]: —>
  <ItemGroup>
    <EnvironmentName Include=»QA1;ST1;PR1″/>
  </ItemGroup>
  <ItemGroup>
    <CurrentShare Include=»$(Shares)%(EnvironmentName.Identity)$(SourceCodeShare)» />
    <CurrentShare Include=»$(PersonalShare)» />
  </ItemGroup>
  <Exec Condition=»Exists(‘%(CurrentShare.Identity)\Current’)»
         Command=’Rename «%(CurrentShare.Identity)\Current» «$(CurrentDateTime)»‘/>
  <ItemGroup>
    <NewBuildToCopy Include=»$(NewBuild)\**\*.*»>
      <Destination>%(CurrentShare.Identity)</Destination>
    </NewBuildToCopy>
  </ItemGroup>
  <!— Copy the last build to the Current shares: —>
  <Copy Condition=»@(NewBuildToCopy) != »»
        SourceFiles=»@(NewBuildToCopy)»
        DestinationFiles=»@(NewBuildToCopy->’%(Destination)\Current\%(RecursiveDir)%(Filename)%(Extension)’)» />
</Target>
 

Этот Target может быть включен в файл  Deployment.btdfproj, который входит в проект BTDF Deployment. Еще его можно добавить в файл BizTalkDeploymentFramework.targets, который устанавливается как часть BTDF.

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

Filed under BizTalk, Code, MSBuild

Лучший Сервер приложений от Microsoft

Рассмотрим разные типы приложений.

Приложение для последовательной обработки

Приложение этого типа однопотоковое. Приложение получает массивы данных  и обрабатывает их одно за другим. BatchProcessing

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

В качестве сервера приложений этого типа работает сама операционная система. Программа запускается либо пользователем, либо по старту операционной системы. Windows service – это один из типов подобного приложения, для него Windows предоставляет дополнительные возможности, такие, как автоматический рестарт в случае ошибки.

Приложение – сервис

Программа-сервис постоянно ожидает запрос от клиента.  Если одновременно поступает много запросов, они ставятся в очередь на обработку. ShortRunningTransactions

Типичный представитель приложений этого класса – веб-сайт. Сервер приложений этого типа – Internet Information Server (IIS). Для каждого пользовательского запроса запускаеся отдельный процессорный поток, который завершается после выдачи результата пользователю. Если в приложении для последовательной обработки всегда работает только одна копия приложения, то здесь работают сразу несколько копий сервиса, по одной на каждый пользовательский запрос.  Обычно приложение не хранит данные клиента. Если по какой-то причине копия сервиса завершает работу с ошибкой и клиент не получает результат, клиент просто повторяет запрос и запускается другая копия сервиса. Данные хранит клиент, а не сервис. Сравним приложение-сервис с приложением для последовательной обработки. Последнее может обрабатывать только одну порцию данных одновременно. Кроме того обработка в нем не изолирована в отдельных копиях, и ошибка в обработке приведет к краху не одной копии, как в приложении-сервисе, а краху всего приложения. Надежная работа приложения-сервиса возможна тогда, когда приложение выполняет свою работу за короткое время. Если это время составляет часы и дни, то многократно возрастает возможность сбоя сервера приложения, соответственно уменьшается надежность тех копий приложения, которые во время краха находятся в памяти.

Приложение – долгоживущий сервис

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

LongRunningTransactions

Другая проблема долгоживущих сервисов – корреляция запросов.

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

В идеале механизм корреляции тоже обеспечивается сервером приложений.

Другая проблема долгоживущих сервисов – очистка от “умерших” копий сервиса. К примеру, сервис делает запрос к внешнему сервису и не получает ответа в течение определенного времени. Внешний сервис может не работать, либо сеть может быть перегружена, причин задержки может быть много. В другом случае копия сервиса просто подвисает, а не завершается с ошибкой. Один из популярных методов очистки «умерших» копий сервисов — «измерение пульса». Специальный сервис периодически запрашивает все копии сервиса и, если какое-то из них не отвечает, оно считается «умершим» и удаляется из памяти.

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

Таким образом для долгоживущих сервисов возникает необходимость в дополнительных функциях сервера приложений:

  • хранилище данных копий сервисов;
  • системе корреляций запросов;
  • системе мониторинга и удаления «умерших» копий сервисов;
  • системе повтора запросов внишним сервисам

Как оказалось в арсенале Microsoft есть сервер приложений с подобными функциями. Это BizTalk Server.

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

В Почтовый Ящик встроена система корреляции запросов. Пришедшие извне запросы анализируются и либо попадают к копии сервиса, которое ожидает именно этот запрос, либо запрос запускает новую копию сервиса.

Постоянно «измеряется пульс» и производится очистка памяти от «умерших» или завершенных копий сервисов.

Система вывода обеспечивает автоматическое повторение запросов внешним сервисам.

И самое главное качество BizTalk Server в качестве сервера приложений, это его надежность. Запущенные сервисы работают годами без присмотра. Пропадает электричество, «падают» сервера, пропадает сеть, ломаются жесткие диски. Но данные не пропадают. BizTalk автоматически перезапускается, прерванные сотни, тысячи копий сервисов восстанавливаются и продолжают работать как ни в чем ни бывало. Для этого работа в BizTalk Server элементарно распределяется между несколькоими компьютерами, а данные хранятся в SQL кластерах.

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

Filed under BizTalk, Integration Architecture, Microsoft

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

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

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

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

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

Определения

Рассмотрим несколько стандартных шаблонов обмена сообщениями (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 хранит все схемы в конфигурационной базе данных.

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

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

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

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

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

В 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

BizTalk: Соглашения об именах в примерах

Вначале можно ознакомиться со статьей BizTalk: BizTalk Solution Naming Conventions.

В небольших  приложениях мы особенно не беспокоимся об именах. Когда же количество объектов приложения начинает расти, мы вынуждены начать думать об именах. Опытного разработчика, работавшего с большими проектами, можно распознать по тщательно и досконально продуманным именам в коде. Это верно на 200% . Программист может со скоростью мысли писать изощренный код , но, если он не думает об именах, он никогда не делал большие проекты.

Когда девелопер начинает работать в новой команде, он/она проводит вначале много часов, читая документацию, и «Соглашения об именах» (Naming conventions) обычно — важная часть этой документации. Потом он/она начинает разработку и опять часть времени уходит на ознакомление со существующим кодом, чтобы вникнуть в действующие стандарты кодирования. И опять, Соглашения об именах — важная часть этого процесса.

Документированные Соглашения об именах важны, но реальный код не менее важен. Документация может устареть, код всегда актуален. И код более нагляден.

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

Описание примера

Этот BizTalk код состоит из многих BizTalk приложений (applications). Каждое из приложений состоит в свою очередь из 1-10 Visual Studio проектов (projects). Эти приложения были разработаны в течении многих лет разными группами разработчиков. Приложения интегрируют несколько систем. Некоторые системы имеют только один интерфейс, некоторые — несколько интерфейсов. В большинстве случаев интерфейс одной системы интегрирован с интерфейсом другой системы. Иногда несколько систем интегрированны с одним интерфейсом системы.

Для этого примера было выбрано одно приложение (solution) . Еще раз акцентирую, это приложение из реальной жизни. Почему это приложение, GLG.Samples.Name.Shared.Schemas, было создано в данной ситуации? 

Как известно, интерфейсы в BizTalk определяются с помощью протокола и одной или нескольких XML cхем (schemas). Во многих случаях эти схемы диктуются самими интегрируемыми системами, а не разработчиками приложений. Обычно разработчик использует Adapter Wizard, чтобы сгенирировать/импортировать эти схемы. Эти схемы определяются и при необходимости меняются не разработчиками BizTalk приложения, а создателями и хозяевами интегрируемых систем. В дальнейшем такие схемы я буду называть внешними (external schemas).

Одна из интересных характеристик внешних схем то, что они могут использоваться несколькими BizTalk приложениями. Я однажды уже писал, что схемы, используемы в портах, должны быть уникальными (receive locations should be unique), они не могут содержаться одновременено в нескольких установленных библиотеках (deployed assemblies). Это означает, что если нам надо использовать одну и ту же схему в нескольких проектах, мы должны установить одну общую (shared) библиотеку один раз, не больше, и ссылаться на нее из всех этих проектов. 

Данное ограничение заставляет обращать особое внимние на организацию и тщательную проработку общих библиотек.

Обычно используется следующий дизайн: Все внешние схемы размещены в отдельном приложении Visual Studio. В данном примере схемы сгруппированы по системам. Внутри каждой системы схемы сгруппированы по имени интерфейса. Группировка схем и лежит в основе Соглашения об именай.

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

Викторина :) по деталям реализации:

  1. Нормально ли, когда имена скомпонованы из четырех и даже более частей, наподобие GLD.Samples.Names.Shared.Schemas?
  2. Необходим ли GLD.Samples префикс для имен BizTalk приложений?
  3. Почему мы используем суффикс _Ops в именах проектов SystemA, SystemB, и SystemC?

(Попытайтесь ответить на эти вопросы самостоятельно. Я дам мои ответы в конце статьи.)

В данном примере рассмотрены два варианта Соглашений об именах. Я назвал их Длинные имена и Короткие имена.

Длинные имена

Картинка из Solution Explorer (все картинки взяты из BizTalk Server 2013):

Solution.Long

Это картинка папок:

Folders.Long

Короткие имена

Это картинка из Solution Explorer:

Solution

Это картинка папок:

Folders

Сравнение соглашений

Соглашение Короткие Имена выглядит изящнее. Здесь нет общих префиксов (GLD.Samples.Names.Shared.Schemas) внутри имен проектов и файловых папок. Если вы сражаетесь с хорошо известным ограничением Visual Studio TFS на общий размер имен файлов, это соглашение будет предпочтительным вариантом.

Я предпочитаю Длинные Имена (Полные имена). В этом случае имена проектов абсолютно такие же как .NET namespace у этих проектов и такие же, как имена билиотек (assembly). Полные имена проектов лучше в ситуациях, когда имена проектов могут быть включены одновременно в несколько Visual Studio приложений (solutions) или когда приложения часто перемещаются между приложениями. Срабатывает закон KISS (keep it simple stupid). В данном случае соглашение Длинные имена позволяет обходиться одним соглашением для многих объектов. Закон KISS неимоверно важен в больших проектах. Простота обходится дорого, сложность рождается бесплатно. За простоту приходится сражаться. В данном случае наблюдается некий пародокс, простота достигается не короткими именами, а длинными.

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

Имена BizTalk приложений (Applications)

Это картинка Административной Консоли (BizTalk Administration Console):

BizTalkAdminConsole

Вы видите Visual Studio приложение (solution) GLD.Samples.Names.Shared.Schemas установлено (deployed) как  Names.Shared.Schemas приложение (application). Префикс GLD.Samples удален, так как все устновленные VS приложения используют этот префикс. Если все артифкты используют одну и ту же часть имени, эта часть совершенно однозначно может быть удалена. Не должна быть удалена, а может быть удлалена. Возникает вопрос, почему эта часть не удалена из имени приложения/проекта (solution/project)? Причина в том, что проекты и assemblies практически всегда именуются одинаково. Но assemblies работают в одном глобальном пространстве имен вместе с system, Microsoft и другими assemblies, в едином пространстве имен .NET run-time. В этом глобальном пространстве имен префикс GLD.Samples помогает нам находить наши assembles. Получается, что глобальное пространство имен assemblies вынуждает нас использовать этот префикс, что, в свою очередь, вынуждает нас использовать этот префикс для имен проектов. Это и есть обещанный ответ на второй вопрос. Smile

В результате я использовал соглашение с Короткими именами для имен BizTalk приложений. 

Насколько сложной может быть иерархия имен?

Для примера возьму имя GLD.Samples.Names.Shared.Schemas.Sap.AV_CREDIT_STATUS_MODIFY. Не слишком ли оно сложное и длинное?

Конечно оно длинное. Но сложное ли оно? Все части этого имени однозначно отражают иерархию объектов, и все части имени здесь нужны. Попробуйте выбросить какую-нибудь часть, чтобы уменьшить длину имени, и получите одни неприятности. Почему? Потому что придется создавать дополнительное соглашение об именах. Дополнительное соглашение стоит куда как больше, чем длина имени на весах суммарной сложности.

Иерархические соглашения об именах — короли в BizTalk разработке. Эти соглашения отражают группировку объектов. Иерархические соглашения работают хуже в тех областях, где объектов мало и они логически не связаны. Здесь лучше работают соглашения, основанные на ключевых словах (keys or tags).

Обычно мы видим такую картину:

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

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

Надеюсь, я ответил на первый вопрос.

Теперь ответ на третий вопрос. Сразу уточню, что этот вопрос относится только к BizTalk проектам.
Почему был использован суффикс _Ops для проектов SystemA, SystemB и SystemC?

 Например, почему было использовано имя GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck_Ops, а не имя GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck ?

Проблема с этим именем в том, что проект содержит схему с именем CreditCheck. Что плохого в этом, почему мы не не можем использовать одинаковое слово для части имени проекта и для схемы?

XML схема (XML schema) сериализуется в .NET класс и имя схемы сериализуется в имя класса. В результате мы имеем класс с полным именем (full qualified name) GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck.ChreditCheck. И когда мы компилируем проект мы получаем ошибку:

Error.SymbolXIsAlreadyDefined

Описание (description) ошибки могло бы быть чуть понятнее, что-нибудь типа: “symbol ‘GLD.Samples.Names.Shared.Schemas.SystemA.CreditCheck’ is already defined; the first definition is in assembly…”.

По какой-то причине .NET builder разбирает имена иногда слева направо, а иногда справа налево, что и приводит к подобным ошибкам.

Это деталь реализации, но мы вынуждены из-за нее изменить наше соглашение об именах. Имя схемы мы не можем изменить (это внешняя схема), а вот имя проекта мы изменить можем. Добавили _Ops (operations) и это разрешило конфликт одинаковых имен.

Выводы

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

Из моего опыта: идеальных Соглашений об именах не бывает, всегда надо исходить из разумных компромисов.

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

Filed under BizTalk, BizTalk course, Integration Architecture

BizTalk: Synchronous pattern. Really?

Последнее время стало модно делать интеграцию в асинхронном стиле. Ничего не блокируется, а значит хорошо масштабируется.  И крайний случай асинхронного стиля – ESB, Enterprise Service Bus, когда все данные перемещаются асинхронно.

Круто.

А на другом конце спектра – point-to-point интеграция, точечная. По крайней мере, если вы спросите об этом архитектора, то ESB много лучше point-to-point. И одна из главных причин в том, что ESB – асинхронна по сути, а point-to-point обычно в видет request-response, синхронна. С тем, что ESB лучше point-to-point я не соглашусь, но разговор здсь не об этом.

Если посмотреть в Википедии, полазить по книжкам, то окажется, что точного понятия синхонности и асинхронности в отношении ИТ и обмена данными нет.

Классическое определиение синхронности мало что нам даст. Синхронность, это когда время в раздельных точках установлено одинаково. В одном месте 54 минуты, 44 секунды и 234234 мили-микро и т.д секунд и в другом в этот же момент времени часы покажут те же цифры.

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

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

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

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

В качестве примера возьмем типичную задачу по интеграции двух систем, так называемый request-response. Одна система (А) запрашивает данные у другой системы (В). А посылает запрос в систему В, В обрабатывает данные и высылает результат обратно системе А.

На первый взгляд перед нами point-to-point интеграция, синхронный процесс. Так ведь?

А теперь подробнее.

BizTalk приемный порт (receive port) запускает процесс при появлении данных по адресу порта. Порт играет роль listener-а. Порт запускает отдельный message процесс под каждый запрос. Этот процесс обрабатывает запрос и записывает его в Почтовый Ящик (MessageBox) BizTalk.  Почтовый Ящик представляет из себя SQL Server базу данных, а с точки зрения системы по обработки сообщений он представляет из себя систему очередей. Почтовый Ящик – это сервер очередей сообщений. Send port (порт отправки) системы В является подписчиком для запросов из системы А. Запросы эти он получает из Почтового Ящика.  Порт получает новый запрос, после чего отправляет этот запрос в систему В и получает обратно ответ. Порт записывает ответ в Почтовый Ящик BizTalk. Приемный порт системы А является подписчиком для данного ответа. Он получает ответ из Почтового Ящика и отправляет его в систему А.

Таким образом данные два раза проходят через Почтовый Ящик. Сначала запрос, потом ответ.

Самое интересное в этом – очереди. Очереди по своей сути асинхронны.  Запрос и ответ не передаются в рамках одной сессии. Создаются от двух до четырех сессий: система А – приемный порт для запроса, порт отправки – система В для запроса, система В – порт отправки для ответа, приемный порт – система А для ответа. В зависимости от транспортного протокола сессии для запроса и ответа могут быть в рамках одной сессии, к примеру для HTTP протокола.

Любая передача сообщений через BizTalk асинхронна.

Архитектор, проектирующий интеграционную систему на базе BizTalk Server, должен понимать, что имеет дело с принципиально асинхронной системой.

В рассмотренном примере с точки зрения системы А передача данных, запрос и ответ, происходят в рамках одной сессии, передача выглядит синхронной. С точки зрения системы В передача данных тоже происходит в рамках одной сессии и также синхронно. На самом деле обе эти сессии замыкаются в рамках система – Почтовый Ящик.

Даже процессы, выглядящие на первый взгляд синхронными, в BizTalk Sever всегда реализуются на базе принципиально асинхронной системы, очереди сообщений – Почтового Ящика BizTalk.

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

Filed under BizTalk, Integration Architecture

BizTalk Summit 2012: возрождение

В Microsoft кончились разговоры о плавном перерождении BizTalk Server в Azure. Microsoft восстанавливает инвестирование в BizTalk в полном объеме (?) Ура!

Несколько факторов стали решающими:

  • Влияние проходящего, вяло текущего кризиса
  • Поднимающаяся волна обновлений версий BizTalk Server
  • Давление клиентов и партнеров
  • Microsoft стал зарабатывать на BizTalk

Все это мы узнали на прошедшем в Рэдмонде саммите, посвященном одному продукту Microsoft, BizTalk Server.

Cам факт этого саммита уже говорит о многом. Я не припоминаю подобных мероприятий в последнее время, посвященным отдельным продуктам.
Открывал конференцию большим докладом Scott Guthrie. Ничего конкретного я тут сказать не могу, саммит проходил на условиях NDA, т.е. почти все, что нам рассказывали, было секретом. То, что я здесь рассказываю, является результатом моих умозаключений и не представляет собою официальную точку зрения Microsoft.

Теперь поподробнее об этих самых факторах.

Кризис привел к большому числу банкротств и слияний.  Чем не повод к новым интеграционным проектам.  BizTalk хорошо показывает себя именно в ситуациях с большим числом разнообразных протоколов, программ, форматов, технологий.

Оканчивается срок гарантийной поддержки BizTalk Server 2006, той самой версии с которой и начался бум внедрений BizTalk. Старые версии работают по-прежнему надежно, но вот техника с тех пор прошла не один круг модернизации. Надо ставить новую технику, к которой есть запчасти. Это тянет за собою обновление операционной системы. А это приводит к тому, что надо менять и BizTalk Server, потому что старая версия BizTalk работает только на старой версии операционной системы. Обновили сервера, обновили ОС, обновили и BizTalk.

Microsoft несколько лет назад решило, что эволюционный путь технологий неизбежно приведет к перерождению BizTalk в набор сервисов, которые сейчас значатся под общим маркетинговым именем Azure. Но этого не произошло. И не из-за недостатков Azure, а по более глубоким причинам. Главные из которых, это надежность BizTalk и консерватизм рынка. Рынок у BizTalk – это рынок больших корпораций. Интеграция для них – не метод для бурного роста, для инноваций, совсем нет. Для них это — возможность повысить эффективность основных бизнес-процессов. А эти основные процессы в больших корпорациях очень консервативные. Они и должны быть такими, потому что они должны быть надежными, надежными и еще раз надежными. К примеру,  финансовые транзакции можно пропускать только через систему, которая уже доказала свою надежность многими годами работы. 12 лет BizTalk на этом рынке, и только в последние годы корпорации начали использовать его на жизненно-важных процессах. Пройдет еще лет 5 и они начнут серьезно рассматривать Azure, если она покажет себя  надежно.

BizTalk очень часто – первая серверная система от Microsoft, которая проникает в большую корпорацию. До него там работали только мэйнфреймы, IBM, Oracle, SAP. И BizTalk играет роль тарана, пробивающего брешь в мощной и серьезной обороне. Специалисты этих корпораций убеждаются, что Microsoft, несмотря на “детские” по их масштабам цены, поставляет серверные системы со взрослыми характеристиками. За BizTalk следуют SQL Server, Windows Server. Оброна прорвана. И Microsoft начинает ощущать это с помощью хорошего датчика, своего банковского аккаунта.

Корпорациям не нужны иновации ради иноваций, им важнее гарантии, что купленная система будет стабильно развиваться и будет обеспечена поддержкой на многие годы вперед. Корпорациям не нужны не подтвердившие свою надежность и стабильность Azure, cloud (пока не подтвердившие). Им нужны от Microsoft стабильные инвестиции в BizTalk, SQL, Winsows.

А что надо для счастливой жизни интеграцинной системы, что надо для счастливой жизни BizTalk Server? Нужны умные головы, которые будут работать над системой долгие годы за хорошие деньги. Общее впечатление от саммита как раз в этом, хорошая команда с большими амбициями собрана в Microsoft на дальнейшее развитие BizTalk Server.

Вот такие оптимистичные настроения навеял на меня прошедший BizTalk Summit 2012.

1 комментарий

Filed under BizTalk, Заметки, Microsoft, MVP

BizTalk: маппинг с помощью Xslt

BizTalk Map редактор (Mapper) — хороший редактор, особенно в последней 2010 версии. Но и он иногда не справляется с некоторыми видами маппинга. Когда это случается, самое время вспомнить про Xslt код. Самое время вспомнить, что maps базируются на Xslt коде и выполняются с помощью Xslt парсера.

Щелкните правой клавишей по Mapper Grid (полю между схемами) и выберите команду Properties /Custom XSLT Path.  Введите имя файла с Xslt кодом. Теперь будет выполняться только код из этого файла, забудьте про все связи и функтоиды на картинке Маппера.

Вот пример из реального проекта.

Посмотрим налево на исходную схему. В ней есть два исходных адреса (Address_1, Address_2, City, Zip). Один на верхнем уровне исходной схемы, другой на внутри записи Member_Address с параметром MaxOccurs=* (это означает, что запись может повторяться неограниченное количество раз).

Результирующий адрес расположен внутри записи Locator также с параметром MaxOccurs=*.

Map.Pict

Нам надо трансформировать все исходные структуры адреса в одну результирующую структуру.

К примеру, исходный XML документ выглядит так:

Source.Xml

Тогда результирующий XML документ должен выглядеть так:

Output.Xml

То есть один адрес верхнего уровня и два адреса нижнего уровня преобразовались в три адреса на одном и том же уровне.

Если мы попробуем сделать маппинг в Маппере с помощью связей и фанктоидов, то потратим много времени, а в результате получим запутанную картинку, разобраться в которой будт чрезвычайно сложно. Основное преимущество графического представления будет утеряно.

Попробуем сделать это же с помощью Xslt кода и получим простой и однозначный маппинг:

Xslt

Просто и элегантно.

Комментарии (4)

Filed under BizTalk, BizTalk course

BizTalk: Последовательная доставка сообщений

Это еще одно описание Последовательной Доставки сообщений [Ordered Delivery -  OD] в BizTalk Server.

Здесь английская версия. Английская версия, но уже в TechNet.

Главное описание OD — на MSDN.

Здесь я обсуждаю детали реализации OD.

Замечания по поводу OD

  • OD режим (режим упорядоченной, последовательной доставки) противоположен режему Параллельной Доставки. Параллельная доставка — это самый производительный режим; OD — менее продуктивный режим.
  • Протоколы, поддерживающие стандарт WS-ReliableMessaging и протоколы, такие как MSMQ, сами по себе поддерживают OD. Другие протоколы, такие как  FTP, File, SQL, SMTP, не имеют понятия о каком-либо «порядке»в последовательностях.
  • Обычно приложение BizTalk-a — это только часть полного маршрута на пути доставки сообщений.
  • Есть два основных подхода к реализации OD:
    • Все шаги на всем маршруте доставки сообщения поддерживают OD независимо друг от друга.
    • Система, которая является потребителем сообщений, сама восстановливает порядок сообщений, сама беспокоится о потерянных сообщениях и о дублированных сообщениях. Канал доставки сообщений может поддерживать OD и может не поддерживать OD.
  • Порядок — понятие относительное. Последовательности могут строиться относительно только одного или нескольких параметров. Например, порядок сообщений может поддерживаться только относительно сообщений, относящийся к одним и тем же компаниям, либо компаниям + отделам внутри компаний.

OD и архитектура BizTalk

  • MessageBox — это реализация Очереди Сообщений (Message Queue). OD — это одна из внутренних характеристик MessageBox.
  • BizTalk по умолчанию работает в режиме Параллельной Доставки.
  • Есть три части в архитектуре обработки сообщений BizTalk-а, не относящихся к MessageBox: Receive Locations; Orchestrations; Send порты.
    • Receive Locations поддерживают OD на уровне транспортных протоколов (к примеру,  в MSMQ и WCF адаптерах).
    • OD в Orchestrations реализовано с помощью шаблона Последовательных Конвоев (sequential convoy pattern).
    • Send порты поддерживают OD для всех статических адаптеров.
  • BizTalk Pipelines (входящие в состав Receive и Send портов) всегда обрабатывают сообщения последовательно, используя потоки (streams).

OD и порты

Чтобы заставить Receive Locations работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Receive Location Transports, в тех транспортах, где это поддерживается. Если этот параметр установлен, BizTalk Adapter для соответствующего транспортного протокола автоматически обеспечивает реализацию OD.

Чтобы заставить Send порты работать в режиме OD, мы устанавливаем параметр  “Ordered Delivery” в Send портах. Если этот параметр установлен, BizTalk MessageBox автоматически обеспечивает реализацию OD.

OD Send Port instance работает как singleton сервис, т.е.сервис, который может быть запущен только в единственном экземпляре. После того, как он стартует, он постоянно остается в рабочем режиме (Running state). Он не изменит режим, если мы сделаем рестарт его Host Instance. Если надо, мы можем вручную удалить этот сервис, но по умолчанию он работает неограниченно долго.

OD и Orchestrations

MessageBox реализует шаблон Последовательного Конвоя, чтобы обеспечить OD.  [См.Using Correlations in Orchestrations]. Смотрите детальное описание этого шаблона здесь BizTalk Server 2004 Convoy Deep Dive.
Это не просто шаблон, которому должны следовать разработчики при создании Orchestration. Внутри MessageBox реализованы специальные механизмы, поддерживающие этот шаблон.

OD и Orchestration: Пример

Рассмотим четыре Orchestrations, реализующих разные подходы в последовательной доставке сообщений.

Первое — ProcessNoOrder Orchestration. На рисунке это сервисы находящиеся в колонке All in Parallel. Оно обрабатывает все сообщения без всякого порядка. По одному экземпляру ProcessNoOrder Orchestration будет создаваться для обработки каждого нового входящего сообщения.

Последнее — ProcessInOrder Orchestration обрабатывает все сообщения в одной последовательности.  На рисунке это сервисы находящиеся в колонке All in Order. Только один экземпляр ProcessInOrder Orchestration будет создан и все сообщения будут обрабатываться им по очереди.

ProcessInOrderByCompany Orchestration обрабатывает сообщения в нескольких последовательностях, собранных (кореллированных) (correlated) в соответствии со значением параметра Company (A, B, C, D и т.д.). Отдельная очередь создается для каждого нового значения Company. Сообщения внутри очередей обрабатываются последовательно. Очереди для разных Companies независимы. Отдельный экземпляр ProcessInOrderByCompany Orchestration будет создаваться для каждого нового значения Company.

ProcessInOrderByProduct Orchestration работает абсолютно так же, как и ProcessInOrderByCompany Orchestration но очереди собираются в соответствии со значением параметра Product (xx, yy и т.д.).

В Orchestration мы можем настроить производительность системы для последовательной доставки сообщений. Это не только два режима: максимальной производительности и без всякого порядка или минимальной производительности для всех подряд сообщений. Производительность можно регулировать, задавая порядок по некоторым параметрам, группируя сообщения в отдельные очереди.

Обсуждение

Быстродействие

По умолчанию все экземпляры Orchestration и Messaging сервисов работают в режиме Parallel Delivery, обеспечиая тем самым максимальную производительность.

Если включить режим Ordered Delivery в Send порту, BizTalk будет инициировать экземпляр Send порта как единственный (singleton) сервис. Он будет запускаться всегда только в единственном экземпляре. У нас здесь нет гибкости, которую мы имеем с Orchestration, где мы можем настроить «степень параллельности» и где мы можем контролировать время жизни экземпляров.

Send порт может работать в двух OD режимах, может быть в двух состояниях,  включен или выключен:

  • OD выключен: много экземпляров порта, по одному на каждое входное сообщение; одно сообщение на очередь; максимальная производительность.
  • OD включен: всегда только один экземпляр порта на все сообщения; все сообщения в одной очереди; минимальная производительность.

Orchestration может работать также в двух OD режимах OD. Чтобы «изменить» режим, нам надо изменить дизайн Orchestration. Это не просто изменение одного параметра в настройках.

  • OD выключен: много экземпляров Orchestration, по одному на каждое активирующее входное сообщение; одно активирующее сообщение на очередь; максимальная производительность.
  • OD включен: один или несколько экземпляров Orchestration, один на каждую новую коррелированную последовательность сообщений; одна очередь на каждую такую последовательность; производительность от минимальной до максимальной, в зависимости от коррелирующих параметров.

Тщательно спроектировав коррелирующий набор параметров мы можем настроить производительность Orchestration. Например, если мы хотим, чтобы все документы, относящиеся к одной компании, обрабатывались последовательно, мы включаем параметр НазваниеКомпании в коррелирующий набор. Если на тысячу документов приходится сотня компаний, то производительность будет ближе к максимальной. Но если есть только две компании, то производительность будет ближе к минимальной, так как в первом случае документы будут обрабатывать сотня экземпляров Orchestration, а во втором — только два экземпляра. Чтобы увеличить производительность для второго варианты, мы можем добавить в коррелирующий набор дополнительный параметр, к примеру Отдел. В результате будет больше уникальных сочетаний НазваниеКомпании +НазваниеОтдела и будет стартовать больше экземпляров Orchestration.

Orchestrations и Зомби

Так называемые Зомби — это специфическая проблема шаблона Последовательных Конвоев. (См. BizTalk: Instance Subscription and Convoys: Details статью с описанием этой проблемы.) Эта проблема может быть уменьшена, но не может быть полностью устранена. Мы ожидаем, что в новой версии BizTalk Server эта проблема будет решена.

BizTalk Server version Next, Последовательная доставки и Зомби

Есть вероятность, что BizTalk Server version Next добавит автоматический режим OD в Orchestrations, реализует шаблон, подобный реализованному в Send портах.

Мы увидим три новых параметра в Orchestration: Ordered Delivery, Stop on Exception, и Recycle Interval (in seconds).

Параметр Ordered Delivery работает очень похоже на такой же параметр в Send порту. Теперь нам не надо вручную строить Последовательный Конвой. Не нужен больше Цикл (Loop) внутри  Orchestration.

Было бы замечательно, если бы эти параметры были бы доступны в run-time.

Если параметр Ordered Delivery установлен как True, Orchestration работает как Singleton. Первый Receive будет принимать все коррелированные сообщения в последовательнсти. Коррелирующий набор создается неявно в соответствии с Акривирующим Subscription выражением (Activation Subscription expression).

Есть несколько ограничений по построению Orchestration, работающих в этом режиме. Одно из главных заключается в том, что только один Receive shape разрешен в таком Orchestration.

Есть два больших преимущества в новом режиме:

  • Это значительно упрощает создание Orchestration, обеспечивающих Последовательную Доставку сообщений.
  • Это нивелирует проблему с Зомби. Теперь жизненный цикл экземпляра Orchestration более контролируем. Экземпляр удаляется (recycled) только тогда, когда в MessageBox нет сообщений, стоящих в очередь к этому экземпляру.

Заключение

Мы обсудили реализацию Последовательной Доставки сообщений в BizTalk Server и возможные пути по ее улучшению.

1 комментарий

Filed under BizTalk