Каковы плюсы и минусы BizTalk 2010+ для мониторинга использования и производительности веб-служб?

Я изо всех сил пытаюсь оценить BizTalk; Мне нужно понимать преимущества и недостатки использования BizTalk для мониторинга использования и производительности (WCF) веб-служб.

Есть ли какие-либо недостатки в использовании BizTalk в качестве инструмента мониторинга производительности веб-сервисов, помимо очевидной стоимости и кривой обучения при освоении новой технологии?

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

Придерживаться одного поставщика - привлекательная перспектива, и мы (в основном) * полностью относимся к среде Microsoft, но есть ли другие ключевые преимущества использования BizTalk, чего-либо, что он предлагает, чего нет в других местах? Или в чем-то это явный лидер рынка?

Редактировать
* Я говорю в основном о Microsoft, потому что мы не используем SCOM; вместо этого у нас есть Nagios и Cactai


biztalk
person Simon Martin    schedule 27.06.2013    source источник
comment
Итак, все, что вам нужно, это мониторинг существующих веб-сервисов? И когда вы говорите «мониторинг», вы больше имеете в виду отслеживание их производительности, а не обеспечение доступности? В любом случае я бы сказал, что BizTalk - это огромный избыток для этого. Если вы предоставляете веб-службы, вы можете создать этот мониторинг как своего рода расширение, которое подключается к конвейеру WCF, или как вызовы трассировки в самих веб-службах.   -  person David Hall    schedule 27.06.2013
comment
И на самом деле (хотя я должен сказать, что не использовал BizTalk в гневе с 2010 года, так что это могло измениться) поддержка хорошей визуализации данных о производительности из коробки не самая лучшая.   -  person David Hall    schedule 27.06.2013
comment
Скорее всего, мы будем добавлять в список сервисов по мере перехода на SOA. Мне действительно нужно знать, насколько хорошо работает каждая служба, а также как часто она используется. Есть предположение, что мы будем использовать BizTalk для предоставления фасада службы, чтобы отделить клиентов от жестко заданных адресов и позволить нам перемещать службы (потенциально), хорошая это идея или нет, я еще не уверен. Действующая политика заключается в том, чтобы в первую очередь искать коммерческие продукты, а если ничего не подходит, создавать собственные. В настоящее время я оцениваю BizTalk. Пока это звучит чересчур   -  person Simon Martin    schedule 27.06.2013
comment
+1 к комментарию Дэвида - IMO BizTalk - не лучшее место для управления и мониторинга 1000 фасадов веб-сервисов < / а>. Ближе всего к нашим оценкам был Managed Services Engine (MSE), который, к сожалению, так и не увидел свет.. Кажется, в этом пространстве могут быть и другие коммерческие предложения, например здесь. В какой-то момент эта возможность, вероятно, появится в AppFabric.   -  person StuartLC    schedule 01.07.2013

Ответы (3)


arrow_upward
2
arrow_downward

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

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

Основная проблема заключается в том, что BizTalk будет сохранять сообщение несколько раз и увеличивать задержку. Это невозможно настроить, поэтому даже для простых сообщений типа get все будет обрабатываться как чрезвычайно важное сообщение (но, может быть, это то, что вы ищете?). В дальнейшем BizTalk фактически не хватает некоторых вещей, таких как хорошие возможности мониторинга для пример использования службы (вам нужно будет использовать BAM или что-то, чтобы решить эту проблему).

Другие возможные решения для этого: Sentinet от Nevatech или что-то от Программное обеспечение SOA.

person Riri    schedule 27.06.2013
comment
Я согласен с Рири, BizTalk - это не приложение для мониторинга сервисов, это продукт интеграции EAI / EDI / ESB (как бы вы его ни называли). Это помогает соединить системы вместе. Sentinet или аналогичный продукт управления SOA - это то, что вам нужно. - person Saravana Kumar; 05.07.2013

arrow_upward
1
arrow_downward

Исходя из моего опыта работы с Biztalk (работая параллельно, а не напрямую), я могу сказать, что он может быть не идеальным для описываемого вами сценария. Его можно использовать для этой работы, но это немного похоже на использование двухэтажного автобуса, чтобы сломать орех; Орех будет треснут, но процесс потребляет больше ресурсов, чем это необходимо.

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

Потратив время на обоюдную оценку этого вопроса, я бы также сказал, что, хотя подход одного поставщика имеет определенную привлекательность, третьи стороны часто создают более полезные инструменты для стека Microsoft, чем Microsoft.

person glenatron    schedule 27.06.2013

arrow_upward
1
arrow_downward

Вам нужен ненавязчивый инструмент для мониторинга сервисов SOAP и REST. Взгляните на Sentinet от Nevatech, http://www.nevatech.com/sentinet/api-monitoring. Это единственный на рынке инструмент в области управления SOA и API и управления во время выполнения, который полностью построен на технологиях Microsoft и прекрасно сочетается со службами Microsoft. Этот инструмент будет именно тем, что вы ищете.

Андрей Сливкер

person user1993194    schedule 18.07.2013