ORACLE СОБИРАЕТСЯ СДЕЛАТЬ РАЗРАБОТКУ КОДОВ И ПРОЩЕ, И ПРОИЗВОДИТЕЛЬНЕЕ
На 11-й ежегодной конференции JavaOne, которая состоялась в мае нынешнего года в Сан-Франциско (США), было затронуто немало тем, но главной из них следует, пожалуй, признать восстановление баланса между богатыми возможностями корпоративной платформы Java и ее сложностью. Здесь была представлена, в частности, последняя версия новой корпоративной модели под названием Java Enterprise Edition 5. Эта наследница хорошо известной платформы J2EE (Java 2 Platform, Enterprise Edition - платформа Java 2, корпоративный вариант) вобрала в себя опыт не только корпорации Sun Microsystems, создавшей и взрастившей язык Java, но и многих других компаний. Одна из ключевых ролей в этом процессе принадлежит, несомненно, фирме Oracle.
Обсудить проблемы развития корпоративных возможностей Java при одновременном устранении препятствий на пути использования данной платформы согласился Тед Фаррел, вице-президент и главный архитектор средств разработки приложений Oracle. Его замечания по этому и другим вопросам, высказанные в ходе интервью редактору eWeek Labs Питеру Коффи, приводятся ниже.
Тед Фаррел из Oracle утверждает, что EJB 3.0 упростит целый ряд элементов, за которыми приходится следить программисту |
eWeek: Какие ключевые моменты вынесла Oracle на JavaOne в этом году?
Тед Фаррел: В первый же день работы конференции, 16 мая, мы объявили о начале поставок своей базовой реализации интерфейса Java Persistence API [JPA, подробнее познакомиться с этой концепцией можно по адресу glassfish.dev.java.net/javaee5/persistence]. Данная разработка уже стала стандартом Java, обеспечивающим сохраняемость [persistence] объектов в базах данных и возможность их извлечения оттуда.
Кроме того, JPA, являясь базовым API платформы Enterprise JavaBeans [EJB] 3.0, имеет одно немаловажное достоинство. Когда программисту не хочется использовать контейнеры EJB 3.0, он может обратиться непосредственно в библиотеку JPA и взять оттуда для своей программы облегченную версию объектно-реляционного решения.
eWeek: А разве раньше сохраняемость Java-объекта не требовала низкоуровневых операций по его сериализации (преобразовании в последовательную форму с дальнейшей обработкой полученных битов?
Т. Ф.: Все зависело от того, где программист собирался сохранять этот объект. Сериализация была лишь одним из возможных путей. Многие разработчики предпочитали вручную писать вызовы JDBC [Java Database Connectivity - подключение к базе данных], а затем выполнять обратную операцию - отображать полученный результат на Java-объектах.
eWeek: А не меняет ли это парадигму мышления программиста, стиль его работы с деталями?
Т. Ф.: Несомненно. И к тому же избавляет от малоэффективного труда. Инфраструктура наподобие TopLink Essentials - нашей базовой реализации JPA - создается уже добрый десяток лет. Она в полной мере понимает объектно-реляционные отображения и оптимизирует вызовы для вас, поэтому индивидуальному программисту больше не придется изучать такие тонкости.
eWeek: Значит, программисту станет легче сохранять объекты для использования в будущем? Ему не придется больше писать собственный исходный код для низкоуровневого взаимодействия в базах данных?
Т. Ф.: Совершенно верно. Программист сможет целиком и полностью сосредоточиться на Java-объектах и исходных текстах. Спецификации JPA и EJB 3.0 - это огромный шаг вперед с точки зрения производительности труда Java-разработчиков. Их базовые реализации уже сегодня предлагаются как версии 1.0, так что программистам ничто не мешает пополнить ими свой арсенал.
eWeek: С появлением Enterprise JavaBeans связано, похоже, самое крупное усложнение среды на памяти нынешних программистов. Может быть, EJB 3.0 продемонстрирует лучший баланс производительности и сложности?
Т. Ф.: Первые версии - особенно реализованный в EJB полномасштабный контейнер управления транзакциями - отличались огромной мощностью, но были - и остаются по сей день - невероятно сложными в управлении и использовании. Именно поэтому нас так привлекает простота EJB 3.0 по сравнению с прежними версиями. Ее концепция во многом совпадает с тем, что мы закладывали в свою TopLink. Ведь не секрет, что именно у TopLink позаимствована часть кода и идей EJB 3.0.
eWeek: Что вы считаете главными достоинствами новинки с точки зрения простоты ее реализации и понимания разработчиками?
Т. Ф.: Прежде всего в EJB 3.0 стало заметно меньше элементов, с которыми приходится иметь дело разработчику. Раньше для реализации одиночного логического объекта - скажем, логического представления таблицы в базе данных - могло потребоваться три, а то и больше Java-файлов плюс файл XML. В EJB 3.0 для этого достаточно одного-единственного класса, который представляет все стороны объекта. Вам больше не нужно отвлекаться от основного кода и отлаживать взаимодействие всех этих подвижных частей. Здесь мы видим четкое отображение "один к одному": доставкой данных в Java-объект теперь ведает внутренний механизм.
eWeek: Учитывался ли при разработке EJB 3.0 опыт пользователей первых версий? Или мы наблюдаем обычную эволюцию технологии по ее собственным законам?
Т. Ф.: Конечно, учитывался! Когда реализуется очередной JSR [Java Specification Request - запрос на спецификацию Java], носители разных идей тут же поднимают вокруг него невероятную шумиху, и в таких условиях отделить зерна от плевел бывает на первых порах очень трудно. Познакомившись с версией EJB 3.0 и тем, что она позволяет делать, программисты обязательно поймут, что это - огромный шаг вперед. Она намного ускоряет разработку Java-кодов, обеспечивающих сохраняемость объектов в базе данных.
eWeek: Все, о чем мы сейчас говорили, касается только первого объявления Oracle на конференции JavaOne, не так ли?
Т. Ф.: Да, конечно. Второе важное сообщение относилось к нашему вкладу в сообщество Open Source. Напомню, что совсем недавно Oracle передала сотню своих компонентов JavaServer Faces в проект Apache MyFaces, который реализует сейчас Apache Software Foundation. Мы называем эти компоненты ADF Faces, где трёхбуквенная аббревиатура расшифровывается как Application Development Framework и указывает на нашу инфраструктуру разработки приложений.
eWeek: Эта инфраструктура используется теми компонентами, которые создаются с помощью инструментария Oracle JDeveloper 10g?
Т. Ф.: Совершенно верно, это - компоненты ADF Faces. Если говорить о базовой реализации JavaServer Faces, то она содержит их минимальный набор. А ведь большинство заказчиков хотели бы получить гораздо больше специализированных компонентов данных с гораздо большими возможностями. Именно для этого мы и предложили этой весной 100 компонентов, начиная от комплексных таблиц и деревьев и заканчивая потоковым видео и изображениями. Реакция была самой доброжелательной.
Но тогда речь шла о так называемых HTML-компонентах, которые используют HTML и немного JavaScript. На конференции же JavaOne мы пообещали ближе к концу года передать сообществу Open Source совершенно новую свою разработку - компоненты JavaServer Faces типа AJAX [Asynchronous JavaScript and XML - асинхронные JavaScript и XML]. Теперь осталось только получить одобрение других участников для включения данных компонентов в проект. Первый комплект также будет передан через Apache MyFaces, а дальше будет видно. Лично я никаких препятствий на этом пути не вижу.
Сейчас многие компании не устают превозносить AJAX и называть эту технологию основой Web 2.0. Вот только нынешние решения заставляют вас обучать своих разработчиков использованию JavaScript и DHTML [Dynamic HTML - динамический HTML] либо какой-нибудь из частных версий языка XML. И тогда программисты смогут сделать всё, что надо. Однако это создает для них ненужную дополнительную нагрузку, когда они и так пишут большой объем JavaScript-кода, требующего дальнейшего сопровождения. Мы же нисколько не меняем модели программирования.
Вы можете взять те 100 исходных компонентов JavaServer Faces, о которых мы говорили выше, и программировать их с помощью JSP и JavaServer Faces. Аналогичный подход приемлем и для новых AJAX-компонентов. Вы просто программируете их, используя JSP и JavaServer Faces, и полученный на этой основе набор компонентов открывает перед вами все возможности технологии AJAX.
eWeek: Таким образом, вся сложность AJAX распределяется по отдельным уровням, а разработчик видит знакомую ему компонентную модель, тогда как пользователь получает все, что ему может предложить AJAX?
Т. Ф.: И не только. Наши компоненты помимо всего прочего используют технологию SVG [Scalable Vector Graphic - масштабируемая векторная графика]. На сегодняшний день AJAX не поддерживает ни таблиц, ни графиков. Поэтому в среде JavaScript эту технологию приходится подкреплять другими, такими, например, как SVG или Flash. А наши компоненты делают все это за программиста.
В результате тот избавляется от необходимости изучать не только JavaScript и DHTML, но и SVG. И при всем этом может использовать в своих разработках таблицы и графики.
eWeek: Удалось ли вам приблизиться к буквальному значению слов "стандартный браузер", уйдя от привычного "браузер достаточно распространен, чтобы его тестировать и использовать"? Или повторяется парадокс Ахилла и черепахи*?
Т. Ф.: Чтобы побыстрее решить эту проблему, мы в начале года присоединились к проекту Open AJAX. Нам нравится эта технология, мы все привержены ей. И очень важно заставить ее работать во всех браузерах и на всех серверах. Это - настоятельная необходимость, и я надеюсь, что со временем мы добьемся конвергенции.
Такая перспектива очень интересна. Мы обязательно воспользуемся возможностями DHTML и SVG. В ближайшие годы нас ждет взлет творчества и совершенствования продукции. Аппетит приходит во время еды. Как только мы даем разработчику то, что он хочет, у него сразу же появляются новые желания.
Думаю, стремление к взаимодействию будет только возрастать, но вы вполне сможете обойтись без переподготовки своих программистов. Опыт, накопленный при разработке приложений Web 1.0, пригодится не только при создании программ Web 2.0 с AJAX, но и во многих других сферах.
eWeek: Так что, разработчикам придется по-прежнему подстраивать демонстрацию контента под конкретные пользовательские среды? И может быть, им не потребуются столь разносторонние знания и умения, как сейчас…
Т. Ф.: Вы правы. Бывают ситуации, когда хочешь раскрыть достоинства чего-то перед всем миром, но это удается лишь до определенного уровня. Ведь человеку мало видеть - ему свойственно желание "пощупать" увиденное, что-то с ним сделать. Так что, думаю, программистам волей-неволей придется подстраиваться под ту среду, куда они выходят.
eWeek: Что в новом инструментарии Oracle есть такого, чего разработчикам не хватает в Eclipse с экосистемой подключаемых компонентов?
Т. Ф.: Мы стремимся к универсальности, поэтому все, что предназначено для подключения к JDeveloper снаружи или изнутри, будет вести себя стандартно и вписываться в рамки одной из предусмотренных здесь концепций. Скажем, будет однозначно относиться к разряду сервисов или компонентов. Некоторые из наших модулей основываются даже на управлении ядром интегрированной среды разработки. Когда программист возьмет наш инструментарий и поработает с ним, он получит большое удовольствие.