Oracle WebLogic Server: Надежный фундамент для сервис-ориентированной архитектуры

ВВЕДЕНИЕ

Сервис-ориентированная архитектура ( Service - oriented Architecture - SOA ) вызвала революцию в ИТ. Развертывание сбалансированных функциональных пакетов программного обеспечения как слабосвязанных, крупномодульных сервисов обеспечивает в значительной степени повышенную гибкость приложения, позволяя предприятиям непрерывно адаптировать целые созвездия сервисов, обеспечивая возможность ИТ идти в ногу с бизнес-целями.

Корпорация Oracle - лидер, помогающий предприятиям понимать и реализовывать преимущества SOA на базе Java . Применяя Oracle WebLogic Server , базирующийся на Java Platform Enterprise Edition 5 ( Java EE 5), корпорация Oracle предоставляет надежный фундамент для SOA . Сервер Oracle WebLogic Server - это чрезвычайно удобный в использовании продукт, готовый к использованию сразу же после установки, обеспечивающий надежность, доступность, масштабируемость и производительность индустриального масштаба. Заказчики могут быстро провести обновление существующих сервисов и управлять ими с помощью мощных инструментальных средств конфигурирования, развертывания и управления. Они могут также провести интеграцию с другими продуктами Oracle Fusion Middleware и использовать квалификацию своих разработчиков в работе с такими технологиями работы с открытыми исходными текстами как, например, Spring Framework .

В этой статье рассматривается вопрос существенного ускорения разработки SOA-приложений с применением Java EE 5, и как корпоративные разработчики могут применить ее возможности, используя Oracle WebLogic Server .

ORACLE и JAVA PLATFORM ENTERPRISE EDITION 5

Одной из последних инноваций Oracle стала Java-платформа Enterprise Edition 5 ( Java EE 5 ). В этом стандарте обеспечиваются радикальные усовершенствования бизнес-логики и персистентности объектов. Спецификация Enterprise JavaBeans ( EJB ) 3.0 упрощает программирование богатой бизнес-логики, в то время как интерфейс Java Persistence API ( JPA ) облегчает возможность подключения этой логики к соответствующим хранимым данным. Усовершенствования стеков Web-сервисов и Web -приложений делают компоновку из сервисов требуемых приложений более простой, чем когда-либо прежде. В целом Java EE 5 упрощает разработку SOA , не принося при этом в жертву мощность.

Как показано на Рис. 1, Oracle сыграла важную роль в усовершенствования Java EE 5, рассматривая требования заказчиков и идентифицируя потребность в упрощении. Далее, специалисты Oracle внесли определяющий вклад в разработку спецификаций EJB 3.0, а также в усовершенствование обработки Web-сервисов через такие механизмы, как Streaming API для XML . Важнее всего, что Oracle была первым коммерческим поставщиком, предоставившим готовую к промышленной эксплуатации реализацию Java EE 5 - Oracle WebLogic Server .

Рис.1: Новые средства для повышения производительности разработчиков в Java EE 5

Существующие заказчики Oracle WebLogic Server уже оценивают обязательства Oracle поддерживать стратегически важные инициативы SOA . Однако последняя версия Oracle WebLogic Server предлагает даже больше, чем эта проверенная платформа: заказчики могут быстрее строить сервисы, легче компоновать и более эффективно управлять ими. Для организаций, которым нужны функциональные возможности производственного уровня, это решение является очевидным выбором как самая современная, надежная и мощная SOA -платформа на базе Java .

Рис. 2: Oracle WebLogic Server

ЛУЧШАЯ БИЗНЕС_ЛОГИКА для SOA

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

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

Во многих случаях более ранние версии EJB оказались слишком сложными для поддержки такого подхода. API выставлял на показ слишком многие из механизмов, необходимых для гарантирования надежного выполнения процессов домена. Построение эффективных моделей домена обычно требует многих проходов по всему циклу разработки прототипа, тестирования и усовершенствования. Тот факт, разработчикам в течение этого цикла приходилось беспокоиться о лежащей в основе "внутренней начинке", делало EJB слишком громоздкими для многих проектов.

Напротив, в EJB 3.0 разработчики полностью изолированы от "внутренней начинки". В значительной степени EJB могут быть обработаны как обычные объекты Java , что в значительной степени упрощает разработку. При таком упрощенном подходе разработчики могут, наконец, использовать EJB для реализации широкого разнообразия моделей доменов, которые поддерживают корпоративные сервисы верхнего уровня.

EJB 3.0 устраняет рутинные операции

Изменения в EJB 3.0 прежде всего направлены на то, как разработчики взаимодействуют с утилитами контейнеров. За исключением персистентности, эти изменения несущественно затрагивают сами по себе утилиты.

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

Второй значительной рутинной операцией было написание в интерфейсе присваивания имен Java и каталога ( Java Naming and Directory Interface - JNDI ) поиска для приобретения ссылок на ресурсы. В насыщенных доменных моделях, естественно, имеется много отношений между элементами. Для каждого отношения, так же как и для любой ссылки на ресурсы инфраструктуры, требуется составлять код поиска.

В EJB 3.0 обе эти рутинные операции устранены. Разработчики пишут EJB как простые старые объекты Java ( Plain Old Java Objects - POJO ). Они взаимодействуют с утилитами контейнеров, добавляя к коду POJO простые, декларативные аннотации. Контейнер заботится о необходимых рутинных операциях, позволяя разработчикам сосредоточиться на построении моделей домена.

Работу делают аннотации

Как уже упоминалось, аннотации - это ключевая инновация, которая повышает квалификацию разработчиков EJB 3.0. В корпорации Oracle помогали "пионерским" аннотациям и работали над тем, чтобы расширить их использование в рамках Java EE . Если разработчик может однозначно определить, что именно должно быть сделано, то почему бы не позаботиться об этом автоматически? Например, предположим, что разработчик, работающий в домене обработки ссуд, хочет написать клиентскую часть для несохраняющего своего состояния компонента сеанса, который выполняет обработку ссуды. Вместо полной реализации интерфейса и кода поиска JNDI , как это было необходимо в предыдущих версиях EJB , теперь разработчик может просто написать

import loanprocessor.LoanProcessor

@Stateless public class LoanProcessorClient {

@ Inject LoanProcessor

…

}

Примечание @ Stateless занимает место ручного определения удаленного интерфейса, в то время как примечание @ Inject занимает место ручного поиска JNDI .

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

Упрощены описатели развертывания

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

В большинство промышленных реализаций, например, в Oracle WebLogic Server , были включены инструментальные средства для генерации описателей развертывания и помещения этих описателей в правильное местоположение. Но они стали для разработчиков еще одним камнем преткновения, требующим их внимания, вместо того, чтобы заниматься деловыми проблемами. В EJB 3.0 описатели развертывания являются опциональными. Разработчик может написать любой тип EJB и выполнить его без описателя, с аннотациями и рядом значений по умолчанию, предлагающих достаточно информации для выполнения EJB . А разработчик, которому действительно хочется определить описатель, должен определить только те их входы, которые отменяют значения по умолчанию. В EJB 3.0 для реализации сложного сервиса, в котором используется группа сотрудничающих EJB , требуется гораздо меньшее количество файлов, в каждом из которых имеется гораздо меньшее количество входов.

В Oracle WebLogic Server реализован EJB 3.0 with Pitchfork

Добавляя Pitchfork к Oracle WebLogic Server , контейнер EJB создает лучшее в своем классе решение: проверенный контейнер промышленного калибра и усиливающую производительность инфраструктуру.

Как было отмечено ранее, EJB 3.0 не изменяет значительно утилиты, обеспечиваемые контейнерами EJB ; напротив, он просто делает эти утилиты намного более легкими для использования. В Oracle WebLogic Server EJB 3.0 реализована как расширение его проверенного контейнера, обеспечивающего интеллект, необходимый для выполнения более упрощенных EJB путем трансляции аннотаций в конкретные команды и разрешения декларативно определенных зависимостей.

Для создания этого расширения в Oracle была проведена совместная с разработчиками инфраструктуры с открытыми исходными кодами Spring Framework работа по созданию Pitchfork - специальной версии популярной инфраструктуры Spring , которая помогла первопроходцам упростить разработку приложений Java с помощью внедрения зависимости (dependency injection). Добавляя Pitchfork к Oracle WebLogic Server, контейнер EJB создает лучшее в своем классе решение: проверенный контейнер промышленного калибра и усиливающую производительность инфраструктуру.

Два побочных эффекта такого подхода - обратная совместимость ( backward compatibility ) и предусмотрительность ( forward thinking ). Поскольку Pitchfork выступает как брокер между кодом EJB 3.0 и традиционными утилитами контейнера, Oracle WebLogic Server полностью обратно совместим с EJB 2.1. Компоненты EJB просто обходят Pitchfork и непосредственно используют утилиты контейнера. И заказчики могут совместно эксплуатировать и EJB 3.0, и EJB 2.1. В дополнение к обратной совместимости Pitchfork облегчает предусмотрительность. Многие разработчики приняли продвинутые подходы программирования, типа аспектно-ориентированного программирования с использованием Spring . В Pitchfork те же самые подходы разрешены для EJB 3.0.

УПРОЩЕННАЯ ПЕРСИСТЕНТНОСТЬ ДЛЯ SOA

Благодаря избавлению разработчиков от сложностей, EJB 3.0 позволяет им сосредоточиться на построении репрезентативных моделей домена. Следующей проблемой является персистентность. Для выполнения бизнес-процессов требуется управление данными записи. Все объекты " заявка на получение ссуды ", " заказчик " и " заказ ", упоминавшиеся ранее как примеры, имеют представления Java , которые выполняются в контейнере EJB . Однако для выполнения реальной работы требуется загрузка и сохранение соответствующих представлений, сохраненных в хранящихся на сервере базах данных, что служит гарантией того, что существует только одна " истинная " копия каждого детализированного модуля данных, и что различные сервисы, управляющие одними и теми же модулями данных, не вредят друг другу.

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

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

Опираясь на опыт использования полей большого размера, Oracle WebLogic Server включает Oracle Kodo , который полностью интегрирует как JPA , так и Java Data Objects ( JDO ). Используя Oracle WebLogic Server , разработчики могут выбрать оптимальный механизм для специфических доменных моделей.

Поддержка JPA и JDO

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

Интерфейс JPA разрешает все эти недостатки. Разработчики просто предлагают аннотации к коду, инструктирующие контейнер, как следует обращаться к соответствующим данным реляционной базы данных. Аннотация @ Id перед рядом методов доступа определяет первичный ключ. Есть даже аннотации для определения сложных ключей. Аннотация @ OneToMany перед определением коллекции определяет отношение " один ко многим ". Для отношений " многие ко многим " аннотация @JoinTable предлагает средства создания таблицы объединения. Более сложные аннотации, типа @ Transaction и @ NamedQueries , включают большой набор атрибутов для точного управления специализированными взаимодействиями с реляционными базами данных.

Интерфейс JPA делает больше, чем только упрощение возможностей опции персистентности из EJB 2.1. Он также включает весьма необходимые усовершенствования. Важнее всего, что разработчикам больше не нужно определять методы жизненного цикла для компонент-сущностей EJB. Контейнер автоматически обеспечивает для управления жизненным циклом экземпляров объект EntityManager. Также JPA дает Java -классам возможность определить стратегии для обработки наследований при отображении в базу данных. По сравнению с языком запросов EJB из версии 2.1, в язык запросов JPA включено несколько новых опций, например, операции массовой обработки данных, внешние соединения и подзапросы.

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

Несмотря на усовершенствования JPA , многие разработчики все еще предпочитают использование JDO . Поскольку JPA сосредоточен на персистентности реляционной базы данных, он выбирает реляционный стиль. При работе с расширенными объектно-ориентированными моделями привлекательным может показаться более объектно-ориентированный синтаксис JDO . Во многих случаях выбор является только вопросом вкуса. При использовании Oracle WebLogic Server разработчики могут применять управляемую контейнером персистентность с JPA или персистентность управления компонентами сеанса с JDO . Хотя JPA и JDO разделяют большую часть основных функциональных возможностей, у каждой из них имеются функциональные возможности, которые отсутствуют у другой. Сервер Oracle WebLogic Server предлагает расширения к обоим API, которые делают их функционально эквивалентными. Разработчики не должны жертвовать функциональными возможностями, выбирая тот или другой интерфейс.

Высокопроизводительная реализация

Обязательства Oracle по построению высокопроизводительных сервисов на Java EE 5 идут дальше предоставления разработчикам возможности выбора API персистентности. Сюда включается обеспечение высокой производительности - независимо от того, какую альтернативу предпочтет разработчик.

Как уже упоминалось, один и тот же самый механизм персистентности выполняет как функции JPA , так и функции JDO.

В Oracle Kodo включен длинный список возможностей промышленного уровня. Возможно, самая большая проблема в обеспечении персистентности для бизнес-сервисов верхнего уровня заключается в поддержке больших, выполняющихся длительное время транзакций. Завершение значительного шага бизнес-процесса может привести к обширным обновлениям во многих различных фрагментах данных. В Oracle Kodo поддерживаются транзакции неограниченного размера. Для гарантии координации сложных бизнес-процессов могут потребоваться транзакции, выполнение которых продолжается в течение многих минут, часов или даже дней. С помощью Oracle Kodo можно эффективно управлять подключениями к источникам данных на всем продолжении таких долго выполняющихся транзакций.

ORACLE TOPLINK

В сервер Oracle WebLogic Server также включена и альтернативная высокопроизводительная технология персистентности - Oracle TopLink. Это решение является релизом коммерческого калибра и надмножеством технологии TopLink Essentials.

Oracle , как лидер в создании совместной спецификации для новой спецификации EJB 3.0/JPA, помогала в проектировании и обеспечивала руководство архитектурой для новой спецификации JPA . Кроме того, корпорация Oracle внесла свой вклад в код TopLink Essentials для эталонной реализации JPA . Теперь TopLink Essentials стала технологией с открытым исходным текстом.

Когда она поставляется вместе с Oracle WebLogic Server , в состав Oracle TopLink входят функциональные возможности продвинутого объектно-реляционного проектирования ( ORM ), превосходящие то, что обычно включается в TopLink Essentials . Это - скоординированное кэширование для поддержки развертывания кластеризованых приложений и дополнительная ненавязчивая оптимистическая политика блокировки. В Oracle TopLink предлагается независимая от платформы поддержка хранимых процедур и функций; она делает возможной историческое отображение и запросы по состоянию на определенный момент времени. Компоненты модели EJB под управлением Java Management Extensions ( JMX ) (так называемые MBeans ) учитывают управление и мониторинг сеансов Oracle TopLink и их кэшей. При работе в среде Oracle Database , Oracle TopLink обеспечивает следующие возможности:

• Виртуальная приватная база данных
• Отображения XML -типа и генерация запросов SQLX
• Подсказки
• Иерархические запросы
• ORM , массивы, структуры, объектные ссылки и вложенные таблицы
• Направления бизнеса заказчиков, отметки времени и двухбайтовые типы данных

И, наконец, Oracle TopLink поддерживает отображения в управленческие информационные системы, используя адаптеры ресурса Java Connection Architecture . Она предлагает отображение объект-XML, базирующееся на Java Architecture for XML Binding ( JAXB ) 1.0 и обеспечивает раннюю поддержку функциональных возможностей JAXB 2.0. Поскольку Oracle поддерживает идеи архитектуры, позволяющей замену в "горячем" режиме ( hot - pluggable architecture ), разработчики имеют возможность использовать ту технологию персистентности, которая является правильной для их проекта.

УСОВЕРШЕНСТВОВАННАЯ ОБРАБОТКА WEB-СЕРВИСОВ

Использование в EJB 3.0 обычных объектов Java позволяет разработчикам быстро и просто строить насыщенные модели доменов и подключать их к размещенным на сервере базам данных. Конечно, затем эти модели должны быть в качестве сервисов сделаны доступными в составе более крупных бизнес-процессов, поддерживаемых корпоративной SOA . Для прозрачного сотрудничества всех сервисов требуется надежный фундамент для обработки протокола Web-сервисов.

В сервер Oracle WebLogic Server включена поддержка последних протоколов, ориентированных на защиту и производительность Web-сервисов.

Есть две главные проблемы, связанные с обработкой протоколов. Во-первых, для функциональной совместимости требуется реализация всего стека протоколов и подтвержденная совместимость со стеками от других поставщиков. Обновления в области защиты поддерживают WS - Security 1.1 и WS -SecurityPolicy 1.1 и 1.2. Есть также новая поддержка протоколов WS - Trust и WS -SecureConversation, которые дают сервисам возможность установить общедоступный контекст защиты и поддерживать долгосрочные доверительные отношения.

В области производительности имеется новая поддержка спецификаций XML - binary Optimized Packaging ( XOP ) и Message Transmission Optimization Mechanism ( MTOM ). Спецификация XOP позволяет сервисам передавать двоичные данные, "как есть", без кодирования по Base-64, и помещать их тот же самый пакет MIME, что и остальную часть документа XML . Этот подход сокращает и требуемую полосу пропускания, и накладные расходы на кодирование. Спецификация MTOM описывает, как использовать XOP для оптимизации передачи сообщений простого протокола доступа к объекту ( SOAP ). Специалисты Oracle участвовали в нескольких мероприятиях по функциональной совместимости, чтобы убедиться, что созданные ими реализации этих протоколов и других протоколов из стека Oracle WebLogic Server хорошо работают с протоколами от других поставщиков.

Вторая проблема, связанная с обработкой протоколов, является более тонкой. Java API для удаленных вызовов процедур на базе XML ( JAX - RPC ), обрабатывающий API из прошлых версий Java EE , поддерживает только стиль RPC , который, к сожалению, является наименее гибким из всех стилей взаимодействия Web-сервисов. В Java EE 5 вводится новый API обработки - Java API for XML Web Services ( JAX - WS ), который поддерживает более гибкий ориентированный на документы стиль. Кроме того, Oracle WebLogic Server обеспечивает базовую поддержку третьего стиля - репрезентативной передачи состояния ( Representational State Transfer ), который может упростить некоторые взаимодействия. Инфраструктура обработки множества стилей Web-сервисов позволяет разработчикам приспосабливать взаимодействия в рамках SOA , чтобы можно было соответствовать различным корпоративным требованиям.

Хотя, строго говоря, это и не является проблемой обработки протоколов, но стеки Web-сервисов только с клиентской частью становятся практической проблемой для заказчиков, которые хотят строить облегченные приложения, действующие только как потребители сервисов, без нагрузки, связанной с ориентированными на сервер функциональными возможностями. Сервер Oracle WebLogic Server предлагает специальную библиотеку Java , которая реализует только клиентские части протоколов, определенных в документе " Web Services Interoperability Organization Basic Profile ".

УСОВЕРШЕНСТВОВАННЫЕ WEB -ИНТЕРФЕЙСЫ

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

Основным Web -интерфейсом Java EE 5 API является JavaServer Faces ( JSF ). Главная цель JSF - сделать разработку Web -интерфейсов более похожей на разработку графических интерфейсов пользователя. Лежащая в основе инфраструктуры модель позволяет разработчикам подключить функциональные возможности интерфейса к логическим компонентам, по существу, создавая абстрактные виджеты. Взаимодействия между пользователем и виджетами используют управляемую событиями модель. Заключительный шаг разработки связывает абстрактную модель взаимодействия с определенной технологией, например, с Web .

Этот стиль взаимодействия делает очень простой обработку состояния интерфейса внутри инфраструктуры. Непосредственная выгода состоит в том, что разработчики в своих JavaServer Pages ( JSP ) не должны реализовывать большие объемы Java -кода и на так называемом языке выражений ( Expression Language - EL ), связанном с состоянием. В технологии JSF можно также изящно обрабатывать преобразования и проверку правильности значений. А поскольку JSF использует ту же самую модель, что и графический интерфейс пользователя, она очень хорошо работает с инструментальными средствами разработки интерфейса. Как давным-давно узнали традиционные клиент/серверные разработчики, построение интерфейса с хорошим инструментарием намного более продуктивно, чем кодирование его вручную.

Теперь, когда JSF является частью Java EE , она органично работает с JSP . Они совместно используют унифицированный язык EL , а JSP является используемым по умолчанию механизмом рендеринга для JSF . Более важно, что имеется огромная возможность расширить функциональные возможности пользовательского интерфейса для стандартной платформы. Технология JSF , объединенная с библиотеками тэгов JSP , облегчит создание многократно используемых компонентов пользовательского интерфейса. Более того, большинство функций инфраструктуры соответствуют идеологии "вставляй и работай" ( plug and play ). Разработчики могут часть за частью заменять их усовершенствованными версиями, или могут даже выгрузить всю инфраструктуру и заменить ее альтернативной, например, Spring .

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

РАЗВЕРТЫВАНИЕ И УПРАВЛЕНИЕ SOA ПРОМЫШЛЕННОГО КАЛИБРА

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

Сервер Oracle WebLogic Server доказал свою способность работать в корпоративной среде. Последняя версия укрепляет этот успех, включив Java EE 5. Таким образом, заказчики могут управлять всеми новыми возможностями из знакомой консоли, что в то же время делает обновление существующих сервисов столь простым, насколько это возможно.

Теперь выполнение перехода на новую версию (апгрейд) просто означает повторное развертывание существующих сервисов на новой платформе - не требуется никакого портирования.

Кроме того, корпоративные заказчики также сталкиваются с проблемой проведения обновления клиентов до новых версий сервисов. Несколько способов облегчают этот естественный процесс применения современной SOA . Многие версии одних и тех же сервисов могут эксплуатироваться на одном и том же сервере или кластере. Администраторы могут сегментировать доступ к версиям по популяциям клиентов, например, делая более новые версии доступными только клиентам из локальных или внутренних сегментов сети. Наконец, администраторы могут декларативно определить политику миграции клиентов.

Сервер Oracle WebLogic Server разрешает и несколько других проблем заказчиков. Для корпоративных сетей, которые не поддерживают групповую передачу ( multicast ), последняя версия предлагает кластеризацию с одноадресной передачей ( unicast ). При работе в кластере для миграции сервисов Java Message Service и Java Transaction API с одной машины на другую обычно требуется несколько выполняемых вручную шагов. В последней версии имеется в наличии опция автоматической миграции сервисов. Она также допускает регистрацию и создание сценариев консольных операций.

По мере того как Oracle WebLogic Server становится стандартной частью инфраструктуры ИТ, многие корпорации хотят вести его мониторинг как часть своих консолей простого протокола управления сетью ( SNMP ). Последняя версия поддерживает SNMP 3, включая представление SNMP для MBeans JMX Runtime . Более того, агент SNMP для сервера администрирования теперь обеспечивает представление для всего домена Oracle WebLogic Server . Такие усовершенствования демонстрируют обязательства Oracle превратить SOA в пользу для всей ИТ-организации, а не только для архитекторов и разработчиков.

Рис. 3: инфраструктура диагностики Oracle WebLogic Server

ЗАКЛЮЧЕНИЕ

Применение Java EE 5 в значительной степени ускоряет разработку приложений SOA . Применение EJB 3.0 упрощает бизнес-логику, давая разработчикам возможность в большей степени сосредоточиться на модели домена, и уделять меньше внимания на "внутреннюю начинку" программного обеспечения среднего слоя. Использование JPA упрощает самые часто встречающиеся задачи управления персистентностью, связанные с отображением объектов области значений на размещенные на сервере реляционные базы данных. API Web -интерфейсов допускают более богатое и более гибкое взаимодействие пользователей с SOA , в то время как JAX - WS допускает более богатое и более гибкое сотрудничество между сервисами в SOA .

Сервер Oracle WebLogic Server является одной из первых готовых к промышленному использованию реализаций Java EE 5. Он не только придерживается буквы стандарта, но и принимает его дух - простота без жертв. Разработчики получают преимущества упрощенного API, не отказываясь при этом ни от одной проверенной инфраструктуры, лежащей в фундаменте Oracle WebLogic Server . В платформу также включен Oracle TopLink , поставляющий высокопроизводительный экземпляр эталонной реализации персистентности Java EE . Помощь заказчикам в стремлении заставить их предприятие работать лучше - вот конечная цель Oracle WebLogic Server, и он обеспечивает функциональные возможности Java EE 5 таким способом, который лучше всего поддерживает это.

Сервер Oracle WebLogic Server - это платформа Java EE самой большой популярности, продуктивности и производительности. Теперь она является одной из первых платформ, способной передать мощь готовой к промышленному использованию реализации Java EE 5 в руки корпоративных разработчиков.