В 2006 году объем продаж прикладного и интеграционного ПО, а также ПО для обмена сообщениями составил, по данным Gartner, около 5,8 млрд. долл.; рынок услуг по поддержке этих систем оценивался в 132 миллиарда. В 2007м потребность в быстром предоставлении агрегированной информации станет еще выше. Ее источником может быть и развитие сервисно­ориентированной архитектуры (SOA), и новая система для бизнеса (скажем, управление бизнес­процессами — BPM), и Ajax — чудодейственное омолаживающее средство для программ собственной разработки с безнадежно устаревшими интерфейсами. Но рано или поздно вам все­таки придется заняться запросами своей программной инфраструктуры. И чем раньше, тем лучше.

Технологии, помогающие сделать инфраструктуру легкой, быстрой и действительно работающие «прямо из коробки», активно развиваются. Новое поколение средств интеграции корпоративных приложений (enterprise application integration, EAI) и стеки протоколов с открытыми исходными кодами, такие как LAMP, заранее сконфигурированы и интегрированы так, что развертывать их — одно удовольствие.

Все славят EAI 2.0

Сочетание ставших общеупотребительными интеграционных инструментов, таких как JDBC (Java Database Connectivity), JMS (Java Messaging Service), IBM WebSphere MQ и простое копирование файлов по протоколу FTP, с SOAP (Simple Object Access Protocol) и другими более современными методами породило мощную платформу интеграции/предоставления услуг. Ее называют по­разному: EAI 2.0, ESB lite, «EAI­из­коробки» (EAI­in­a­box), «взаимодействие протоколов» (protocol mediation), — но независимо от терминологии функциональность и простота установки соответствующих продуктов возвещают зарю новой эры в интеграционных технологиях.

Любопытно, что лидеры рынка EAI — BEA Systems, Oracle, TIBCO Software и webMethods — в эту игру не играют. Здесь в первых рядах идут такие компании, как Cast Iron Systems, IBM DataPower, Layer 7 Technologies, Reactivity и SOA Software, которые берут лучшее из миров традиционного ПО и EAI 2.0 и соединяют то и другое в целом спектре специализированных серверов — легко устанавливаемых, управляемых и конфигурируемых. Опыт разработки XML­серверов «под ключ» помогает их производителям эффективно работать и в качестве поставщиков «чистого» ПО.

Эти реализации обладают огромной ценностью для бизнеса, так как сочетают легкость развертывания с простотой последующей оркестровки и в результате интеграция требует не больше усилий, чем построение диаграммы в Visio. Беспокоитесь, удастся ли построить решение для монолитной унаследованной программы? Не волнуйтесь: тех, кого EAI 2.0 бросает на произвол судьбы, очень немного. Интегрировать ПО от PeopleSoft, SAP, Siebel скоро будет не сложнее, чем двигать значки на рабочем столе. И эти продукты взрослеют, обзаводятся новыми адаптерами и плагинами для поддержки конкретных корпоративных систем и источников данных.

Перспективные технологии

EAI 2.0

Технология EAI, как и SOA, достигла зрелости и способна обеспечить высокий коэффициент ROI. Присмотритесь к имеющемуся у вас интеграционному ПО и подумайте, вместо чего можно использовать EAI 2.0. Как только EAI 2.0 займет свое место в ЦОД, вам станет непонятно, как можно было обходиться без нее.

ESB

Рынок развивается, и на подходе ESB­фабрики. Но лучше уже сейчас подумать, как быть с масштабируемостью.

Стеки с открытыми исходными кодами

Легкие и проворные стеки без труда обойдут корпоративные платформы таких конкурентов, как BEA, IBM или Oracle. Запустите пилотный проект, и вы будете приятно удивлены.

Безопасность SOA/XML

В вашей сети вскоре объявятся Ajax и механизмы передачи контента. Придется либо принять все мыслимые меры, чтобы их обезопасить, либо смириться с незащищенностью.

Но подождите секундочку…

Чтобы не выглядеть чрезмерными оптимистами (а для нас это совсем не характерно), скажем и об отрицательных сторонах технологии EAI 2.0. Ей пока недостает возможностей интеграции для ПО собственной и заказной разработки (иначе, как через Web­сервисы) и более традиционных механизмов работы с файлами и базами данных. Программ, обеспечивающих, к примеру, SOA для мэйн­фреймов, очень мало. В качестве механизмов для встраивания старых программ в современные вычислительные среды популярны продукты SOA Software, Software AG и TIBCO, но они дороги и сложны в установке.

Интегрировать клиент­серверные приложения, разработанные своими силами или на заказ, тоже непросто. Чтобы подсоединить такую программу к интеграционному центру, необходимо написать дополнительный код (для центра или для нее самой). Если приложение работает с базой данных, это, как всегда, облегчает задачу, но так мы получаем интеграцию на уровне данных, а не функциональности, и для встраивания приложения в общую экосистему здесь опять же понадобится заново закодировать существенный объем алгоритмов.

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

Стеки с открытыми исходными кодами

Термин «стек LAMP» первоначально обозначал программную инфраструктуру на основе четырех компонентов с открытыми исходными кодами — Linux (операционная система), Apache (Web­сервер), MySQL (СУБД) и PHP (язык сценариев). В 2005 году число подобных стеков и поддерживающих их поставщиков существенно выросло. Буква «P» в аббревиатуре LAMP наряду с PHP стала относиться к двум другим языкам — Python и Perl, к которым добавился еще и последний крик моды: Ruby on Rails (RoR). В 2006м компания MuleSource предложила в качестве альтернативы ESB свой стек — SMuT (Spring Framework, Mule и Apache Tomcat). СМИ, следящие за развитием открытых стеков, поговаривают о стеке Sun Microsystems, включающем Solaris, PostGRES, Apache и Rails, — наверное, он будет называться SPAR.

Обнаружилось, что заранее сконфигурированные интегрированные стеки программной инфраструктуры исключительно ценны для предприятия. Время, необходимое для развертывания LAMP до работающего состояния, ничтожно по сравнению с тем, что уходит на установку коммерческих корпоративных платформ, выпускаемых BEA Systems, IBM и Oracle. У конкурентов интеграция Web­сервера и баз данных в полнофункциональную программную инфраструктуру обычно требует многочасового дополнительного конфигурирования, а со стеком она происходит безболезненно, поскольку вся работа уже сделана.

Но стеки — это не просто улучшенная интеграция между компонентами инфраструктуры. Их среды программирования на основе J2EE — не то же, что Java­среды, и подсистемы взаимодействия с пользователями здесь часто пишутся не на JSP или Java, а на языках сценариев (Perl, PHP, Python, Rails). Такая возможность — большой плюс для предприятия, поскольку при этом упрощается создание приложений, в которых интерфейс и бизнес­логика отделены друг от друга. В Java нет хороших механизмов для такого разделения — между тем оно необходимо, чтобы выйти в мир SOA и начать работу с действительно гибкими приложениями, модифицируемыми без продолжительного цикла разработки.

Итак, открытые стеки снижают первоначальные и текущие затраты на интеграцию и обслуживание и одновременно позволяют поставщикам создавать недорогое, легко устанавливаемое пакетированное ПО. Базирующиеся на них приложения развертываются в считанные часы, чего не скажешь о программах, требующих для работы BEA WebLogic или IBM WebSphere. Далее, эти стеки больше конкурируют с Microsoft, чем друг с другом, поскольку именно инфраструктура Microsoft всегда отличалась простотой интеграции между продуктами в стеке и легкостью установки приложений.

Мы вас не убедили? Тогда обратите внимание на то, что даже BEA на свой лад движется к «стековой» идеологии. В 2005 году VMware, BEA и Red Hat выпустили совместный продукт — «виртуализированную» программу для быстрого развертывания полного стека BEA на платформе Red Hat Linux. Это заранее сформированный интегрированный стек в виртуализированном программном окружении. Трудно более точно попасть в русло тенденции.

Тенденции

  • Уязвимость SOA/XML будет увеличиваться с ростом популярности Ajax.
  • Благодаря EAI 2.0 интеграция в конце концов станет безболезненной.
  • Увеличится число компаний­лидеров, взявших на во­оружение стеки программной инфраструктуры наподобие LAMP.

Накачай корпоративную сервисную шину

Самым популярным словом из области ESB становится «фабрика». То есть вы создаете не просто корпоративную сервисную шину, а основу для фабрики по переработке данных, куда они стягиваются из нескольких источников, а затем выходят с другого конца как информация, готовая к тому, чтобы её потребляли бизнес­аналитики (пока мы не научились распутывать этот клубок сразу).

Концепцию фабрики продвигают и BEA, и webMethods (недавно куплена Software AG), хотя в случае BEA это, по­видимому, главным образом обоснование для разделения ESB и уровня предоставления сервисов. Конкуренты BEA — CapeClear Software, Fiorona Software, IONA Technologies, Oracle, Software AG и TIBCO — в противоположность ей все как один включают сервисы в свои предложения по ESB. Их адаптеры, правда, по большей части не бесплатны, но хотя бы могут использоваться на одной платформе и не требуют еще одного продукта для доступа к корпоративным приложениям и источникам данных. Зато в продукте BEA — AquaLogic Data Services Platform (ALDSP) — присутствуют и понятие виртуализации источников данных, и EII­подобная функциональность, в то время как у конкурентов ничего подобного нет.

Рынок ESB еще молод и переживает период развития, поэтому в 2007 году вероятен рывок в сторону включения EII­подобной функциональности в ESB­продукты других производителей. Движение возглавят поставщики платформ, такие как IBM и Sybase, ранее сделавшие приобретения в этой области.

Главным вопросом для ИТ­подразделений, внедряющих ESB, по­прежнему остается масштабируемость. Число сообщений и транзакций, проходящих через ESB, будет расти, компании — переходить в своих инициативах по ESB и SOA от стратегий уровня департаментов к общей стратегии предприятия в целом, так что большой вопросительный знак при слове «масштабируемость» никуда не денется. IBM уже начала потихоньку заниматься этой темой и разработала ряд примеров архитектур внедрения, отражающих лучший опыт. В них задействованы понятие ESB­федерации и стратегия шлюзов, т. е. распределение нагрузки между несколькими экземплярами ESB для повышения производительности, которая в настоящее время относительно невысока.

Безопасность XML

Из соображений точности мы часто используем термин «безопасность SOA» вместо более общего «безопасность XML». Но в 2007 году в дополнение к SOA­трафику возрастет и трафик XML. Если его не сгенерируют ваши собственные механизмы SOA, то создадут пакетированные приложения независимых разработчиков, в которых взаимодействие между браузером и сервером осуществляется по протоколу Ajax или SOAP.

Проблема заключается в том, что технологии Ajax и Web 2.0, такие как средства объединения контента (mashups), не имеют механизмов обеспечения интернет­безопасности. Между тем в 2007м они станут фактом нашей жизни, следовательно, необходимо аккуратно изучить возможности защиты, доступные для этих технологий.

К счастью, большинство поставщиков SOA идут к тому, чтобы работать с уже имеющимися сегодня относительно несвязанными вариантами Ajax и передачи контента. Во всяком случае они создали ПО, следящее, чтобы XML­сообщения, передаваемые от браузера к серверу, не содержали в себе никаких вирусов или вредоносного кода. Например, компания Layer 7 Technologies в октябре 2006 года объявила о выпуске продукта XML Data Screen, который специально предназначен для контроля XML­трафика, не являющегося трафиком SOAP, — речь идет о таких протоколах, как REST (Representational State Transfer), POX (Plain Old XML) и Ajax.

Скоро будет видно, насколько хорошо эти продукты справляются с увеличенным трафиком и большим числом поступающих запросов, характерных для приложений на базе Ajax. XML­устройства всегда отличались более низкой, чем у другой сетевой аппаратуры, пропускной способностью (по той причине, что процедура анализа XML­кода требует интенсивных вычислений), однако этот недостаток был не очень заметен, поскольку предприятиям не приходилось обрабатывать значительные объемы информации в формате XML. С приходом Ajax и мощных SOA­решений картина изменится: проблема производительности XML­продуктов вновь выйдет на перед­ний план, и ее надо будет учитывать как один из важнейших факторов при принятии решений.

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