В очередной раз столкнувшись с предложением заказчика "а сделайте мне универсальный транспорт, в котором сообщения будут представлять собой обычные строки, содержащие XML, и который не будет осуществлять никакой валидации/обогащения/мониторинга, но зато я должен иметь возможность включать новые маршруты/преобразования правкой строчек в некоторой конфигурационной базе данных, а да, еще очень хочу чтобы это все было на Oracle Service Bus/IBM WebSphere ESB/IBM WebSphere Message Broker", Суровый решил написать вам о своем отношении к подобным решениям. Статья из серии "не могу молчать".
Так получилось, что за четыре года опыта занятия системной интеграцией, практически каждый раз или в начале проекта, или в процессе его развития заказчиков озаряет идея. Нет, даже так: Идея! Идея универсальной шины, которая ничего не будет делать, кроме маршрутизации и трансформации сообщений. Зато заказчик сможет сам настраивать эти процессы (в основном маршрутизацию), причем обязательно с помощью только лишь правки конфигурации в базе данных. По сути от нас как исполнителей требуется некоторая универсальная реализация паттернов интеграции корпоративных приложений и каноническая модель данных. Каждый такой заказчик считает, что получив подобное решение, он сможет оперативно подключать к нему новые информационные системы, просто разработав соответствующий адаптер и добавив несколько строк в базу данных конфигурации.
На рисунке представлена типичная схема такой универсальной шины. От подключенных систем поступают сообщения, закодированные в формате данных этих систем. Обычно у каждого такого сообщения предполагаются некие заголовки, описывающие откуда идет сообщение, куда, каков его тип. Далее возможны варианты: либо адаптер разбирает поступившее сообщение и преобразует его в канонический формат, а затем передает на вход некоторому "ядру", либо просто отправляет в "ядро" как есть. "Ядро", анализируя метаданные, выбирает из базы данных конфигурации системы дальнейший маршрут сообщения. В варианте с отсутствием канонического формата, оно же осуществляет и преобразование сообщения в формат каждой системы-приемника (т.е. возможны и маршруты вида 1 -> N). Сообщение поступает на вход адаптера соответствующей системы-приемника, который либо преобразует его из канонического формата в требуемый, либо просто передает на ее вход. Предполагается, что для расширения данной конструкции заказчику достаточно лишь разработать адаптер системы, набор преобразований из ее формата в канонический или формат всех других систем, с которыми она взаимодействует, а так же добавить сведения о новых маршрутах и преобразованиях в базу данных конфигурации.
Так вот, на самом деле этого не достаточно. Даже у самого-самого "универсального" решения описанной задачи есть ограничения.
Во-первых, если весь обмен по такой шине идет в каноническом формате данных, то все адаптеры заняты только трансформацией сообщений из формата подключенной системы в канонический и наоборот. Но у канонического формата данных есть ограничения. При подключении системы, в сообщениях которой содержится новая бизнес-информация, потребуется расширять канонический формат, дорабатывать все связанные с данным сообщением преобразования, дорабатывать адаптеры систем-приемников и зачастую дорабатывать сами системы-приемники. Как мы видим - слишком много всего придется дорабатывать, что как-то не вписывается в заявленную концепцию универсальности. Если же в решении не предполагается использование канонического формата, то все гораздо печальнее - каждое подключение новой внешней системы потребует разработки трансформаций для сообщений данной системы в/из форматы/ов сообщений всех систем, с которыми она будет взаимодействовать.
Во-вторых, возникают вопросы организации грамотного тестирования. Адекватный архитектор не станет подключать информационную систему к интеграции без полномасштабного тестирования. Однако наличие в компании "универсального" решения слишком повышает соблазн выполнить такое подключение. Ну действительно, что там тестировать, мы же адаптер написали, записи в базе данных конфигурации добавили, значит все будет работать. При этом как-то забывается, что если даже сообщения между системами будут передаваться, то это не гарантирует правильности выполнения бизнес-процессов, зависящих от данных сообщений. Тестировать нужно всю интеграцию в комплексе.
В-третьих, не стоит забывать, что если у тебя в руках молоток, то все вокруг начинает казаться гвоздями. Нужно подумать о том, как наличие такой "универсальной интеграционной шины" скажется на архитектуре предприятия. Если подключить информационную систему просто, то велик соблазн выносить на шину все больше и больше межсистемных взаимодействий, которые еще гордо можно назвать "каноническими сервисами". Т.е. вместо разработки в конечной информационной системе сервиса, возвращающего информацию по заявке со всеми комментариями мы разрабатываем два взаимодействия на шине: одно для получения информации по заявке, другое - для получения комментариев. И как-то забывается, что шина находится в Москве, а конечная система управления заявками - во Владивостоке. Но даже не это главное. Концепция универсального транспорта предполагает, что сам по себе этот транспорт выполняет лишь ограниченный набор операций: маршрутизацию и трансформацию отдельных сообщений. Агрегация, обогащение и более сложные манипуляции возлагаются на сами подключенные информационные системы. Таким образом, в нашем примере, объединять данные, возвращенные двумя информационными потоками: информацию о заявке и комментарии к ней, является обязанностью системы-приемника. А если данная информация нужна в нескольких системах - обязанностью каждой такой системы.
Хуже всего же в данной ситуации не тот факт, что концепция универсального транспорта не работает, т.е. не обеспечивает пресловутую универсальность. Хуже всего то, что для реализации концепции предлагается применять весьма дорогостоящее программное обеспечение, при этом на практике используя лишь единицы процентов его возможностей. Данная проблема имеет два аспекта.
Во-первых, заказчики ведь не просто так хотят подобное универсальное решение. Они как правило уже имеют опыт внедрения информационных систем. И они видят, что внедрение занимает довольно много времени. И это действительно так, пока речь идет об использовании таких низкоуровневых средств, как языки программирования Java, SQL, PL/SQL и т.д. При разработке интеграции на Java приходится тратить месяцы на решение довольно стандартных проблем, таких, как трансформация сообщений, особенно если речь идет о работе с коллекциями. Несколько последних статей в блоге Сурового посвящены описанию данных проблем и решений. Ситуацию несколько исправляет наличие ряда фреймворков, реализующих паттерны интеграции. Речь идет об Apache Camel и Spring Integration.
Во-вторых, исполнители - компании-интеграторы и независимые разработчики - как правило не умеют пользоваться имеющимися средствами. Для многих промышленные сервисные шины предприятия - это лишь реализация каких-то интеграционных паттернов, из которых как можно быстрее нужно собрать "универсальное решение". У многих разработчиков на российском рынке так же наличествует предвзятость, граничащая с религиозной: зачем нужны все эти сервера приложений, WebLogic какой-то, WebSphere там, сервисные шины, какая-то Oracle Service Bus, IBM WebSphere Message Broker, когда есть Apache Tomcat и Spring Framework, на которых сейчас на коленке я сделаю вам приложение. При этом приложение возможно даже и будет работать, но с одной стороны непонятно кто будет его поддерживать, а с другой - реализация займет шесть месяцев, вместо одного, как было бы при использовании промышленных инструментов. Впрочем, любителей варить кашу из топора, данные вопросы не интересуют, как-то низко это все, поддержка какая-то, деньги, амикошонство какое, фи.
Впрочем, перечислить имеющиеся проблемы мало. Нужно предложить какое-то адекватное решение. Таким решением является использование промышленных интеграционных продуктов по назначению. Данные продукты задумывались не как кубики для построения "универсального решения", т.е. не как средства разработки адаптеров или многофункционального ядра. Они и есть такое решение. Продукты Oracle, как и продукты IBM, Tibco, Software AG и других уважаемых корпораций имеют в своем составе специализированные IDE существенно упрощающие разработку. По сути разработка интеграционного решения сводится к прорисовке информационных потоков, сервисов и процессов. Это как правило ничуть не сложнее добавления записей в конфигурационные таблицы, но обладает рядом преимуществ.
- Гибкость. Сервисная шина предприятия перестает быть просто транспортом, осуществляющим маршрутизацию и преобразование сообщений. Не нужно вгонять себя в рамки. Современные промышленные решения могут выполнять множество других действий: валидацию, обогащение, агрегацию, разделение сообщений на части с их независимой обработкой и последующим объединением результатов и даже создание настоящих композитных сервисов.
- Наглядность. Вместо хранения информации об интеграции в таблицах базы данных, при правильном использовании промышленных решений данная информация закладывается в сами схемы информационных потоков. Эти схемы легко открыть с помощью IDE и просмотреть в графическом виде. При этом данные схемы могут быть не только вида "отправили что-то в ядро" или "отправили что-то из ядра в систему", но и представлять собой сквозные процессы, на которых явно видны все взаимодействующие участники. Такие схемы предлагают неоценимую помощь администраторам и аналитикам при сопровождении и развитии интеграционного решения.
- Производительность. Информация о маршруте каждого сообщения не обязана содержаться в базе данных, откуда ее необходимо каждый раз извлекать. Сам код интеграционного потока является такой информацией. Накладные расходы существенно снижаются. Если же учесть, что обновление кода одного потока в современных промышленных решениях не требует остановки других, а зачастую и самого обновляемого потока, то повышается не только производительность решения, но и его надежность и доступность.
- Отсутствие единой точки отказа. На схеме, представленной в начале статьи, мы можем видеть две точки отказа: ядро и базу данных с информацией о конфигурации решения. При выходе из строя каждой из них интеграция полностью останавливается. Использование промышленных решений избавляет нас от необходимости создавать некоторое ядро: все операции над сообщениями, трансформации, маршрутизация, обогащение и т.д., выносятся в соответствующие сервисы, выход из строя одного из которых не приводит к потери работоспособности других. База данных с настройками интеграции же зачастую вообще становится не нужна.
- Тестирование и мониторинг. Некоторые промышленные решения, такие как Oracle SOA Suite, содержат средства автоматического модульного и интеграционного тестирования разрабатываемых потоков, сервисов и бизнес-процессов. При этом данные решения снабжены мощными средствами мониторинга во время исполнения, показывающими какое время занимает выполнение того или иного сервиса, каков был процент отказов и по какой причине. При необходимости можно так же настроить отправку оповещения администратору по почте или с помощью SMS. При реализации "универсальных решений" данные возможности как правило не используются.
Выводы из моего рассказа можно сделать следующие. Не нужно бояться нового, его нужно изучать. Заказчику нужно объяснять, что разработка с использованием правильных средств больше не напоминает программирование на Java. Ему не нужно будет ждать месяцами своего интеграционного решения. Он его уже купил. Теперь доработка информационных потоков в ответ на изменение бизнеса будет занимать время, измеряемое днями, а зачастую - часами. С учетом тестирования. Силами существенно меньшей команды программистов.
На моем самом крупном проекте в AT Consulting сервисную шину, обеспечивающую интеграцию порядка 60 информационных систем и передачу более 5 000 000 сообщений в сутки, поддерживала команда из трех разработчиков. Трех разработчиков. Для сравнения доработка основной информационной системы на Java велась силами примерно двадцати человек, а сколько ресурсов тратилось на доработки остальных приложений, участвующих в интеграции, не берусь даже оценить.
Так же могу рассказать об опыте решения одной и той же задачи с использованием разных технологий. В каком-то смысле это - бесценный опыт для архитектора, поскольку такое счастье выдает очень редко: сравнить несколько технологий на примере решения одной задачи. Если не учитывать время на бизнес-анализ и согласование требований, то с использованием Oracle Service Bus задача была решена за месяц, лично помню как большинство трансформаций сообщений (два десятка сообщений, каждое содержит от 5-ти до 40-ка полей) было сделано за один день. На Java решение данной задачи заняло более полугода. Оба решения разрабатывал ваш покорный слуга лично. По-моему разница между подходами очевидна и довольно наглядна. Понятно, что мои слова могут показаться кому-то рекламой и конечно нужно учитывать квалификацию персонала, ведь задача, занявшая у кого-то месяц, может другой командой решаться гораздо дольше. Признаю, что современные промышленные средства интеграции имеют некий порог вхождения, но инвестиции в эту сферу вполне оправданы.
К тому же за легкость и гибкость разработки, даруемые правильным использованием правильных средств, приходится платить. Т.к. команда поддержки шины показывает производительность в разы превосходящую все другие команды, то у менеджмента появляется соблазн вынести на шину все что можно и даже нельзя. Как правило даже пытаются вынести вещи, которые не имеют никакого отношения к интеграции. Но это уже другая, более приятная, история.
Оставайтесь на связи ;)
Понравилось сообщение - подпишитесь на блог
Так получилось, что за четыре года опыта занятия системной интеграцией, практически каждый раз или в начале проекта, или в процессе его развития заказчиков озаряет идея. Нет, даже так: Идея! Идея универсальной шины, которая ничего не будет делать, кроме маршрутизации и трансформации сообщений. Зато заказчик сможет сам настраивать эти процессы (в основном маршрутизацию), причем обязательно с помощью только лишь правки конфигурации в базе данных. По сути от нас как исполнителей требуется некоторая универсальная реализация паттернов интеграции корпоративных приложений и каноническая модель данных. Каждый такой заказчик считает, что получив подобное решение, он сможет оперативно подключать к нему новые информационные системы, просто разработав соответствующий адаптер и добавив несколько строк в базу данных конфигурации.
На рисунке представлена типичная схема такой универсальной шины. От подключенных систем поступают сообщения, закодированные в формате данных этих систем. Обычно у каждого такого сообщения предполагаются некие заголовки, описывающие откуда идет сообщение, куда, каков его тип. Далее возможны варианты: либо адаптер разбирает поступившее сообщение и преобразует его в канонический формат, а затем передает на вход некоторому "ядру", либо просто отправляет в "ядро" как есть. "Ядро", анализируя метаданные, выбирает из базы данных конфигурации системы дальнейший маршрут сообщения. В варианте с отсутствием канонического формата, оно же осуществляет и преобразование сообщения в формат каждой системы-приемника (т.е. возможны и маршруты вида 1 -> N). Сообщение поступает на вход адаптера соответствующей системы-приемника, который либо преобразует его из канонического формата в требуемый, либо просто передает на ее вход. Предполагается, что для расширения данной конструкции заказчику достаточно лишь разработать адаптер системы, набор преобразований из ее формата в канонический или формат всех других систем, с которыми она взаимодействует, а так же добавить сведения о новых маршрутах и преобразованиях в базу данных конфигурации.
Так вот, на самом деле этого не достаточно. Даже у самого-самого "универсального" решения описанной задачи есть ограничения.
Во-первых, если весь обмен по такой шине идет в каноническом формате данных, то все адаптеры заняты только трансформацией сообщений из формата подключенной системы в канонический и наоборот. Но у канонического формата данных есть ограничения. При подключении системы, в сообщениях которой содержится новая бизнес-информация, потребуется расширять канонический формат, дорабатывать все связанные с данным сообщением преобразования, дорабатывать адаптеры систем-приемников и зачастую дорабатывать сами системы-приемники. Как мы видим - слишком много всего придется дорабатывать, что как-то не вписывается в заявленную концепцию универсальности. Если же в решении не предполагается использование канонического формата, то все гораздо печальнее - каждое подключение новой внешней системы потребует разработки трансформаций для сообщений данной системы в/из форматы/ов сообщений всех систем, с которыми она будет взаимодействовать.
Во-вторых, возникают вопросы организации грамотного тестирования. Адекватный архитектор не станет подключать информационную систему к интеграции без полномасштабного тестирования. Однако наличие в компании "универсального" решения слишком повышает соблазн выполнить такое подключение. Ну действительно, что там тестировать, мы же адаптер написали, записи в базе данных конфигурации добавили, значит все будет работать. При этом как-то забывается, что если даже сообщения между системами будут передаваться, то это не гарантирует правильности выполнения бизнес-процессов, зависящих от данных сообщений. Тестировать нужно всю интеграцию в комплексе.
В-третьих, не стоит забывать, что если у тебя в руках молоток, то все вокруг начинает казаться гвоздями. Нужно подумать о том, как наличие такой "универсальной интеграционной шины" скажется на архитектуре предприятия. Если подключить информационную систему просто, то велик соблазн выносить на шину все больше и больше межсистемных взаимодействий, которые еще гордо можно назвать "каноническими сервисами". Т.е. вместо разработки в конечной информационной системе сервиса, возвращающего информацию по заявке со всеми комментариями мы разрабатываем два взаимодействия на шине: одно для получения информации по заявке, другое - для получения комментариев. И как-то забывается, что шина находится в Москве, а конечная система управления заявками - во Владивостоке. Но даже не это главное. Концепция универсального транспорта предполагает, что сам по себе этот транспорт выполняет лишь ограниченный набор операций: маршрутизацию и трансформацию отдельных сообщений. Агрегация, обогащение и более сложные манипуляции возлагаются на сами подключенные информационные системы. Таким образом, в нашем примере, объединять данные, возвращенные двумя информационными потоками: информацию о заявке и комментарии к ней, является обязанностью системы-приемника. А если данная информация нужна в нескольких системах - обязанностью каждой такой системы.
Хуже всего же в данной ситуации не тот факт, что концепция универсального транспорта не работает, т.е. не обеспечивает пресловутую универсальность. Хуже всего то, что для реализации концепции предлагается применять весьма дорогостоящее программное обеспечение, при этом на практике используя лишь единицы процентов его возможностей. Данная проблема имеет два аспекта.
Во-первых, заказчики ведь не просто так хотят подобное универсальное решение. Они как правило уже имеют опыт внедрения информационных систем. И они видят, что внедрение занимает довольно много времени. И это действительно так, пока речь идет об использовании таких низкоуровневых средств, как языки программирования Java, SQL, PL/SQL и т.д. При разработке интеграции на Java приходится тратить месяцы на решение довольно стандартных проблем, таких, как трансформация сообщений, особенно если речь идет о работе с коллекциями. Несколько последних статей в блоге Сурового посвящены описанию данных проблем и решений. Ситуацию несколько исправляет наличие ряда фреймворков, реализующих паттерны интеграции. Речь идет об Apache Camel и Spring Integration.
Во-вторых, исполнители - компании-интеграторы и независимые разработчики - как правило не умеют пользоваться имеющимися средствами. Для многих промышленные сервисные шины предприятия - это лишь реализация каких-то интеграционных паттернов, из которых как можно быстрее нужно собрать "универсальное решение". У многих разработчиков на российском рынке так же наличествует предвзятость, граничащая с религиозной: зачем нужны все эти сервера приложений, WebLogic какой-то, WebSphere там, сервисные шины, какая-то Oracle Service Bus, IBM WebSphere Message Broker, когда есть Apache Tomcat и Spring Framework, на которых сейчас на коленке я сделаю вам приложение. При этом приложение возможно даже и будет работать, но с одной стороны непонятно кто будет его поддерживать, а с другой - реализация займет шесть месяцев, вместо одного, как было бы при использовании промышленных инструментов. Впрочем, любителей варить кашу из топора, данные вопросы не интересуют, как-то низко это все, поддержка какая-то, деньги, амикошонство какое, фи.
Впрочем, перечислить имеющиеся проблемы мало. Нужно предложить какое-то адекватное решение. Таким решением является использование промышленных интеграционных продуктов по назначению. Данные продукты задумывались не как кубики для построения "универсального решения", т.е. не как средства разработки адаптеров или многофункционального ядра. Они и есть такое решение. Продукты Oracle, как и продукты IBM, Tibco, Software AG и других уважаемых корпораций имеют в своем составе специализированные IDE существенно упрощающие разработку. По сути разработка интеграционного решения сводится к прорисовке информационных потоков, сервисов и процессов. Это как правило ничуть не сложнее добавления записей в конфигурационные таблицы, но обладает рядом преимуществ.
- Гибкость. Сервисная шина предприятия перестает быть просто транспортом, осуществляющим маршрутизацию и преобразование сообщений. Не нужно вгонять себя в рамки. Современные промышленные решения могут выполнять множество других действий: валидацию, обогащение, агрегацию, разделение сообщений на части с их независимой обработкой и последующим объединением результатов и даже создание настоящих композитных сервисов.
- Наглядность. Вместо хранения информации об интеграции в таблицах базы данных, при правильном использовании промышленных решений данная информация закладывается в сами схемы информационных потоков. Эти схемы легко открыть с помощью IDE и просмотреть в графическом виде. При этом данные схемы могут быть не только вида "отправили что-то в ядро" или "отправили что-то из ядра в систему", но и представлять собой сквозные процессы, на которых явно видны все взаимодействующие участники. Такие схемы предлагают неоценимую помощь администраторам и аналитикам при сопровождении и развитии интеграционного решения.
- Производительность. Информация о маршруте каждого сообщения не обязана содержаться в базе данных, откуда ее необходимо каждый раз извлекать. Сам код интеграционного потока является такой информацией. Накладные расходы существенно снижаются. Если же учесть, что обновление кода одного потока в современных промышленных решениях не требует остановки других, а зачастую и самого обновляемого потока, то повышается не только производительность решения, но и его надежность и доступность.
- Отсутствие единой точки отказа. На схеме, представленной в начале статьи, мы можем видеть две точки отказа: ядро и базу данных с информацией о конфигурации решения. При выходе из строя каждой из них интеграция полностью останавливается. Использование промышленных решений избавляет нас от необходимости создавать некоторое ядро: все операции над сообщениями, трансформации, маршрутизация, обогащение и т.д., выносятся в соответствующие сервисы, выход из строя одного из которых не приводит к потери работоспособности других. База данных с настройками интеграции же зачастую вообще становится не нужна.
- Тестирование и мониторинг. Некоторые промышленные решения, такие как Oracle SOA Suite, содержат средства автоматического модульного и интеграционного тестирования разрабатываемых потоков, сервисов и бизнес-процессов. При этом данные решения снабжены мощными средствами мониторинга во время исполнения, показывающими какое время занимает выполнение того или иного сервиса, каков был процент отказов и по какой причине. При необходимости можно так же настроить отправку оповещения администратору по почте или с помощью SMS. При реализации "универсальных решений" данные возможности как правило не используются.
Выводы из моего рассказа можно сделать следующие. Не нужно бояться нового, его нужно изучать. Заказчику нужно объяснять, что разработка с использованием правильных средств больше не напоминает программирование на Java. Ему не нужно будет ждать месяцами своего интеграционного решения. Он его уже купил. Теперь доработка информационных потоков в ответ на изменение бизнеса будет занимать время, измеряемое днями, а зачастую - часами. С учетом тестирования. Силами существенно меньшей команды программистов.
На моем самом крупном проекте в AT Consulting сервисную шину, обеспечивающую интеграцию порядка 60 информационных систем и передачу более 5 000 000 сообщений в сутки, поддерживала команда из трех разработчиков. Трех разработчиков. Для сравнения доработка основной информационной системы на Java велась силами примерно двадцати человек, а сколько ресурсов тратилось на доработки остальных приложений, участвующих в интеграции, не берусь даже оценить.
Так же могу рассказать об опыте решения одной и той же задачи с использованием разных технологий. В каком-то смысле это - бесценный опыт для архитектора, поскольку такое счастье выдает очень редко: сравнить несколько технологий на примере решения одной задачи. Если не учитывать время на бизнес-анализ и согласование требований, то с использованием Oracle Service Bus задача была решена за месяц, лично помню как большинство трансформаций сообщений (два десятка сообщений, каждое содержит от 5-ти до 40-ка полей) было сделано за один день. На Java решение данной задачи заняло более полугода. Оба решения разрабатывал ваш покорный слуга лично. По-моему разница между подходами очевидна и довольно наглядна. Понятно, что мои слова могут показаться кому-то рекламой и конечно нужно учитывать квалификацию персонала, ведь задача, занявшая у кого-то месяц, может другой командой решаться гораздо дольше. Признаю, что современные промышленные средства интеграции имеют некий порог вхождения, но инвестиции в эту сферу вполне оправданы.
К тому же за легкость и гибкость разработки, даруемые правильным использованием правильных средств, приходится платить. Т.к. команда поддержки шины показывает производительность в разы превосходящую все другие команды, то у менеджмента появляется соблазн вынести на шину все что можно и даже нельзя. Как правило даже пытаются вынести вещи, которые не имеют никакого отношения к интеграции. Но это уже другая, более приятная, история.
Оставайтесь на связи ;)
Понравилось сообщение - подпишитесь на блог
2 комментария:
Спасибо за достаточно злободневную тему. Однако цифра 1 месяц на внедрение 20 сообщений (=10 потоков запрос/ответ) выглядит фантастической.
Там было скорее порядка 20 однонаправленных запросов, но здесь нет никакой фантастики. Причем, что интересно, это не просто нарисованные в визуальном редакторе трансформации, они еще довольно сильно кастомизировались вручную. Просто я довольно опытный OSB-боец.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!