BizTalk Server 2009



    Здравствуйте уважаемые хабропользователи. В данном посте я хочу рассказать вам о продукте для автоматизации и управления бизнес процессами BizTalk Server 2009.

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

    Введение


    Уже давно системы управления средними и крупными компаниями включают в себя множество программных комплексов, вводимых по мере роста и развития предприятия. Также эти системы требуют связи с программами и сервисами вне предприятия. Выглядит это приблизительно так:



    Для понимания проблемной области приведу пример простейшего бизнес процесса:
    1. Пользователь создает документ «Заказ товара» через web портал
    2. Заказ должен быть передан во все остальные системы предприятия (бухгалтерам чтобы оплатить счет, в логистическую систему для учета и доставки товара, в Datawarehouse для составления исторических данных и подсчета kpi и т.д.)

    Имеем проблему: как заставить все компоненты работать друг с другом?

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



    Для решения таких проблем и был создан BizTalk Server (BTS). Он вводит новый уровень, с которым взаимодействуют системы, и берет на себя обязанности по доставке сообщений подписчикам. Теперь в нашем примере не нужно слать документ с web портала во все остальные системы. Достаточно передать его в BizTalk, после чего быть уверенным в доставке сообщения в каждую из требующих этого систем. Очевидно, что количество связей при таком подходе значительно уменьшится. Это позволит снизить затраты на управление системами в целом (ведь мы сняли с них обязанности общения с другими системами), а также позволит с легкостью добавлять новые.



    Архитектура BTS


    Вот простейший сервис достаточный для описания архитектуры работы BTS:
    1. На входящем порту получаем сообщение инициирующее бизнес процесс;
    2. Обрабатываем сообщение;
    3. Отправляем сообщение на один или несколько исходящих портов;


    А вот так этот процесс протекает на уровне сервера:


    Для начала немного определений из того что видно на картинке:

    Receive Adapter – входной порт. Необходим для приема сообщения из внешнего мира. Поддерживает различные протоколы и способы доступа к приложениям.
    Orchestration – исполняющая часть бизнес процесса. Здесь можно писать код на C#, трансформировать сообщения, выбрасывать и ловить эксепшены, вызывать компенсацию для успешно отработавших сегментов и т.д. Но главный функционал, который предоставляет оркестрейшен — это паттерны обработки сообщений. Один из них я приведу в разделе с примером.
    Send Adapter – тоже что и Receive Adapter только предназначен для отправки сообщений.

    Ну а теперь процесс работы сервиса более детально:

    1. Receive Adapter получает сообщение по одному из множества доступных протоколов из внешнего мира;
    2. Сообщение пропускается через Receive Pipeline (с возможностями трансформации и валидиции);
    3. Сообщение попадает в Message Box (MB) – хранилище сообщений внутри базы на основе MS SQL Server;
    4. Постоянно работающий агент фиксирует наличие не обработанного сообщения и получателя в виде оркестрейшена;
    5. Агент вызывает оркестерейшен с передачей ему на вход сообщения;
    6. Оркестерейшен выполняет всю необходимую работу и генерирует новое сообщение которое попадает обратно в Message Box (чаще всего структура нового сообщения отличается от оригинального);
    7. Агент снова фиксирует появление сообщения в MB и ищет получателя. На это раз им является Send Adapter;
    8. Сообщение передается на Send Adapter который в связке с Send Pipeline по необходимости валидирует, трансформирует и отправляет сообщение во внешний мир по любому из доступных протоколов;

    Теперь, когда базовый пример понятен я постараюсь на его основе описать некоторые полезные и даже уникальные возможности которые предоставляет BTS:
    1. Большое количество протоколов с которыми могут работать входящие (исходящие) порты (File, SMTP, HTTP, WCF, MSMQ, SOAP и другие). Кроме протоколов есть также поддержка различных приложений: Oracle, SQL Server, WebSphere MQ, SharePoint, Tibco, SAP, JMS, JD Edwards, Dynamics и другие. Если же вашей системы нет в списке, то есть SDK при помощи которой вы можете сами разработать адаптер;
    2. Полученные на входе сообщения можно преобразовывать внутри Pipeline в наиболее удобный формат до того как они попадут в оркестрейшен. Из коробки есть поддержка для работы с Flat files и богатые возможности обработки EDIFACT. Все эти форматы BizTalk сам преобразует в XML с заранее заданной XSD схемой.
      И опять-таки если вы хотите на вход получать, например Excel файлы или Binary файлы то может сами написать процедуру преобразования в XML, а можете и прямо так кинуть в Message Box, и потом уже разобрать начинку сообщения внутри оркестрейшена.
      Хочется особенно отметить удобство обработки EDIFACT сообщений. Поддерживаются все имеющиеся форматы, но если один из ваших партнеров отклонился от стандарта, можно легко подправить формат под него. Кроме фреймворка обработки сообщений BizTalk предоставляет еще инфраструктуру для обмена документами. В ней можно вести учет уникальности сообщений, вводить специальные настройки для каждого из партнеров и автоматические отправлять подтверждения принятия EDI документа. Также все это может работать через AS2 протокол;
    3. В описанном примере происходит асинхронная обработка сообщения, но в общем случае она может быть синхронной или смешанной. Например если на вход нам приходит HTTP запрос требующий ответа то мы можем ответить на него только после того как убедимся в успешной отправке сообщения на исходящий порт;
    4. Паттерны разработки подразумевают повторное использование одних компонент без необходимости дублирования. Например, если вам понадобиться получать сообщение не через FileSystem а через FTP то это никак не коснется реализации – достаточно только изменить тип входящего порта и настроить его на правильный адрес;
    5. Контекстный роутинг сообщений. Очень удобная функциональнсоть! Если у вас есть несколько компонент обрабатывающих один тип сообщения, то вы можете подписать их на получение по описанию XSD схемы. Таким образом, как только в Message Box падает XML удовлетворяющих заданной XSD структуре, тут же все заинтересованные подписчики получают себе его копию. Естественно добавление нового подписчика не влияет не на получателей не на отправителя. Если провести аналогию с JMS то это как если бы у вас был один топик с одним паблишером и множеством сабскрайберов. Но разница в том, что в случае контекстного роутинга вам не нужен топик, а нужен только контракт на получение сообщения в виде XSD схемы;
    6. Немного про масштабирование. Как вы заметили, Окестрейшен получает сообщение напрямую из базы. Он не знает, откуда оно пришло и кому предназначено, его задача взять сообщение, обработать и положить обратно. Поэтому вы можете установить сколько угодно серверов, каждый из которых будет подписан на получение сообщений. И в тот момент, когда внезапно их окажется в базе 1000 штук — Load Balancer автоматически раздаст их поровну для каждого сервера в зависимости от его текущей загрузки;
    7. Хранение сообщений в базе дает еще один положительный момент. Если при отправке сообщения на порт происходит ошибка (например — канал закрыт фаерволом), сообщение отбракуется и сохранится в базе с описанием ошибки. Когда администратор обнаружит проблему, он сможет при необходимости исправить проблему с сетью и повторно отправит сообщение на порт. Также можно реализовывать автоматические стратегии репроцессинга. Все это делается без какого либо участия девелопера через удобную и информативную консоль администрирования BTS;
    8. Пару слов о самой консоли – это мощное средство управления и мониторинга состояния одного или нескольких BizTalk серверов. Тут можно наблюдать какие сервисы активны, управлять их запуском, настраивать шедулинг, проверять как происходит роутинг сообщений между компонентами, были ли в последнее время ошибки и многое другое;
    9. BRE (Business Rule Engine) – механизм внедрения функциональности в сервис налету (Dependency injection). Для использования BRE девелопер вставляет в оркестрейшен элемент Bussines Rule и реализует процесс обработки в контексте этого правила. Затем сервис деплоится на сервер и начинает работать. Со временем бизнес модель может измениться, тогда Аналитик должен будет создать новое правило в специальном user friendly редакторе и задеплоить его в BRE репозиторий ассоциировав с требуемым сервисом. При этом ранее созданный процесс будет функционировать на основе изменившегося правила, без необходимости привлечения разработчика и перезапуска сервиса;
    10. BAM (Business Activity Monitoring) – все элементы внутри оркестрейшена которые используются в процессе функционирования сервиса содержат набор параметров которые доступны для BAM сервера. Например, объект ремаппинга xml сообщения предоставляет доступ ко всем полям заданным XSD схемой. Имея эти данные бизнес пользователи, без участия девелопера, могут создавать выборки данных, чарты и диаграммы на основе данных проходящих в XML сообщении через сервис. Вся эта работа происходит независимо от процесса работы самого сервиса и может изменяться без необходимости остановки сервиса. Результаты могут выводиться в документы office или на специальный BAM портал.


    Пример сервиса


    Вот пример более искушенного сервиса, показывающий возможности оркестрейшена по управлению течением бизнес процесса (номера в списке соответствуют пунктам в дизайнере оркестрейшена на картинке):



    1. Пользователь в своей системе создает заказ товара. На его запрос должен прийти положительный или отрицательный ответ в зависимости от разных факторов, определяющихся внешними, по отношению к пользователю системами. Заказ попадает на вход адаптеру BizTalk, далее в MessageBox, и затем выполнение передается в оркестрейшен;
    2. Сервис отправляет полученный заказ менеджеру для проверки валидности (ведь пользователь мог заказать товар не касающийся работы фирмы);
    3. Этот же заказ немедленно отправляется на склад для проверки возможности его выполнения (Товара может попросту не быть в наличие);
    4. Далее в работу вступает ParallelActions Shape, реализующий Parallel Convoy Pattern. Этот элемент завершит выполнение только когда отработают все составляющие его элементы. А сработать должны 2 факта: сервис должен получить ответы от менеджера и со склада.
      В общем случае ожидание может длиться достаточно долго (например если Менеджер в отпуске). На этот случай в BizTalk есть возможность задать тип Orchestration: Long Running. Тогда во время ожидания ответа из обеих систем состояние выполнение оркестрейшена сериализуется и сохранится в базе (в терминах BTS этот процесс называется Дегидротацией приложения). А как только будут получены оба ответа — сервис снова загрузится в память и завершит выполнение ParallelActions Shape.
      Тут есть один тонкий момент. В реальной системе юзеров всегда много и приложению менеджера и на склад одновременно может приходить несколько сообщений, соответственно и отвечать они могут не в том порядке, в котором пришли запросы. Отсюда вопрос: как BizTalk знает какому из работающих инстансов сервиса предназначен ответ из внешней системы?
      Ответ прост, логичен и реализуется всего в пару кликов в оркестрейшен дизайнере. У каждого сообщения уходящего на Send Port должен быть выставлен Correlation_ID. В данном случае на его роль идеально подходит поле OrderNo. Его нужно указать прямо из контекста XML сообщения. Этот же Correlation_ID задается и для ответа на запрос. Таким образом, мы имеем множество сервисов ждущих ответа и множество ответов. Для их связи между собой Агент управления вызовами будет использовать поле OrderNo. То есть, если инстанс «А» отправил заказ номер «35», а инстанс «В» заказ «47», то ответ на заказ «47» вернется инстансу «В», а на заказ «35» — «А»;
    5. После того как ответы получены останется проверить результаты от менеджера и со склада. Если все OK, пользователь получит уведомление об успешном выполнении его заказа, а сам заказ уйдет в систему поставщика товара. Иначе пользователь получит сообщение с описанием причины, почему его заказ не может быть удовлетворен. На этом сервис завершит работу;


    В этом пример сервис работал с 4 портами. За каждым из них находится своя система (на пример это могут быть Oracle Retail, Dynamics, порты JMS и Web Sphere или еще что-нибудь), но сам сервис не должен беспокоиться какая именно. Детали доставки сообщения, авторизации, преобразования сообщения в нужный формат для каждой из систем происходят на уровне адаптера и ассоциированного Pipeline. Также проблемы транспорта и возможных ошибок доставки также решаются при помощи стандартных средств, и не требует реализации на уровне сервиса (хотя если понадобится, это можно сделать и внутри оркестрейшена).

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

    Спасибо за внимание, надеюсь вам было интересно.

    Литература:


    • WROX: Professional BizTalk Server 2006
    • APRESS: Pro BizTalk 2009
    • PACKT: SOA Patterns with BizTalk Server 2009


    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 45
    • 0
      Интересно, спасибо.
      Во втором разделе:
      >> Если логику передачи дЫнных реализовывать
      • +7
        «BizTalk'овый сервер»
        интересно звучит
        • +3
          Отличная статья.

          Спасибо.
          • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Да, 35 тыс. долл. за enterprise-версию — это более чем изрядно. Поэтому такая интересная и мощная штука используется только крупными предприятиями. Наверное, это правильно, ибо она и нужна только крупным. Но из этого получается, что разработчиков, имеющих опыт работы с BizTalk, мало. Как же оно двигается в бизнес? Видимо, как-то сбоку и сверху — через сейлзменов на месредесах, продающих это большим боссам.
              • 0
                Да разве ж это дорого? Вот возьмите IBM [WebSphere] Message Broker: «IBM's pricing is straightforward and based on a flat $85,000 per CPU» (правда, это баян 4-летней давности, но не думаю, чтобы соотношение цен существенно поменялось с тех пор).

                Что касается модели продвижения, то вы тут попали в точку. Активные продажи, будь они неладны…

                • 0
                  Позволю себе с Вами не согласиться. Все просто, средняя зарплата программиста, для простоты 3000$, берем команду из 4 разработчиков (менеджеров, аренду помещения и все остальное не считаем). Вы уверены, что эта команда напишет аналогичную систему интеграции ваших разрозненных систем за 3 месяца (опять же отбросим сопровождение, включенные в стоимость обновления и т.д.). Если разработают, то наверно это действительно дорого. В противном случае, Вы в плюсе.
                  • +2
                    А почему вы стоимость внедрения (и сопровождения) BizTalk не учитываете? Сильно сомневаюсь, что стоимость лицензии это основная часть в расходах.
                    • 0
                      Я дороговизну мерял не потенциальными трудозатратами, а некими абсолютными абстрактными величинами. Надо чтобы босс решил выложить 35 тыс. за софтину, которая щастье начнет приносить (если начнет) только после внедрения. А ежели не начнет? :)
                      • 0
                        По моим наблюдениям, люди которые интересуются BizTalk уже при таких деньгах, что им легче заплатить и спать спокойно чем вливаться в рискованный замес создания чего-то самописного.
                    • 0
                      В 2006 году работал в крупной компании (>5000 чел), пробовали внедрять бизток для интегграции разных инфопотоков — в том числе КИС и сайт. Вобщем проект получился монстрозный, не очень поддерживаемый. Развивать его можно было только с помощью вендоров, которые внедряли.
                      В итоге нам не очень понравилось и дальше пилота дело не пошло.
                    • 0
                      попробуйте openerp, правда, я не уверен, что она умеет тоже самое
                    • +3
                      Просто интересно, а есть open source аналоги или стремящиеся к тому продукты?
                        • +1
                          Очень хорошие OpenSource продукты: Mule ESB, ServiceMix, Apache Camel — это так сказать легковесные варианты ESB.

                          Также есть бесплатная версия JBoss ESB от RedHat который уже ближе к BizTalk.
                          • +2
                            Не забываем про очень интересный RabbitMQ на Erlang. Есть хороший опыт построение на нем отказоустойчивых финансовых приложений. Плюс – его можно дорабатывать. Но крупные предприятия (в т.ч. банки) зачастую предпочитают бренд опенсурсу.
                            • 0
                              Насчет предпочтения бренда опенсорсу — да, порой доходит до маразма.

                              В компании, на объекте которой я работаю, готовы купить лицензии Adobe Photoshop вместо установки Paint.NET, покупать SnagIT вместо использования фриварных или гораздо более дешевых аналогов и т.д. ИТ бюджет компании тратится на всякую ерунду вмест куда более нужных вещей.

                              Обоснование очень простое: «бренды отвечают за свою продукцию, предоставляю поддержку и т.д.».

                              По факту это объяснение не выдерживает никакой критики, особенно когда пытаешь получить эту поддержку от вендоров. То у тебя версия ПО уже не поддерживаемая (Microsoft, ABBYY), то просто «это у вас локальные проблемы совместимости, ничем помочь не можем».

                              Странные они в этой компании, одной из крупнейших в мире, кстати…
                              • +3
                                В больших компаниях очень хорошо работают механизмы перекладывания ответственности и прикрывания жёпы. Поставьте себя на место начальника ИТ-отдела. Зачем ему брать на себя ответственность за непонятный софт? Вот представьте, произошел сбой, если софт куплен у серьезного поставщика — можно связать с техподдержкой, переложить проблему на них. В случае какиих-то серьезных проблем, можно подключить их специалистов, и объяснить своим серьезность проблемы.
                                А вот если используется бесплатный софт — что с ним делать? первый вопрос, который ему зададут: «Нафига вы это поставили? Вам что бюджет не выделили?»
                          • 0
                            Спасибо за отличное введение, хотелось продолжения и целого цикла статей по BizTalk :-)
                            • –1
                              лого немного напомнило логотип Microsoft Zune
                              • +2
                                А мне больше SQL Server 2008
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +4
                                    WTF?!
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • +1
                                    Если в одно слово, то это паттерн Обзёрвер.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0
                                      Очень позитивная идея — работать в BizTalk с банками через электронные протоколы. Если бы это еще работало в России для рядовых ООО, было бы вообще круто. А то де факто приходится такой огород городить даже для простейших операций, что крыша едет.

                                      За пост по BizTalk спасибо, думаю тут многим интересно о нем почитать. Жаль правда что в VS2010 с ним не повозиться — ждем 2010го релиза :)
                                      • +1
                                        я немного подкорректировал вашу первую схему и в модели появилась гармония
                                        39.07 КБ
                                        • 0
                                          Пентаграмма очень уместна. Полагаю, большинство из тех, кому довелось поработать с Бистоком в боевом проекте, с Вами согласится :))
                                          • +1
                                            Рогами вверх надо ставить. Так слишком мирно.

                                          • 0
                                            Мне статья понравилась — доходчивая превьюшка назначения/возможностей рассматриваемого софта. Спасибо.
                                            • +2
                                              Когда мне довелось впервые столкнуться с бизтолком (а было это в версии 2001), одной из главных проблем для нас было — понять, а что же это такое? Ну да, порты, каналы, очереди… Круто!!! А дальше чего? Что на этом можно делать, а что нельзя? Может его хорошо использовать для репликации баз данных? Или он может быть основой для ERP? Или вести на нем список задач?
                                              Синхронизировать файловые директории? Обмениваться короткими сообщениями, как в аське? Ваять интернет-магазины? Или это долгожданное некоторыми деятелями средство программирования одной мышью (без применения программистов)? А нужно ли его тут применять, или нам хватит небольшого скрипта на перле?..

                                              Мне тогда здорово помогла книжка Enterprise Integration Patterns, из серии «одобрено товарищем Фаулером», довольно давно есть и в русском переводе Шаблоны интеграции корпоративных приложений (на просторах рунета можно найти в формате djvu). С ее помощью в голове все утряслось и стало на свои места. Очень рекомендую почитать ее прежде чем встраивать бизток в корпоративную архитектуру. Да и независимо от бизтока — хорошая книжка.

                                              ЗЫ Одно время EAI было очень модным направлением, страстно любимым Гартнером и прочими консалтерами. С разных сторон неслись стенания: унаследованные (legacy) приложения нас душат, не пуская в светлое будущее е-бизнеса. Количество информационных связей растет лавинообразно, устраивать линки «каждый с каждым» уже нету сил. Интеграция приложений — вот что поможет разобраться в помойке!
                                              Со временем выяснилось (где ты, капитан Очевидность?) что интеграция — тоже не такая простая штука, всех проблем не решает, некоторые новые создает, чтобы интегрировать legacy приложение — к нему почти всегда приходится залезать в кишки, отлаживать распределенную систему долго и сложно… Не стала EAI серебряной пулей. Тем не менее направление живет и побеждает, судя по всему. Продукты развиваются, новые версии выходят. Жизнь продолжается.
                                              • 0
                                                Пользовался я этой штукой. При интеграции нескольких биллинговых, телевезионных и сетевых систем, в большомом азиатском национальном операторе. Населения в этой стране было много, абонентов соотвественно и нагрузки на систему были дикие.
                                                Поначалу все было вроде бы хорошо, собрал себе быстро в конструкторе orchestration и опубликовал, развернул и все ок.

                                                Но как только мы добрались до реальной логики то «баста» — лапки вверх и никуда дальше. Системы были очень разные и отличался не только формат данных вызовов, но и логика, посему пришлось дописывать для BizTalk дополнительные модули, которые свели преимущество системы на нет. Потому код проще писать и разворачивать без BizTalka.

                                                Вообщем штука красивая, но бесполезная.
                                                Пробовали, так же использовать другие ESB — результат тот же.
                                                • 0
                                                  Вот у меня, не работающего пока с BizTalk, пока тоже появляется такое ощущение что с BizTalk от идиллии до напильника один шаг. Собственно, для оркестраций работает и WCF, для мэппингов есть MapForce, для адаптеров… да, тут конечно полезно иметь «адаптеров на $100,000» но если учесть отсутствие таких банальных вещей как поддержка Excel или RSS, становится совсем не смешно — при таком-то ценнике :)
                                                  • 0
                                                    На счет грани между напильником и идиллией бывали случаи. Тогда просто можно часть логики вынести в отдельную dll'ку.

                                                    И еще как говорил кто-то из MS: «BizTalk позволяет решать средние по сложности задачи легко, а сложные делать выполнимыми» :)
                                                • 0
                                                  А кто-нибудь знает бесплатные аналоги (лучше opensource)?
                                                  • +1
                                                    Уже более 2-ух лет используем BizTalk Server.

                                                    Более глючного и уродского ПО я не видел ни разу в жизни! После знакомства с ним Microsoft очень сильно упала в моих глазах. Причём подпиливаем BizTalk мы не только сами, но и с помощью Microsoft Consulting. И некоторые проблемы до сих пор не решены.

                                                    Проблем очень много. Всех не перечислить. Например:

                                                    1. Утечки памяти (это в серверном продукте!). Сам делал костыль. Без этого костыля BizTalk падал через 5-10 минут c ошибкой Out of memory. Причём на msdn это всё описано, и относится к 2006 году. До сих пор не залатали. Есть рекомендации: использовать как можно реже эти функции, уменьшить объём обрабатываемых данных.

                                                    2. Нет нормальной документации. Формально она есть.

                                                    3. На вопрос сотрудникам Microsoft: где искать информацию о том-то… Ответ: поищите по блогам. Есть очень хорошие блоги… Официально информация отсутствует…

                                                    ну и так далее…
                                                    • 0
                                                      "… использовать как можно реже эти функции..." — это 5 баллов.
                                                  • 0
                                                    Более 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. Результат превзошел ожидания.
                                                    • 0
                                                      А Ensemble от InterSystems пробовали?
                                                      • 0
                                                        А Informatica / InformaticaCloud?
                                                        • 0
                                                          Информатик это ETL продукт, а не middleware. Ключевое отличие ETL в оптимизации под большие объемы отчетных данных, в то время как middleware предназначен для интеграции бизнес процессов.

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое