Skip to content
April 23, 2012 / ahriman hpc mode

Разработка на Java для Windows Azure–что нужно учитывать

Итак, что нужно учитывать при разработке на Java для Windows Azure? Есть плагин для Eclipse (что уже очень большой прогресс), есть SDK, есть готовые наработки. Однако просто так взять и разработать приложение, может быть, и не получится – необходимо учитывать ряд особенностей платформы, которые могут быть и неочевидны.

Microsoft рассматривает язык программирования Java как first-class citizen на своей платформе Windows Azure. В целом я согласен с этим заявлением, потому что уже существующие предложения для размещения Java-приложений в облаке Microsoft позволяют разместить любое приложение. Попробуем рассмотреть “за” и “против” размещения Java-приложения в Windows Azure.

Почему вообще необходимо облако для нужд Java-приложения? Уже разработанные приложения могут быть достаточно сложными и иметь распределенную архитектуру, которая использует множество серверов, соответственно, то, что предлагает облачная платформа, подходит для этих нужд и, возможно, сулит экономические выгоды.

Web-приложения на Java и Windows Azure

Обычно веб-приложения на Java пишутся с использованием сервлетов, JSP, JSF и так далее. На мощностях Tomcat, JBoss, Jetty, GlassFish. Радостно видеть, что даже в плагине Windows Azure для Eclipse есть конфигурационные файлы, подготовленные отдельно для каждого из этих серверов приложений и контейнеров (не будем вдаваться в обсуждение, что из чего является чем). Кроме этого, у Microsoft уже заготовлены полезные готовые проекты с мануалами, так называемые Solution Accelerator – Windows Azure Tomcat Solution Accelerator и Windows Azure Jetty Solution Accelerator, например.

Распространенный вопрос про сохранение сессий и липкие сессии актуален и с Java—приложениями. Радость и тут – плагин позволяет делать липкие сессии. Вторым подходом является использование Atomus TomcatAzureSessionManager (сохраняющего сессию в хранилище таблиц Windows Azure)  и Windows Azure Sticky HTTP Session Router. Разработчику позволяется использовать модуль IIS Application Request Routing.

Что с хранилищем в Java-приложении?

Где хранить данные, если у нас есть Java-приложение? Есть несколько вариантов – это SQL Azure, реляционная СУБД на основе SQL Server 2008 R2 и наследующая большинство функциональности (и, всё же, не всей). Недавно JDBC Driver от Microsoft зарелизился в 3.0 версию и стал окончательно официально поддерживать SQL Azure. В целом, работа с JDBC Driver, SQL Azure и Java-приложением достаточно приятна и несложна. Если же есть уже готовая база данных и ее требуется перенести в облако, у Microsoft есть для этого средство – SQL Azure Migration Wizard. Позволяет переносить готовую базу данных в облако, будь она Oracle, MySQL или Access.

Вторым вариантом размещения данных являются сервисы хранилища Windows Azure. Windows Azure SDK for Java полностью поддерживает взаимодействие хранилища Windows Azure и Java, поэтому и тут не возникнет никаких проблем. Напоминание: сервисы хранилищ состоят из трех основных сервисов – блобы (дешевое и масштабируемое хранилище больших документов, которое может использовать Windows Azure Content Delivery Network для доставки контента ближе к пользователям), таблицы (масштабируемое и дешевое хранение нереляционных данных, аналог реляционных баз данных, но не позволяет хранить сколь-либо связные данные) и очереди (хранилище сообщений для осуществления коммуникации между ролями).

Таким образом, если вы не используете дополнительную функциональность платформы, вы можете легко разместить ваше приложение и управлять его масштабируемостью.

К недостаткам необходимо отнести:

Максимальный размер базы данных в SQL Azure – 150 гигабайт. Для определенной части приложений такого объема будет достаточно, но, если его станет мало, придется придумывать решение по масштабированию. В SQL Azure уже есть федерации, можно реализовывать шардинг – в целом, недостатком это является только потому, что придется делать это самому, а не дать на откуп платформе.

Отсутствие поддержки для Java сервиса кэширования.

Количество внешних портов-конечных точек входа для каждого экземпляра. Сейчас равно 25, раньше было всего 5 и это было действительно плохо, учитывая использование некоторыми функциональностями Java портов, этого может и не хватить (JMX и др.). Например, для Glassfish необходимо по умолчанию открыть 4 порта сразу же.

Java != Microsoft. Несмотря на то, что Java – first-class citizen на платформе, какой-то внятной поддержки от вендоров из мира Java можно и не дождаться – всё это только входит в моду.

Отсутствие шаблонов для Java Runtime и серверов приложений. В принципе, можно объединить с предыдущим пунктом. На платформе есть стандартные образа виртуальных машин, которые построены на основе Windows Server 2008 или Windows Server 2008 R2 различных билдов. Естественно, по умолчанию там нет Java Runtime и тем более каких-то серверов приложений. Есть некоторая возможность, и ходят слухи по Интернету, что может и появиться подобный шаблон, но это всего лишь слухи. В целом же развертывание приложения с Tomcat не занимает особо много времени и не вызывает трудностей. С Glassfish и JBoss немного сложнее, но опять же ненамного. Этот недостаток опять же очень сложно назвать недостатком – невозможно “объять необъятное”, невозможно иметь поддержку всех версий Tomcat и Glassfish, и при этом оставаться простой в освоении платформой. Кроме этого, ролевая модель Windows Azure и Startup-задачи позволяют выполнять любые настройки и установки при запуске экземпляра, в том числе производить любые настройки ваших серверов приложений. Microsoft не ставит никаких ограничений в этом контексте – Java-разработчику позволено выбирать, устанавливать и настраивать любые версии Java Runtime и серверов приложений. А с плагином Windows Azure для Eclipse всё вообще становится задачей внесения изменений в текстовый файл конфигурации.

Как видите, недостатков не так много. Надо обязательно упомянуть, что Microsoft активно работает над вопросами interoperability и Windows Azure, вероятно, является наиболее открытой ко всему миру IT платформой.

Выводы
Как уже было сказано выше, недостатков при разработке на Java на платформе Windows Azure не так много, как может показаться на первый взгляд. Да, необходимо пересматривать архитектуру проекта, предусматривать стоимость, масштабируемость, недостатки, преимущества, специфичные для Windows Azure настройки (брандмауэры SQL Azure, балансировщики нагрузки и так далее). Необходимо также четко понимать, нужно ли вообще переносить в облако свое приложение – но это уже универсальная задача, не специфичная для Java-приложений, так как, несмотря на преимущества и экономическую эффективность, для некоторых ситуаций облако может и не подойти. В целом же платформа Microsoft – ещё одна возможность для выполнения ваших приложений. А, учитывая явный интерес корпорации к interoperability с Java, Python… да, на самом деле, со всем, что сейчас реально популярно и не-.NET, эта возможность должна быть рассмотрена всерьёз.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: