Какви са предимствата и недостатъците на 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 за коментара на David - 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
Ще се съглася с Riri, 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