Журнал ВРМ World

Мировая история развития технологий управления эффективностью бизнеса – обзоры зарубежных публикаций

Связующее программное обеспечение: часть решения или часть проблемы?

Автор рассказывает о проблемах так называемого связующего программного
обеспечения (middleware) и показывает, что они могут быть эффективно решены с
помощью сервис-ориентированной архитектуры.

Предлагаемая статья, как и предыдущая, посвящена сервис-ориентированной архитектуре (СОА). Ее автор, старший аналитик исследовательской компании ZapThink, рассуждает о проблемах так называемого связующего программного обеспечения (middleware) и том, как их можно решить с помощью СОА. Кроме того, в статье проводится сравнение СОА и других подходов к интеграции, например, реализованных в средствах интеграции корпоративных приложений, (см. материалы Интеграция корпоративных приложений: основные понятия и Текущее состояние и перспективы развития рынка интеграционных технологий в прошлых номерах Журнала).

У известного американского комика, Хенни Янмэна (Henny Youngman), была такая шутка: "Пациент жалуется: 'Доктор, мне больно, когда я так делаю'. 'Ну так не делайте этого,' - отвечает доктор". Похожим образом современные IT-системы представляют собой сложный комплекс движущихся частей, которые вызывают повторяющуюся, хроническую операционную боль, настолько трудноизлечимую, что многие IT-организации просто "заклеивают" проблемы пластырем, оставляя без внимания первопричины этих явлений. Под этими проблемами автор имеет в виду периодические издержки и риск, связанные с негибкими, жестко связанными (tightly-coupled) подходами к интеграции.

Так называемое связующее программное обеспечение (middleware) оказывается в центре дискуссии о проблемах интеграции. Во многих случаях это обеспечение помогало компаниям решать сложные IT-проблемы. Но в других ситуациях оно только усугубляло ситуацию, "регулируя" проблему таким образом, что отбивало у компании всякую охоту использовать эти средства в будущем. Как же нужно понимать роль связующего программного обеспечения в контексте сервис-ориентированной архитектуры? Является ли оно частью решения или частью проблемы?

К сожалению, термин "связующее программное обеспечение" весьма многозначен. В наиболее общем смысле связующее программное обеспечение - это программные средства, которые объединяют функциональность или данные двух отдельных независимых систем. В большинстве случаев это обеспечение не является реальным приложением, с которым может работать пользователь, или системами записей, хранящими данные и информацию. Скорее, связующее обеспечение - это своего рода "клей", удерживающий вместе отдельные системы, отвечающие за пользовательский интерфейс, логику работы приложений и хранение данных, которые необходимы распределенным приложениям для того, чтобы соответствовать требованиям бизнеса. Клей действительно полезен, когда нужно связать две системы для работы. Но если применить его больше, чем надо, или же в неподходящем месте, то очень быстро можно "влипнуть" самому.

Плюсы связующего программного обеспечения

Компаниям особенно необходимо связующее программное обеспечение тогда, когда их системы имеют специфические интерфейсы и поэтому требуется тесное взаимодействие даже для получения наиболее общей информации. Быстрое развитие IT-возможностей в течение двух последних десятилетий привело к распространению "изолированных островков" бизнес-функциональности, что вынуждало компании извлекать информацию из "тисков" своих специфических интерфейсов прикладного программирования для того, чтобы она стала полезной для них самих. Поэтому организации испытывали большие трудности, пытаясь получить от этих систем искомый результат, не говоря уже об установлении связей с другими системами для удовлетворения новым требованиям.

Связующее программное обеспечение, в т.ч. и средства интеграции корпоративных приложений (EAI), сыграло свою роль в обеспечении срочных нужд компаний, таких как электронный бизнес, проблема 2000 года и разработка корпоративных приложений. Поставщики подобных продуктов обычно предоставляют возможности доступа к данным или приложениям в форме индивидуализированных или сделанных под конкретную систему платформ обмена сообщениями и набора встроенных адаптеров, которые обеспечивают двустороннюю связь со многими типами приложений и источников данных, таких как корпоративные программные приложения, базы данных, файловые системы, директории, а также мейнфреймы и другие унаследованные приложения. Вдобавок к основным функциональным интеграционным возможностям многие поставщики предоставляют средства для выполнения преобразования данных, моделирования и управления бизнес-процессами, преобразования и выбора маршрута сообщений, а также разнообразные инструменты бизнес-логики и бизнес-правил. Но, как будет показано ниже, все эти разнообразные функциональные возможности не помогают компаниям решать свои хронические IT-проблемы.

Связующее обеспечение для связующего обеспечения

Одна из самых сложных проблем жестко связанной интеграции заключается в том, что число необходимых путей интеграции или соединений растет в геометрической прогрессии в зависимости от числа систем, которые необходимо интегрировать. И хотя некоторые подходы к интеграции, основанные на технологии EAI или корпоративной шины, могут помочь в ограничении этого роста, они оказываются бесполезными в решении проблемы жестких связей между системами. А это означает, что внесение необходимых изменений по-прежнему остается дорогостоящим и сложным делом. Более того, проблема интеграции усугубляется тем фактом, что большинство компаний осуществляют интеграцию непоследовательно, имея в виду прежде всего краткосрочные интеграционные нужды, а не эффективные долгосрочные решения. Итоговым результатом этого процесса оказывается запутанная сеть жестких и хрупких интеграционных связей, поддержание и обслуживание которых становится все дороже.

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

Но расходование денег на то, чтобы обеспечить хорошее взаимодействие разных слоев связующего программного обеспечения, имеет мало смысла. Зачем компаниям громоздить друг на друга слои этого обеспечения, если каждый из них предназначен для решения какой-то небольшой специфической интеграционной проблемы? Одно дело - использовать связующее обеспечение для решения острых локальных интеграционных вопросов, и другое - для решения хронических проблем, связанных с оперативностью и гибкостью бизнеса. Компаниям не требуется больше связующего обеспечения или обеспечение лучшего качества для того, чтобы повысить оперативность своих систем. Вместо этого им нужно сделать шаг назад и подумать о том, как создать, использовать и поддерживать распределенные вычислительные инфраструктуры, которые по своему существу уже являются гибкими и оперативными. То, что действительно необходимо современным компаниям, - это архитектура, и, в частности, сервис-ориентированная архитектура (Service-Oriented Architecture - SOA).

Уход от ментальности, сфокусированной на интеграции

Частично сложность перехода к SOA заключается в том, что это требует от организаций изменить свой подход к IT-ресурсам и к разработке и интеграции функциональности бизнеса. Гораздо проще внедрить, инсталлировать и развернуть изолированную систему, а уже потом решать, как соединить ее с другими системами корпорации, чем заранее разработать соответствующий архитектурный подход, который предполагает гетерогенность и возможность многократного использования. Но, тем не менее, переход к SOA требует именно таких глубоких изменений мышления. Непросто будет создать слабо связанные сервисы, если интеграция остается центральным элементом подхода. Хотя связующее программное обеспечение по-прежнему остается нужным большинству компаний, особенно в тех случаях, когда требуется установить связь между специфическими интерфейсами прикладного программирования и интерфейсами сервисов, нет никакой необходимости в том, чтобы "нанизывать" это обеспечение одно на другое.

Вместо интеграции SOA ставит в центр IT-подходов сервисы. При таком взгляде на IT сервисы создают основу инфраструктуры. После этого компания может включать сервисы в процессы и таким образом управлять бизнес-логикой в описательной манере, тогда как в сфере ответственности IT-отдела остаются не функциональные атрибуты технологий, лежащих в основе сервисов (т.е. обеспечение их доступности и масштабируемости, а также выполнение других соглашений и установок, связанных с ними). Сам факт интеграции при таком подходе перемещается на процессный уровень, где бизнес-аналитики и архитекторы бизнес-процессов могут соединять сервисы друг с другом во время разработки процессов. Таким образом, в фокусе технической инфраструктуры, обеспечивающей это взаимодействие, уже находится не интеграция как таковая (т.е. соединение систем или приложений), а создание и поддержка тех сервисов, которые необходимы бизнесу.

Заключение

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

Автор: Рональд Шмелцер (Ronald Schmelzer)