Вы находитесь на страницах старой версии сайта.
Переходите на новую версию Interface.Ru

Удобный и понятный Java под рукой

© Питер Коффи
© Статья была опубликована на сайте PCWeek/RE, №25/2006

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 упростит целый ряд элементов, за которыми приходится следить программисту

Тед Фаррел из 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 снаружи или изнутри, будет вести себя стандартно и вписываться в рамки одной из предусмотренных здесь концепций. Скажем, будет однозначно относиться к разряду сервисов или компонентов. Некоторые из наших модулей основываются даже на управлении ядром интегрированной среды разработки. Когда программист возьмет наш инструментарий и поработает с ним, он получит большое удовольствие.


*Классический парадокс древнегреческого философа Зенона: "Ахилл никогда не догонит черепаху". - Прим. ред.

Дополнительная информация

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме Oracle

Рекомендовать страницу

INTERFACE Ltd.
Телефон/Факс: +7 (495) 925-0049
Отправить E-Mail
http://www.interface.ru
Rambler's Top100
Ваши замечания и предложения отправляйте редактору
По техническим вопросам обращайтесь к вебмастеру
Дата публикации: 08.08.06