Выработка долгосрочных стратегий использования платформы Java EE

Постоянное развитие технологий – неизбежный и полезный процесс, однако некоторые изменения могут повлиять на работу ваших приложений. В этой ситуации легко прийти к выводу о том, что рискованно полагаться на технологии, основанные на постоянно меняющихся спецификациях, подобных Java™ EE. Но негативные эффекты от изменений, нарушающих совместимость с предыдущими версиями, вполне можно минимизировать. Для этого необходимо тщательное планирование и осознанный выбор используемых технологий. В этой статье мы расскажем о том, как не ошибиться в выборе, а также о том, как IBM® может помочь минимизировать отрицательные последствия подобных изменений для вашей компании. Из журнала IBM WebSphere Developer Technical Journal.

Джим Кнутсон, проектировщик WebSphere J2EE, IBM

Джим Кнутсон (Jim Knutson) является разработчиком WebSphere J2EE. Джим отвечает за участие IBM в связанных с J2EE спецификациях. Джим также принимает участие в развитии программной модели для поддержки SOA и Web-служб.



28.11.2008

Введение

За свою историю платформа Java™ EE претерпела множество изменений, которые получали как позитивную, так и негативную оценку. Хотя по большей части эти изменения были продиктованы нуждами разработчиков ПО и потому в целом желательны для отрасли, были и такие, из-за которых терялась совместимость с ранее написанным кодом. Среди последних можно упомянуть как модификации API, которые являлись причиной ошибок при компиляции существующих приложений, так и изменения в моделях поведения, приводившие к ошибкам на этапе выполнения программ. Как и следовало ожидать, это раздражало тех, кто затратил существенные ресурсы (в том числе и финансовые) на разработку программного обеспечения, затронутого подобными ревизиями платформы.

В данной статье мы попробуем объяснить, как можно снизить риск появления проблем, связанных с недостаточной обратной совместимостью платформы Java EE. Кроме того, мы расскажем об усилиях IBM®, направленных на минимизацию подобных отрицательных последствий для вашей компании.


Причины потери совместимости

Изменения, нарушающие совместимость с предыдущими версиями, могут происходить по нескольким причинам. Члены экспертных групп, вовлеченных в работу над спецификациями, как правило, действительно пытаются выработать наилучший вариант, но они тоже люди, а следовательно - небезгрешны. Как бы они ни старались, всегда найдется что-то, ускользнувшее от их внимания:

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

    С этой проблемой отдаленно связана другая – недостаточное тестирование соответствия спецификации. Для обеспечения корректного поведения всех компонентов в соответствии со спецификациями был создан набор тестов Java EE Compliance Test Suite (CTS). Однако он не проверяет соответствие всем требованиям. В некоторых случаях создать тест невозможно или на разработку всех необходимых тестов просто не хватает ресурсов. Иногда бывает, что тесты удаляются из набора по причине их некорректной работы. При этом компания-разработчик может считать, что все тесты успешно пройдены, и не заметить несоответствие спецификации. Проблемы могут всплыть позднее, после добавления новых тестов в CTS, но к этому времени приложение уже может быть выпущено, поэтому любые изменения в поведении будут проблематичны. К тому же возможна ситуация, когда программное обеспечение успешно пройдет все тесты, но его поведение будет отличаться от других реализаций из-за различий в допущениях при интерпретации спецификации. В этом случае необходимы пояснения к спецификации, что обычно делается в рамках коррекционных релизов. Подобная корректировка может потребовать изменений в поведении ранее выпущенных программных продуктов, если их интерпретация отличается от скорректированной.

  • Другой причиной потери обратной совместимости является ускоренное добавление в платформу новых технологических решений. Одним из таких примеров может служить JAX-RPC, который появился в результате попытки быстро реализовать набор программных интерфейсов (API) для удовлетворения стремительно возрастающих потребностей отрасли в Web-сервисах. В дальнейшем, как только появился практический опыт и методики использования, стало ясно, что эти API изначально могли бы быть спроектированы значительно эффективнее и что было бы лучше полностью пересмотреть весь стек технологий и предоставить более совершенный набор программных интерфейсов.

    Похожим образом была одобрена модель развертывания приложений J2EE™ (J2EE deployment model). Изначальная версия оказалась настолько неудачной и неудобной для развертывания приложений, что не нашла серьезного применения. К счастью, эту конкретную технологию внедрило настолько незначительное число разработчиков, что большинство пользователей при отзыве или замене данной модели не должны пострадать.

  • Третьим источником нарушения обратной совместимости может быть недооценка самой проблемы. Несмотря на то что экспертные группы состоят из специалистов, работающих в области, для которой разрабатывается спецификация, были случаи, когда несовместимости проходили незамеченными или были недооценены. Разумеется, группы создаются для решения общих задач, но не нужно забывать, что при этом каждый из экспертов имеет собственные интересы, которые не всегда совпадают и не всегда согласуются с интересами всех пользователей платформы.

  • Далее следует проблема ограниченности ресурсов, выделяемых на обеспечение совместимости. Компании-разработчики компонентов платформы Java EE могли бы предоставить лучшие гарантии совместимости, проводя тестирование и отправляя отчеты о возникающих проблемах. Но для этого необходимо, чтобы компании получали в свое распоряжение работающие черновые варианты спецификаций, что, как показывает опыт, не всегда реализуемо на практике.


Усилия IBM по преодолению проблем несовместимости

IBM в курсе проблем, вызванных потерей обратной совместимости, и прилагает все усилия по их преодолению. Начиная со спецификации Java 5, IBM делает все возможное, чтобы сохранить обратную совместимость, причем как бинарную, так и на уровне исходных кодов. Sun™ всегда следила за сохранением бинарной совместимости, но в IBM пришли к выводу, что совместимость на уровне исходных кодов очень важна для поддержки приложений. Одним из результатов стало то, что новинки в спецификациях теперь сопровождаются данными о совместимости.

Разумеется, полностью описать все детали модели поведения практически невозможно, но IBM принимает участие во многих экспертных группах и высказывает свое мнение по всем проблематичным с нашей точки зрения моментам. В каких-то случаях нам удавалось предотвратить проблемы потери обратной совместимости, в каких-то нет.

Одним из успешных примеров стало прекращение развития JAX-RPC. Вместо дальнейших изменений в спецификации, которые вызвали бы проблемы с обратной совместимостью, началась работа над технологией следующего поколения – JAX-WS. Конечно, это не избавляет разработчиков от необходимости переходить на новые технологии в будущем, но по крайней мере устраняет ненужную спешку. Замораживание спецификации означает, что использование соответствующего API стратегически нецелесообразно, но не нарушает работу приложений, созданных с его применением. Сохранение инвестиций клиентов – это одна из главных целей, ради которых IBM участвует в экспертных группах по разработке стандартов.

С этими аспектами тесно связана проблема устаревания. IBM прикладывает усилия для сохранения моделей поведения ранее разработанных программ и API, а также обеспечивает их поддержку в более полном объеме, чем требует спецификация. В какой-то момент IBM объявляет, что некоторый элемент модели поведения или API является устаревшим (deprecated), и это говорит о том, что в будущих версиях данный элемент будет удален. Как правило, это происходит не ранее чем через два полных релиза продуктов IBM.

Были и отрицательные примеры. В частности, нам не удалось вовремя обнаружить несовместимости, вызванные различиями в интерпретации спецификации, описывающей требования к передаче транзакций между Web-компонентами. Этой проблеме примерно столько же лет, сколько и спецификации сервлетов. В итоге было решено добавить примечание, что использование функций, связанных с передачей транзакций, может затруднить портирование приложения. На данный момент неясно, окажет ли эта проблема влияние на поведение сервера приложений IBM WebSphere®.

За информацией о лучших методиках, планировании и других вопросах, связанных с переходом на различные уровни выпуска сервера приложений IBM WebSphere, можно обратиться к Web-сайту поддержки IBM..

Раннее внедрение новой технологии имеет как преимущества, так и недостатки. Одним из плюсов является то, что это позволяет оперативно отвечать на новые требования отрасли. Но при этом есть опасность заложить в спецификацию проблемы, которые при накоплении определенного опыта можно было бы своевременно обнаружить. IBM выступает за изменение политики добавления новых технологий в состав платформы Java EE. Принимая во внимание зрелость платформы, недопустимо включать в нее технологии, которые могут потребовать несовместимых изменений в API или в поведении отдельных компонентов уже в следующем релизе. Крайне желательно предоставить так называемый инкубационный период – отрезок времени, за который технологию можно усовершенствовать или убедиться в ее достаточной зрелости. За это время компании-разработчики могут выпустить реализацию технологии, находящейся в процессе созревания, с оговоркой, что в будущем возможны изменения, причем возможна потеря совместимости. Но как только технология становится частью платформы Java EE, она обязана развиваться разумно и сохранять обратную совместимость. На данный момент в экспертной группе Java EE существуют разногласия по поводу этой позиции. Мы призываем вас – как пользователя платформы Java EE – высказать свое мнение по этой проблеме, если какой-либо из вариантов решения кажется вам предпочтительным. Это можно сделать, связавшись непосредственно с группой, занимающейся вопросами стандартизации Java EE, или даже с автором данной статьи.

С того момента как IBM начала выступать за сохранение совместимости, этой проблеме стало уделяться повышенное внимание. Большее число членов экспертных групп начали серьезно относиться к вопросам совместимости, а сами эти вопросы стали описываться в спецификациях значительно детальнее. Это, конечно, не означает, что мы застрахованы от потери совместимости в будущем: просто и разработчики спецификаций, и члены экспертных групп будут тщательнее анализировать возможные последствия перед тем, как вносить изменения, нарушающие совместимость. К тому же эти случаи будут отражены в документации, чтобы пользователи имели необходимую информацию.

Пока еще не все убеждены в том, что совместимость на уровне исходного кода не менее важна, чем бинарная. Возможны разные случаи. В некоторых грамотно спроектированных технологиях интерфейсы можно развивать без изменения использующего их исходного кода. В других - разработчики вынуждены идти на несовместимые изменения в интересах развития. IBM прилагает усилия к тому, чтобы технологии проектировались правильно, но нам нужна помощь сторонних разработчиков и компаний, потому что невозможно уследить за всем сразу. Все спецификации проходят стадию проекта, в течение которой разработчики, и вы в том числе, могут высказать свое мнение.


Как пользователи могут повлиять на ситуацию

В дополнение к усилиям, прилагаемым IBM, вы тоже имеете возможность повлиять на ситуацию и снизить негативные последствия, вызванные потерей обратной совместимости:

  • Примите участие в работе над спецификациями. Не будет ничего плохого, если еще один человек примет участие в обсуждении предлагаемых изменений. Это гарантирует также, что ваши проблемы и потребности будут услышаны. Спецификация Java EE 6 сейчас находится на этапе рассмотрения и исправления недочетов, скоро ожидается выход предварительного варианта. Это будет прекрасная возможность для того, чтобы ознакомиться с изменениями и оценить их возможное влияние на ваши приложения в том случае, если эти изменения войдут в окончательную версию спецификации.

  • Полагайтесь только на стабильные спецификации и их части. Например, спецификация сервлетов появилась достаточно давно и не претерпевала кардинальных изменений. Фильтры сервлетов были предложены значительно позднее, а сервисы JAX-WS появились только что. Справедливо полагать, что риск будущих несовместимых изменений гораздо выше в случае использования новых технологий.

  • Следите за тенденциями в отрасли. Если какая-то область приковывает к себе повышенное внимание, то, вероятно, соответствующая технология будет развиваться. Примерами могут служить Web-сервисы и SOA, поэтому, скорее всего, технологии, лежащие в этой области, будут претерпевать изменения. Насколько будет сохраняться совместимость – зависит от всех участников процесса, хотя со своей стороны IBM сделает все возможное, чтобы она сохранялась.


Настоящие и будущие технологии Java EE

Далее мы рассмотрим отдельные составляющие платформы Java EE и то, насколько они могут быть подвержены изменениям:

Уровень представления

  • Сервлеты

    К данному моменту времени сервлеты представляют собой достаточно стабильную, зрелую и хорошо изученную технологию. В будущем ее не ожидают серьезные изменения, за исключением продиктованных требованиями Web 2.0. Разумеется, отсутствие серьезных изменений не означает, что изменений не будет вообще:

    • В спецификации Java EE 5 были решены некоторые проблемы, связанные с удобством использования, благодаря возможности включать метаданные в исходный код компонентов. Это пока не нашло должного отражения в спецификации сервлетов, поэтому ожидается, что это случится в будущем. Но эти изменения только добавят новые формы метаданных и не затронут поведение.

    • Другим серьезным новшеством Java EE 5 стала интеграция языка выражений между JavaServer™ Faces и JavaServer Pages. Однако она изначально проектировалась с учетом требования обратной совместимости и поэтому не должна приводить к сколько-нибудь серьезным проблемам.

    • Одним из возможных будущих изменений являются области видимости метаданных. Как правило, сервлеты объявляют метаданные на уровне модуля и делают их доступными для всех Web-компонентов. Компоненты EJB объявляют метаданные на уровне компонента. В будущем планируется развитие обоих подходов, что обеспечит поддержку сразу двух типов областей видимости метаданных. Но это не должно привести к потере совместимости, так как существующие на данный момент области видимости будут поддерживаться и далее.

    • Другой возможной новинкой могут стать программные интерфейсы для динамического описания поведения вместо декларативного. Похоже, что SOA стимулирует прогресс в данной области, и вполне вероятно, что в какой-то момент времени все технологии станут поддерживать как декларативную, так и программную модели поведения (некоторые из них уже поддерживают). В большинстве случаев это не должно сказаться на совместимости. Единственным исключением может оказаться добавление методов в интерфейсы, которые должны реализовываться приложениями. Но, учитывая текущие тенденции к использованию аннотированных методов вместо интерфейсов, это не должно стать серьезной проблемой.

  • JavaServer Pages (JSP) и стандартная библиотека Java-тегов (JSTL)

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

  • JavaServer Faces (JSF)

    JSF – это сравнительно новая технология, для которой в настоящий момент продолжается работа по подготовке следующей версии спецификации. При этом ожидается интеграция между управляемыми объектами JavaBean в JSF и объектами EJB (Enterprise JavaBeans™). Таким образом, риск негативного влияния изменений для приложений, использующих JSF, больше, чем для приложений, в которых применяются другие технологии представления. У IBM есть представительство в экспертной группе JSF, и мы будем внимательно отслеживать потенциальные проблемы.

    Одним из проблемных вопросов остается то, насколько строго поддержка Ajax в JSF будет соответствовать спецификациям OpenAjax Alliance. Участвуя в работе над JSF, IBM сделает все возможное, чтобы совместимость не была потеряна в процессе развития стандартов. В любом случае какое-то время после появления поддержки Ajax в JSF использовать эту возможность будет более рискованно, чем другие функции JSF. Многое должно проясниться к началу 2009 г.

  • Портлеты

    Несмотря на то что портлеты не являются частью платформы Java EE, сервер приложений IBM WebSphere V6.1 предоставляет возможность их использования. Спецификация портлетов в настоящее время находится в состоянии разработки новой версии, но IBM руководит работой над этой спецификацией и имеет возможность контролировать эволюцию данной технологии.

    Версия 2.0 претерпела существенные изменения по сравнению с 1.0. В спецификацию портлетов добавлены новые возможности, опущенные в версии 1.0, такие как координация предоставления ресурсов. В целом новая спецификация выглядит более зрелым стандартом, чем 1.0. Изменения в последующих версиях будут, скорее всего, обусловлены изменениями в других спецификациях внутри Java EE, например выходом Servlet 3.0 или JSF 2.0, но маловероятно, что они будут включать серьезные новшества в функциональности самих портлетов.

    На момент написания этой статьи версия 2.0 казалась полностью совместимой с 1.0 как бинарно, так и на уровне исходных кодов. При этом ожидается, что будут добавлены специальные ключи для контроля над аспектами поведения портлетов, неполно описанными в версии 1.0, но специфицированными в 2.0. Уверенно говорить о реальной обратной совместимости можно будет после того, как работа будет закончена и технология протестирована.

Бизнес-логика

  • Enterprise JavaBeans (EJB)

    В прошлом изменения, вносимые в спецификации EJB, делались без потери совместимости. При этом в версии 3.0 был серьезно изменен синтаксис программной модели EJB. Тем не менее прошлые программные модели – из версий 2.1 и более ранних – по-прежнему поддерживаются. Даже программная модель версии 3.0 осталась обратносовместимой, что позволяет реализовывать клиентские и серверные компоненты на различных версиях спецификации.

    • Сессионные объекты на данный момент достаточно стабильны, и фундаментальных изменений их поведения не предвидится, хотя некоторые новые функции могут появиться.

    • Также не должно быть изменений в объектах, управляемых сообщениями (message-driven beans).

    • Часть спецификации, отвечающая за CMP/BMP-сохранение, достаточно стабильна, но ее могут заменить новые программные интерфейсы JPA (Java Persistence APIs) в случаях, когда требуется сохранение данных в реляционных базах данных, и архитектура JCA (Java EE Connector Architecture) в остальных случаях.

    • Одним из возможных серьезных изменений в следующей версии спецификации может стать интеграция сессионных объектов с объектами, управляемыми сообщениями. Таким образом, появится новый тип компонентов, которые могут взаимодействовать как по синхронной, так и по асинхронной схеме. Но на данный момент все говорит о том, что развитие технологии будет происходить разумно и без потери совместимости.

Уровень сохранения данных

  • JDBC

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

  • Java Persistence API (JPA)

    JPA – это технология, являющаяся частью платформы Java и рассматриваемая в качестве кандидата на замену объектно-реляционного отображения CMP в EJB. Это достаточно новая технология, находящаяся в фазе активного развития. Но благодаря использованию опыта различных производителей, таких как Hibernate, TopLink и Kodo, риск утраты совместимости несколько снижается. JPA позволяет абстрагироваться от некоторых моментов JDBC, зависящих от используемого сервера базы данных.

Интеграция

  • Служба сообщений Java (Java Message Service – JMS)

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

  • Архитектура коннекторов Java EE (Java EE Connector Architecture)

    Архитектура коннекторов Java EE уже некоторое время остается стабильной, но существует ряд проблем, которые планируется решить в следующей версии спецификации. В настоящее время нет функций, реализующих переключение при отказе (failover), а также входящую и исходящую целостность, поэтому разработчикам приходится полагаться на расширения технологии. Изменения в спецификации, направленные на решение этих проблем, не должны привести к утрате совместимости, но могут затронуть самостоятельно созданные адаптеры ресурсов. Адаптеры, поставляемые и поддерживаемые сторонними разработчиками, должны будут самостоятельно решать все сложности, связанные с изменениями в спецификации.

  • JavaMail и технология активации объектов JavaBean (JavaBeans Activation Framework – JAF)

    Развитие JavaMail не привлекает к себе внимания, возможно потому, что ее использует меньшее число разработчиков, чем, например, сервлеты или EJB. Архитектура JavaMail содержит относительно много классов, которые могут быть затронуты в будущих версиях. Это усложняет внесение изменений с сохранением совместимости на уровне исходного кода. При этом сама технология выглядит достаточно стабильной, и изменений на данный момент не предвидится. JAF используется для работы с форматом MIME и в целом считается не менее стабильной, чем JavaMail.

  • Java API для удаленного вызова процедур на основе XML (Java API for XML-based RPC – JAX-RPC)

    Скорее всего, в Java EE 6 технология JAX-RPC будет объявлена устаревшей, поэтому в новых проектах придется выбирать между:

    • JAX-RPC – стабильной технологией, которая не охватывает некоторые ситуации и скоро будет заменена, и
    • JAX-WS – новой технологией, хотя и подверженной изменениям в будущем, но отражающей общие тенденции развития этой области.
  • Java API для Web-сервисов XML (Java API for XML Web Services – JAX-WS)

    JAX-WS – это набор интерфейсов второго поколения для Web-сервисов, призванный заменить JAX-RPC. JAX-WS изначально позиционировалась как новая технология, поэтому не пришлось заниматься проблемами обратной совместимости, что значительно усложнило бы работу над спецификацией. Эволюция JAX-WS сопровождалась другими трудностями, вызванными решениями комитетов стандартизации W3C, которые привели к тому, что некоторые требования были исключены из спецификации. Сама область Web-сервисов, скорее всего, продолжит бурно развиваться. В настоящее время есть стремление стандартизировать характеристики качества обслуживания Web-сервисов, такие как, например, надежная передача сообщений или поддержка транзакций. Вдобавок особое внимание уделяется JSR 311, описывающему RESTful Web-сервисы. Все эти дополнения появились сравнительно недавно и, скорее всего, будут меняться по мере накопления опыта их использования.

    В смысле зрелости опыт JAX-RPC оказался очень полезным при работе над JAX-WS. Уроки, усвоенные после выпуска JAX-RPC, помогли разработать достаточно эффективную и зрелую спецификацию JAX-WS. Включение JAX-WS и JAXB в состав Java SE 6 (в JDK/JRE) будет способствовать их дальнейшей стабилизации.

  • Архитектура Java для привязки к XML (Java Architecture for XML Binding – JAXB)

    JAXB – это также достаточно новая технология, являющаяся развитием JAXB 1.0. Благодаря предыдущему опыту, а также опыту, полученному в результате использования JAX-RPC и включения JAXB в новый стандарт JAX-WS, второй релиз JAXB выглядит значительно более стабильной и совместимой технологией. Несмотря на то что разработчики сохранили прежнее название, ее реализация и значительная часть функциональности были серьезно переработаны с учетом прошлых недостатков. JAXB, скорее всего, будет развиваться и дальше, по мере того как в платформу Java будут добавляться новые и новые средства для согласованного отображения между объектами Java и другими представлениями, использующимися, например, в различных протоколах при маршаллинге или при сохранении данных. На данный момент ожидается, что добавление подобных средств не приведет к потере обратной совместимости.

  • Java API для SOAP с вложениями (SOAP with Attachments API for Java – SAAJ)

    SAAJ – это достаточно стабильный способ представления сообщений Web-сервисом. С первого выпуска и до текущего момента в нем были сделаны лишь незначительные изменения, за исключением перехода на стандартный интерфейс DOM API.

  • Java API для XML-реестров (Java API for XML Registries – JAXR)

    JAXR – это еще один пример технологии, которая вошла в состав платформы Java EE преждевременно. JAXR создавалась в качестве абстрактного слоя над UDDI V2 и ebXML V2, но практически в то же время появились третьи версии этих технологий, в результате чего JAXR оказалась несколько устаревшей с самого начала. Эта область продолжает развиваться, поэтому следующая версия JAXR также может оказаться устаревшей уже к моменту выпуска. Как только прогресс в данной области немного стабилизируется, JAXR, скорее всего, будет либо радикально изменена, либо заменена другой технологией.

Другие технологии

  • Технология для управления приложениями Java EE (Java EE Management)

    Данная технология была и, вероятно, будет оставаться достаточно стабильной.

  • Технология для развертывания приложений Java EE (Java EE Deployment)

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

  • Служба аутентификации и авторизации в Java (Java Authentication and Authorization Service – JAAS)

    JAAS предоставляет базовые сервисы для обеспечения безопасности на платформе Java EE. Сама спецификация стабильна, но известно, что существуют несоответствия между разными реализациями JAAS в том, что касается передачи субъектов (subject propagation). В будущем ожидаются попытки уточнить этот момент в спецификации, чтобы исключить разногласия.

  • Соглашения об авторизации для Java-контейнеров (Java Authorization Contract for Containers – JACC)

    В JACC требуется внести изменения для работы с объявлениями через аннотации. Эти изменения продиктованы новшествами в Java EE 5, в которую была добавлена возможность объявления метаданных с помощью аннотаций. Скорее всего, разработчики JACC 1.0 не смогут обеспечить необходимое поведение, используя доступные на данный момент аннотации, но приложения, пока не применяющие аннотированные объявления, не должны испытывать трудности с совместимостью в будущем.

Будущие технологии

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

  • RESTful-сервисы (JAX-RS)

    В данной области разработчики пришли к соглашению, что создавать формальное описание Web-сервиса для слабо связанных сервисов не всегда эффективно. Технология JAX-RS – это новый подход к данной проблеме, и пока еще не накоплен достаточный опыт ее применения. Логично предположить, что по мере выработки методологии ее использования сама технология будет серьезно меняться.

  • WebBeans

    Прототип спецификации Java EE 6 содержит новую технологию под названием WebBeans. Изначально она проектировалась в целях интеграции управляемых объектов JSF и объектов EJB, но постепенно трансформировалась в отдельную компонентную модель, призванную включить в себя многие другие компонентные модели. Пока опыта использования крайне мало (хотя WebBeans первоначально планировалось испытать на JBoss Seam, этот проект пошел значительно дальше). Наиболее близким примером может служить многолетний процесс работы над первой версией спецификации SCA – также компонентной модели, содержащей множество других моделей. В общем, все говорит о том, что спецификация WebBeans будет существенно меняться, если только серьезно не сузить область применения данной технологии.

  • Timer и Workmanager

    Эти технологии призваны реализовать уровни сервиса корпоративного класса в асинхронных (т.е. потоковых) моделях программирования. Они основаны на результатах совместной работы IBM и BEA (CommonJ). Уровень риска для них относительно невысок благодаря наличию реализаций данных технологий от разных поставщиков, но в то же время в этих спецификациях организация параллелизма потоков в API была перебазирована на библиотеку Java Concurrency Utilities. Время покажет, будет ли это решение воспринято отраслью или потребуются дополнительные изменения. В любом случае риск при использовании Timer и Workmanager, скорее всего, ниже, чем при использовании WebBeans. Наилучшим решением с точки зрения долгосрочной стабильности и совместимости будет применение предоставляемых сервером приложений IBM WebSphere интерфейсов асинхронных объектов (Asyncronous Beans API) по крайней мере до тех пор, пока эти спецификации не стабилизировались.


Заключение

Не существует никакого волшебного способа точно определить, стоит ли использовать ту или иную технологию или функциональность платформы Java EE. Индустрия постоянно развивается, и это накладывает свой отпечаток на платформу. Но, несмотря на это, можно делать осмысленный выбор в пользу какой-либо технологии. Надеемся, что информация, приведенная в нашей статье, поможет вам принимать подобные решения в будущем.


Благодарности

Автор благодарит Дану Даффилд (Dana Duffield), Грега Трати (Greg Truty), Кевина Саттера (Kevin Sutter), Максима Мольденхауэра (Maxim Moldenhauer), Петра Пржибыльского (Piotr Przybylski), Рэнди Шнайера (Randy Schnier), Стефана Хеппера (Stefan Hepper) и Стивена Кенну (Stephen Kenna) за их вклад в написание этой статьи.

Ресурсы

Научиться

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • developerWorks Premium

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

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Технология Java
ArticleID=355222
ArticleTitle=Выработка долгосрочных стратегий использования платформы Java EE
publish-date=11282008