Для этого прежде всего необходимо создать эффективную интегрированную среду для работы с ответственными приложениями.
По мере того как растет стремление предприятий установить связи между различными логистическими цепочками при помощи средств Internet и определить внутри предприятия источники информации для новых служб (например, для службы поддержки или для системы автоматизации продаж через Web), все более актуальной становится необходимость быстрой интеграции приложений.
Различные подходы к так называемой интеграции корпоративных приложений (enterprise application integration — EAI) базируются на объединении и продлении срока службы старых, но все еще весьма полезных приложений и одновременном создании гибкой платформы для разработки новых программ, ориентированных на задачи электронной коммерции.
Долгое время пользователи имели возможность осуществлять обмен данными (создавать запросы и получать на них ответы, регистрировать события и просматривать информацию о состоянии системы) между различными приложениями при помощи ориентированного на обработку сообщений промежуточного ПО, которое использовалось в качестве базового транспортного протокола. Довольно часто процесс поддерживался брокером сообщений, который определял конечный адрес пересылки информации и контролировал последовательность считывания пакетов.
Сегодня вниманию специалистов предлагаются средства расширения функциональных возможностей интегрированных приложений. Не последняя роль здесь принадлежит языку Extensible Markup Language и соответствующим схемам. Построив гибкую, многозвенную, стандартную архитектуру, позволяющую выбирать методы интеграции и новые инструментальные средства, компании могут избежать ситуации, при которой их заказчики попадают в зависимость от какого-то конкретного решения.
Однако стремление разработчиков интеграционных технологий, производителей промежуточного программного обеспечения и создателей серверов приложений порадовать своих пользователей технологиями EAI все чаще наталкивается на скепсис последних. Производители предлагают сложные, недостаточно масштабируемые средства, вместо того чтобы применить системный подход в решении конкретных задач и попытаться объединить разнородные приложения, функционирующие на различных платформах.
«Я с большой осторожностью отношусь к подобным решениям, — заметил директор информационной службы консультационной компании Booz-Allen & Hamilton Роджер Уолтерс. — Идея связывания унаследованных приложений с промежуточным программным обеспечением или со средствами Web может загнать вас в тупик».
По словам Уолтерса, поначалу системы EAI кажутся панацеей от всех бед, однако на деле они бывают не в состоянии выполнить возложенные на них задачи: «В конечном итоге, израсходовав массу денег и времени и полностью утратив гибкость, вы оказываетесь ни с чем. Кроме того, в течение ближайших пяти лет вам все равно придется модернизировать систему».
Разработчики платформ, которые выступают за универсальный способ построения приложений, ориентированный на конкретную архитектуру, разделяют эту точку зрения.
«Индустрия EAI предлагает тактическое решение тактических задач, но совершенно очевидна необходимость более тесной интеграции приложений, — отметил менеджер продуктов Java2 Enterprise Edition корпорации Sun Microsystems Билл Рот. — Эта задача решается за счет использования возможностей языка XML и систем обработки сообщений».
Споры между разработчиками относительно эффективности той или иной технологии продолжаются, но тем не менее специалистам нужно помнить о необходимости интеграции приложений при определении спецификаций перспективных систем и создании новых прикладных программ. Открытая архитектура поможет пользователям избежать появления «кода спагетти» (запутанного лабиринта, связывающего между собой различные приложения и значительно усложняющего общую структуру) и позволит перейти к новым, стандартным системам.
Карты на стол
Существующие сегодня технологии EAI базируются на трех методах — это построение специализированного приложения на основе специализированных модулей, создание промежуточного объектного ПО и брокеров сообщений и проектирование серверных платформ для многозвенных приложений.
Новые серверы приложений разрабатываются для того, чтобы удовлетворить потребности пользователей в прикладных программах для Web. Они представляют собой современное программное обеспечение, часто создаваемое на основе набора спецификаций и API-интерфейсов Java и помогающее объединить уже существующее промежуточное ПО со средствами, которые предлагаются производителями систем EAI.
«Серверы приложений, оснащенные стандартным набором интерфейсов прикладных программ, предоставляют разработчикам возможности языков четвертого поколения, C++ и Java, а также компоненты JavaBeans для связывания приложений в Internet, не вдаваясь при этом в сложности промежуточного программного обеспечения», — подчеркнул аналитик Giga Information Group Майк Гилпин.
К функциям промежуточного ПО и службам сообщений Java, которые ранее составляли основу практически всех систем EAI, все чаще начинают подключаться другие новейшие технологии (например, XML).
Даже Microsoft, делавшая ставку исключительно на однородную корпоративную платформу, которая базировалась на операционной системе Windows и принципиально отличалась от технологий Java, предлагаемых другими разработчиками, в последнее время вынуждена уделять повышенное внимание вопросам интеграции разнородных систем и встраиванию соответствующих функций в Windows 2000 и компонентную объектную модель COM+.
Для успешного построения интегрированных платформ необходимо четко представлять себе, каким образом можно управлять интеграционными процессами при помощи сервера приложений, в каких случаях подобный подход оправдывает себя и какая часть нагрузки должна приходиться на специализированные решения. Справиться с этой задачей непросто, потому что производители, поддерживающие системы EAI, предлагают все новые и новые разработки, и ситуация на рынке постоянно меняется. Во многих случаях наблюдаются наложение и взаимозависимость различных технологий.
Объединяй и расширяй
По мнению производителей специализированных систем EAI (к представителям данного направления относится компания Vitria Technology) и разработчиков универсального промежуточного программного обеспечения (к примеру, компании Candle), быстрый переход на серверы приложений сопряжен с серьезным риском.
Компании Crossworlds, Software Technologies и Active Software предлагают решения EAI, ориентированные на определенную область и использующие специализированные хранилища и брокеры сообщений для преобразования, обработки и пересылки данных между различными приложениями. Кроме того, они служат для связи систем планирования ресурсов предприятия (enterprise resource planning — ERP), предлагаемых компаниями SAP и PeopleSoft, с другими клиент-серверными программными системами, унаследованными приложениями и хранилищами данных.
Однако производители систем EAI считают, что с помощью серверов приложений нельзя построить архитектуру, годную для широкомасштабной интеграции.
«Серверы приложений — это всего лишь дополнительный источник данных, который также нуждается в интеграции, — отметил директор компании Vitria по маркетингу Малколм Льюис. — Серверы приложений — одна из составных частей задачи, но отнюдь не полноценное решение. Необходимо предварительно упорядочить базисные средства и лишь потом переходить к созданию новой надстройки. Кроме того, нужно наладить управление потоком сообщений, пересылаемых по магистралям информационных систем предприятий».
Неупорядоченность базисных систем — далеко не единственная задача, требующая решения. Аналитики и пользователи говорят о необходимости создания архитектуры, с помощью которой можно было бы связывать серверные системы не только в пределах одной компании, но в рамках целой группы предприятий.
«Вместо того чтобы заниматься проектированием средств EAI, которые предназначены главным образом для интеграции жизненно важных бизнес-процессов одной организации, нужно подумать об объединении бизнес-процессов нескольких предприятий, — подчеркнул Гилпин. — При этом в качестве магистрали лучше всего использовать Internet. Традиционные технологии интеграции приложений уже исчерпали себя».
Производители серверов приложений и инструментальных средств разделяют эту точку зрения.
«Средства EAI помогают объединить различные системы одной или нескольких корпораций, — отметил вице-президент компании Progress Software по маркетингу Джордж Кассабджи. — Если для этого используется магистраль, необходимо определить способы пересылки сообщений, выбрать методы реализации технологии публикации и подписки и продумать вопросы поддержки средств XML. Наиболее известные сегодня системы EAI построены на основе оригинальных технологий передачи сообщений и не имеют отношения к Java».
Компания Progress Software, как и многие другие производители серверов приложений, считает, что лучшим средством определения логики интеграционных процессов является стандартный сервер приложений, с помощью которого можно не только связывать различные прикладные программы, но и решать целый ряд других задач.
«Пользователи хотят не просто объединять различные компоненты своих систем, но и расширять их функциональность», — заметил Кассабджи.
Нельзя сказать, что эти процессы взаимно исключают друг друга.Сегодня множество производителей занялись вопросами интеграции, и аналитики предсказывают появление большого числа систем с пересекающимися функциями и даже переход к взаимному обмену лицензиями.
По крайней мере в ближайшее полугодие серверам приложений и продуктам EAI гарантирован спрос на двух независимых рынках, считают аналитики компании Hurwitz Group. Большинству крупных организаций в этот период потребуются и серверы приложений, и решения EAI.
«В следующем году различия между серверами приложений старшего класса и системами EAI будут постепенно исчезать. Производители серверов приложений оснастят свои продукты новыми функциями и обеспечат интегрированную поддержку систем обработки сообщений и специальных интерфейсов для широкого набора унаследованных приложений и программных пакетов, максимально приблизив их к классу решений EAI», — утверждает аналитик Hurwitz Бет Голдбернштейн.
Специалисты уверены, что таким компаниям, как Tibco и Neon, удастся совершить прорыв в области инструментов, реализующих схему «публикации и подписки», а среда разработки, предложенная Forte Software, завоюет популярность у производителей. Аналитики отмечают также, что компания Active Software сумела заметно усовершенствовать свой информационный брокер. Заслуживают внимания и средства управления потоками процессов компании Vitria.
Ситуация на рынке систем интеграции приложений стала меняться в лучшую сторону после того, как во многих компаниях появился широкий набор не связанных между собой программных пакетов. В то же время достаточно велико число тех, кто предпочитает дождаться более простых решений, одновременно застраховав себя от ошибки 2000 года.
«Мы продолжаем тщательное изучение архитектуры CORBA, — отметил специалист Центра цифровых метеорологических и океанографических исследований Военно-морского флота США Джон Уэндел. — В любом случае нам нужны новые решения. Необходимо упростить существующие подходы».
В целом специалисты согласны с тем, что производители средств EAI, промежуточного программного обеспечения, платформ и серверов приложений станут уделять больше внимания корпоративным программным средствам, а роль этих продуктов будет возрастать.
«Мы станем свидетелями объединения технологии серверов приложений с промежуточным корпоративным ПО и программными средствами EAI, — считает аналитик консультационой компании Ovum Гэри Барнетт. — В то же время пользователям следует весьма осторожно относиться к обещаниям производителей, предлагающих простые системы, а разработчики должны понять, что клиентам нужны продукты разного уровня сложности».
По мнению Барнетта, стратегия встраивания продуктов EAI в информационную инфраструктуру вместо введения новых функций выгодна как пользователям, так и разработчикам; производители могут постепенно уйти с изжившего себя клиент-серверного рынка, а информационные службы получат возможность централизованного развертывания, администрирования и диагностики прикладного ПО.
Старое и новое в одной обойме
Концепция архитектурного подхода к построению систем EAI подразумевает использование самых разных приложений независимо от их авторов и заложенных в них основ. При этом интеграция базируется на принципе: «единое целое лучше, чем простая сумма составных частей».
Объединение множества приложений на основе общего интерфейса (в отличие от глубокой интеграции только особо важных программ, отражающих внутренние процессы) способно изменить основные направления деятельности предприятия и расширить сферу его интересов. Лучший совет в данном случае — продвигаться к цели не торопясь, связывая ключевые приложения и постепенно формируя систему, с помощью которой можно будет интегрировать старые и новые приложения.
Впрочем, не все согласны с тем, что движение к электронной коммерции и многоуровневым серверным системам повысит значимость объединяющих технологий и станет важным шагом на пути к интеграции бизнес-процессов.
«Сами по себе системы EAI базируются на концепции, суть которой — заставить работать уже устаревшие средства, решить какие-то частные задачи и справиться с краткосрочными трудностями текущего момента, — подчеркнул аналитик консультационной компании Patricia Seybold Group Джон Манн. — Интеграция бизнес-процессов — это стратегическое направление, в то время как средства EAI предназначены для решения исключительно технических вопросов».
Несовершенство существующих систем — в недостатках средств интеграции приложений, а эти пробелы можно устранить при помощи стандартного промежуточного ПО, серверов приложений; специализированных продуктов интеграции или комбинации перечисленных средств.
«Все зависит от того, с какими приложениями вы работаете, — заметил Обри Черник, председатель совета директоров компании Candle, специализирующейся на разработке промежуточного программного обеспечения. — Можно попытаться развернуть универсальную систему EAI, объединяющую все и вся, установить специализированные средства EAI, позволяющие связать программное обеспечение Service Advertising Protocol с унаследованными программами, или интегрировать какие-то другие компоненты, взаимодействующие с серверами приложений для Web».
В конце концов, каждая организация должна определить для себя требуемую ей архитектурную смесь, обеспечивающую доступ к тем или иным конкретным продуктам.
Технологии сборки
Аналитики сходятся в том, что для построения интегрированных систем необходимо использовать архитектуру широкого спектра применений, хотя средства, предлагаемые ими, значительно отличаются друг от друга. Давайте перечислим технологии, о которых идет речь.
- Ориентированные на данные: широко применяется тиражирование, данные перемещаются между системами в соответствии с разного рода бизнес-событиями
- Ориентированные на промежуточное ПО: используются очереди сообщений и объектные промежуточные программные средства, пересылка данных производится в соответствии с определенным графиком и маршрутами
- Ориентированные на модели: базируются на выбранной архитектуре, интеграция определяется моделью обработки данных и процессов
Передача сообщений при поддержке XML
Патрисия Сиболд: «XML представляет собой стратегический ответ Microsoft» |
Технология обработки сообщений (или очереди сообщений), создававшаяся для автоматизации пакетной обработки транзакций на мэйнфреймах, призвана удовлетворить потребности приложений в интеграции и объединить разнородные системы при помощи средств Internet.
Сегодня же системы обработки сообщений дополнены средствами поддержки технологии Extensible Markup Language и предоставляют разработчикам возможность переносить данные из одной схемы XML в другую, обеспечивая тем самым обмен разнородной информацией между предприятиями через общедоступные сети.
Системы обработки сообщений сложны в установке и обслуживании, и большинство разработчиков приложений не представляют себе, каким образом можно повысить их эффективность. В результате крупнейшие производители пытаются автоматизировать отдельные процедуры и упростить систему обработки сообщений при помощи средств языка XML, так чтобы она превратилась в практически невидимый слой, находящийся внутри среды разработки.
«XML представляет собой стратегический ответ Microsoft на повышение требований к переносимости и интероперабельности», — подчеркнула Патрисия Сиболд, глава консалтинговой компании Patricia Seybold Group.
Недавно Microsoft представила технологию BizTalk Framework, позволяющую создавать различные схемы (или наборы общепринятых атрибутов) на языке XML и использовать теги XML для маршрутизации сообщений. Такой подход поможет уменьшить сложность ПО и оригинальных брокеров сообщений и упростит процедуру построения систем обработки сообщений.
Представители Microsoft предлагают разработчикам и поставщикам схем XML шире применять таблицы стилей XSL для связи схем между собой и для организации широкомасштабного обмена данными между приложениями.
Хочется отметить, что в этом Microsoft не одинока. Sun Microsystems и IBM также работают над интеграцией технологии обработки сообщений и средств языка XML.
Sun Microsystems совместно с третьими фирмами встраивает средства поддержки обработки сообщений в пакет Java2 Enterprise Edition (J2EE), который должен появиться в конце текущего года. Что касается IBM, она расширяет возможности ПО MQSeries за счет связывания собственных систем (в том числе и клиентских).