Спецификация Java EE Connector Architecture (JCA) определяет стандартную архитектуру для соединения платформы Java EE с разнородными корпоративными информационными системами (EIS). Примеры EIS включают планирование ресурсов предприятия (ERP), обработку транзакций мэйнфреймов (TP), базы данных и системы обмена сообщениями.
Спецификация Java EE Connector Architecture 1.6 была разработана под зонтиком Java Community Process (JCP) как
JSR-322 и включена в полный профиль спецификации Java EE 6.
В этой статье мы рассмотрим новую спецификацию Java EE Connector Architecture и посмотрим, как можно приступить к разработке своих адаптеров ресурсов с помощью проекта JBoss JCA.
Что нового в JCA 1.6
Спецификация Java EE Connector Architecture 1.6 является обратно совместимым обновлением спецификации JCA, которое добавляет новые ключевые области в спецификацию.
Спецификация была обновлена в следующих областях:
- Легкость развития
- Универсальный WorkContext
- Приток безопасности
- Другие улучшения
В следующих разделах мы кратко рассмотрим, что могут предложить эти новые области.
Простота разработки
Одним из основных направлений в спецификации Java Enterprise Edition 5 было использование аннотаций для облегчения разработки различных технологий.
Применение тех же принципов простоты использования к спецификации Java EE Connector Architecture позволит значительно упростить разработку адаптера ресурсов, поскольку вам не нужно указывать дескриптор развертывания META-INF / ra.xml.
Разработчики теперь могут использовать следующие аннотации:
- @Connector
- @AuthenticationMechanism
- @SecurityPermission
- @ConfigProperty
- @ConnectionDefinitions / @ConnectionDefinition
- @Activation
- @AdministeredObject
… чтобы минимизировать нагрузку на метаданные.
Примером класса адаптера ресурса может быть:
import javax.resource.spi.Connector;
import javax.resource.spi.ConfigProperty;
import javax.resource.spi.ResourceAdapter;
/**
* My resource adapter
*/
@Connector
public class MyResourceAdapter implements ResourceAdapter
{
@ConfigProperty(defaultValue="5")
private Integer myIntegerProperty;
...
}
Спецификация позволяет разработчику использовать разреженный XML-файл, если параметры конфигурации адаптера ресурса должны быть оставлены на усмотрение человека, развертывающего архив.
Универсальный WorkContext
Универсальная функциональность WorkContext позволяет адаптеру ресурсов распространять контекстную информацию из EIS во время доставки сообщения или рабочей отправки.
Это позволяет контейнеру JCA поддерживать новые схемы доставки и доставки сообщений.
Контекстная информация передается с помощью интерфейса WorkContextProvider, который задает поддерживаемый контекст. Стандарт поддерживает следующие три контекста:
- TransactionContext
- SecurityContext
- HintsContext
public interface WorkContextProvider extends Serializable
{
/**
* Gets an instance of <code>WorkContexts</code> that needs to be used
* by the <code>WorkManager</code> to set up the execution context while
* executing a <code>Work</code> instance.
*
* @return a <code>List</code> of <code>WorkContext</code> instances.
*/
List<WorkContext> getWorkContexts();
}
TransactionContext, который обрабатывает транзакционный контекст операции, SecurityContext, который мы рассмотрим в следующем разделе, и HintsContext, который позволяет распространять подсказки о выполнении, QoS или другие свойства о работе, которую необходимо выполнить.
Это, например, позволит разработчику указать, что отправленный экземпляр Work является долгосрочным заданием, и тем самым разрешить контейнеру JCA выполнить этот экземпляр в пуле потоков, обрабатывающем такие задачи.
Приток
безопасности Функциональность SecurityContext была добавлена для обеспечения сквозной безопасности на уровне приложений при выполнении экземпляра Work или доставке сообщения конечной точке.
Это позволяет выполнять Работу в контексте безопасности с установленным идентификатором и для передачи Принципала из EIS в MessageEndpoint.
Эта функциональность использует работу, выполненную в интерфейсе поставщика услуг аутентификации Java для контейнеров (JSR-196), который использует обратные вызовы для установления личности вызывающего абонента.
package javax.resource.spi.work;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
public abstract class SecurityContext implements WorkContext
{
...
public abstract void setupSecurityContext(CallbackHandler handler,
Subject executionSubject,
Subject serviceSubject);
Это действительно ключевая новая особенность спецификации JCA, поскольку она позволит намного лучше интегрировать информацию о безопасности между платформой Java EE и EIS.
Другие улучшения
В спецификации было несколько других улучшений.
- Теперь можно указать уровень поддержки транзакций во время выполнения.
- Есть определение распределённого менеджера работ
- Для притока сообщений createMessageEndpoint () теперь поддерживает значение тайм-аута
- Понятие повторяющихся исключений были введены
- Проверка бина (JSR-303) была интегрирована, чтобы позволить проверку свойств
- Уточнена семантика загрузчика классов
И, наконец, была определена автономная контейнерная среда для указания среды JCA, работающей вне сервера приложений — подробнее об этом позже.
Контейнер JBoss JCA
Проект JBoss JCA направлен на реализацию спецификации Java EE Connector Architecture 1.6 с использованием облегченного подхода «Простой старый объект Java» (POJO), чтобы контейнер мог работать на любом ядре Java.
Контейнер состоит из POJO, которые соединены друг с другом с помощью инъекции и, таким образом, упрощают настройку контейнера, который выполняется с помощью файлов XML.
Проект JBoss JCA поддерживает два разных ядра POJO: микроконтейнер JBoss и собственное ядро проекта под названием Fungal.
Это позволяет использовать контейнер в разных вкусах.
Три разновидности
Проект фокусируется на трех разных разновидностях обеспечения функциональности JCA:
- Внутри сервера приложений JBoss
- Полный автономный контейнер
- Встроенное решение
В следующих разделах будут описаны цели этих вкусов.
Внутри сервера приложений JBoss
Основная цель проекта — включить его в состав сервера приложений JBoss в качестве его реализации контейнера JCA и тем самым обеспечить развертывание JCA 1.6, которое поддерживается в полном профиле Java Enterprise Edition 6.
Эта интеграция, конечно, будет использовать профиль проекта JBoss Microcontainer, поскольку сервер приложений JBoss использует это ядро для своей основы.
Автономный профиль
Автономный профиль реализует часть спецификации «Автономная контейнерная среда», как определено в главе 3, раздел 5.
Эта среда определяет платформу JCA для исходящей и возможной входящей связи и какие аспекты спецификации являются обязательными.
Короче говоря, у вас будет доступ по крайней мере к исходящему контейнеру JCA и ко всем службам, которые использует JCA, включая транзакции, безопасность и проверку компонентов.
Каждый поставщик должен заполнить «пробелы», такие как модель компонента приложения, среда ядра и любые дополнительные сервисы.
Проект JBoss JCA использует POJO в качестве модели компонента приложения, что означает, что вы будете писать свои сервисы как стандартные POJO, использующие жизненный цикл, предоставляемый средой ядра. В проект был включен веб-сервер для базовых веб-возможностей управления.
Автономная среда обеспечивает отличную базовую линию для интеграции с сервером приложений JBoss,
поскольку ее можно протестировать за пределами среды сервера приложений перед ее включением.
Встроенный профиль
Проект также существует во встроенном профиле, который позволяет разработчикам включать контейнер в
свое приложение.
Этот профиль основан на автономном профиле и поэтому имеет одинаковые функциональные возможности.
Для упрощения тестирования адаптеров ресурсов встроенный контейнер интегрируется с
проектом ShrinkWrap , размещенным на JBoss.org.
Этот проект позволяет легко настроить тестовый пример JUnit и программно собрать
архив адаптера ресурса, который вы хотите протестировать, например:
package org.jboss.jca.embedded.unit;
import org.jboss.jca.embedded.EmbeddedJCA;
import org.jboss.jca.embedded.rars.simple.MessageListener;
import org.jboss.jca.embedded.rars.simple.TestActivationSpec;
import org.jboss.jca.embedded.rars.simple.TestConnection;
import org.jboss.jca.embedded.rars.simple.TestConnectionFactory;
import org.jboss.jca.embedded.rars.simple.TestConnectionInterface;
import org.jboss.jca.embedded.rars.simple.TestConnectionManager;
import org.jboss.jca.embedded.rars.simple.TestManagedConnection;
import org.jboss.jca.embedded.rars.simple.TestManagedConnectionFactory;
import org.jboss.jca.embedded.rars.simple.TestResourceAdapter;
import java.util.UUID;
import org.jboss.logging.Logger;
import org.jboss.shrinkwrap.api.Archives;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.jboss.shrinkwrap.api.spec.ResourceAdapterArchive;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import static org.junit.Assert.*;
/**
* Test cases for deploying resource adapter archives (.RAR)
* using ShrinkWrap
*
* @author <a href="mailto:[email protected]">Jesper Pedersen</a>
* @version $Revision: $
*/
public class ShrinkWrapTestCase
{
// --------------------------------------------------------------------------------||
// Class Members ------------------------------------------------------------------||
// --------------------------------------------------------------------------------||
private static Logger log = Logger.getLogger(ShrinkWrapTestCase.class);
/*
* Embedded
*/
private static EmbeddedJCA embedded;
// --------------------------------------------------------------------------------||
// Tests --------------------------------------------------------------------------||
// --------------------------------------------------------------------------------||
/**
* Basic ShrinkWrap ResourceAdapterArchive test case
* @exception Throwable Thrown if case of an error
*/
@Test
public void testBasic() throws Throwable
{
ResourceAdapterArchive raa =
Archives.create(UUID.randomUUID().toString() + ".rar", ResourceAdapterArchive.class);
JavaArchive ja = Archives.create(UUID.randomUUID().toString() + ".jar", JavaArchive.class);
ja.addClasses(MessageListener.class, TestActivationSpec.class, TestConnection.class,
TestConnectionFactory.class, TestConnectionManager.class,
TestConnectionInterface.class, TestManagedConnection.class,
TestManagedConnectionFactory.class, TestResourceAdapter.class);
raa.addLibrary(ja);
raa.addManifestResource("simple.rar/META-INF/ra.xml", "ra.xml");
try
{
embedded.deploy(raa);
// Lookup ConnectionFactory and start making asserts
}
catch (Throwable t)
{
log.error(t.getMessage(), t);
fail(t.getMessage());
}
finally
{
embedded.undeploy(raa);
}
}
// --------------------------------------------------------------------------------||
// Lifecycle Methods --------------------------------------------------------------||
// --------------------------------------------------------------------------------||
/**
* Lifecycle start, before the suite is executed
* @throws Throwable throwable exception
*/
@BeforeClass
public static void beforeClass() throws Throwable
{
// Create and set an embedded JCA instance
embedded = new EmbeddedJCA();
// Startup
embedded.startup();
}
/**
* Lifecycle stop, after the suite is executed
* @throws Throwable throwable exception
*/
@AfterClass
public static void afterClass() throws Throwable
{
// Shutdown embedded
embedded.shutdown();
// Set embedded to null
embedded = null;
}
}
… который развертывает простой архив адаптера ресурса.
Тестирование адаптеров ресурсов еще никогда не было таким простым.
В будущем выпуске встроенный контейнер также будет интегрирован с проектом Arquillian , чтобы сделать тестирование еще проще.
Инструменты для удобства использования
В проекте имеется компонент проверки адаптера ресурса, который проверяет архив адаптера ресурса
на соответствие правилам реализации, определенным в спецификации. Валидатор выведет, какие правила
были запущены во время запуска контейнера, и — если он настроен — не удастся развернуть
адаптер ресурса.
Пример вывода может быть:
Severity: ERROR
Section: 19.4.2
Description: A ResourceAdapter must implement a "public int hashCode()" method.
Code: com.mycompany.myproject.ResourceAdapterImpl
Severity: ERROR
Section: 19.4.2
Description: A ResourceAdapter must implement a "public boolean equals(Object)" method.
Code: com.mycompany.myproject.ResourceAdapterImpl
… что может привести к сбою в развертывании, но даст разработчику понимание того, что необходимо исправить и где найти требования в спецификации JCA.
Валидатор также можно использовать из командной строки или через задачу Apache Ant.
В проекте также имеется генератор кода адаптера ресурсов, который предоставляет разработчику скелет кода на основе ввода, полученного из командной строки или через файл конфигурации.
Сгенерированный код также предоставит подсказки о том, где искать в спецификации требования к реализации.
Разумеется, генератор будет поддерживать различные спецификации JCA, а также различные типы адаптеров ресурсов.
Проект также будет включать в себя несколько примеров реализации адаптера ресурсов, которые помогут разработчикам начать работу в составе документации в будущем выпуске.
Принять участие
Проект JBoss JCA всегда ищет новые таланты , чтобы помочь с проектом. Вклады могут принимать любую форму, от разработки новых функций, сообщения об ошибках до помощи в улучшении документации.
Так что не стесняйтесь присоединяться к нашим дискуссиям на форуме ( пользователь) ( разработчик ) или заходите на канал jboss-dev во FreeNode.
Что мы покрыли?
В этой статье мы рассмотрели спецификацию Java EE Connector Architecture 1.6, включенную в полный профиль стандарта Java Enterprise Edition 6.
Мы увидели, как новые области помогут разработчикам с легкостью в использовании и предоставят им новые мощные функциональные возможности для контроля выполнения работ и использования преимуществ безопасности, используя обработчики обратного вызова.
Мы также рассмотрели проект JBoss JCA, который обеспечит реализацию спецификации и предложит ключевые дополнительные преимущества, которые помогут разработчикам адаптеров ресурсов в их повседневной работе.
Об авторе
работает разработчиком ядра в JBoss , Red Hatгде он возглавляет проект JBoss JCA и другие проекты. Он работал в группе экспертов по спецификации Java EE Connector Architecture 1.6 (JSR-322).