Fox populi

В прошлом месяце вводная статья серии Работа с Grails познакомила с новым каркасом для разработки Web-приложений, называемым Grails. Grails включает в себя такие современные подходы, как MVC (Model-View-Controller — модель-представление-контроллер), разделение обязанностей (separation of concerns) и соглашение по конфигурации (convention over configuration). В сочетании со встроенными возможностями скаффолдинга Grails позволяет получить первую работающую версию Web-сайта за несколько минут.

Эта статья посвящена другой области, которую также упрощает Grails: долговременному сохранению объектов с помощью API GORM. Статья начинается с описания того, что такое ORM (object-relational mapper — объектно-реляционный преобразователь) и как создать отношение типа «один ко многим». Далее рассказывается о проверке данных, гарантирующей, что приложение не будет поражено синдромом garbage in/garbage out (неправильные данные на входе/неправильные данные на выходе). Будет показано практическое использование Grails ORM DSL (domain-specific language — язык для конкретной доменной области), который позволяет детально настраивать способ постоянного сохранения POGO-объектов (plain old Groovy objects — обычные старые Groovy-объекты) за рамками приложения. Наконец, будет показано, как легко переключиться с одной реляционной базы данных на другую. Подойдет любая база данных, поддерживающая JDBC-драйвер и Hibernate-диалект.

Eclipse — это прежде всего качественная платформа для построения самых разных приложений. Основным компонентом платформы является Equinox — реализация спецификации OSGi R4. На базе Equinox строятся другие компоненты, такие, как, например, Eclipse Communication Framework, о котором мы сегодня и поговорим.

Не секрет, что большинство создаваемых в наше время приложений работают в сетевой среде. Особенно это характерно для т.н. Enterprise-приложений, для разработки которых в основном Java и используется. Естественно, что такие приложения нуждаются в средствах взаимодействия с локальной сетью и/или Интернетом. Писать такое взаимодействие самому утомительно, поэтому для облегчения создания программ, использующих возможности сети и основанных на OSGi (в частности — Eclipse RCP-приложений), был разработан ECF.

ECF — это реализация концепции распределенных контейнеров, осуществляющих передачу данных по различным прикладным протоколам. Контейнеры могут обеспечивать связь с сохранением состояния (т.е. с сессией) и без сохранения. Поддерживается взаимодействие типа «точка-точка» (например, клиент — сервер) и типа «публикатор — подписчики». Само взаимодействие может быть как синхронным, так и асинхронным.

По сути, ECF предоставляет единый набор API к контейнерам, обеспечивающим различные протоколы связи, причем данный набор расширяемый и допускает использование особенностей, характерных для того или иного протокола. Обеспечивается такая возможность за счет использования механизма адаптеров.

Единый API позволяет не беспокоиться о том, что у нас находиться «на другой стороне» — в случае изменения протокола мы просто меняем создаваемый контейнер, остальной код менять не требуется. Другим плюсом такой унификации является легкий переход от одной технологии (например, от Apache ActiveMQ, представленного в той же IBM WebSphere) к другой (например, Weblogic от Oracle).

В этом учебном руководстве мы спроектируем и разработаем приложение обработки заказов, отображающее свою функциональность в виде Web-сервисов, посредством которых различные клиенты могут размещать информацию о заказе независимым от используемой платформы способом.
Информация по теме:
Советы и приемы для Web-сервисов: сравнение JAX-RPC и JAX-WS
Интерфейсы программирования приложений JAX-WS client API в Web Services Feature Pack for WebSphere Application Server V6.1 series
Демонстрационные материалы по Web-сервисам, предоставляемые по требованию
Доставка Web-сервисов в мобильные приложения

Связанная структура данных (rope data structure) представляет собой неизменяемую последовательность символов, во многом похожую на String в Java. Но эффективная реализация изменений в связках делает их, в отличие от объектов типа String и их изменяемых собратьев, объектов типа StringBuffer и StringBuilder, идеально подходящими для приложений, которые выполняют большой объем работы по манипуляции строками, особенно в многопоточных средах.

После краткого знакомства со структурами данных, основанных на связках, эта статья знакомит читателя с библиотекой Ropes for Java, реализацией связок для платформы Java. Затем выполняется сравнение классов String, StringBuffer и класса Rope из библиотеки Ropes for Java для Java-платформы; исследуются отдельные проблемы, связанные с производительностью, а завершается статья обсуждением, когда стоит использовать связки в приложении, а когда от них лучше отказаться.

С момента представления в 1995 г. Java-платформы как единого целого мира, Java прошел радикальный эволюционный путь от концепции “апплеты повсюду”, которую исповедовали первые идеологи и приверженцы. Вместо этого мир Java развился до Swing, сконцентрировался вокруг сервлетов, направил движение к J2EE, споткнулся на EJB, нашел обходной путь через Spring и Hibernate, добавил возможности абстрактного программирования и стал более динамичным, а затем и более функциональным, и продолжает развиваться во множестве интересных направлений, в то время как я пишу эту статью.

Это многообразие может несколько озадачить Java-программиста, если он не рос и не развивался профессионально вместе с данным языком все эти годы.