Известный JavaEE архитектор-фрилансер недавно опубликовал свое видение будущего в построении архитектуры корпоративных приложений. Далее идет вольный перевод.

Java EE 6 и Spring 3 оказались очень похожи — как минимум архитектура и дизайн отличаются лишь в деталях. Не вижу отличий и в процессе разработки, где JPA и SessionBean-ы в Glassfish можно заменить технологиями Spring.

Spring также идет со своим сервером приложений, который с 7 октября 2008 является open source сервером с коммерческой поддержкой. Если вам понадобится получить патчи старых версий Spring — вам будет необходимо преобрести коммерческую поддержку от SpringSource/VMWare. Для серьезных проектов вы будете вынуждены преобрести два пакета поддержки — для сервера приложений от вендора и один от SpringSource, хотя этом случае одновременное использование Java EE 5/6 опровдать сложно. В перспективе я вижу два возможных варианта:

• Развертывание Spring-а на проприетарный tc сервер
• Развертывание Java EE 6 приложений без Spring-а

Обозначенная выше дилемма также справедлива и для проектов по миграции — стоит ли использовать стек Java EE, либо мигрировать на Spring. Это скорее стратегическая или политическая дилемма, нежели технологическая. Конечно, можно еще самостоятельно собирать и распространять Spring, однако такой подход недопустим в большинстве коммерческих проектов.

Я считаю, что будущее корпоративной Java очень чистое — мы полностью используем либо Spring, либо стек Java EE, но не эти технологии вместе.

См. также Oracle опубликовал планы развития Glassfish

25 марта Oracle официально представил планы по развитию недавно преобретенного вместе с Sun Microsystems сервера приложений Glassfish. Самая важная новость — никаких изменений в работе сообщества над проектом не произойдет, Oracle заинтересован в дальнейшем развитии продукта.

Open source версия Glassfish остается, а в дополнение к ней Oracle будет поставлять свой Oracle GlassFish Server с преферансом и куртизанками со своей поддержкой, лицензированием и закрытыми дополнениями. Были опровергнуты утверждения о том, что прекратится поддержка кластеризации, проект станет закрытым для внешних разработчиков, Oracle не понимает Open source и т.д.

Планы по развитию затрагивают следующие аспекты: следующие релизы версий 2 и 3 через 100 дней (в основном интеграция с технологиями Oracle), векторы технологического развития Glassfish, интеграции с семейством Oracle Fusion Middleware, анонс версий 3 и 4.

Для использования одного из самых удобных веб фреймворков для java на популярной облачной платформе Google AppEngine необходимо совершить ряд действий. Данная статья появилась в результате моих продолжительных экспериментов. Буду рад, если Вы поделитесь своим опытом работы с вашими любимыми фреймворками на платформе GAE в коментариях :-)

Используемые библиотеки

Я использую обычно следующий набор библиотек:

• commons-fileupload-1.2.1.jar
• commons-io-1.3.2.jar
• commons-logging-1.0.4.jar
• commons-logging-api-1.1.jar
• freemarker-2.3.13.jar
• ognl-2.6.11.jar
• struts2-core-2.1.6.jar
• xwork-2.1.2.jar

Я пользуюсь IntelliJ Idea 9 и она подкачивает зависимости автоматически после того, как я указываю использование Struts 2 при создании проекта. Также существует возможность развертывать приложения на облачной платформе через специальное меню IDE, и вообще поддержка AppEngine на очень хорошем уровне.

Далее необходимо обойти или адаптироваться к ограничениям облачной платформы, ибо Appengine запрещает прямой доступ к тредам, файловым и многим другим ресурсам.

Нет ничего проще установки флеш плеера на Ubuntu 9.10 x64, требуется всего 2 шага:

1. Скачать с сайта Adobe Labs архив;
2. Извлечь из ахрихва файл libflashplayer.so и переместить в директорию ~/.mozilla/plugins.

UPD: Если для вас сей процесс очевиден — не стесняйтесь, проходите мимо.

UPD 2: Еще один рецепт установки 10.1.x версии для тех, у кого тормозит 10.0.x версия

Продолжение серии. Ранее: Java EE 6. Обзор JPA 2.0, часть 1: Введение. В данной статье я продолжаю рассматривать изменения в JPA.

Встроенные коллекции

Введенный в JPA 2.0 компонент ElementCollection позволяет задавать политики отображения для необычных в JPA 1.0 видов коллекций: коллекций embeddable объектов, либо коллекций «простых» типов (Integer, String и т.д.). Также это компонент используется при в определениях отношений с Map, в роли ключа которого выступают любого рода объекты, а в роли значения — embeddable или «простые» объекты.

Значения ElementCollection всегда хранятся в отдельных таблицах, которые задаются аннотацией @CollectionTable. CollectionTable отпределяет имя таблицы и @JoinColumn или @JoinColumns в случае составного первичного ключа.

Пожалуй, наибольшее количество изменений с выходом спецификации Java EE 6 было привнесено в JPA (Java Persistence API). В серии статей, начиная с этой, я планирую рассказать подбробно о каждом из нововведений.

Введение

Технология JPA является абстракцией над JDBC и позволяет быть независимым от SQL. Все классы и интерфейсы JPA расположены в пакете javax.persistence, основными составляющими технологии являются:

• ORM (механизм объектно-реляционного отображения);
• Entity manager API — позволяет осуществлять базовые операции CRUD;
• JPQL и Criteria API — механизмы извлечения данных;
• Управление транзакциями и блокировками (как с использованием JTA, так и без);
• Механизмы обратных вызовов и listener-ов.

 

С выходом Java EE 6 на ряду со значительными изменениями в JPA 2.0 спецификации сервлетов 3.0 также притерпела ряд улучшений: упростилась разработка и процедура развертывания, конфигурирование стало более удобным, появилась поддержка асинхронных запросов и улучшилась модель безопасности. Далее я попытаюсь осветить основные изменения в API.

Программирование и развертывание сервлетов упростилось главным образом за счет введения аннотаций для декларирования сервлет (@WebServlet), фильтров (@WebFilter), листнеров (@WebListener) и ограничений безопасности (@ServletSecurity). Таким образом, и дескриптор развертывания web.xml стал опциональным элементом. Обращаю внимание, что сами компоненты Servlet API не стали POJO, привычную иерархию интерфейсов и классов никто не отменял. Также добавилась аннотация для поддержки загрузки файлов @MultipartConfig и для установки параметров инициализации @WebInitParam.

Пример Hello World сервлета
package net.ismailov.tests;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet(name="hw", urlPatterns = "/hello_world")
public class HelloWorld extends HttpServlet{

  public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

    PrintWriter writer = response.getWriter();
    writer.println("<h1>Hello, World!</h1>");
    
  }

}


Уже пару лет пользуюсь сервисом Яндекс.Фотки для хранения всех своих фотографий, а недавно возникло желание на своей домашней страничке выводить последние n фотографий, загруженных на Яндекс.Фотки, тем самым убив сразу несколько зайцев:

• домашняя страничка не требует администрирования;
• не требуется хранение и управление изображениями;
• не требуется заниматься ресайзингом изображений для превью и т.д.

Сказано — сделано. Оказалось, что Фотки предоставляют достаточно удобный API по протоколу AtomPub. Т.к. страничку планировал делать на платформе Ruby on Rails, после непродолжительных поисков нашел неплохую библиотеку для работы feedzirra. Устанавливалась библиотека совершенно стандартным образом:

1. gem sources -a gems.github.com
2. gem install pauldix-feedzirra

и далее в ruby достаточно прописать ее использование:

1. require 'feedzirra'

Пришло время изучить предоставляемый API