Guia de instalação do EJB

1. Visão geral

Neste artigo, vamos discutir como começar com o desenvolvimento Enterprise JavaBean (EJB).

Enterprise JavaBeans are used for developing scalable, distributed, server-side componentse normalmente encapsula a lógica de negócios do aplicativo.

UsaremosWildFly 10.1.0 como nossa solução de servidor preferencial, no entanto, você pode usar qualquer servidor de aplicativos Java Enterprise de sua escolha.

2. Configuração

Vamos começar discutindo as dependências do Maven necessárias para o desenvolvimento do EJB 3.2 e como configurar o servidor de aplicativos WildFly usando o plug-in Maven Cargo ou manualmente.

2.1. Dependência do Maven

Para usar o EJB 3.2,, certifique-se de adicionar a versão mais recente à seçãodependencies do arquivopom.xml:


    javax
    javaee-api
    7.0
    provided

Você encontrará a dependência mais recente emMaven Repository. Essa dependência garante que todas as APIs do Java EE 7 estejam disponíveis durante o tempo de compilação. O escopoprovided garante que, uma vez implantado, a dependência será fornecida pelo contêiner onde foi implantado.

2.2. Configuração do WildFly com Maven Cargo

Vamos falar sobre como usar o plugin Maven Cargo para configurar o servidor.

Aqui está o código para o perfil Maven que provisiona o servidor 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!

Usamos o plug-in para baixar o zipWildFly 10.1 diretamente do site do WildFly. Que é então configurado, certificando-se de quehostname é127.0.0.1e definindo a porta para 9990.

Em seguida, criamos um usuário de teste, usando a propriedadecargo.servlet.users, com a id do usuáriotestUsere a senhaadmin1234!.

Agora que a configuração do plug-in foi concluída, poderemos chamar um destino Maven e fazer com que o servidor seja baixado, instalado, iniciado e o aplicativo implantado.

Para fazer isso, navegue até o diretórioejb-remote e execute o seguinte comando:

mvn clean package cargo:run

Quando você executa esse comando pela primeira vez, ele baixa o arquivo zip do WildFly 10.1, extrai-o e executa a instalação e, em seguida, inicia-o. Ele também adicionará o usuário de teste discutido acima. Quaisquer execuções adicionais não baixarão o arquivo zip novamente.

2.3. Configuração manual do WildFly

Para configurar o WildFly manualmente, você deve baixar o arquivo zip de instalação do sitewildfly.org. As etapas a seguir são uma visualização de alto nível do processo de configuração do servidor WildFly:

Depois de baixar e descompactar o conteúdo do arquivo no local onde deseja instalar o servidor, configure as seguintes variáveis de ambiente:

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

Em seguida, no diretóriobin, execute./standalone.sh para sistemas operacionais baseados em Linux ou./standalone.bat para Windows.

Depois disso, você terá que adicionar um usuário. Este usuário será usado para conectar-se ao bean EJB remoto. Para descobrir como adicionar um usuário, você deve dar uma olhada em‘add a user' documentation.

Para obter instruções de configuração detalhadas, visiteGetting Started documentation do WildFly.

O POM do projeto foi configurado para funcionar com o plug-in Cargo e a configuração manual do servidor, definindo dois perfis. Por padrão, o plug-in Cargo está selecionado. No entanto, para implantar o aplicativo em um servidor Wildfly já instalado, configurado e em execução, execute o seguinte comando no diretórioejb-remote:

mvn clean install wildfly:deploy -Pwildfly-runtime

**3. Remote vsLocal**

Uma interface de negócios para um bean pode serlocal ouremote.

Um bean anotado@Local só pode ser acessado se estiver no mesmo aplicativo que o bean que faz a chamada, ou seja, se residirem no mesmo.ear ou.war.

Um bean anotado@Remote pode ser acessado de um aplicativo diferente, ou seja, um aplicativo residente em umJVM ou servidor de aplicativos diferente.

Existem alguns pontos importantes a se ter em mente ao projetar uma solução que inclui EJBs:

Osjava.io.Serializable,java.io.Externalizablee interfaces definidas pelo pacotejavax.ejb são sempre excluídos quando um bean é declarado com@Local ou@Remote
Se uma classe de bean for remota, todas as interfaces implementadas deverão ser remotas
Se uma classe de bean não contém nenhuma anotação ou se a anotação@Local é especificada, então todas as interfaces implementadas são consideradas locais
Qualquer interface que é explicitamente definida para um bean que não contém interface deve ser declarada como@Local
A liberação do EJB 3.2 tende a fornecer mais granularidade para situações em que as interfaces locais e remotas precisam ser explicitamente definidas.

4. Criando o EJBRemote

Vamos primeiro criar a interface do bean e chamá-la deHelloWorld:

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

Agora vamos implementar a interface acima e nomear a implementação concretaHelloWorldBean:

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

    @Resource
    private SessionContext context;

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

Observe a anotação@Stateless na declaração da classe. Indica que esse bean é um bean de sessão sem estado. This kind of bean does not have any associated client state, mas pode preservar seu estado de instância e é normalmente usado para fazer operações independentes.

A anotação@Resource injeta o contexto da sessão no bean remoto.

The SessionContext interface provides access to the runtime session context that the container provides for a session bean instance. O contêiner então passa a interfaceSessionContext para uma instância depois que a instância é criada. O contexto da sessão permanece associado a essa instância por toda a vida.

O contêiner EJB normalmente cria um pool de objetos do bean sem estado e usa esses objetos para processar solicitações do cliente. Como resultado desse mecanismo de pool, não é garantido que os valores das variáveis da instância sejam mantidos nas chamadas do método de pesquisa.

5. Configuração Remota

Nesta seção, discutiremos como configurar o Maven para criar e executar o aplicativo no servidor.

Vejamos os plug-ins um por um.

5.1. O plug-in EJB

O plug-in EJB fornecido abaixo é usado para empacotar um módulo EJB. Especificamos a versão do EJB como 3.2.

A seguinte configuração de plug-in é usada para definir o JAR de destino para o bean:


    maven-ejb-plugin
    2.4
    
        3.2

5.2. Implantar o EJB Remoto

Para implantar o bean em um servidor WildFly, verifique se o servidor está em funcionamento.

Em seguida, para executar a configuração remota, precisaremos executar os seguintes comandos Maven no arquivo pom no projetoejb-remote:

mvn clean install

Então devemos executar:

mvn wildfly:deploy

Como alternativa, podemos implantá-lo manualmente como um usuárioadmin no console de administração do servidor de aplicativos.

6. Configuração do cliente

Depois de criar o bean remoto, devemos testar o bean implementado criando um cliente.

Primeiro, vamos discutir a configuração do Maven para o projeto do cliente.

6.1. Configuração do Maven do lado do cliente

Para iniciar o cliente EJB3, precisamos adicionar as seguintes dependências:


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

Dependemos das interfaces comerciais remotas EJB desse aplicativo para executar o cliente. Portanto, precisamos especificar a dependência JAR do cliente EJB. Nós adicionamos o seguinte no pom pai:


    com.example.ejb
    ejb-remote
    ejb

O<type> é especificado comoejb.

6.2. Acessando o Remote Bean

Precisamos criar um arquivo emsrc/main/resourcese nomeá-lojboss-ejb-client.properties que conterá todas as propriedades necessárias para acessar o bean implantado:

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. Criando o cliente

A classe que irá acessar e usar o beanHelloWorld remoto foi criada emEJBClient.java, que está no pacotecom.example.ejb.client.

7.1 Remote Bean URL

O bean remoto está localizado através de uma URL em conformidade com o seguinte formato:

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

O${appName} é o nome do aplicativo da implantação. Aqui, não usamos nenhum arquivo EAR, mas uma implementação simples de JAR ou WAR, portanto, o nome do aplicativo estará vazio
The[.crayon-pre .crayon-code] ${moduleName}## é o nome que definimos para nossa implantação anterior, portanto, éejb-remote
O${distinctName} é um nome específico que pode ser atribuído opcionalmente às implantações que são implantadas no servidor. Se uma implantação não usadistinct-name, podemos usar uma String vazia no nome JNDI, paradistinct-name, como fizemos em nosso exemplo
A variável[.crayon-pre .crayon-code]${beanName}## é o nome simples da classe de implementação do EJB, então em nosso exemplo éHelloWorld
[.crayon-pre .crayon-code]${viewClassName}## denota o nome de interface totalmente qualificado da interface remota

7.2 Look-up Logic

A seguir, vamos dar uma olhada em nossa lógica de pesquisa simples:

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);
}

Para nos conectarmos aosbean que acabamos de criar, precisaremos de uma URL que possamos inserir no contexto.

7.3 The Initial Context

Agora vamos criar / inicializar o contexto da sessão:

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);
}

Para conectar-se ao bean remoto, precisamos de um contexto JNDI. A fábrica de contexto é fornecida pelo artefato Mavenorg.jboss:jboss-remote-naming e isso cria um contexto JNDI, que resolverá a URL construída no métodolookup, em proxies para o processo do servidor de aplicativo remoto.

7.4 Define Lookup Parameters

Definimos a classe de fábrica com o parâmetroContext.INITIAL_CONTEXT_FACTORY.

OContext.URL_PKG_PREFIXES é usado para definir um pacote para fazer a varredura de contexto de nomenclatura adicional.

O parâmetroorg.jboss.ejb.client.scoped.context = false informa ao contexto para ler os parâmetros de conexão (como o host e a porta de conexão) do mapa fornecido em vez de um arquivo de configuração de caminho de classe. Isso é especialmente útil se desejarmos criar um pacote JAR que possa conectar-se a hosts diferentes.

O parâmetroContext.PROVIDER_URL define o esquema de conexão e deve começar comhttp-remoting://.

8. Teste

Para testar a implantação e verificar a instalação, podemos executar o seguinte teste para garantir que tudo funcione corretamente:

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

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

Com a aprovação no teste, agora podemos ter certeza de que tudo está funcionando conforme o esperado.

9. Conclusão

Portanto, criamos um servidor EJB e um cliente que chama um método em um EJB remoto. O projeto pode ser executado em qualquer servidor de aplicativos adicionando corretamente as dependências para esse servidor.

Todo o projeto pode ser encontradoover on GitHub.

TOC

Guia de instalação do EJB