WF 4 или BizTalk 2010?

У меня вопрос - BizTalk или WF? И позвольте мне пояснить, что я реализую аналогичные технологии первых трех артефактов и понимаю, что могу их построить, но я не считаю, что они встроены в WF, и поэтому я пытаюсь понять, почему я бы использовал один технологии с другой.

  • Transformations
  • Наручники
  • Порты/адаптеры
  • BizTalk Future

Transformations

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

В отличие от WF, у меня нет такой роскошной встроенной памяти, так что я что-то упускаю или у BizTalk есть +1 здесь?

Наручники

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

В отличие от WF, у меня нет такой роскошной встроенной памяти, так что я что-то упускаю или у BizTalk есть +2 здесь?

Порты/адаптеры

Это, возможно, самый большой артефакт, который существует в BizTalk - IMHO. Объем усилий, необходимых для абстрактного физического подключения к многочисленным конкретным реализациям, особенно в очень большой организации, где некоторые из этих конкретных достигают простейшей файловой системы по сравнению с SOAP/REST и в таких вещах, как мэйнфрейм IBM и MSMQ. Адаптеры физического порта BizTalk, которые автоматически запускают необработанные данные через преобразования перед отправкой рабочего сообщения, довольно просто, элегантны.

В отличие от WF, у меня нет такой роскошной встроенной памяти, так что я что-то упускаю или у BizTalk есть +3 здесь?

BizTalk Future

Наконец, я хотел бы упомянуть, что из моих исследований одна и та же команда людей, которые построили BizTalk, строит WF - это здорово! Кроме того, долгосрочное видение Microsoft - это новое слово buzz "сервер интеграции" и фактически представляет собой большой массив слабо связанных фреймворков, которые обеспечивают то, что BizTalk делает сегодня. И это усилие имеет для меня большой смысл из-за усилий Azure, которые, я уверен, вносят свой вклад в это. Тем не менее, мне нужно реализовать решение сегодня, которое будет работать через 15 лет, но мне также нужно понять, какие части я буду использовать для объединения, если я использую WF через BizTalk. Пожалуйста, предоставьте мне свои впечатления.

ОТВЕТЫ

Ответ 1

(Отказ от ответственности - мой опыт WF ограничен WF3.0, поэтому я могу быть за недавними разработками WF)

BizTalk наиболее подходит для межсистемных, межотраслевых и межфирменных процессов Integration + Business Process (BPEL), то есть для предприятий. IMO WF до сих пор больше позиционируется в отношении внутренних систем или приложений. Но есть, несомненно, все более серые области, так как кажется, что они сходятся к Azure + Appfabric.

Кажется, что вы смотрите на WF для интеграции?

Трансформации - несомненно, хорошая вещь в BizTalk - при условии, что вы можете отображать либо визуально, либо непосредственно в XSLT, вы можете быстро преобразовать форматы сообщений в портах или оркестровках и оставить физическую технологию, используемую как afterthought - то есть вы можете реализовать свой дизайн на логическом уровне и не будете "увязнуть" в любой конкретной технологии (MQ, WCF, SQL, FTP и т.д.).

Одно предостережение - управление схемами может стать довольно больным - каждое сообщение имеет схему, для которой требуется уникальный XMLNS # Root для всех приложений на BizTalk. И вы можете быть "агностиком" и использовать канонические схемы для ваших внутренних потоков - поэтому нужны хорошие дисциплины для именования, настройки и управления. Управление схемой становится особенно обременительным, если вы связываете BizTalk со многими службами WCF/WebService - будет существовать схема запроса и ответа для каждого потребляемого сервиса (вы можете использовать общие схемы, если используете MessageContract).

Привязки - вы в значительной степени его получили. Кроме того, если вы используете привязки Direct (message box), вы можете выбрать несколько мест приема входящих сообщений или отправить адресаты, просто добавив новый порт с соответствующими фильтрами. Эта возможность pub-sub лежит в основе инструментария ESB для Bizalk. Связывание для разных сред (Dev, UAT, Prod и т.д.) Также хорошо управляется.

Адаптеры - согласованы - переход из файла в MQ Series так же просто, как изменение конфигурации порта. BizTalk отлично работает с MSMQ и IBM MQ.

Кроме того, не стоит недооценивать объем усилий по администрированию и поддержке решения EAI/BP. Интеграция, как правило, важна для предприятия, и ошибки отслеживания и избежание простоев являются существенными. BizTalk обладает следующими эксплуатационными преимуществами:

  • Оперативное управление - отслеживание/отслеживание, управление приостановленными сообщениями, пакеты интеграции SCOM и т.д.
  • Возможности масштабируемости/кластеризации/отказоустойчивости, повторные попытки адаптера, автоматическое дросселирование и т.д.
  • Мониторинг и ведение бизнеса - BAM

IMO - большие "недостатки" для BizTalk:

  • Стоимость
  • Время разгона, чтобы стать квалифицированным в разработке (у BTS есть свои причуды, например, зомби и определение определений BAM в файлах XLS и XML).
  • Увеличьте время для профессионалов в сети/администраторах, чтобы получить навыки управления операциями.

Итог: если вы выполняете интеграцию между 2 или 3 приложениями с небольшим количеством некритических сообщений, переходите на проприетарный или WF-маршрут, но если вы смотрите на решение масштаба предприятия, механизм EAI/BPEL, такой как BizTalk, быть в будущем.

Ответ 2

Отличная почта и ответ.

Являются ли люди, которые начинают видеть клиентов, рассматривают WF для проектов интеграции теперь, когда доступен WF-менеджер? Раньше id никогда не видел, чтобы кто-либо рассматривал WF + WCF для чего-то другого, кроме небольших или нишевых областей из-за отсутствия зрелой среды хостинга. Люди начинают видеть это изменение в реальном мире?

Могу ли я также добавить свою точку зрения на упоминания о нижних сторонах stuart. Я не согласен на 100% с его комментариями.

  • Стоимость

Стоимость не такая большая проблема, как раньше. BizTalk на Azure может изменить эту ситуацию для вас, чтобы вы могли получить настройку с оплатой по ходу модели. Хотя по-прежнему существует стоимость лицензии (ее только в месяц), когда вы рассматриваете диапазон типов решений, вы можете построить свое неплохое соотношение цены и качества. Я думаю, что люди часто пытаются количественно оценить стоимость решения для сборки и просто предположить, что у biztalk есть лицензия, она должна быть дороже. Когда люди обсуждают стоимость BizTalk, я часто спрашиваю, почему они будут использовать Sharepoint для совместной работы, когда они могут просто использовать общую папку и электронную почту. Я думаю, что стоимость относительно, для некоторых компаний это может быть больше, чем то, что вы получите значение, если у вас есть только несколько интеграционных процессов, но для других это может быть большой инвестицией.

  • Ramp up/Dev

Я согласен, что biztalk - это специализированный набор навыков, но не тот, который отличается от разработчика на любой другой платформе. Иногда компания хочет поставить .NET-разработчика без опыта работы с sharepoint или динамикой CRM, а затем задается вопросом, почему они делают ошибки, вам не нужно быть genuis, чтобы работать с этим. Есть несколько отличных ресурсов, которые помогут вам стать разработчиком biztalk, особенно по сравнению с некоторыми продуктами конкурентов, и я рассматриваю это как силу над WF по моему мнению. Ключевым риском развития BizTalk является то, что вы можете легко сделать это очень плохо, если не знаете, что делаете. Это распространенная ошибка в отрасли, но я видел, что это было сделано с другими реализациями платформы много раз.

(Замечание о "WF как конкурент" я рассматриваю WF как конкурента на подмножестве того, что BizTalk делает, но в долгосрочной перспективе я думаю, что они тоже будут дополнять друг друга в некоторых ситуациях)

  • Ramp up/Admin

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

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

Возможно, вы захотите проверить нижеприведенную книгу, в которой есть глава (я думаю) о сценарии, в котором они рассматривали BizTalk или WF + AppFabric, некоторые интересные моменты обсуждения

http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7