http://ganeline.wordpress.com/ - добро пожаловать на новое место!
На этом хосте статьи больше не обновляются!
2008-11-23
2008-11-22
Архитектура BizTalk
Здесь английская версия статьи: http://geekswithblogs.net/LeonidGaneline/archive/2006/12/18/101541.aspx
Когда я начал работать с BizTalk, я начал строить в голове разные модели того, что происходит с сообщениями внутри BizTalk. С каждой новой итерацией получалась другая модель.
[Далее я не перевожу на русский язык основные термины BizTalk-а: Receive Location, Send Port, Orchestration, MessageBox и т.д. Иначе получится полная мешанина, когда вы обратитесь к документации BizTalk.]
Назовем эту модель «Принять - Передать».
Ясно, что речь здесь идет об отправлении и приемке сообщений.
Выглядит, как будто Receive Locations – это приемники сообщений, Send Ports – передатчики сообщений, а Orchestrations являются одновременно приемниками и передатчиками. Правильно?
Неверно. Все объекты являются как приемниками, так и передатчиками.
Receive Locations получают сообщения из «внешнего мира» и потом отправляют их в Message Box.
Send Ports получают сообщения из Message Box и передают их дальше, во «Внешний мир».
Orchestrations получают сообщения из Message Box и передают их дальше. Куда? Опять в Message Box.
Message Box получает сообщения от Receive Locations или от Orchestrations и передает их в Send Ports или снова в Orchestrations.
В BizTalk Help есть описание другой модели, Издатель-Подписчик (Publisher-Subscriber). Но большая часть внимания в Help уделена именно модели Принять-Передать.
Термины передать и принять продолжали смущать меня.
Для иллюстрации неоднозначности терминов принять и передать в контексте BizTalk, посмотрим на цитату из книги «Pro BizTalk 2006», написанной George Dunphy и Ahmed Metwally, страница 119:
« ... The left side shows the sender configuration, which consists of a static one-way send port to send the business document or message and a static one-way receive port to receive BizTalk Framework 2.0 delivery receipts. The right side shows the receiver configuration, which contains a static one-way receive port to receive the message and a dynamic one-way send port that... »
В переводе:
« …Левая часть показывает передающую конфигурацию, которая состоит из статического одностороннего передающего порта и статического одностороннего принимающего порта. Эта конфигурация получает BizTalk Framework 2.0 подтверждения доставки. Правая часть показывает принимающую конфигурацию, которая состоит из статического одностороннего принимающего порта и динамического одностороннего передающего порта…»
(Я выделил смущающие меня термины.)
Вас не смущает то, что передающая конфигурация и предает, и принимает сообщения? Так же, как и принимающая конфигурация.
Хорошо, давайте обсудит эту неоднозначность. Термины передать и принять означают… Хмммм, они означают одно и то же.
Мы передаем сообщение? Да. И ОДНОВРЕМЕННО мы принимаем сообщение.
Эти термины имеют смысл ТОЛЬКО, если они используются ВМЕСТЕ с субъектом или объектом операции.
Сообщение передается? В этом вопросе нет смысла. Мы отправляем сообщение в приемник и из передатчика.
Сообщение принимается? Нет смысла. Сообщение принимается от передатчика и в приемник.
Попробуем использовать другие термины, такие, как публиковать и подписываться.
Эти термины в контексте BizTalk всегда означают «относительно MessageBox».
Термины передать и принять не имеют такого смысла.
Я не хочу полностью отказываться от этих терминов. Но они должны использоваться только вместе с объектом или субъектом операции, соответственно.
После того, как я сделал изменения, получилась вторая версия модели:
Здесь я выдвинул термины Subscriber и Publisher на первое место модели.
Эта модель явным образом «Message Box - центрированная», если можно так выразиться.
Publishers передают сообщения в Message Box. Subscribers принимают сообщения из Message Box.
Все действия происходят вокруг Message Box.
Publishers передают сообщения с определенным типом в Message Box. Тип сообщения в BizTalk определяется, как объединение значений namespace и имя корневого узла (namespace + root_node). Речь идет, конечно, о сообщении в формате XML, так как все сообщения внутри BizTalk имеют формат XML. Subscribers принимают из Message Box только те сообщения, которые проходят через фильтр конкретной подписки (Filter expression).
В этой модели Receive Locations и Send Shapes в Orchestrations размещаются в группе Publishers, а Send Ports и Receive Shapes размещаются в группе Subscribers.
Давайте посмотрим, как термин Binding накладывается на эту модель.
Я получил такую модель.
Подписка для Binding создается за сценой. В большинстве случаев Publishers ID используется как Filter expression.
Термин Binding используется здесь для описания связи между Orchestration и Port.
Насколько я понимаю, этот термин был создан для упрощения модели, для автоматизации работы с созданием наиболее простой и наиболее часто используемой операции, когда сообщения передаются из одной четко определенной точки в другую точно определенную точку. Binding создает 1-1 связь, когда один Publisher должен передать сообщения одному Subscriber. Binding делает шаг в сторону от «чистой» модели Publisher-Subscriber (издатель-подписчик), которая заложена в основе BizTalk, и реализует один из часто используемых шаблонов передачи сообщений (Direct Link).
Publishers и Subscribers в чистой модели Publisher-Subscriber не знают ничего друг о друге и не должны знать. Publishers отправляют сообщения в Message Box, а Subscribers извлекают сообщения из Message Box, опираясь на параметры подписки.
Binding делает модель более сложной. Binding упрощает выполнение одной конкретной операции, но при этом усложняет модель.
Чистая Publisher-Subscriber модель в BizTalk доступна с помощью так называемого Direct port.
Ниже очередная версия модели:
----------------------------------
Когда я начал работать с BizTalk, я начал строить в голове разные модели того, что происходит с сообщениями внутри BizTalk. С каждой новой итерацией получалась другая модель.
[Далее я не перевожу на русский язык основные термины BizTalk-а: Receive Location, Send Port, Orchestration, MessageBox и т.д. Иначе получится полная мешанина, когда вы обратитесь к документации BizTalk.]
Все началось с традиционной модели:
Назовем эту модель «Принять - Передать».
Ясно, что речь здесь идет об отправлении и приемке сообщений.
Выглядит, как будто Receive Locations – это приемники сообщений, Send Ports – передатчики сообщений, а Orchestrations являются одновременно приемниками и передатчиками. Правильно?
Неверно. Все объекты являются как приемниками, так и передатчиками.
Receive Locations получают сообщения из «внешнего мира» и потом отправляют их в Message Box.
Send Ports получают сообщения из Message Box и передают их дальше, во «Внешний мир».
Orchestrations получают сообщения из Message Box и передают их дальше. Куда? Опять в Message Box.
Message Box получает сообщения от Receive Locations или от Orchestrations и передает их в Send Ports или снова в Orchestrations.
В BizTalk Help есть описание другой модели, Издатель-Подписчик (Publisher-Subscriber). Но большая часть внимания в Help уделена именно модели Принять-Передать.
Термины передать и принять продолжали смущать меня.
Для иллюстрации неоднозначности терминов принять и передать в контексте BizTalk, посмотрим на цитату из книги «Pro BizTalk 2006», написанной George Dunphy и Ahmed Metwally, страница 119:
« ... The left side shows the sender configuration, which consists of a static one-way send port to send the business document or message and a static one-way receive port to receive BizTalk Framework 2.0 delivery receipts. The right side shows the receiver configuration, which contains a static one-way receive port to receive the message and a dynamic one-way send port that... »
В переводе:
« …Левая часть показывает передающую конфигурацию, которая состоит из статического одностороннего передающего порта и статического одностороннего принимающего порта. Эта конфигурация получает BizTalk Framework 2.0 подтверждения доставки. Правая часть показывает принимающую конфигурацию, которая состоит из статического одностороннего принимающего порта и динамического одностороннего передающего порта…»
(Я выделил смущающие меня термины.)
Вас не смущает то, что передающая конфигурация и предает, и принимает сообщения? Так же, как и принимающая конфигурация.
Хорошо, давайте обсудит эту неоднозначность. Термины передать и принять означают… Хмммм, они означают одно и то же.
Мы передаем сообщение? Да. И ОДНОВРЕМЕННО мы принимаем сообщение.
Эти термины имеют смысл ТОЛЬКО, если они используются ВМЕСТЕ с субъектом или объектом операции.
Сообщение передается? В этом вопросе нет смысла. Мы отправляем сообщение в приемник и из передатчика.
Сообщение принимается? Нет смысла. Сообщение принимается от передатчика и в приемник.
Попробуем использовать другие термины, такие, как публиковать и подписываться.
Эти термины в контексте BizTalk всегда означают «относительно MessageBox».
Термины передать и принять не имеют такого смысла.
Я не хочу полностью отказываться от этих терминов. Но они должны использоваться только вместе с объектом или субъектом операции, соответственно.
После того, как я сделал изменения, получилась вторая версия модели:
Здесь я выдвинул термины Subscriber и Publisher на первое место модели.
Эта модель явным образом «Message Box - центрированная», если можно так выразиться.
Publishers передают сообщения в Message Box. Subscribers принимают сообщения из Message Box.
Все действия происходят вокруг Message Box.
Publishers передают сообщения с определенным типом в Message Box. Тип сообщения в BizTalk определяется, как объединение значений namespace и имя корневого узла (namespace + root_node). Речь идет, конечно, о сообщении в формате XML, так как все сообщения внутри BizTalk имеют формат XML. Subscribers принимают из Message Box только те сообщения, которые проходят через фильтр конкретной подписки (Filter expression).
В этой модели Receive Locations и Send Shapes в Orchestrations размещаются в группе Publishers, а Send Ports и Receive Shapes размещаются в группе Subscribers.
Давайте посмотрим, как термин Binding накладывается на эту модель.
Я получил такую модель.
Binding = неявная подписка
[the Binding = the Implicit Subscription]
Подписка для Binding создается за сценой. В большинстве случаев Publishers ID используется как Filter expression.
Термин Binding используется здесь для описания связи между Orchestration и Port.
Насколько я понимаю, этот термин был создан для упрощения модели, для автоматизации работы с созданием наиболее простой и наиболее часто используемой операции, когда сообщения передаются из одной четко определенной точки в другую точно определенную точку. Binding создает 1-1 связь, когда один Publisher должен передать сообщения одному Subscriber. Binding делает шаг в сторону от «чистой» модели Publisher-Subscriber (издатель-подписчик), которая заложена в основе BizTalk, и реализует один из часто используемых шаблонов передачи сообщений (Direct Link).
Publishers и Subscribers в чистой модели Publisher-Subscriber не знают ничего друг о друге и не должны знать. Publishers отправляют сообщения в Message Box, а Subscribers извлекают сообщения из Message Box, опираясь на параметры подписки.
Binding делает модель более сложной. Binding упрощает выполнение одной конкретной операции, но при этом усложняет модель.
Чистая Publisher-Subscriber модель в BizTalk доступна с помощью так называемого Direct port.
Ниже очередная версия модели:
Здесь я изобразил Orchestration из двух частей. В предыдущей модели Send и Receive Shapes были в одной Orchestration, что неправильно.
Я изобразил Shapes и Port/Locations одинакового размера. Я чувствую, что Orchestrations не должны быть «больше», чем Ports.
Я добавил «Внешний мир» («Outer World»). Почему бы нет!?
Теперь это Publisher-Subscriber model.
Я изобразил Shapes и Port/Locations одинакового размера. Я чувствую, что Orchestrations не должны быть «больше», чем Ports.
Я добавил «Внешний мир» («Outer World»). Почему бы нет!?
Теперь это Publisher-Subscriber model.
Выводы:
* Модель «Принять – Передать» резко усложняет восприятие архитектуры BizTalk. Не используйте термины отправить и принять (Receive и Send) для описания движения сообщений. Лучше используйте термины издать и подписаться (Publish и Subscribe).
* Подходите критически к BizTalk Help, так как там термины receive и send используются бессистемно.
* Binding надо использовать на втором уровне обучения BizTalk. Этот термин усложняет вещи, когда используется для маскировки Publisher-Subscriber модели. Описание операций с сообщениями без использования этого термина облегчает жизнь.
2008-11-16
Пример применения Microsoft BizTalk Server: аптечная сеть
Пример применения Microsoft BizTalk Server: Аптечная сеть
-------------------------------------------
Описание имеющейся системы
Аптечная сеть состоит из головного офиса, нескольких главных складов, десятков региональных складов и сотен аптек.
Все эти места оснащены выделенным или dial-up интернетом, локальными сетями. В каждом месте работают одна или несколько десятков программ. Документооборот в аптечной сети очень большой, так как подвергается жесткой законодательной регуляции. Буквально каждое лекарство сопровождается несколькими документами.
Описание проблемы
Документы, передаваемые в аптечной сети, являются частью разнообразных бизнес процессов.
К примеру, покупатель делает заказ лекарства. Данное лекарство есть только в одном из региональных складов. Лекарство надо доставить в аптеку, ближайшую к покупателю.
Требуется координировать множество операций, как то, отслеживание оплаты, перемещение заказа между складами и аптекой, восстановление складского запаса.
Требуется обеспечить передачу документов в аптечной сети в условиях ненадежной связи, когда узлы сети временно недоступны, когда данные могут передаваться с ошибками.
Требуется согласовать различные форматы данных при передачи их межу разными программами.
Различные архитектурные решения
«По течению»
Автоматизация бизнес процессов делается по мере появления требований. К примеру потребовалось передавать какой-то документ из аптечной программы в складскую программу. Для этого делается отдельная программа, которая согласовывает формат передачи данных, синхронизирует передачу данных. Потребовалось передать другой документ – пишется другая программа.
Преимущества данного подхода в том, что он достаточно оперативен, не требует системного подхода, часто самый дешевый.
Недостатки в том, что с течением времени система, состоящая из множества самодельных интеграционных программ, становится все более сложным, дорогим и ненадежным. Каждая программа уникальна, поэтому любое изменение в ней не оперативно, дорого и ненадежно. Наступает момент, когда вся система становится мало управляемой, когда никто не знает, как она работает и как ее можно изменять. Сложность всей системы растет экспоненциально.
Корпоративный стандарт
Утверждается набор стандартов. Стандарты для форматов данных, стандарты на используемые технологии, стандарты на используемые в разработке и в работе программы.
Например, для передачи данных определяется стандартный формат сообщений. Каждое сообщение дополняется служебной информацией: уникальный идентификатор сообщения, время создания сообщения, параметры передающей стороны (ФИО создателя документа, адрес, дата, время и т.п.), параметры адресата и т.п.
Создаются стандартные программы, работающие со стандартными сообщениями. К примеру, программы, передающие сообщения в локальных сетях и в интернете, кодирующие сообщения с соблюдением корпоративных стандартов безопасности.
Утверждаются технологии, разрешенные к использованию. К примеру, разрешается использование в разработке только Visual Basic .NET, .NET версии 2.0, Веб-сервисы asmx. Разрешается использование стандарта SOAP 1.1. Разрешается использование Microsoft SQL Server 2005 для баз данных.
Преимущества этого подхода в том, что количественно система хорошо масштабируется, то есть добавление новых документов, новых процедур обработки документов делается в предсказуемые сроки и с предсказуемым качеством. С течением времени сложность системы увеличивается практически линейно.
Недостатки этого подхода в том, что добавление новых, современных технологий и стандартов индустрии в систему происходит крайне медленно и сложно. Система плохо адаптирует новые технологии, поэтому с течением времени развитие системы идет дороже и медленнее, чем по индустрии в целом.
Внедрение данной архитектуры требует значительных административных, финансовых и технических затрат, происходит медленно. Из-за этого оно часто не доходит до реального завершенного внедрения, а кончается внедрением лишь части стандартов.
Поддержание данной архитектуры в рабочем виде тоже постоянно требует больших усилий.
Интеграционная платформа
Создается или покупается «промежуточный слой». На него возложены функции согласования данных, координации обмена данных, синхронизация обмена данных, обеспечение надежности передачи данных.
Документы «путешествуют» в системе всегда через этот промежуточный слой.
Там, где это выгодно, используется стандартизация.
Преимущества этого подхода в том, что большая часть проблем, возникающих в интеграции данных, решается средствами промежуточного слоя. Согласование форматов данных, координация данных и процессов, обеспечение надежной передачи данных.
Архитектура легко дополняется новыми, современными стандартами и технологиями, как правило, простым подключением дополнительных модулей.
Недостатки этого подхода в том, интеграционная платформа требует значительных начальных финансовых и технических затрат. Покупка готовой интеграционной платформы, такой как IBM WebSphere или Microsoft BizTalk Server помогает максимально быстро запустить в работу промежуточный интеграционный слой.
Использование BizTalk Server
С точки зрения BizTalk Server система аптечной сети не представляет из себя особой сложности. Большая часть интеграционных задач решается базовыми средствами BizTalk без использования сложных техник.
Система не требует быстрого времени реакции, документы могут обрабатываться в течении секунд или минут.
Разработка и внедрение обычно делается в несколько этапов. Требования к системе сильно изменяются после внедрения каждого из этапов, когда заказчик знакомится с возможностями системы.
При оценке внедрения можно использовать следующую методику расчета затрат:
Стоимость системы = (затраты на покупку ПО и оборудования) * (4..6)
-------------------------------------------
Описание имеющейся системы
Аптечная сеть состоит из головного офиса, нескольких главных складов, десятков региональных складов и сотен аптек.
Все эти места оснащены выделенным или dial-up интернетом, локальными сетями. В каждом месте работают одна или несколько десятков программ. Документооборот в аптечной сети очень большой, так как подвергается жесткой законодательной регуляции. Буквально каждое лекарство сопровождается несколькими документами.
Описание проблемы
Документы, передаваемые в аптечной сети, являются частью разнообразных бизнес процессов.
К примеру, покупатель делает заказ лекарства. Данное лекарство есть только в одном из региональных складов. Лекарство надо доставить в аптеку, ближайшую к покупателю.
Требуется координировать множество операций, как то, отслеживание оплаты, перемещение заказа между складами и аптекой, восстановление складского запаса.
Требуется обеспечить передачу документов в аптечной сети в условиях ненадежной связи, когда узлы сети временно недоступны, когда данные могут передаваться с ошибками.
Требуется согласовать различные форматы данных при передачи их межу разными программами.
Различные архитектурные решения
«По течению»
Автоматизация бизнес процессов делается по мере появления требований. К примеру потребовалось передавать какой-то документ из аптечной программы в складскую программу. Для этого делается отдельная программа, которая согласовывает формат передачи данных, синхронизирует передачу данных. Потребовалось передать другой документ – пишется другая программа.
Преимущества данного подхода в том, что он достаточно оперативен, не требует системного подхода, часто самый дешевый.
Недостатки в том, что с течением времени система, состоящая из множества самодельных интеграционных программ, становится все более сложным, дорогим и ненадежным. Каждая программа уникальна, поэтому любое изменение в ней не оперативно, дорого и ненадежно. Наступает момент, когда вся система становится мало управляемой, когда никто не знает, как она работает и как ее можно изменять. Сложность всей системы растет экспоненциально.
Корпоративный стандарт
Утверждается набор стандартов. Стандарты для форматов данных, стандарты на используемые технологии, стандарты на используемые в разработке и в работе программы.
Например, для передачи данных определяется стандартный формат сообщений. Каждое сообщение дополняется служебной информацией: уникальный идентификатор сообщения, время создания сообщения, параметры передающей стороны (ФИО создателя документа, адрес, дата, время и т.п.), параметры адресата и т.п.
Создаются стандартные программы, работающие со стандартными сообщениями. К примеру, программы, передающие сообщения в локальных сетях и в интернете, кодирующие сообщения с соблюдением корпоративных стандартов безопасности.
Утверждаются технологии, разрешенные к использованию. К примеру, разрешается использование в разработке только Visual Basic .NET, .NET версии 2.0, Веб-сервисы asmx. Разрешается использование стандарта SOAP 1.1. Разрешается использование Microsoft SQL Server 2005 для баз данных.
Преимущества этого подхода в том, что количественно система хорошо масштабируется, то есть добавление новых документов, новых процедур обработки документов делается в предсказуемые сроки и с предсказуемым качеством. С течением времени сложность системы увеличивается практически линейно.
Недостатки этого подхода в том, что добавление новых, современных технологий и стандартов индустрии в систему происходит крайне медленно и сложно. Система плохо адаптирует новые технологии, поэтому с течением времени развитие системы идет дороже и медленнее, чем по индустрии в целом.
Внедрение данной архитектуры требует значительных административных, финансовых и технических затрат, происходит медленно. Из-за этого оно часто не доходит до реального завершенного внедрения, а кончается внедрением лишь части стандартов.
Поддержание данной архитектуры в рабочем виде тоже постоянно требует больших усилий.
Интеграционная платформа
Создается или покупается «промежуточный слой». На него возложены функции согласования данных, координации обмена данных, синхронизация обмена данных, обеспечение надежности передачи данных.
Документы «путешествуют» в системе всегда через этот промежуточный слой.
Там, где это выгодно, используется стандартизация.
Преимущества этого подхода в том, что большая часть проблем, возникающих в интеграции данных, решается средствами промежуточного слоя. Согласование форматов данных, координация данных и процессов, обеспечение надежной передачи данных.
Архитектура легко дополняется новыми, современными стандартами и технологиями, как правило, простым подключением дополнительных модулей.
Недостатки этого подхода в том, интеграционная платформа требует значительных начальных финансовых и технических затрат. Покупка готовой интеграционной платформы, такой как IBM WebSphere или Microsoft BizTalk Server помогает максимально быстро запустить в работу промежуточный интеграционный слой.
Использование BizTalk Server
С точки зрения BizTalk Server система аптечной сети не представляет из себя особой сложности. Большая часть интеграционных задач решается базовыми средствами BizTalk без использования сложных техник.
Система не требует быстрого времени реакции, документы могут обрабатываться в течении секунд или минут.
Разработка и внедрение обычно делается в несколько этапов. Требования к системе сильно изменяются после внедрения каждого из этапов, когда заказчик знакомится с возможностями системы.
При оценке внедрения можно использовать следующую методику расчета затрат:
Стоимость системы = (затраты на покупку ПО и оборудования) * (4..6)
Subscribe to:
Comments (Atom)