Новые перспективы Java Enterprise с Polyglot JVM

В этой статье хочу поделиться размышлениями об архитектуре серверных платформ для корпоративных приложений на Java с использованием Java EE, Spring, Akka.
Почему возникло желание написать? На JavaOne 2012 много было рассказано о трендах и изменениях в мире Java и JVM — Polyglot JVM, лямбды, модульность. На конференции возникло ощущение, что все наработки Java EE не должны зависеть от языка программирования. Сейчас часто задают вопрос – какой язык заменит Java? Но тогда куда девать все существующие технологии разработки корпоративных приложений? Эти технологии однозначно имеют ценность. Можно ли одновременно заменить язык программирования и при этом сохранить существующие наработки и сделанные инвестиции? Видимо да.
Теперь постараюсь подробнее – о влиянии тренда Polyglot JVM.
Введение Polyglot JVM достигает двух целей: открывает путь инновациям и позволяет сохранить все технологии Java в секторе корпоративных приложений. Но путь к этим выводам будет долгим;-)
Эта статья – для разработчиков корпоративных приложений. Надеюсь, она поможет систематизировать знания по архитектурам серверных платформ на базе Java и, возможно, вдохновит расширить диапазон используемых языков.

1. Object Management Architecture, CORBA

У истоков архитектур серверных платформ для корпоративных приложений находятся Object Management Architecture(OMA) и CORBA, разработанные группой OMG.

Архитектура Object Management Architecture (OMA, http://www.omg.org/oma) была разработана для объектных распределенных систем, в которых клиент осуществляет по RPC удаленный вызов метода объекта.
Подробнее о типах ресурсов для обращения по RPC, можно почитать тут https://www2.opengroup.org/ogsys/catalog/c706 (раздел 2.1.1.5). В зависимости от того, как трактовать удаленный ресурс, выделяются следующие ресурсные модели: сервер, сервис, объект. Если внимательно посмотреть на эти типы ресурсов, то для каждого типа «напрашивается» свой тип архитектуры приложения: соответственно клиент-серверная, сервис-ориентированная, распределенная объектная архитектуры.
Итак, OMA создавалась для третьего типа ресурсов – для объектов. Сейчас активнее используются другие типы ресурсов — сервис (например, SOAP), сервер (например, SQL, HTTP).
Но изменение типа ресурса с объекта на сервер/сервис не помешало перенести множество идей из OMA, в частности, на архитектуру Java EE.

Архитектура OMA

Важной частью OMA является брокер объектных запросов – Object Request Broker (ORB). ORB – это шире чем просто объектно-ориентированный RPC. Функционально – это частично аналог сервера приложений.

CORBA (Common Object Request Broker Architecture and Specification) специфицирует, как должен быть реализован ORB.
Архитектура ORB основана на двух важных идеях:

Именно в ORB по сути вводится понятие контейнера для объектов бизнес-логики (это называется object adapter): объекты бизнес-логики на сервере создает и разрушает контейнер. На рисунке ниже приведена структура ORB и красной границей выделен object adapter.

Структура ORB, красной границей выделен object adapter

Мотивацией для этого было обеспечить работу сервера под высокой нагрузкой. Так, 1) клиенту не позволено создавать «вручную» серверные объекты — вдруг забудет разрушить, 2) сервер может применять к объектам механизмы масштабируемости (выгружать объект, если к нему давно не было обращений, загружать, если он понадобился). Все полномочия клиента в данной схеме работы — запросить у сервера ссылку на серверный объект с бизнес-логикой и удаленно вызвать метод объекта.

Кроме контейнера объектов бизнес-логики в OMA есть понятие сервисов (Object Services) как составной части серверной платформы – см. рисунок ниже. Среди сервисов: сервис распределенных транзакций, сервис безопасности, event service и другие (полный список сервисов см. http://www.omg.org/spec/#CS).

CORBA Object Services

Реализация серверного объекта может обращаться к сервисам через упомянутый выше object adapter.
Таким образом, в CORBA заложены идеи, которые активно используются в современных серверных платформах на Java: использование контейнеров и сервисов, как показано на следующем рисунке.

Состав серверной платформы: контейнеры и сервисы

В CORBA также было заложено много других идей, которые интенсивно используются в настоящий момент. Так, именно в CORBA было введено понятие «интерсептор» (спецификация CORBA, версия 2.3, глава 21). Интерсептор в CORBA – это «хук», с помощью которого могут быть вызваны сервисы во время создания серверного объекта или при вызове серверного объекта. Сейчас интерсепторы активно используется в IoC-контейнерах в Spring и в Java EE.

2. Архитектуры платформ Java EE / Spring

Современные архитектуры серверных платформ (в частности, Java EE, Spring) прошли определенную эволюцию после CORBA.
В их состав добавились фреймворки:

• веб-фреймворк;
• IoC-контейнер;
• ORM-фреймворк.

CORBA ориентирована на использование протокола коммуникации клиента с сервером GIOP/IIOP. В настоящее время для коммуникации клиента с сервером используются протоколы HTTP, SOAP и REST (поверх HTTP).
Для обеспечения работы с протоколом HTTP в состав серверной платформы включается сервлет-контейнер. Сервлет-контейнер взял на себя только работу с протоколом HTTP и, по сути, не представил никакой программной модели для написания бизнес-логики. Код, написанный для сервлет-контейнера, изобилует зависимостями от протокола HTTP.
В связи с этим появились веб-фреймворки, которые выполняют задачи:

1. убирают зависимость кода с бизнес-логикой от протокола коммуникации;
2. вводят архитектурные паттерны для прикладных модулей (например, MVC), которые ускоряют разработку веб-ориентированных приложений;
3. управляют жизненным циклом объектов в областях видимости, имеющих место для веб-приложений.

Теперь про IoC-контейнер (Inversion of Control). IoC-контейнер решает следующую задачу: позволяет передать управление жизненным циклом любого объекта на сервере контейнеру, но при этом код бизнес-логики не будет зависеть от самого контейнера.
Важное место в составе платформы занял ORM-фреймворк для сохраняемых объектов. Почему я акцентирую внимание на этом очевидном факте? Практика показала, что данный фреймворк не должен обладать функциями контейнера (то есть управлять жизненным циклом сохраняемых объектов). Эта ошибка – Container Managed EJB Entity Beans — была допущена в EJB 2.0. Практика показала, что такое решение не прижилось.
Вот как это можно изобразить.

Типичная архитектура серверной платформы на базе Java

2.1. Java EE

В разделе, посвященном CORBA, выделены два важных конструктивных элемента, которые интенсивно используются в платформе Java EE – контейнеры серверных объектов и сервисы как составная часть серверной платформы.
Основными контейнерами в Java EE являются сервлет-контейнер, EJB-контейнер и IoC-контейнер, а среди основных сервисов: сервис транзакций JTS, сервис безопасности, JDBC, сервис именований JNDI, сервис сообщений JMS, сервис HTTP, management JMX.

Структура платформы Java EE

По сути, Java EE — наследник CORBA. Если кто сомневается, сделайте приложение с поддержкой Remote EJB, допустите ошибку при выполнении EJB и посмотрите на стек – увидите слова CORBA, poa (portable object adapter) и marshalling.

2.2. Spring

Spring – представитель той же архитектуры, что и Java EE (CORBA): активно используются контейнеры, сервисы и фреймворки.

Структура платформы Spring

Однако есть и различия:

1. Spring может разворачиваться отдельно либо на базе веб-сервера, который предоставляет сервлет-контейнер и базовые сервисы;
2. Spring поставляет в своем составе API для работы с необходимыми enterprise-сервисами, которые могут быть доставлены по мере использования.

2.3. Spring vs Java EE

Совершенно не хочу разводить “holy war” на тему Java EE vs Spring.
Бесспорно, Spring предоставляет программисту более инновационную программную модель.
На сессии Java EE and Spring Framework Panel Discussion на JavaOne 2012 было предложена следующая точка зрения: Spring – это инновации, Java EE – стандартизация. Инновации в технологиях должны доказать свое право на жизнь, а затем могут быть стандартизированы. Неудачное решение EJB 2.0 Entity Bean до сих пор портит мнение о технологии EJB, причина этой неудачи была в поспешной стандартизации технологии.

Фото с JavaOne 2012, Java EE and Spring Framework Panel Discussion

3. Java Enterprise без Java?

Описанные идеи, шаблоны, практики, которые составляют «Enterprise Edition», по сути не зависят от Java. Конечно, они работают на платформе Java, но имеют отдельную от Java ценность.
Можно ли сохранить эту ценность и при этом изменить язык программирования? Сначала логично было бы рассмотреть – а зачем менять язык?
Суммируя архитектуры из предыдущего раздела, хочу предложить следующий рисунок, в который добавлены компоненты бизнес-логики.

Анализируя данный рисунок, возникает следующий вопрос: должны ли компоненты бизнес-логики быть зависимы от языка, на котором реализована серверная платформа.
Если такая независимость возможна, это позволит сохранить все наработки, весь стек технологий серверной платформы, а также привнести инновации и все преимущества других языков, например, функциональных или языков с динамической типизацией. Из преимуществ других языков – лаконичность, замыкания, перегрузка операторов, интуитивный синтаксис для работы с коллекциями, функциональная парадигма программирования. Также динамические языки открывают путь к использованию DSL с Java EE.
Одновременно возникает вопрос о том, что серверная платформа должна быть открыта для инноваций. Возможно, некоторые из этих инноваций будет удобно сделать на другом языке программирования из-за характера решаемых ими задач.
С вопросом, зачем может понадобиться другой язык программирования, разобрались.

Теперь к вопросу – а как этого добиться?
Независимость серверных объектов от языка реализации серверной платформы была предложена еще в CORBA. Это достигалось стандартизацией платформы и использованием IDL (interface definition language) при написании серверных объектов. Однако жесткая стандартизация серверной платформы закрывает путь инновациям. В результате CORBA мало распространена при построении корпоративных систем.
Для того, чтобы найти решение, необходимо выйти за пределы предыдущего рисунка и поискать фундамент, на котором построена сама серверная платформа. Этот фундамент – JVM, см. рисунок ниже.

Если серверная платформа и бизнес-логика будут написаны на разных языках, которые выполняются на одной и той же JVM, то это позволит добиться целей:

1. сохраняет все существующие наработки серверных платформ;
2. позволяет обеспечить открытость серверной платформы для инноваций;
3. позволяет разрабатывать бизнес-логику и серверную платформу на разных языках.

Именно поэтому активно развивается направление Polyglot JVM.
Следующие примеры подтверждают сделанные выводы:

1. платформа Grails (на основе Groovy);
2. Django with Jython;
3. JSF + Groovy;
4. Spring + Groovy (http://www.ibm.com/developerworks/java/library/j-groovierspring1/index.html, http://habrahabr.ru/post/145158/).

Итак, использование Polyglot JVM достигает двух целей: открывает путь инновациям и позволяет сохранить все наработки в секторе корпоративных приложений.

4. Polyglot JVM

JVM всегда была отделена от Java и выполняла собственный набор инструкций – байткод. Программа, написанная на другом языке и скомпилированная в байткод, могла быть выполнена на JVM.
Однако до JDK 6 и JDK 7 это было возможно только для языков со статической типизацией.
Scala – язык со статической типизацией, появившийся в 2003 году – без проблем компилировался в байткод на основе существующего на то время набора инструкций для JVM.
Первый шаг для поддержки языков с динамической типизацией был сделан в JDK 6 — была добавлена библиотека Java Scripting API (javax.script.*). Однако это решение было частичным. Для того, чтобы скриптовый код работал, необходим был scripting engine для этого языка. Такое решение не отличалось производительностью, так как по сути выполнялась «двойная» интерпретация – сначала интерпретация скриптового кода с помощью engine-а, а потом интерпретация кода engine виртуальной машиной.
Настоящим «полиглотом» JVM стала в JDK 7 благодаря появлению новой инструкции для JVM invokedynamic, специально предназначенной для динамических языков. Благодаря этой инструкции производительность выполнения скриптового кода значительно улучшена.
На данный момент поверх JVM могут работать следующие языки: Java, Scala, JRuby, Groovy, Clojure, Jython и другие.
Для дополнительной информации порекомендую презентацию по языкам для JVM.

5. Альтернативные архитектуры и Polyglot JVM

Сейчас развиваются и другие серверные платформы, например, на основе event driven architecture (EDA), в частности, Akka (http://www.oraclejavamagazine-digital.com/javamagazine/20121112?pg=56#pg56).
Для платформ на основе EDA также применима идеология контейнеров и сервисов. Однако список сервисов для них должен быть пересмотрен и отличаться от списка сервисов CORBA/Java EE/Spring. Это красиво демонстрируется на примере сервиса распределенных транзакций. Использование событий вместо удаленных вызовов (RPC) позволяет добиться слабой связанности. Однако при таком подходе становятся непонятно, где устанавливать границы транзакции. Установка границ транзакции ведет к сильной связанности (http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html).
Таким образом, для EDA та же картина – наработки в области EDA имеют собственную ценность, и не зависят от языка программирования.
Традиционно Akka рассматривается в паре со Scala или Java. Однако есть прецеденты использования других языков, например Akka + Groovy (http://littlesquare.com/2012/02/playing-with-akka-groovy-rest-maven/).
Использование Polyglot JVM для EDA также позволяет сохранить наработки в технологиях и платформах и при этом использовать преимущества других языков.

6. Выводы

Технологии Java для корпоративных приложений бесспорно ценны. Благодаря Polyglot JVM можно сохранить все эти технологии и при этом открывается возможность использования новых языков в enterprise.
Итак, Polyglot JVM открывает путь инновациям и позволяет сохранить все наработки в секторе корпоративных приложений:

1. сохранить все существующие наработки серверных платформ для Java;
2. обеспечить открытость серверной платформы для инноваций;
3. разрабатывать бизнес-логику на языке, отличном от языка реализации серверной платформы, и привнести в разработку бизнес-логики все преимущества функциональных языков и языков с динамической типизацией;
4. позаботиться о финансовой стороне вопроса: использовать те языки, которые знает команда и не тратить время и деньги на переучивание.

Ух. Кажется, это все;-)

Автор: sirotae

Источник