TOC

Руководство по настройке EJB

Руководство по настройке EJB

1. обзор

В этой статье мы собираемся обсудить, как начать разработку Enterprise JavaBean (EJB).

Enterprise JavaBeans are used for developing scalable, distributed, server-side components и обычно инкапсулируют бизнес-логику приложения.

Мы будем использоватьWildFly 10.1.0 в качестве предпочтительного серверного решения, однако вы можете использовать любой сервер приложений Java Enterprise по своему выбору.

2. Настроить

Давайте начнем с обсуждения зависимостей Maven, необходимых для разработки EJB 3.2, и того, как настроить сервер приложений WildFly с помощью подключаемого модуля Maven Cargo или вручную.

2.1. Maven Dependency

Чтобы использовать EJB 3.2,, убедитесь, что вы добавили последнюю версию в разделdependencies вашего файлаpom.xml: 


    javax
    javaee-api
    7.0
    provided

Вы найдете последнюю зависимость вMaven Repository. Эта зависимость гарантирует, что все API Java EE 7 доступны во время компиляции. Область действияprovided гарантирует, что после развертывания зависимость будет предоставлена ​​контейнером, в котором она была развернута.

2.2. Настройка WildFly с Maven Cargo

Давайте поговорим о том, как использовать плагин Maven Cargo для настройки сервера.

Вот код для профиля Maven, который обеспечивает сервер WildFly: 


    wildfly-standalone
    
        
            
                org.codehaus.cargo
                cargo-maven2-plugin
                ${cargo-maven2-plugin.version
                
                    
                        wildfly10x
                        
                            
                                http://download.jboss.org/
                                  wildfly/10.1.0.Final/
                                    wildfly-10.1.0.Final.zip
                            
                        
                    
                    
                        
                            127.0.0.0
                            
                                9990
                            
                            
                                testUser:admin1234!

Мы используем плагин для загрузки архиваWildFly 10.1 прямо с веб-сайта WildFly. Что затем настраивается, убедившись, чтоhostname равен127.0.0.1, и установив порт на 9990.

Затем мы создаем тестового пользователя, используя свойствоcargo.servlet.users, с идентификатором пользователяtestUser и паролемadmin1234!..

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

Для этого перейдите в каталогejb-remote и выполните следующую команду: 

mvn clean package cargo:run

Когда вы запускаете эту команду в первый раз, она скачает zip-файл WildFly 10.1, распакует его и выполнит установку, а затем запустит. Это также добавит тестового пользователя, обсужденного выше. Любое дальнейшее выполнение не будет загружать файл zip снова.

2.3. Ручная настройка WildFly

Чтобы установить WildFly вручную, вы должны сами загрузить установочный zip-файл с веб-сайтаwildfly.org. Следующие шаги представляют собой общее представление процесса настройки сервера WildFly:

После загрузки и распаковки содержимого файла в место, где вы хотите установить сервер, настройте следующие переменные среды: 

JBOSS_HOME=/Users/$USER/../wildfly.x.x.Final
JAVA_HOME=`/usr/libexec/java_home -v 1.8`

Затем в каталогеbin запустите./standalone.sh для операционных систем на базе Linux или./standalone.bat для Windows.

После этого вам нужно будет добавить пользователя. Этот пользователь будет использоваться для подключения к удаленному EJB-компоненту. Чтобы узнать, как добавить пользователя, вам следует взглянуть на‘add a user' documentation.

Для получения подробных инструкций по установке посетитеGetting Started documentation WildFly.

Проект POM был настроен для работы с плагином Cargo и ручной настройкой сервера путем установки двух профилей. По умолчанию плагин Cargo выбран. Однако для развертывания приложения на уже установленном, настроенном и работающем сервере Wildfly выполните следующую команду в каталогеejb-remote: 

mvn clean install wildfly:deploy -Pwildfly-runtime

3. Remote противLocal

Бизнес-интерфейс для компонента может бытьlocal илиremote..

Доступ к аннотированному компоненту@Local возможен только в том случае, если он находится в том же приложении, что и компонент, выполняющий вызов, т.е. если они находятся в одном и том же.ear или.war.

Доступ к аннотированному компоненту@Remote можно получить из другого приложения, т. Е. приложение, находящееся на другомJVM или сервере приложений.

При разработке решения, включающего EJB-компоненты, следует учитывать несколько важных моментов:

  • java.io.Serializable,java.io.Externalizable и интерфейсы, определенные пакетомjavax.ejb, всегда исключаются, когда компонент объявляется с помощью@Local или@Remote

  • Если класс bean является удаленным, то все реализованные интерфейсы должны быть удаленными

  • Если класс компонента не содержит аннотации или если указана аннотация@Local, то предполагается, что все реализованные интерфейсы являются локальными.

  • Любой интерфейс, который явно определен для bean-компонента, не содержащий интерфейса, должен быть объявлен как@Local

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

4. Создание EJBRemote

Давайте сначала создадим интерфейс компонента и назовем егоHelloWorld: 

@Remote
public interface HelloWorld {
    String getHelloWorld();
}

Теперь мы реализуем вышеуказанный интерфейс и назовем конкретную реализациюHelloWorldBean: 

@Stateless(name = "HelloWorld")
public class HelloWorldBean implements HelloWorld {

    @Resource
    private SessionContext context;

    @Override
    public String getHelloWorld() {
        return "Welcome to EJB Tutorial!";
    }
}

Обратите внимание на аннотацию@Stateless в объявлении класса. Это означает, что этот компонент является сессионным компонентом без сохранения состояния. This kind of bean does not have any associated client state, но он может сохранять свое состояние экземпляра и обычно используется для выполнения независимых операций.

Аннотация@Resource вводит контекст сеанса в удаленный компонент.

The SessionContext interface provides access to the runtime session context that the container provides for a session bean instance. Затем контейнер передает интерфейсSessionContext экземпляру после того, как экземпляр был создан. Контекст сеанса остается связанным с этим экземпляром в течение его времени жизни.

Контейнер EJB обычно создает пул объектов bean без сохранения состояния и использует эти объекты для обработки клиентских запросов. Благодаря такому механизму объединения значения переменных экземпляров не гарантируются при вызовах методов поиска.

5. Удаленная настройка

В этом разделе мы обсудим, как настроить Maven для сборки и запуска приложения на сервере.

Давайте посмотрим на плагины один за другим.

5.1. Плагин EJB

Плагин EJB, который приведен ниже, используется для упаковки модуля EJB. Мы указали версию EJB как 3.2.

Следующая конфигурация плагина используется для настройки целевого JAR-файла для bean-компонента: 


    maven-ejb-plugin
    2.4
    
        3.2

5.2. Разверните удаленный EJB

Для развертывания компонента на сервере WildFly убедитесь, что сервер запущен и работает.

Затем, чтобы выполнить удаленную настройку, нам нужно будет запустить следующие команды Maven для файла pom в проектеejb-remote: 

mvn clean install

Тогда мы должны запустить: 

mvn wildfly:deploy

В качестве альтернативы мы можем развернуть его вручную как пользовательadmin из консоли администратора сервера приложений.

6. Настройка клиента

После создания удаленного компонента мы должны протестировать развернутый компонент, создав клиент.

Сначала давайте обсудим настройку Maven для клиентского проекта.

6.1. Настройка Maven на стороне клиента

Для запуска клиента EJB3 нам нужно добавить следующие зависимости: 


    org.wildfly
    wildfly-ejb-client-bom
    pom
    import

Мы зависим от удаленных бизнес-интерфейсов EJB этого приложения для запуска клиента. Поэтому нам нужно указать JAR-зависимость EJB-клиента. Мы добавляем следующее в родительский пом: 


    com.example.ejb
    ejb-remote
    ejb

<type> указывается какejb.

6.2. Доступ к удаленному компоненту

Нам нужно создать файл вsrc/main/resources и назвать егоjboss-ejb-client.properties, который будет содержать все свойства, необходимые для доступа к развернутому компоненту: 

remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options
  .SASL_POLICY_NOANONYMOUS = false
remote.connection.default.connect.options.org.xnio.Options
  .SASL_POLICY_NOPLAINTEXT = false
remote.connection.default.connect.options.org.xnio.Options
  .SASL_DISALLOWED_MECHANISMS = ${host.auth:JBOSS-LOCAL-USER}
remote.connection.default.username=testUser
remote.connection.default.password=admin1234!

7. Создание клиента

Класс, который будет обращаться к удаленному компонентуHelloWorld и использовать его, был создан вEJBClient.java, который находится в пакетеcom.example.ejb.client.

7.1 Remote Bean URL

Удаленный компонент находится через URL-адрес, соответствующий следующему формату: 

ejb:${appName}/${moduleName}/${distinctName}/${beanName}!${viewClassName}

  • ${appName} - это имя приложения развертывания. Здесь мы использовали не EAR-файл, а простое развертывание JAR или WAR, поэтому имя приложения будет пустым

  • The[.crayon-pre .crayon-code] ${moduleName}## - это имя, которое мы установили для нашего развертывания ранее, поэтому этоejb-remote

  • ${distinctName} - это конкретное имя, которое можно при желании назначить развертываниям, развернутым на сервере. Если развертывание не используетdistinct-name, мы можем использовать пустую строку в имени JNDI дляdistinct-name, как мы это делали в нашем примере.

  • Переменная[.crayon-pre .crayon-code]${beanName}## - это простое имя класса реализации EJB, поэтому в нашем примере этоHelloWorld.

  • [.crayon-pre .crayon-code]${viewClassName}## обозначает полное имя интерфейса удаленного интерфейса

7.2 Look-up Logic

Теперь давайте посмотрим на нашу простую логику поиска: 

public HelloWorld lookup() throws NamingException {
    String appName = "";
    String moduleName = "remote";
    String distinctName = "";
    String beanName = "HelloWorld";
    String viewClassName = HelloWorld.class.getName();
    String toLookup = String.format("ejb:%s/%s/%s/%s!%s",
      appName, moduleName, distinctName, beanName, viewClassName);
    return (HelloWorld) context.lookup(toLookup);
}

Чтобы подключиться к только что созданномуbean, нам понадобится URL-адрес, который мы можем передать в контекст.

7.3 The Initial Context

Теперь мы создадим / инициализируем контекст сеанса: 

public void createInitialContext() throws NamingException {
    Properties prop = new Properties();
    prop.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
    prop.put(Context.INITIAL_CONTEXT_FACTORY,
      "org.jboss.naming.remote.client.InitialContextFacto[ERROR]
    prop.put(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080");
    prop.put(Context.SECURITY_PRINCIPAL, "testUser");
    prop.put(Context.SECURITY_CREDENTIALS, "admin1234!");
    prop.put("jboss.naming.client.ejb.context", false);
    context = new InitialContext(prop);
}

Для подключения к удаленному компоненту нам нужен контекст JNDI. Фабрика контекста предоставляется артефактом Mavenorg.jboss:jboss-remote-naming, и это создает контекст JNDI, который преобразует URL-адрес, созданный в методеlookup, в прокси для процесса удаленного сервера приложений.

7.4 Define Lookup Parameters

Мы определяем фабричный класс параметромContext.INITIAL_CONTEXT_FACTORY.

Context.URL_PKG_PREFIXES используется для определения пакета для сканирования на предмет дополнительного контекста именования.

Параметрorg.jboss.ejb.client.scoped.context = false указывает контексту читать параметры соединения (такие как хост и порт соединения) из предоставленной карты, а не из файла конфигурации пути к классам. Это особенно полезно, если мы хотим создать JAR-пакет, который должен иметь возможность подключаться к разным хостам.

ПараметрContext.PROVIDER_URL определяет схему подключения и должен начинаться сhttp-remoting://.

8. тестирование

Чтобы проверить развертывание и проверить настройки, мы можем запустить следующий тест, чтобы убедиться, что все работает правильно: 

@Test
public void testEJBClient() {
    EJBClient ejbClient = new EJBClient();
    HelloWorldBean bean = new HelloWorldBean();

    assertEquals(bean.getHelloWorld(), ejbClient.getEJBRemoteMessage());
}

С прохождением теста мы можем быть уверены, что все работает так, как ожидалось.

9. Заключение

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

Весь проект можно найтиover on GitHub.

Related