При использовании более 50 сторонних веб-сервисов следует использовать BizTalk или только C#?

Я создаю серверное приложение, которому необходимо получать данные по различным расписаниям из более чем 50 сторонних веб-сервисов, и это число будет продолжать расти. Данные из этих служб в настоящее время можно сгруппировать по 3 типам, поэтому каждый ответ необходимо сопоставить с 1 из 3 известных схем.

Написание собственного кода C# для обращения к каждой веб-службе кажется кошмаром для управления, не говоря уже о том, что все эти данные отображаются в коде.

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

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

Спасибо!


biztalk web-services biztalk-2009
person typemismatch    schedule 16.04.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Приятно слышать, что кто-то рассматривает BizTalk вместо C#!

Я бы порекомендовал подход BizTalk, использующий функциональные возможности ESB Toolkit 2.0 и UDDI Services v3 (найденных в BizTalk Server 2009), по нескольким причинам:

  • 50 конечных точек веб-службы могут храниться в реестре UDDI — общем портале управления, где можно добавлять и поддерживать будущие конечные точки;
  • Каждый вызов веб-службы опрашивается, и результирующее сообщение передается на шину, преобразуется в одно из трех сообщений и доставляется в определенную конечную точку;

Что касается сопоставления, схемы необходимо будет определить для каждого из трех распространенных типов сообщений и каждого ответа веб-службы; Затем необходимо будет создать карты для сопоставления ответного сообщения с соответствующей общей схемой.

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

person Nick Heppleston    schedule 05.05.2010

arrow_upward
2
arrow_downward

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

Будут ли какие-либо веб-сервисы требовать нескольких вызовов? Например. получение токена аутентификации перед их опросом? Такие службы потребуют более сложных оркестровок для вызова через BizTalk.

Говоря в целом, я думаю, вам будет проще разработать и поддерживать целевое решение проблемы на C#, чем использовать корпоративную систему, такую ​​как BizTalk. По моему опыту внедрения решений BizTalk, объем необходимого обслуживания и сложность устранения неполадок намного превышают любые преимущества, предоставляемые платформой. Однако, по моему опыту, BizTalk 2006 R2 - 2009, возможно, решил проблемы, с которыми мы столкнулись.

person Gareth Saul    schedule 05.05.2010
comment
Относительно параграфа 1: если отображение будет некрасивым, ничто не мешает вам использовать XSLT (который может иметь встроенные функции C#) или компонент C#, вызываемый в блоке Expression. - person Jimmy; 17.02.2012