Используя более 50 сторонних веб-сервисов, я должен использовать BizTalk или просто C #? - PullRequest
Новая
       6

Используя более 50 сторонних веб-сервисов, я должен использовать BizTalk или просто C #?

1 голос
/ 16 апреля 2010

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

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

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

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

Спасибо!

Ответы [ 2 ]

3 голосов
/ 05 мая 2010

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

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

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

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

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

2 голосов
/ 05 мая 2010

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

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

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

...