WF 4 или BizTalk 2010?

Ответ 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