Когда и до нас докатились отголоски новой технологической волны под названием «Web-сервисы», обнаружилось, что специалистов, вещающих на связанные с ней темы сверх меры, а понимающих предмет — единицы. Во всем мире среди многоголосья создателей информационного шума можно было найти всего нескольких человек, способных оценить и внятно передать суть и масштаб происходящего. С подачи Microsoft все больше говорили о глобализации приложений, о всемирных репозитариях, о том, кто будет владеть единым пространством. Однако забыли о корпоративной среде, где реально востребованы эти самые Web-сервисы. В большинстве своем отдельные специалисты или даже целые компании, говорившие и писавшие о Web-сервисах, преждевременно стремились успеть высказаться на становящуюся модной тему. Попытки докопаться до того, что они понимают на самом деле, успеха не имели.
Наибольшее внимание к себе привлек Адам Босуорт, его статьи выделялись прежде всего концептуальностью и фундаментальностью взглядов. И заочно было понятно, за ними стоит яркая и необычная личность, в последующем очном знакомстве это мнение только укрепилось. В рассуждениях Адама, прежде всего, отсутствовало то, что классики называли профессиональным кретинизмом. Позже я нашел разгадку источника широты его взглядов. Оказывается, Босуорт, как это не покажется странным, по первому образованию историк, окончил Гарвардский университет со специализацией в области экономической истории Америки и Европы. Удивляла и самостоятельность взглядов, Адам открыто демонстрировал свою приверженность не только XML (это ему было положено по штату), но и Java — в то время, когда занимал должность главного XML-архитектора в Microsoft. Еще более его личность и инженерная деятельность стали мне интересны, когда в 2001 году Босуорт вместе с Тодом Нильсеном, тоже занимавшим не последнюю позицию в руководящей иерархии Microsoft, оставили свои высокие посты и образовали собственную компанию CrossGain — их идеям в Microsoft было тесно. Но и самостоятельными они оставались недолго. Первым и единственным продуктом, который новая компания успела выпустить за полугодовой срок автономной жизни, был инструментарий разработки Web-служб Cajun, потому что вскоре она была куплена более крупной компанией BEA. А далее произошла удивительная трансформация. Как привитый черенок своими генами превращает дерево-дичок в культурную плодоносящую яблоню, так и небольшой коллектив, пришедший вместе Босуортом и Нильсеном, создал новый облик BEA, точнее, довел до стадии готовности задуманное годами раньше.
Стоит напомнить, что с самых первых дней существования компании, буквально от ее рождения, отцы-основатели BEA (BEA=B+E+A) — Билл Коллеман (B), Эд Скотт (E) и Алфред Чанг (A) — ставили своей задачей создание универсальной платформы для корпоративных приложений. Они считали, что если Microsoft удалось построить универсальную платформу для офисных приложений, то они могут сделать нечто аналогичное и для корпоративных приложений. Идя по избранному пути, BEA скупила десятки компаний и продуктов, начиная от известного программного обеспечения промежуточного слоя Tuxedo до сервера приложений WebLogic, из которых можно строить такую платформу. Но картине не хватало именно той цельности, которую она обрела с покупкой CrossGain. Показательно, что уже на ежегодной конференции BEA eWorld в 2002 году, т. е. буквально через несколько месяцев после перехода в BEA, Босуорт и Нильсен заняли доминирующее место в компании. А в 2003 году стало ясно, что «Адам и его команда» стали интеллектуальным ядром BEA. Не случайно, главным сувениром, который получали все участники BEA eWorld 2003, была шуточная статуэтка Босуорта, что-то вроде китайского болванчика с качающейся головкой.
В движении по направлению к единой платформе лидером и техническим идеологом является именно Босуорт, поэтому интересныего взгляды, мнения и прогнозы. Впервые я побеседовал с Адамом в Сан-Диего на BEA eWorld 2002, а затем на BEA eWorld 2003 в Орландо.
Адам, можете ли вы представить схему эволюционного процесса развития корпоративных систем?
Вы наверняка помните, что корпоративные системы начались с плоских баз данных и c множества не связанных между собой приложений. Но вскоре стало ясно, что «изоляционизм» приложений невозможен, отдельные разрозненные приложения должны как-то между собой взаимодействовать, обмениваться данными. Эта потребность лет тридцать тому назад была удовлетворена средствами систем обмена сообщениями (messaging backbone). Но эта, если так можно сказать, шина, созданная десятки лет назад, оказалась слишком «толстой», к тому же для согласования несвязанных между собой двоичных кодов требовались тяжеловесные адаптеры. Первая революция в области корпоративных систем, нацеленная на преодоление сложностей такого рода, совпала с появлением реляционных СУБД, которые обладают качеством, которое можно назвать «самоописанием». Их преимущества заключаются в том, что, во-первых, используя словари и языки запросов, разные приложения смогли обращаться к общим информационным массивам. Во-вторых, средствами и возможностями реляционных баз смогли пользоваться люди, ничего не понимающие в их устройстве, появились клиенты. Работать стало легче и удобнее, хотя при этом приложения по-прежнему образовывали сложную путаницу, и именно эта сложность не была преодолена, поскольку до поры с ней можно было мириться. Она стала критической спустя годы.
Масштабировать «спагетти» невозможно. Первым решением, распутывавшим клубок на входе (front-end) стали Web-серверы. Затем потребовалось масштабировать нагрузку внутри системы (back-end), эту задачу решают серверы приложений. В результате сложилось некоторое промежуточное «квазистабильное» состояние передовых технологий, включающее эти два компонента, которое можно было наблюдать пару лет назад.
Но вместе с XML стартовал очередной переходный процесс, вторая революция корпоративной архитектуры, которая пока еще пребывает в самой зародышевой стадии. Для понимания происходящего нужно учитывать то, что динамика процессов изменения корпоративных систем имеет определенную специфику. Со стороны кажется, что все происходит быстро — как говорят, «быстро растут чужие дети». Но не стоит забывать, что и у реляционных СУБД ушло шесть-восемь лет на путь от изобретения до массового использования. Утверждаю это вполне ответственно, как непосредственный участник процесса. Второе наблюдение — общность динамики, с которой воспринимаются любые новые технологии. Маховик раскручивается медленно, но потом, когда он наберет обороты, процесс не остановить. Эту динамику можно проиллюстрировать на более наглядном примере, если сравнить развитие информационных технологий с потреблением электрической энергии. Кто мог представить современную потребность общества в энергии сто лет назад, в начале прошлого века? Потребность возрастает по мере формирования спроса, достигая в результате тех гигантских масштабов, которые мы видим сегодня. Здесь есть своего рода положительная обратная связь: чем доступнее ресурс, тем больше на него спрос.
Новая волна архитектур, ориентированных на службы (Service Oriented Architecture, SOA), возникла двадцать лет спустя после появления СУБД. Сейчас она пребывает примерно в том состоянии, как электрификация в 1910 году. Все только начинается, даже для меня, человека, стоявшего у истоков, новый процесс начался в 1997 году, когда я вместе со своей командой опубликовал первый сервер приложений, построенный на XML и Java.
В чем заключается качественное отличие нового этапа эволюции корпоративных систем от предыдущего?
Прежде всего — отношением к данным, точнее, изменением доминирующей модели данных. В этой области предшествующие двадцать лет были периодом очевидного господства систем управления базами данных. Следующие двадцать лет станут годами управления самоописываемыми (self-describing), расширяемыми сообщениями. Повсеместно будет наблюдаться переход от складирования данных к их распределению.
Чтобы лучше понять динамику изменений, происходящих в масштабе отрасли, необходимо определить поднятие, которое я называю «разрушительной новацией» (disruptive innovation), т. е. инновацией, которая разрушает прежнюю и вызывает очередную волну технической революции. Принципиально важно, что с каждой волной количество пользователей ИТ увеличивается, причем их привлекают не собственно технологии, а возможности, предоставляемые очередной новацией. Не следует путать новую технологию с новацией, которую она поддерживает. В качестве примеров новых технологий можно привести изобретение микросхемы или Ethernet; соответствующими им новациями стали персональный компьютер и локальная сеть. Новация — это новое потребительское качество, основанное на технологиях. Локальные сети приобрели популярность не благодаря техническим возможностям Ethernet, а потому, что появился более удобный и эффективный доступ к данным. В 60-е годы транзисторные технологии вызвали к жизни мэйнфреймы, а вместе с ними и языки Кобол и Фортран, унаследованные из 50-х. В 70-е годы интегрированные схемы и сетевые технологии породили волну миниЭВМ и языков программирования нового поколения. В 80-е годы микропроцессоры дали толчок ПК, DOS и языку Си. В 90-е годы мы стали свидетелями двух революций, вызванных TCP/IP. Сначала развитие локальных сетей, SQL и ODBC стало толчком к развитию клиент-серверных архитектур, а позже стандарты HTML и HTTP сформировали импульс к тому, что мы сейчас называем Internet-технологиями.
В чем специфические особенности новаций последней волны?
Пока мы видели всего две безусловно успешные составляющие: электронная почта для общения между личностями и HTTP/HTML для общения личностей с приложением. Они способствовали радикальному изменению представлений о компьютерах. Сейчас на очереди следующая составляющая новой волны, обеспечивающая взаимодействие между приложениями, реализуемое Web-службами на основе SOAP, XML, WSDL и других стандартов. Хотя термин Web-службы уже укрепился, он, на самом деле, не вполне адекватен. Специалисты из Morgan Stanley вполне справедливо утверждают, что не стоит слишком прочно связывать ориентированную на службы архитектуру SOA со словом Web; лучше и точнее говорить просто о службах. Они, по сути, никак Internet не связаны, использованы лишь сетевые принципы. Точнее, речь идет просто о следующем поколении многозвенной архитектуры. В такой архитектуре приложения могут вызывать друг друга, причем отдельные приложения могут разрабатываться несвязанными между собой разработчиками. Можно выделить три основных качества новых приложений. Во-первых, они слабо связаны (loosely coupled); прежде всего, это означает, что изменения в одном приложении не должны влиять на другие. В этом обнаруживается принципиальное отличие от клиент-серверных архитектур. Во-вторых, они работают асинхронно, это качество принципиально, особенно с переходом в мир беспроводных коммуникаций, где необходимо обеспечивать надежное взаимодействие по крайне ненадежным каналам. Третья особенность относится не к самим приложениям, а скорее к коммуникациям: они должны быть блочными, как сейчас говорят, «крупнозерновыми» (coarse-grain). Для того чтобы процесс обмена был эффективен, он должен осуществляться достаточно крупными информационными блоками, если блоки будут слишком мелкими, то произойдет закупорка магистралей.
Итак, одна из важнейших особенностей новой волны заключается в переходе от модели, основанной на выборке данных, к распределительной модели. Распределительная модель в большей степени соответствует природе приложений и принципам ведения бизнеса. Мы хотим, чтобы системы работали 24 часа, 7 дней в неделю, но при этом прекрасно понимаем, что любое приложение неработоспособно — в какие-то временные окна по тем или иным причинам. Если в этот момент направить запрос на немедленное получение данных, то он останется необработанным, а если же запрос предполагает только «заявку» на получение, то она со временем будет обработана, и требуемые данные будут получены.
Если приложение имеет на входе очередь заявок на обслуживание, то оно в состоянии выбрать из них наиболее приоритетные и обработать в первую очередь те, которые имеют большее значение. Таким образом, например, можно избежать катастроф, связанных с перегрузкой Web, которые получили название firestorm или web-storm. Кроме того, очевидно, что, если приложение имеет дело с реальным физическим процессом, а не просто выборкой данных из СУБД, то этот процесс выполняется в течение определенного промежутка времени; реакция на адресованный запрос обычно возможна по окончании этого промежутка. Эти особенности хорошо понимают те компании, которые занимаются интеграцией приложений, они отражены в специальных адаптерах. При переходе к Web-службам эти специфические особенности являются заложенными в модель программирования.
Особую актуальность свойство асинхронности приобретает в связи с расширением сферы использования мобильных устройств. WAP рабски скопировал обычный способ взаимодействия. Но есть прекрасный пример: система обмена короткими сообщениями SMS, построенная на адекватной беспроводной связи push-модели. Этот способ связи больше развит в Европе и Азии, чем в Америке, но на очереди еще мультимедийные сообщения MMS. Особенно важна push-модель в тех случаях, когда пользователь хочет заказать какие-нибудь виды информационного обслуживания и перейти в режим получения — примерно так, как слушают радио.
К каким технологическим сдвигам приведет преимущественное использование push-модели?
Пока я могу делать только предположения, но, скорее всего, XML останется важнейшим средством. Сообщения должны уметь описывать самих себя, XML как нельзя лучше для этого приспособлен, могут возникнуть версии, но они останутся изоморфными языку XML, практически нет иного выбора. Возникнут новые технологии для работы с очередями. «Умные очереди» (smart queue) потребуются, чтобы обеспечить нужное качество обслуживания путем фильтрации потока сообщений и выборки из них первоочередных. Одна из самых сложных и нерешенных пока задач заключается в организации обмена сообщениями. Пока даже не ясно, на каких принципах должен быть построен корпоративный брокер сообщений. Поток сообщений может измеряться тысячами в секунду, как при этом успеть разобрать и переадресовать их? Обычные СУБД для этой задачи не годятся, думаю, необходимость решения этой задачи повлияет на направление в развитии баз данных.
Но все это простые задачи. Система обмена сообщениями представлена «не имеющей состояний» (stateless) технологией. Это серьезное допущение, система имеет состояния, и требуется управление ими. Отсюда возникает совершенно новая задача, точнее, новая парадигма программирования, нацеленная на управление потоками работ. Уже сейчас понятно, что традиционная система обмена транзакциями, в том числе, и модель ACID здесь неприменимы; нужны формальные модели и описания для того, как выполняются процессы с использованием потоков работ и служб.
Еще более сложная проблема — управление потоками работ. Даже если представить, что удастся нагрузить брокер сообщений всеми необходимыми функциями для управления, то как описать, как выразить необходимую информацию для представления? Потребуются качественно новые языки для управления потоками работ. Эти языки не будут ни процедурными, ни декларативными в чистом виде. Они совместят в себе возможности обоих типов языков. Можно перефразировать Алана Кая, который говорил: «Простые вещи должны оставаться простыми, а сложные нужно делать доступными». На основании многолетнего опыта могут утверждать, что для простых задач подходят декларативные и визуальные языки, а для сложных процедурные. При создании новых языков придется расширить возможности декларативных языков до процедурных (как Transact SQL использует PL/SQL и DHTML использует XL, предложенный Даной Флореску), а процедурные снабдить возможностями работать метаданными, заключенными в декларативную структуру. Так, в BEA работают над языком Pi-Java.
Над решением проблем, связанных с языками для управления потоками работ, серьезная работа ведется и внутри BEA; компания также финансирует академические исследования и эксперименты в области расширения XML Query, выполняемые в университетах. В процессе движения к новым языкам происходят далеко не тривиальные события. В их числе — реанимация исследований, которые проводились в 80-е и 90-е годы, исследований, которые проводились в Xerox PARC в 70-е годы, и даже язык Симула из 60-х выбивается в современный основной поток. Не менее мощные трансформации ожидают и базы данных. Современные реляционные модели слишком статичны, они не годятся для того, чтобы быть положенными в основу сооружаемого Нового Вавилона. На то, чтобы он был возведен, уйдет еще лет десять. В процессе его создания потребуются не только новые языки и СУБД, но и новые разделы математики, новые знания и экспертиза, а самое главное — новые специалисты. И все это для того, чтобы удовлетворить потребности пользователей Internet и мобильных устройств.
Явление, называемое сегодня Web-сервисами, можно сравнить с будущим лесом, пробивающимся пока в виде слабых побегов. Вы нарисовали впечатляющую картину, ее понимание необходимо современникам, но особенно критично для тех, кто займет ответственные позиции в этом профессиональном мире лет через десять. В номере «Открытые Системы. СУБД» за февраль 2003 год обсуждались вопросы, связанные с ИТ-образованием и в том числе вопрос о необходимости фундаментального образования. Если у кого-то и оставались сомнения, то Адам Босуорт их рассеял.
