![[z/OS]](../images/ngzos.gif)
Solicitação de Serviço Remoto do WebSphere Optimized Local Adapter (WOLA) em um Destino de Enterprise Java Bean
Este recurso permite que um aplicativo cliente, tal como lote, CICS, etc. contate uma instância do servidor do WebSphere Application Server remota que hospeda um aplicativo cuja execução da lógica de negócios e os resultados são requeridos pelo cliente. A chamada remota é feita alavancando as APIs BBOA1INV/BBGA1INV e BBOA1SRQ/BBGA1SRQ e um aplicativo proxy (RemoteEJBProxy), o qual é fornecido com o WebSphere Application Server para z/OS.
- Federe o namespace da instância do WebSphere Application Server no z/OS WebSphere Application Server local para ativar o servidor local para consultar o aplicativo no servidor remoto. O aplicativo remoto deve ser um Enterprise Java™ Bean stateless que implementa um método chamado execute(), o qual aceitar uma matriz de bytes como entrada e retorna uma matriz de bytes como saída, conforme definido pela interface com.ibm.websphere.ola.Execute. Ele também deve especificar o nome com.ibm.websphere.ola.ExecuteHome para a interface EJB home e com.ibm.websphere.ola.Execute para a interface remota ao usar as especificações EJB 2.1 ou anterior ou deve definir a anotação @RemoteHome especificando com.ibm.websphere.ola.ExecuteHome ao usar a especificação EJB 3.0. Estas interfaces estão disponíveis no tempo de execução no WebSphere Application Server para z/OS e no WebSphere Application Server para plataformas distribuídas. Para propósitos de desenvolvimento do aplicativo remoto, as interfaces mencionadas são fornecidas com o WebSphere Application Server para z/OS como parte da ferramenta do conjunto ola_apis.jar. Não empacote estas interfaces com seu arquivo EAR do aplicativo.
- Instale o arquivo EAR do proxy de adaptadores locais otimizados (ola_proxy.ear)
que contém o aplicativo RemoteEJBProxy na instância do servidor do WebSphere Application Server do z/OS local.
O arquivo EAR pode ser localizado no diretório $(WAS_INSTALL_ROOT)/installableApps
do sistema de arquivos do WebSphere Application
Server para z/OS.
O aplicativo remoteEJBProxy é ligado por padrão ao nome JNDI: ejb/com/ibm/ws390/ola/jca/RemoteEJBProxyHome. Se, por qualquer razão, o valor padrão precisar ser alterado, o nome JNDI do recurso de destino do aplicativo proxy poderá ser customizado por meio da página do console administrativo em Aplicativos > ola_proxy > Nome JNDI do EJB > Nome JNDI para todas as interfaces. Se o nome JNDI for atualizado, o tempo de execução do WebSphere deverá ser informado da mudança configurando a variável de ambiente ola_remote_ejb_proxy_jndiname conforme discutido no tópico Variáveis de Ambiente de Adaptadores Locais Otimizados.
Observe que a alteração do nome JNDI padrão do aplicativo remoteEJBProxy é uma etapa opcional. Ela não é necessária, a menos que você precise que ele seja alterado.
- Reinicie os servidores.
Os procedimentos de chamada para as APIs Chamar (BBOA1INV/BBGA1INV) e Enviar Solicitação (BBOA1SRQ/BBGA1SRQ) são os mesmos que aqueles para chamadas locais, com a única diferença sendo que o parâmetro de tipo de solicitação de chamada (requesttype) deve ser configurado como 2, conforme discutido no tópico Adaptadores Locais Otimizados para APIs do z/OS.
O nome do serviço (nome JNDI) especificado nas chamadas da API chamar ou enviar solicitação deve ser o nome que o WebSphere Application Server para z/OS usaria para consultar o aplicativo remoto usando o namespace JNDI federado para o servidor remoto. Por exemplo, se o namespace do servidor remoto foi federado no local remote/server5, e o aplicativo foi instalado usando o nome JNDI ejb/myRemoteApp no nome do serviço, o nome do serviço especificado na API chamar ou na API enviar solicitação será remote/server5/ejb/myRemoteApp.
Este recurso também fornece a capacidade de chamar o aplicativo remoto demtro de uma transação global iniciada pelo cliente. Ao usar um cliente CICS dentro de uma transação global, o resultado poderá resultar em um ABEND ASP3 quando o CICS detectar que a transação foi retrocedida após ela emitir um comando para confirmar a transação global. Este é um caso esperado dada a manipulação do CICS de um cenário desse tipo. O comportamento de retrocesso também é um comportamento esperado em casos em que uma condição de erro ocorre ao processar a chamada de EJB de forma que o resultado da transação global não pode ser outro além do retrocesso.