Зручний і зрозумілий Java під рукою, CASE-засоби (моделювання), Програмування, статті

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*