Java готовится отметить свою десятую годовщину. Свершилась ли «Java-революция», обещанная ее создателями? Отчасти да, однако Java — явление многоплановое. Есть, безусловно, единый язык, байт-код и виртуальная машина. Между тем, если рассматривать технологическую платформу в целом, скажем, Java в мобильном телефоне и в корпоративном центре обработки данных, то различий обнаруживается больше, чем сходства. Насколько широкое распространение получили технологии Java среди корпоративных клиентов? Результаты здесь не слишком впечатляют — платформа J2EE получила меньшее признание, чем того заслуживает.
Прежде чем разбирать текущее положение дел, проследим перипетии развития Java как немного поднадоевший (все-таки десятый сезон), но все еще популярный сериал. Как и в телесериалах, где в каждой серии зрителя ждет новая сюжетная интрига, в ИТ-индустрии специалисты по маркетингу к каждому сезону готовят новые эффектные инициативы.
Эпизод 1. Рождение
Язык Java (первоначально Oak) появился на свет в Sun Microsystems как побочный продукт исследовательского проекта Green, начатого в 1990 году. Поучительно, что целью этого проекта являлась разработка встраиваемого программного обеспечения для бытовой электроники. Первоначально команда проекта собиралась использовать C++, но из-за специфики платформы обнаружились проблемы, наилучшим решением которых была признана разработка нового языка.
Таким образом, уже на первом этапе язык Java был нацелен на вполне определенное применение и совсем не претендовал на ту роль и ту сферу применения, которую занимает сейчас.
Эпизод 2. Обещание
В 1996 году был выпущен Java Development Kit 1.0. Надо отдать должное компании Sun, которая очень быстро сумела снабдить новый язык доступным инструментарием (компилятор, отладчик, средства документирования), жестко стандартизованной средой исполнения (виртуальные Java-машины для самых разнообразных платформ и библиотеки классов) и, главное, широкой поддержкой практически всех лидеров ИТ-индустрии, среди которых на первых порах была и корпорация Microsoft. Это очень отличалось от предшествующих технологических волн C++ и Ada, когда от появления спецификации языка до создания работоспособного компилятора проходили годы.
Уже этого одного было достаточно, чтобы привлечь к новому языку множество разработчиков. Однако Java обещал больше. Главной приманкой стал лозунг Write once, run anywhere («Напиши раз, запускай где хочешь»). Правда, недоброжелатели переиначили эту фразу в Write once, debug anywhere («Напиши раз и отлаживай всюду»), намекая на проблемы с совместимостью между разными Java-машинами, и даже в Right once, run anywhere («По одному разу запускай где хочешь»), это уже намек на функциональные ограничения апплетов. Но в целом обещание переносимости оказалось выполнено, хотя и не совсем так, как ожидалось. Умные холодильники, самостоятельно заказывающие продукты через Internet, стали частью фольклора, но вот компьютерные игры для сотовых телефонов превратились в совсем неигрушечный рынок с годовым оборотом в 3 млрд долл.
Эпизод 3. Корпорация «J»
К середине 90-х недостатки «толстого клиента» были осознаны. У корпоративных пользователей и системных администраторов созрела потребность в приложениях, нетребовательных к характеристикам компьютеров на рабочих местах, масштабируемых без проблем с администрированием сети и адаптированных к работе в гетерогенных средах, имеющих многозвенную архитектуру, использующих различные источники данных — от баз на мэйнфреймах до Microsoft Excel на локальном ПК.
Вот типичный пример корпоративной системы: схема базы на SQL/DDL; логика данных на PL/SQL; пользовательский интерфейс на Delphi; отчетные формы в Crystal Reports. Даже если перечисленные среды разработки состыкованы друг с другом, программисты обычно дублируют структуры и фрагменты логики в разных языках, что неизбежно чревато ошибками и проблемами при сопровождении. Перспектива повторного использования одних и тех же классов во всех частях проекта не могла не воодушевлять.
Но хотя разговоры об Enterprise Java велись давно, стабильная платформа J2EE появилась далеко не сразу. В Sun выпустили окончательную версию спецификаций J2EE только в конце 1999 года, а в 2000-м появились первые сертифицированные J2EE-серверы приложений. В июле 2001 года спецификации J2EE предстали в версии 1.3, а конкуренция между поставщиками серверов приложений выявила тройку лидеров — BEA WebLogic, IBM WebSphere и Oracle Application Server. Но это в сегменте «тяжелых» серверов — как по функциональности (кластеризация, кэширование, расширенное администрирование и т.п.), так и по цене. Массовой же популярности технологии способствовало появление свободно распространяемых серверов, например, выход Apache Tomcat в 2001 году. Хотя это не полнофункциональный J2EE сервер, а «всего лишь» контейнер сервлетов и JSP, но для многих Web-проектов больше и не требуется. В 2002 году появился сертифицированный J2EE-сервер Jboss, который сегодня вышел на третье место по популярности.
Эпизод 4. X-миссия
Можно было ожидать, что к 2002 году технологии Enterprise Java наконец-то вступят в пору зрелости, однако в полной мере это не произошло. Некоторые компоненты полностью устоялись (JDBC, EJB, сервлеты), другие усовершенствовались (JSP custom tags), третьи отошли на второй план (RMI-IIOP), но главное — появились новые (технология JavaServer Faces, Web-сервисы). В настоящее время подходит к завершению технологический переворот Enterprise Java, суть которого определяют несколько тенденций:
- отказ от Java на стороне клиента в пользу «тонкого» Web-клиента, использующего динамический HTML;
- распределенные вычисления на основе Web-сервисов вместо RMI и CORBA;
- переход к сервис-ориентированной архитектуре, поддержка порталов и бизнес-процессов.
Web-клиенты
Первоначально реализация трехзвенной архитектуры в Java выглядела следующим образом: Java-апплет в роли тонкого клиента или Java-программа на компьютере пользователя отвечают за пользовательский интерфейс; компоненты Enterprise Java Beans (EJB) на сервере аккумулируют бизнес-логику; сервер базы данных реализует логику доступа к данным. Но, во-первых, апплет оказался не таким уж «тонким»; во всяком случае, толще, чем хотелось бы: время его загрузки и запуска на компьютере пользователя достаточно велико, чтобы вызвать раздражение. Во-вторых, апплеты не очень хорошо вписались в корпоративную инфраструктуру, конфликтуя с сетевыми экранами и другими защитными средствами; с другой стороны, встроенная в апплеты система безопасности ограничивает функциональность разрабатываемых приложений. В-третьих, Microsoft удалось внушить пользователям недоверие к Java в среде Windows. В-четвертых, за Java закрепилась репутация сложной в освоении среды; во многих случаях разработчики «проголосовали ногами», предпочтя технологически прогрессивным, усиленно рекламируемым и увешанным изощренными интерфейсами Java-решениям Web-приложения, использующие Perl, PHP, Python, ASP и Javascript.
Архитекторы Java внесли соответствующие корректировки в свои планы, и вектор развития повернулся в сторону Web-клиента со страницами, описанными посредством динамического HTML или XML. Теперь уже его, а не апплет, стали называть тонким клиентом. Такой клиент состоит из двух частей: браузер на компьютере пользователя для работы с HTML/XML-страницами и программное обеспечение на сервере, которое эти страницы динамически создает. Генерация страниц на сервере всегда присутствовала в J2EE, сначала в виде сервлетов, потом усовершенствовалась в JavaServer Pages (JSP), однако выяснилось, что в этом направлении сделано еще недостаточно, чтобы удовлетворить и привлечь разработчиков. Основная проблема — смешение HTML и Java-кода, при том, что за HTML-верстку и за программирование в крупных проектах отвечают разные люди. Решение этой проблемы идет по нескольким направлениям.
- Методика MVC (Model-View-Controller) вводит специализацию в Java-код, отвечающий за интерфейс с пользователем. Формирование Web-страниц (View) отделяется от выполнения действий по нажатию кнопок на формах (Controller).
- Custom Tag Library преобразует обращения к Java-коду в XML-теги, которые ближе и понятнее Web-дизайнеру.
- Java-шаблоны (например, Velocity, часть проекта Apache Jakarta) позволяют дизайнерам обращаться к Java-коду при помощи упрощенного синтаксиса, который по духу ближе к Perl, чем к Java.
Web-сервисы
Web-сервисы полностью нейтральны к выбору языка программирования, системно-аппаратной платформы и поставщика программных средств промежуточного слоя. Кроме того, их популярности способствует то, что они опираются на проверенный и доступный технологический фундамент — протокол HTTP для передачи и XML для кодирования сообщения. Поддержка Web-сервисов стала для платформы Java приоритетной задачей еще и потому, что эту технологию очень активно поддерживает конкурирующая платформа .Net. Сходство этих двух платформ бросается в глаза: байт-код и виртуальная машина (JVM у Java и CLR у .Net), серверный контейнер для исполняемых компонентов (JSP, EJB и ASP+, COM+ соответственно), поддержка распределенных вычислений и многозвенной архитектуры. Но есть и различия. J2EE предоставляет широкий спектр платформ при одном-единственном языке программирования, а .Net — наоборот, целый перечень языков для единственной платформы.
Воодушевляет тот факт, что Web-сервисы активно развивают в обоих непримиримых лагерях. Благодаря этому Web-сервисы стали сегодня наилучшим средст?вом для стыковки компонентов, реализованных на этих двух платформах.
Сервис-ориентированная архитектура
Интеграция разнородных приложений — давняя и постоянная головная боль корпоративных ИТ-подразделений. Бизнес давно осознал неэффективность традиционного деления управленческих служб по функциональному признаку. Проблема состоит в том, что специалисты, подготовленные для решения своих узких задач (бухгалтерия, логистика, финансы и т.д.), обучены поддерживать порядок в своих бумагах, но не нацелены на потребителя. Давно определен и путь решения — концепция бизнес-процесса как цепочки связанных процедур, оптимизированная на достижение конечного результата в виде ожидаемого заказчиком продукта или услуги.
Однако путь к автоматизации бизнес-процессов оказался тернист, ведь программы тоже разрабатываются для автоматизации отдельных процедур. Кроме того, имеется и объективная сложность: бизнес-процессы обладают большей, по сравнению с бизнес-функциями, изменчивостью. И если можно запрограммировать, скажем, процедуру выписки счета и пользоваться ею годами, то бизнес-процесс, использующий эту процедуру, за это время несколько раз изменится.
Концепция Web-сервисов указывает направление решения этой застарелой проблемы: не разработка новых приложений, а эффективное использование уже имеющихся путем «упаковки» их в Web-сервисы небольшим по объему программным кодом на любом языке и на произвольной платформе, включая J2EE и .Net. Аббревиатуру SOA (Service-Oriented Architecture) в шутку расшифровывают еще и как Save Our Assets. Действительно, проблема заключена не в отсутствии информационных активов, а в способном «похоронить» эти активы неэффективном их использовании без налаженного взаимодействия. Web-сервисы в SOA рассматриваются как «кирпичики», из которых складываются системы интеграции бизнес-процессов (business process integration, BPI) и порталы. Эти концепции находятся пока в ранней стадии проработки — стандарты уже появляются, а поддержка их программными инструментами оставляет желать лучшего.
Но ожидания очень высоки. К примеру, с точки зрения пользователя, портал — это просто Web-страница с настраиваемыми окнами, в которых могут быть открыты различные приложения. Однако дело тут не в технологии, а в психологии посетителя такого сайта. Психологически, разница между традиционным сайтом и порталом такая же, как между магазином, в котором товары находятся за прилавком, где только продавец может их потрогать, и современным супермаркетом.
Мнение зрителя
Если говорить о восприятии J2EE, то достоинства и перспективность данной платформы специалистами, как правило, признаются. Но имеются и негативные факторы, в том числе, отрицательный опыт ранних проектов на Java и отсутствие инструментария, адекватного ожиданиям разработчиков корпоративных приложений.
Груз первых неудач
Период до 2000 года оказался тяжелым для тех, кто пытался реализовывать на Java корпоративные проекты:
- неустоявшиеся стандарты (окончательный вариант первой версии спецификации J2EE появился лишь в конце 1999 года);
- недостаточно стабильная и отлаженная среда (сертифицированные J2EE-серверы стали доступны к 2001 году);
- смена архитектурных парадигм (постепенная переориентация от Java к HTML/XML-клиенту и от CORBA к Web-сервисам, произошедшая в 2001-2002 годах).
Добавим к этому проблемы с производительностью; принято считать, что Java-код эффективен, если он проигрывает раза в полтора программам на С++ (в конце концов, это можно компенсировать масштабируемостью и постоянным ростом производительности процессоров). Но беда в том, что для построения корпоративной системы приходится использовать множество компонентов от разных поставщиков (JDBC-драйверы, библиотеки интерфейсных классов, EJB-компоненты, JCA-коннекторы и т.п.). И для снижения производительности всей системы зачастую достаточно, чтобы всего один из компонентов был неудачно реализован, например, чтобы в нем отсутствовало кэширование, пул коннекторов к базе данных или неэффективно были бы реализованы вызовы удаленных процедур. Автору известен подобный пример, когда Java-компонент оказался медленнее аналога на Delphi в 6000 раз, что стало почти фатальным для проекта.
В июле 2004 года изобретатель Java, Джеймс Гослинг, заявил, что он является «горячим поклонником эволюции» и что вообще, для того, чтобы жить в мире Java, надо быть последователем Дарвина. Но эволюция — не просто постепенное развитие, это путь проб и ошибок. Идеи появляются, развиваются, затем в результате естественного отбора «менее приспособленные» идеи исчезают. Но ведь речь идет не об интеллектуальных игрушках, а о реальных программных продуктах, за которые кто-то платит деньги, рассчитывая, что и эти продукты, и технологическая платформа, на которой они построены, будут жить и развиваться. А тут «случается эволюция», и кому-то приходится списывать свои убытки на Дарвина?
Инструменты
Но кто он, типичный разработчик корпоративных приложений, чего он ждет от инструментария для разработки приложений на платформе J2EE и насколько реальность соответствует его ожиданиям? И что такое, в конце концов, сами эти корпоративные приложения?
Говоря просто — это приложения для работы с базами данных (если не на 100%, то на 90%), а самые распространенные среди российских программистов средства разработки — это Delphi, Visual Basic и FoxPro. Да, это устаревшие технологии — традиционные клиент-серверные и даже файл-серверные. Но разработка с их помощью ведется быстро — разработали схему базы данных, при помощи визуального редактора создали экранные формы, также при помощи визуальных средств разработали отчеты и все.
Можно ли такого разработчика переучить, скажем, с Delphi на Visual Basic или с Oracle Forms на Power Builder? Да, поскольку все эти инструменты концептуально схожи. А научить разрабатывать Web-приложения с тонким клиентом для J2EE? По оценке Gartner, требуется от десяти до двенадцати месяцев для того, чтобы квалифицированного разработчика приложений Oracle Forms превратить в разработчика Java начального уровня. Это не просто барьер, это барьер запретительный.
Прикладной программист должен думать о бизнес-логике и об эргономике разрабатываемых приложений, не отвлекаясь на стандартные и низкоуровневые функции. Традиционный инструментарий этому требованию отвечает. Программист работает с экранными формами и полями с соответствующими им таблицами и полями базы данных, не заботясь о множестве рутинных операций — о поиске в стиле Query By Form, об упреждающем чтении базы данных, о блокировках текущей записи, о проверке содержимого экранного поля типу данных, об отображении связанных таблиц. Все это инструментарий, включая среду исполнения, предоставляет ему в готовом виде. То же относится и к разработке отчетных форм. Вот это и называют инструментальными средствами быстрой разработки приложений (rapid application development, RAD).
С точки зрения программиста, на Delphi в J2EE обработка событий сильно оторвана от места их возникновения: привяжи к кнопке на форме POST-запрос, отдай его на обработку, напиши JSP, передай ему результат, покажи. Количество JSP нарастает очень быстро, и вскоре проект становится неуправляем. При помощи традиционного RAD-инструментария все делается, не задумываясь: ткнул мышью в кнопку, получил процедуру обработки нажатия кнопки, прописал в ней код и кнопка работает.
Сценарий на завтра
Конечно, у традиционных средств разработки есть серьезный изъян — они не следуют общему стандарту. Поэтому нельзя, например, позаимствовать экранную форму для некоторой таблицы базы данных, сделанную в Oracle Forms, и использовать ее в приложении на Visual Basic. В этом, а также в поддержке многозвенной архитектуры, в многочисленных сервисах, которые она предоставляет, преимущества платформы Java неоспоримы.
Но давайте будем реалистами — разработчики корпоративных приложений для платформы J2EE не прилетят с Марса. Поэтому, либо вести разработку для этой платформе научатся существующие прикладные программисты из ИТ-подразделений компаний-заказчиков и программисты компаний-поставщиков прикладных решений, либо массовый переход на эту платформу не состоится. Поэтому, если нацеливаться на масштабную разработку бизнес-приложений для платформы Java, то необходим инструментарий, который предоставляет нечто большее, чем редактор исходного текста с выделением языковых конструкций, удобный браузер классов и справочник по API. Нужен полноценный RAD-инструментарий, целенаправленно ориентированный на разработку интерактивных приложений и отчетных форм и предоставляющий в готовом виде соответствующие программные компоненты. При этом он должен быть полностью совместим со стандартом J2EE и поддерживать серверы приложений и базы данных от всех ведущих поставщиков.
Популярные средства разработки на языке Java от компаний Sun Microsystems, IBM, BEA Systems, Borland слишком универсальны, чтобы ими ограничиться. Приберегите их для программирования низкоуровневых задач — библиотечных классов, утилитных программ и т.п. Для разработки того, что составляет основную часть прикладной системы — экранных приложений и отчетных форм — лучше поискать специализированный инструментарий, например, в Сети, задав в поле запроса «J2EE RAD non-java developer». Сегодня такой инструментарий уже есть на рынке, что открывает путь к успеху многим компаниям, которые хотели бы начать разработку корпоративных приложений на платформе J2EE, но не находили реальной возможности задействовать для этого имеющийся персонал.
Анатолий Белайчук (bell@b-k.ru) — технический директор компании «Бизнес-Консоль» (Москва).
