Comments 45
UFO just landed and posted this here
«BizTalk'овый сервер»
интересно звучит
интересно звучит
Отличная статья.
Спасибо.
Спасибо.
UFO just landed and posted this here
Да, 35 тыс. долл. за enterprise-версию — это более чем изрядно. Поэтому такая интересная и мощная штука используется только крупными предприятиями. Наверное, это правильно, ибо она и нужна только крупным. Но из этого получается, что разработчиков, имеющих опыт работы с BizTalk, мало. Как же оно двигается в бизнес? Видимо, как-то сбоку и сверху — через сейлзменов на месредесах, продающих это большим боссам.
Да разве ж это дорого? Вот возьмите IBM [WebSphere] Message Broker: «IBM's pricing is straightforward and based on a flat $85,000 per CPU» (правда, это баян 4-летней давности, но не думаю, чтобы соотношение цен существенно поменялось с тех пор).
Что касается модели продвижения, то вы тут попали в точку. Активные продажи, будь они неладны…
Что касается модели продвижения, то вы тут попали в точку. Активные продажи, будь они неладны…
Позволю себе с Вами не согласиться. Все просто, средняя зарплата программиста, для простоты 3000$, берем команду из 4 разработчиков (менеджеров, аренду помещения и все остальное не считаем). Вы уверены, что эта команда напишет аналогичную систему интеграции ваших разрозненных систем за 3 месяца (опять же отбросим сопровождение, включенные в стоимость обновления и т.д.). Если разработают, то наверно это действительно дорого. В противном случае, Вы в плюсе.
А почему вы стоимость внедрения (и сопровождения) BizTalk не учитываете? Сильно сомневаюсь, что стоимость лицензии это основная часть в расходах.
Я дороговизну мерял не потенциальными трудозатратами, а некими абсолютными абстрактными величинами. Надо чтобы босс решил выложить 35 тыс. за софтину, которая щастье начнет приносить (если начнет) только после внедрения. А ежели не начнет? :)
В 2006 году работал в крупной компании (>5000 чел), пробовали внедрять бизток для интегграции разных инфопотоков — в том числе КИС и сайт. Вобщем проект получился монстрозный, не очень поддерживаемый. Развивать его можно было только с помощью вендоров, которые внедряли.
В итоге нам не очень понравилось и дальше пилота дело не пошло.
В итоге нам не очень понравилось и дальше пилота дело не пошло.
попробуйте openerp, правда, я не уверен, что она умеет тоже самое
Просто интересно, а есть open source аналоги или стремящиеся к тому продукты?
Очень хорошие OpenSource продукты: Mule ESB, ServiceMix, Apache Camel — это так сказать легковесные варианты ESB.
Также есть бесплатная версия JBoss ESB от RedHat который уже ближе к BizTalk.
Также есть бесплатная версия JBoss ESB от RedHat который уже ближе к BizTalk.
Не забываем про очень интересный RabbitMQ на Erlang. Есть хороший опыт построение на нем отказоустойчивых финансовых приложений. Плюс – его можно дорабатывать. Но крупные предприятия (в т.ч. банки) зачастую предпочитают бренд опенсурсу.
Насчет предпочтения бренда опенсорсу — да, порой доходит до маразма.
В компании, на объекте которой я работаю, готовы купить лицензии Adobe Photoshop вместо установки Paint.NET, покупать SnagIT вместо использования фриварных или гораздо более дешевых аналогов и т.д. ИТ бюджет компании тратится на всякую ерунду вмест куда более нужных вещей.
Обоснование очень простое: «бренды отвечают за свою продукцию, предоставляю поддержку и т.д.».
По факту это объяснение не выдерживает никакой критики, особенно когда пытаешь получить эту поддержку от вендоров. То у тебя версия ПО уже не поддерживаемая (Microsoft, ABBYY), то просто «это у вас локальные проблемы совместимости, ничем помочь не можем».
Странные они в этой компании, одной из крупнейших в мире, кстати…
В компании, на объекте которой я работаю, готовы купить лицензии Adobe Photoshop вместо установки Paint.NET, покупать SnagIT вместо использования фриварных или гораздо более дешевых аналогов и т.д. ИТ бюджет компании тратится на всякую ерунду вмест куда более нужных вещей.
Обоснование очень простое: «бренды отвечают за свою продукцию, предоставляю поддержку и т.д.».
По факту это объяснение не выдерживает никакой критики, особенно когда пытаешь получить эту поддержку от вендоров. То у тебя версия ПО уже не поддерживаемая (Microsoft, ABBYY), то просто «это у вас локальные проблемы совместимости, ничем помочь не можем».
Странные они в этой компании, одной из крупнейших в мире, кстати…
В больших компаниях очень хорошо работают механизмы перекладывания ответственности и прикрывания жёпы. Поставьте себя на место начальника ИТ-отдела. Зачем ему брать на себя ответственность за непонятный софт? Вот представьте, произошел сбой, если софт куплен у серьезного поставщика — можно связать с техподдержкой, переложить проблему на них. В случае какиих-то серьезных проблем, можно подключить их специалистов, и объяснить своим серьезность проблемы.
А вот если используется бесплатный софт — что с ним делать? первый вопрос, который ему зададут: «Нафига вы это поставили? Вам что бюджет не выделили?»
А вот если используется бесплатный софт — что с ним делать? первый вопрос, который ему зададут: «Нафига вы это поставили? Вам что бюджет не выделили?»
Спасибо за отличное введение, хотелось продолжения и целого цикла статей по BizTalk :-)
лого немного напомнило логотип Microsoft Zune
UFO just landed and posted this here
Если в одно слово, то это паттерн Обзёрвер.
UFO just landed and posted this here
Есть и такое :-). Например www.comarch.ru/ru/industries/ecod
Очень позитивная идея — работать в BizTalk с банками через электронные протоколы. Если бы это еще работало в России для рядовых ООО, было бы вообще круто. А то де факто приходится такой огород городить даже для простейших операций, что крыша едет.
За пост по BizTalk спасибо, думаю тут многим интересно о нем почитать. Жаль правда что в VS2010 с ним не повозиться — ждем 2010го релиза :)
За пост по BizTalk спасибо, думаю тут многим интересно о нем почитать. Жаль правда что в VS2010 с ним не повозиться — ждем 2010го релиза :)
я немного подкорректировал вашу первую схему и в модели появилась гармония
Мне статья понравилась — доходчивая превьюшка назначения/возможностей рассматриваемого софта. Спасибо.
Когда мне довелось впервые столкнуться с бизтолком (а было это в версии 2001), одной из главных проблем для нас было — понять, а что же это такое? Ну да, порты, каналы, очереди… Круто!!! А дальше чего? Что на этом можно делать, а что нельзя? Может его хорошо использовать для репликации баз данных? Или он может быть основой для ERP? Или вести на нем список задач?
Синхронизировать файловые директории? Обмениваться короткими сообщениями, как в аське? Ваять интернет-магазины? Или это долгожданное некоторыми деятелями средство программирования одной мышью (без применения программистов)? А нужно ли его тут применять, или нам хватит небольшого скрипта на перле?..
Мне тогда здорово помогла книжка Enterprise Integration Patterns, из серии «одобрено товарищем Фаулером», довольно давно есть и в русском переводе Шаблоны интеграции корпоративных приложений (на просторах рунета можно найти в формате djvu). С ее помощью в голове все утряслось и стало на свои места. Очень рекомендую почитать ее прежде чем встраивать бизток в корпоративную архитектуру. Да и независимо от бизтока — хорошая книжка.
ЗЫ Одно время EAI было очень модным направлением, страстно любимым Гартнером и прочими консалтерами. С разных сторон неслись стенания: унаследованные (legacy) приложения нас душат, не пуская в светлое будущее е-бизнеса. Количество информационных связей растет лавинообразно, устраивать линки «каждый с каждым» уже нету сил. Интеграция приложений — вот что поможет разобраться в помойке!
Со временем выяснилось (где ты, капитан Очевидность?) что интеграция — тоже не такая простая штука, всех проблем не решает, некоторые новые создает, чтобы интегрировать legacy приложение — к нему почти всегда приходится залезать в кишки, отлаживать распределенную систему долго и сложно… Не стала EAI серебряной пулей. Тем не менее направление живет и побеждает, судя по всему. Продукты развиваются, новые версии выходят. Жизнь продолжается.
Синхронизировать файловые директории? Обмениваться короткими сообщениями, как в аське? Ваять интернет-магазины? Или это долгожданное некоторыми деятелями средство программирования одной мышью (без применения программистов)? А нужно ли его тут применять, или нам хватит небольшого скрипта на перле?..
Мне тогда здорово помогла книжка Enterprise Integration Patterns, из серии «одобрено товарищем Фаулером», довольно давно есть и в русском переводе Шаблоны интеграции корпоративных приложений (на просторах рунета можно найти в формате djvu). С ее помощью в голове все утряслось и стало на свои места. Очень рекомендую почитать ее прежде чем встраивать бизток в корпоративную архитектуру. Да и независимо от бизтока — хорошая книжка.
ЗЫ Одно время EAI было очень модным направлением, страстно любимым Гартнером и прочими консалтерами. С разных сторон неслись стенания: унаследованные (legacy) приложения нас душат, не пуская в светлое будущее е-бизнеса. Количество информационных связей растет лавинообразно, устраивать линки «каждый с каждым» уже нету сил. Интеграция приложений — вот что поможет разобраться в помойке!
Со временем выяснилось (где ты, капитан Очевидность?) что интеграция — тоже не такая простая штука, всех проблем не решает, некоторые новые создает, чтобы интегрировать legacy приложение — к нему почти всегда приходится залезать в кишки, отлаживать распределенную систему долго и сложно… Не стала EAI серебряной пулей. Тем не менее направление живет и побеждает, судя по всему. Продукты развиваются, новые версии выходят. Жизнь продолжается.
Пользовался я этой штукой. При интеграции нескольких биллинговых, телевезионных и сетевых систем, в большомом азиатском национальном операторе. Населения в этой стране было много, абонентов соотвественно и нагрузки на систему были дикие.
Поначалу все было вроде бы хорошо, собрал себе быстро в конструкторе orchestration и опубликовал, развернул и все ок.
Но как только мы добрались до реальной логики то «баста» — лапки вверх и никуда дальше. Системы были очень разные и отличался не только формат данных вызовов, но и логика, посему пришлось дописывать для BizTalk дополнительные модули, которые свели преимущество системы на нет. Потому код проще писать и разворачивать без BizTalka.
Вообщем штука красивая, но бесполезная.
Пробовали, так же использовать другие ESB — результат тот же.
Поначалу все было вроде бы хорошо, собрал себе быстро в конструкторе orchestration и опубликовал, развернул и все ок.
Но как только мы добрались до реальной логики то «баста» — лапки вверх и никуда дальше. Системы были очень разные и отличался не только формат данных вызовов, но и логика, посему пришлось дописывать для BizTalk дополнительные модули, которые свели преимущество системы на нет. Потому код проще писать и разворачивать без BizTalka.
Вообщем штука красивая, но бесполезная.
Пробовали, так же использовать другие ESB — результат тот же.
Вот у меня, не работающего пока с BizTalk, пока тоже появляется такое ощущение что с BizTalk от идиллии до напильника один шаг. Собственно, для оркестраций работает и WCF, для мэппингов есть MapForce, для адаптеров… да, тут конечно полезно иметь «адаптеров на $100,000» но если учесть отсутствие таких банальных вещей как поддержка Excel или RSS, становится совсем не смешно — при таком-то ценнике :)
А кто-нибудь знает бесплатные аналоги (лучше opensource)?
Уже более 2-ух лет используем BizTalk Server.
Более глючного и уродского ПО я не видел ни разу в жизни! После знакомства с ним Microsoft очень сильно упала в моих глазах. Причём подпиливаем BizTalk мы не только сами, но и с помощью Microsoft Consulting. И некоторые проблемы до сих пор не решены.
Проблем очень много. Всех не перечислить. Например:
1. Утечки памяти (это в серверном продукте!). Сам делал костыль. Без этого костыля BizTalk падал через 5-10 минут c ошибкой Out of memory. Причём на msdn это всё описано, и относится к 2006 году. До сих пор не залатали. Есть рекомендации: использовать как можно реже эти функции, уменьшить объём обрабатываемых данных.
2. Нет нормальной документации. Формально она есть.
3. На вопрос сотрудникам Microsoft: где искать информацию о том-то… Ответ: поищите по блогам. Есть очень хорошие блоги… Официально информация отсутствует…
ну и так далее…
Более глючного и уродского ПО я не видел ни разу в жизни! После знакомства с ним Microsoft очень сильно упала в моих глазах. Причём подпиливаем BizTalk мы не только сами, но и с помощью Microsoft Consulting. И некоторые проблемы до сих пор не решены.
Проблем очень много. Всех не перечислить. Например:
1. Утечки памяти (это в серверном продукте!). Сам делал костыль. Без этого костыля BizTalk падал через 5-10 минут c ошибкой Out of memory. Причём на msdn это всё описано, и относится к 2006 году. До сих пор не залатали. Есть рекомендации: использовать как можно реже эти функции, уменьшить объём обрабатываемых данных.
2. Нет нормальной документации. Формально она есть.
3. На вопрос сотрудникам Microsoft: где искать информацию о том-то… Ответ: поищите по блогам. Есть очень хорошие блоги… Официально информация отсутствует…
ну и так далее…
"… использовать как можно реже эти функции..." — это 5 баллов.
Подлинник:
Статья «How to troubleshoot a memory leak or an out-of-memory exception in the BizTalk Server process»
support.microsoft.com/kb/918643
Статья «How to troubleshoot a memory leak or an out-of-memory exception in the BizTalk Server process»
support.microsoft.com/kb/918643
Более 5 лет работаю на рынке интеграции систем для телефонных компаний. Могу сказать точно — до сих пор нет НИ ОДНОГО нормального middleware для интеграции. И что самое печальное, до сих пор маюсь вопросом: НАФИГА оно вообще нужно? Клиент думает, что покупает панацею от всех проблем, но все с точностью до наоборот.
1. Любое Enterprise middleware не решает проблему дизайна архитектуры системы, которую все-равно так или иначе приходится разрабатывать.
2. Не устанавливает никакой четкой медотики разработки. Цикл разработки и versioning процессов — бич всех BPM-систем, до сих пор не разрешенный.
3. Лимитирует разработчика в использовании средств. Сильно усложняет многие простые концепты. Как правило даже невозможно сделать нормально модульный тестинг.
4. Такое ощущение, что SCA вообще не предназначена для бизнес-решений. Нет динамической линковки между модулями и сервисами! А когда количество модулей и связей между ними растет, и диаграмма зависимостей становится сложной, возникают неразрешимые проблемы при deploy.
5. А BPEL между прочим абсолютно не предназначен для бизнес-процессов! Через 4-5 лет поняли, наконец, и пытаются заменить BPMN.
6. А повсеместное испльзование WSDL и XSD приводит к тому, что если меняется интерфейс, то изменения затрагивают сразу ВСЕ модули, что создает дополнительные проблемы с versioning-ом.
7. Решения жутко тяжелые, глючные и тормозные. Абсолютно непредсказуемы в поведении. Требуют гораздо больше затрат в support & maintenance (чаще всего кто-то должен крутить педали, чтобы это все работало).
P.S. С BizTalk не работал. Использовали Websphere — глюкалово, которае просто не работает (с дорогущей и бесполезной поддержкой). Относительно неплохое Middleware от Oracle, но очень тяжелое.
В качестве эксперимента был использован OSGi+Camel+Spring+jBPM. Результат превзошел ожидания.
1. Любое Enterprise middleware не решает проблему дизайна архитектуры системы, которую все-равно так или иначе приходится разрабатывать.
2. Не устанавливает никакой четкой медотики разработки. Цикл разработки и versioning процессов — бич всех BPM-систем, до сих пор не разрешенный.
3. Лимитирует разработчика в использовании средств. Сильно усложняет многие простые концепты. Как правило даже невозможно сделать нормально модульный тестинг.
4. Такое ощущение, что SCA вообще не предназначена для бизнес-решений. Нет динамической линковки между модулями и сервисами! А когда количество модулей и связей между ними растет, и диаграмма зависимостей становится сложной, возникают неразрешимые проблемы при deploy.
5. А BPEL между прочим абсолютно не предназначен для бизнес-процессов! Через 4-5 лет поняли, наконец, и пытаются заменить BPMN.
6. А повсеместное испльзование WSDL и XSD приводит к тому, что если меняется интерфейс, то изменения затрагивают сразу ВСЕ модули, что создает дополнительные проблемы с versioning-ом.
7. Решения жутко тяжелые, глючные и тормозные. Абсолютно непредсказуемы в поведении. Требуют гораздо больше затрат в support & maintenance (чаще всего кто-то должен крутить педали, чтобы это все работало).
P.S. С BizTalk не работал. Использовали Websphere — глюкалово, которае просто не работает (с дорогущей и бесполезной поддержкой). Относительно неплохое Middleware от Oracle, но очень тяжелое.
В качестве эксперимента был использован OSGi+Camel+Spring+jBPM. Результат превзошел ожидания.
А Ensemble от InterSystems пробовали?
А Informatica / InformaticaCloud?
Sign up to leave a comment.
BizTalk Server 2009