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)
2008-10-14
Обзор книги «MCTS Self-Paced Training Kit (Exam 70-503): Microsoft .NET Framework 3.5 Windows Communication Foundation (PRO-Certification)»
Обзор книги «MCTS Self-Paced Training Kit (Exam 70-503): Microsoft .NET Framework 3.5 Windows Communication Foundation (PRO-Certification)» http://www.amazon.com/MCTS-Self-Paced-Training-70-503-PRO-Certification/dp/0735625654/ref=sr_1_12?ie=UTF8&s=books&qid=1224042536&sr=8-12
Что мне нравится в книгах этой серии, так это то, что теория всегда закачивается практическими примерами. И примеры эти показывают реальные проблемы, ситуации.
Это сильно отличается от документации, где все функции продукта просто перечислены без расстановки приоритетов. В книгах серии Self-Paced Training Kit (СПТК) нет места, чтобы излагать все функции, цели здесь другие. Здесь даются только ОСНОВНЫЕ функции и показываются цепочки действий для достижения *реального* результата. К примеру, часть о MessageContract. В документации по WCF масса информации об этом типе контракта, но чрезвычайно трудно понять, для чего же вообще (!) можно его использовать. В СПТК дан *конкретный* пример, где MessageContract используется для передачи лицензионного ключа. Все становится понятно.
Я работаю с Web-сервисами больше 3х лет, последний год исключительно с WCF сервисами. Книгу я использовал не для сдачи экзамена, а для систематизации своих знаний. (Здесь дискуссия о пользе сертификационных экзаменов http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3280207&SiteID=1)
Я использую любой источник информации, для того, чтобы *понять*, что происходит внутри продукта, почему данные конкретные функции были введены в продукт, какие альтернативы есть. Почему? Без ответов на этот вопрос, информация просто не укладывается в моей голове. Я не могу как обезьянка выучить действия, приводящие к результату. Мне надо знать, *почему*.
В любой методике объяснений немаловажную часть занимают объяснения *неправильного* использования, примеров *неправильных* техник. Не давая Cons, очень тяжело рассказать о Pros. Иногда десяток примеров правильного использования продукта не заменит одного примера "неправильного" использования.
Чем серия СПТК серия отличается от других книг издания Microsoft:
* в книгах этой серии приведен только *основной* функционал продуктов. На описание всего там нет места. Этот функционал выбран с точки зрения Microsoft, то есть с точки зрения производителя. И это важно.
* в них приведены примеры *реальных проблем* и как они решаются с помощью основного функционала продукта.
* в книгах сжато рассказано, что послужило основанием для создания именно этого функционала.
* здесь приведены примеры *неправильного* использования.
Pros:
* По сути СПТК - видение Microsoft о том, для чего замышлялся продукт, какие основные шаблоны его использования.
* в разделах Lessons приведена концентрированная информация об основных характеристиках WCF. Рядом находятся примеры из практики. Примеры тоже концентрируют на самых необходимых вещах.
* Мне очень нравятся разделы Lesson Summary. Это списки важнейшего функционала основных частей WCF.
Cons:
* Иногда используемые в примерах методы устарели много раньше выхода книги. К примеру, генерация классов из XSD с помощью XSD.exe утилиты. Несколько поколений Software Factory поддерживают уже эту функцию. Как и SvcUtil.exe
* частенько объяснения, что именно было сделано и какой в этом смысл, далеки от совершенства. Чувствуется, что писатели сами многого не понимают, а следуют лишь подробным инструкциям. Что, в общем-то, и неудивительно, принимая во внимание невообразимое количество функционала WCF. (К примеру, на стр.66 просится закомментировать директиву [XmlSerializerFormat...] после чего сгенерировать схемы заново и убедиться, что новые схемы будут очень сильно отличатся от схем, сгенерируемых по-умолчанию. Без объяснений, почему мы получили различия, все эти упражнения с комментированием имеют мало смысла.)
Я знаю несколько хороших источников информации о WCF именно в приведенном выше разрезе:
* Samples in .NET SDK
* Книга "Programming .NET Components", 2nd Edition by Juval Lowy
* форумы MSND (http://social.msdn.microsoft.com/forums/en-US/wcf/threads/
- и теперь к этим источникам прибавилась эта книга.
Я ставлю этой книге твердую пятерку.
Не смотря на все ее недостатки, польза от использования книги в качестве быстрого и надежного изучения WCF несомненна.
C уважением,
Leonid Ganeline [BizTalk MVP] http://geekswithblogs.net/leonidganeline/
Что мне нравится в книгах этой серии, так это то, что теория всегда закачивается практическими примерами. И примеры эти показывают реальные проблемы, ситуации.
Это сильно отличается от документации, где все функции продукта просто перечислены без расстановки приоритетов. В книгах серии Self-Paced Training Kit (СПТК) нет места, чтобы излагать все функции, цели здесь другие. Здесь даются только ОСНОВНЫЕ функции и показываются цепочки действий для достижения *реального* результата. К примеру, часть о MessageContract. В документации по WCF масса информации об этом типе контракта, но чрезвычайно трудно понять, для чего же вообще (!) можно его использовать. В СПТК дан *конкретный* пример, где MessageContract используется для передачи лицензионного ключа. Все становится понятно.
Я работаю с Web-сервисами больше 3х лет, последний год исключительно с WCF сервисами. Книгу я использовал не для сдачи экзамена, а для систематизации своих знаний. (Здесь дискуссия о пользе сертификационных экзаменов http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3280207&SiteID=1)
Я использую любой источник информации, для того, чтобы *понять*, что происходит внутри продукта, почему данные конкретные функции были введены в продукт, какие альтернативы есть. Почему? Без ответов на этот вопрос, информация просто не укладывается в моей голове. Я не могу как обезьянка выучить действия, приводящие к результату. Мне надо знать, *почему*.
В любой методике объяснений немаловажную часть занимают объяснения *неправильного* использования, примеров *неправильных* техник. Не давая Cons, очень тяжело рассказать о Pros. Иногда десяток примеров правильного использования продукта не заменит одного примера "неправильного" использования.
Чем серия СПТК серия отличается от других книг издания Microsoft:
* в книгах этой серии приведен только *основной* функционал продуктов. На описание всего там нет места. Этот функционал выбран с точки зрения Microsoft, то есть с точки зрения производителя. И это важно.
* в них приведены примеры *реальных проблем* и как они решаются с помощью основного функционала продукта.
* в книгах сжато рассказано, что послужило основанием для создания именно этого функционала.
* здесь приведены примеры *неправильного* использования.
Pros:
* По сути СПТК - видение Microsoft о том, для чего замышлялся продукт, какие основные шаблоны его использования.
* в разделах Lessons приведена концентрированная информация об основных характеристиках WCF. Рядом находятся примеры из практики. Примеры тоже концентрируют на самых необходимых вещах.
* Мне очень нравятся разделы Lesson Summary. Это списки важнейшего функционала основных частей WCF.
Cons:
* Иногда используемые в примерах методы устарели много раньше выхода книги. К примеру, генерация классов из XSD с помощью XSD.exe утилиты. Несколько поколений Software Factory поддерживают уже эту функцию. Как и SvcUtil.exe
* частенько объяснения, что именно было сделано и какой в этом смысл, далеки от совершенства. Чувствуется, что писатели сами многого не понимают, а следуют лишь подробным инструкциям. Что, в общем-то, и неудивительно, принимая во внимание невообразимое количество функционала WCF. (К примеру, на стр.66 просится закомментировать директиву [XmlSerializerFormat...] после чего сгенерировать схемы заново и убедиться, что новые схемы будут очень сильно отличатся от схем, сгенерируемых по-умолчанию. Без объяснений, почему мы получили различия, все эти упражнения с комментированием имеют мало смысла.)
Я знаю несколько хороших источников информации о WCF именно в приведенном выше разрезе:
* Samples in .NET SDK
* Книга "Programming .NET Components", 2nd Edition by Juval Lowy
* форумы MSND (http://social.msdn.microsoft.com/forums/en-US/wcf/threads/
- и теперь к этим источникам прибавилась эта книга.
Я ставлю этой книге твердую пятерку.
Не смотря на все ее недостатки, польза от использования книги в качестве быстрого и надежного изучения WCF несомненна.
C уважением,
Leonid Ganeline [BizTalk MVP] http://geekswithblogs.net/leonidganeline/
2008-10-12
Microsoft BizTalk Server: Что же это такое?
Что такое Microsoft BizTalk Server?
Довольно веселый и простенький вопрос.
Что Microsoft вкладывает в понятие "интеграция", применительно к BizTalk?
1). Это обмен данными в разных форматах и по разным протоколам и стандартам. Имеются в виду как форматы данных, такие, как многочисленные текстовые форматы, 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...).
2). Другая сторона обмена данных - это преобразование форматов данных. В BizTalk преобразование данных реализуется по простой идее: все внешние форматы данных преобразуются к одному внутреннему формату - Xml. Все адаптеры осуществляют такое преобразование, как в одну, так и в другую сторону. Сообщения в формате Xml описываются схемами - Xsd. Чтобы осуществить структурные преобразования, то есть когда требуется часть данных поменять местами, часть данных просто удалить и т.п, используется стандарт Xslt. Документ Xslt (карта - map) описывает, как исходный (source) XML документ преобразовывается в конечный (destination) XML документ. BizTalk имеет для этих целей два редактора: Schema Editor и Mapper. Первый редактирует и создает Xsd документы, второй - Xslt.
3). 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.
Один из нюансов использования BizTalk, требующий внимания, состоит в том, что он используется прежде всего для интеграции систем в автоматическом режиме, для интеграции программ с минимальным участием человека. Одни приложения поставляют данные, другие их потребляют. В промежутке располагается BizTalk Server, который согласовывает форматы обмена, координирует обмен данных и их обработку. Типичная система на базе BizTalk работает без участия человека. BizTalk – это типичная back-end система. Ее многочисленные и мощные средства для разработчика контрастируют с минимальным набором средств для оператора, которому надо лишь в ограниченных пределах наблюдать за работающей системой, подстраивать ее. В BizTalk есть четкое деление между средой разработки (development) и средой исполнения (runtime).
Суммируя вышеизложенное, BizTalk - это интеграционный пакет, обеспечивающий обмен данными в разных форматах, преобразование данных, создание и обеспечение работы бизнес процессов, плюс среда разработки.
Типичные примеры использования BizTalk:
1) Приложение или оператор выкладывает готовые данные в определенном формате в файлы в определенный каталог. BizTalk процесс с заданным промежутком просматривает этот каталог и забирает файлы. Данные из файлов преобразуются во внутренний формат (Xml). Другие приложения, подписанные на эти данные, получают их. Данные предварительно преобразовываются в формат этих приложений. Данные хранятся в системе до тех пор, пока принимающая сторона не будет готова принять их.
2) BizTalk процесс с определенной периодичностью запрашивает SQL базу на предмет появления новых данных. Процесс стартует, когда обнаруживаются новые данные. Процесс рассылает эти данные в другие приложения и ожидает от этих приложений ответа, что данные обработаны. Когда все ответы получены, данные в SQL базе помечаются, как обработанные.
3) Приложение обращается к Web-сервису за данными. Web-сервис запускает BizTalk процесс, который обращается к другим Web-сервисам за дополнительными данными, после чего консолидирует данные и выдает их первому приложению. (Это типичный пример создания модных сейчас композитных Web-сервисов.)
4) Складская система на базе RFID (радио кодов). BizTalk процессы получают данные с RFID считывателей установленных на воротах склада, фильтруют их и передают данные в многочисленные складские приложения для учета и мониторинга движения товара.
-----------------------------------------------------------
[1] BizTalk Server – главная страница в интернете http://www.microsoft.com/biztalk/
[2] BizTalk Server документация на сайте MSDN http://msdn.microsoft.com/en-us/library/bb430723.aspx
[3] BizTalk datasheet: версии, цены, список адаптеров http://download.microsoft.com/download/c/2/2/c22737c1-707e-42a3-ae45-5df40973a0a7/BizTalk%202006%20R2%20Datasheet.pdf
Довольно веселый и простенький вопрос.
BizTalk позиционируется, как пакет для интеграции систем.
Что Microsoft вкладывает в понятие "интеграция", применительно к BizTalk?
1). Это обмен данными в разных форматах и по разным протоколам и стандартам. Имеются в виду как форматы данных, такие, как многочисленные текстовые форматы, 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...).
2). Другая сторона обмена данных - это преобразование форматов данных. В BizTalk преобразование данных реализуется по простой идее: все внешние форматы данных преобразуются к одному внутреннему формату - Xml. Все адаптеры осуществляют такое преобразование, как в одну, так и в другую сторону. Сообщения в формате Xml описываются схемами - Xsd. Чтобы осуществить структурные преобразования, то есть когда требуется часть данных поменять местами, часть данных просто удалить и т.п, используется стандарт Xslt. Документ Xslt (карта - map) описывает, как исходный (source) XML документ преобразовывается в конечный (destination) XML документ. BizTalk имеет для этих целей два редактора: Schema Editor и Mapper. Первый редактирует и создает Xsd документы, второй - Xslt.
3). 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.
Один из нюансов использования BizTalk, требующий внимания, состоит в том, что он используется прежде всего для интеграции систем в автоматическом режиме, для интеграции программ с минимальным участием человека. Одни приложения поставляют данные, другие их потребляют. В промежутке располагается BizTalk Server, который согласовывает форматы обмена, координирует обмен данных и их обработку. Типичная система на базе BizTalk работает без участия человека. BizTalk – это типичная back-end система. Ее многочисленные и мощные средства для разработчика контрастируют с минимальным набором средств для оператора, которому надо лишь в ограниченных пределах наблюдать за работающей системой, подстраивать ее. В BizTalk есть четкое деление между средой разработки (development) и средой исполнения (runtime).
Суммируя вышеизложенное, BizTalk - это интеграционный пакет, обеспечивающий обмен данными в разных форматах, преобразование данных, создание и обеспечение работы бизнес процессов, плюс среда разработки.
Типичные примеры использования BizTalk:
1) Приложение или оператор выкладывает готовые данные в определенном формате в файлы в определенный каталог. BizTalk процесс с заданным промежутком просматривает этот каталог и забирает файлы. Данные из файлов преобразуются во внутренний формат (Xml). Другие приложения, подписанные на эти данные, получают их. Данные предварительно преобразовываются в формат этих приложений. Данные хранятся в системе до тех пор, пока принимающая сторона не будет готова принять их.
2) BizTalk процесс с определенной периодичностью запрашивает SQL базу на предмет появления новых данных. Процесс стартует, когда обнаруживаются новые данные. Процесс рассылает эти данные в другие приложения и ожидает от этих приложений ответа, что данные обработаны. Когда все ответы получены, данные в SQL базе помечаются, как обработанные.
3) Приложение обращается к Web-сервису за данными. Web-сервис запускает BizTalk процесс, который обращается к другим Web-сервисам за дополнительными данными, после чего консолидирует данные и выдает их первому приложению. (Это типичный пример создания модных сейчас композитных Web-сервисов.)
4) Складская система на базе RFID (радио кодов). BizTalk процессы получают данные с RFID считывателей установленных на воротах склада, фильтруют их и передают данные в многочисленные складские приложения для учета и мониторинга движения товара.
-----------------------------------------------------------
[1] BizTalk Server – главная страница в интернете http://www.microsoft.com/biztalk/
[2] BizTalk Server документация на сайте MSDN http://msdn.microsoft.com/en-us/library/bb430723.aspx
[3] BizTalk datasheet: версии, цены, список адаптеров http://download.microsoft.com/download/c/2/2/c22737c1-707e-42a3-ae45-5df40973a0a7/BizTalk%202006%20R2%20Datasheet.pdf
2008-06-05
Полезно ли учиться на МБА или нет
Вот здесь пошел офтоп про то, полезно ли учиться на МБА или нет [http://forum.privet.com/viewtopic.php?t=134596&postdays=0&postorder=asc&&start=550]
Логика-то понятна. БА, по сути, довольно далеко от реальных научных методик. Больше - практические схемы, "доказавшие" свою полезность. Выучил схемы - получил МБА. Схемы = шаблоны. Шаблоны никогда к прорывам в любом деле не приводят. В том числе и в бизнесе. Они позволяют только не совершать самых очевидных ошибок. При этом значительно сужают кругозор, "затупляют" свежесть взгляда и мыслей. В ИТ постоянно появляются новые течения и теории в менеджменте, которые с МБА имеют мало общего. Посмотрите, как управляются внутри успешные ИТ компании. Все идет скорее вопреки БА "науке". БА - как бы то, что выжило в круговерти новых БА технологий. Это типа университетской линейной алгебры. Знать о ее существовании надо, иногда можно и использовать. Но передовым краем математики ее назвать нельзя (тот объем, что преподается в универах для базовых знаний).
Логика-то понятна. БА, по сути, довольно далеко от реальных научных методик. Больше - практические схемы, "доказавшие" свою полезность. Выучил схемы - получил МБА. Схемы = шаблоны. Шаблоны никогда к прорывам в любом деле не приводят. В том числе и в бизнесе. Они позволяют только не совершать самых очевидных ошибок. При этом значительно сужают кругозор, "затупляют" свежесть взгляда и мыслей. В ИТ постоянно появляются новые течения и теории в менеджменте, которые с МБА имеют мало общего. Посмотрите, как управляются внутри успешные ИТ компании. Все идет скорее вопреки БА "науке". БА - как бы то, что выжило в круговерти новых БА технологий. Это типа университетской линейной алгебры. Знать о ее существовании надо, иногда можно и использовать. Но передовым краем математики ее назвать нельзя (тот объем, что преподается в универах для базовых знаний).
Subscribe to:
Comments (Atom)