EJB Facades em Sistema Distribuído?

[alerodrigues]

Olá pessoal. Meu nome é Alexandre, trabalho há uns dois anos com Java e ainda não cheguei a desenvolver nada envolvendo EJB’s, apenas alguns exemplos básicos de alguns livros sobre o tema.

Mas na empresa onde trabalho, precisarei desenvolver dois sistemas distribuídos, com a parte web rodando no Tomcat utilizando JSF e a parte corporativa (.ear) rodando no JBOSS, e estou com algumas dúvidas com relação a melhor arquitetura desses dois sistemas, visto que é a primeira vez q trabalho com sistemas distribuídos.

Os dois sistemas vão precisar se comunicar, pois em alguns casos, cada um dos sistemas vai precisar de um processamento q será executado pelo outro sistema. Para isso pensei em criar duas Session Facades em cada sistema, uma q teria os métodos necessários à camada WEB (.war) e outra Session Facade com os métodos necessários ao outro sistema.

1. Minha dúvida é se realmente eu deveria criar duas Session Facades em cada aplicação (uma para o .war e outra para a aplicação dependente) e se essas Facades devem ficar em projetos EJB diferentes ou podem ficar no mesmo projeto ?

2. Acredito que seja melhor criar dois projetos EJB (um para cada Session Facade), neste caso eu posso deixar os dois projetos EJB’s dentro do mesmo projeto .ear, ou devo criar um .ear para cada EJB Session Facade ?

3. A camada WEB se comunicará com a camada de domínio da aplicação, através de DTO’s (pensei nessa solução por ser um sistema distribuído). Nesse caso, os DTO’s devem ficar em um projeto .jar separado ?

Pensei em agrupar os DTO’s, as Exceptions, o Business Delegate e as interfaces (Home e Remote) da Session Facade dentro de um projeto .jar q seria disponibilizado para o .war no Tomcat, mas não sei se essa é a forma correta. Assim o projeto EJB ficaria apenas com a implementação da Session Facade.

4. Como fica os nomes dos projetos ?

Pensei em criar:
app (aplicação corporativa) (.ear)
app-war (cliente web da aplicação) (.war)
app-ejb (projeto com a implementação da Session Facade (.jar)
app-dto (projeto com os dto’s e as interfaces da SF) (.jar)
app-api (projeto com as classes de negócio e os DAO’s) (.jar)

Estou com essas dúvidas e gostaria de ouvir a opinião de vcs ou de quem já trabalhou dessa forma, com dois sistemas distribuídos precisando de alguns serviços, um do outro. Como fica a arquitetura da aplicação, com relação a divisão das classes e nomenclatura dos projetos.

Qualquer ajuda é bem vinda. Mto obrigado!!!

[alerodrigues]

sim sim!

mas a classe de Business Delegate não deveria ficar em um projeto .jar separado, junto com as interfaces dos EJB’s de Session Facade ?

e qte aos serviços que a aplicação deverá prover para a outra aplicação, deveria ser criado um outro projeto .jar com as interfaces de Session Facade e os DTO’s?

e o melhor seria criar dois projetos EJB, um com os EJB’s que serão utilizados pelo .war e outro com os EJB’s que serão utilizados pela aplicação externa, ou é melhor deixar um projeto EJB só com todos os EJB’s agrupados?

estou com essas dúvidas, e não consigo dar o próximo passo sem esclarecê-las u.u

[Kenobi]

[quote=alerodrigues]Olá pessoal. Meu nome é Alexandre, trabalho há uns dois anos com Java e ainda não cheguei a desenvolver nada envolvendo EJB’s, apenas alguns exemplos básicos de alguns livros sobre o tema.

Mas na empresa onde trabalho, precisarei desenvolver dois sistemas distribuídos, com a parte web rodando no Tomcat utilizando JSF e a parte corporativa (.ear) rodando no JBOSS, e estou com algumas dúvidas com relação a melhor arquitetura desses dois sistemas, visto que é a primeira vez q trabalho com sistemas distribuídos.

Os dois sistemas vão precisar se comunicar, pois em alguns casos, cada um dos sistemas vai precisar de um processamento q será executado pelo outro sistema. Para isso pensei em criar duas Session Facades em cada sistema, uma q teria os métodos necessários à camada WEB (.war) e outra Session Facade com os métodos necessários ao outro sistema.

1. Minha dúvida é se realmente eu deveria criar duas Session Facades em cada aplicação (uma para o .war e outra para a aplicação dependente) e se essas Facades devem ficar em projetos EJB diferentes ou podem ficar no mesmo projeto ?

2. Acredito que seja melhor criar dois projetos EJB (um para cada Session Facade), neste caso eu posso deixar os dois projetos EJB’s dentro do mesmo projeto .ear, ou devo criar um .ear para cada EJB Session Facade ?

3. A camada WEB se comunicará com a camada de domínio da aplicação, através de DTO’s (pensei nessa solução por ser um sistema distribuído). Nesse caso, os DTO’s devem ficar em um projeto .jar separado ?

Pensei em agrupar os DTO’s, as Exceptions, o Business Delegate e as interfaces (Home e Remote) da Session Facade dentro de um projeto .jar q seria disponibilizado para o .war no Tomcat, mas não sei se essa é a forma correta. Assim o projeto EJB ficaria apenas com a implementação da Session Facade.

4. Como fica os nomes dos projetos ?

Pensei em criar:
app (aplicação corporativa) (.ear)
app-war (cliente web da aplicação) (.war)
app-ejb (projeto com a implementação da Session Facade (.jar)
app-dto (projeto com os dto’s e as interfaces da SF) (.jar)
app-api (projeto com as classes de negócio e os DAO’s) (.jar)

Estou com essas dúvidas e gostaria de ouvir a opinião de vcs ou de quem já trabalhou dessa forma, com dois sistemas distribuídos precisando de alguns serviços, um do outro. Como fica a arquitetura da aplicação, com relação a divisão das classes e nomenclatura dos projetos.

Qualquer ajuda é bem vinda. Mto obrigado!!![/quote]

Estou vendo vários conceitos errôneos aqui, desde Façade que não é para ser utilizado dessa forma à DTOs.

Acho sinceramente que está na hora da sua empresa contratar um Arquiteto ou Analista Sênior.

Não dá para as empresas começarem a explorar dessa forma o mercado, contratando um recurso júnior e exigindo dele conhecimento sobre arquitetura distribuída, patterns, tunning entre outros.

++++++++++

Feita minha crítica, vou tentar ajudá-lo, para seu crescimento e porque você não tem haver diretamente com isso

1 - SessionFaçade você encapsula as chamadas remotas num único ponto de entrada, para lidar com as chamadas locais à outros EJBs. Logo não faz sentido você tê-lo no War, pois ele seria um SessionBean.

2- Você pode modularizar a aplicação em diversos ejbs.jar, é uma prática recomendada para facilitar a manutenibilidade da sua aplicação.

3 - O DTO não tem haver com o sistema ser ou não distribuído e sim com a latência da rede, em diversas chamadas. Esse é um cenário que você precisa conhecer e estudar. Aqui tenho uma sugestão à você, pode trabalhar diretamente com suas entidades de domínio para operações que não requerem contexto transacional.

Como está trabalhando com JSF, vai necessitar de muitas chamadas ao banco, para popular Combos, realizar operações simples. Você pode utilizar até mesmo diretamente a Session do Hibernate , sem DAO ( isso é um anti-pattern ) ou utilizar o repository + DAO Genérico - implementação, aí você decide com o que for melhor para sua solução.

O que você for de fato controlar (transações), poderia usar um delegate que passa à sua camada business - EJB container - JBOSS no caso.

4 - Nomeclatura de projeto , não utilize Pattern como DTO no nome dos mesmos.

Faça uma abstração real , como Domain - Domínio, algo assim .

Espero ter ajudado em algo

PS: Ale falei tudo isso sobre o profissional, pois estruturação é um dos primeiros problemas com aplicações distribuídas, mas acredite, vai haver muito mais pela frente, problemas reais sérios !!

[alerodrigues]

1 - SessionFaçade você encapsula as chamadas remotas num único ponto de entrada, para lidar com as chamadas locais à outros EJBs. Logo não faz sentido você tê-lo no War, pois ele seria um SessionBean.

No caso eu teria dois pontos de chamadas remotas: as chamadas web vindas do .war e as chamadas externas vindas da outra aplicação, certo? A minha dúvida é se eu deveria ter dois projetos .jar contendo as interfaces de cada facade, já que o .war e a outra aplicação vão ficar em servidores distintos e por isso acredito eu que deveriam carregar as interfaces das facades, ficando a implementação no servidor JBOSS.

2- Você pode modularizar a aplicação em diversos ejbs.jar, é uma prática recomendada para facilitar a manutenibilidade da sua aplicação.

A aplicação deveria ter dois ejbs.jar, um com as facades utilizadas pelo .war e outro com as facades utilizadas pela aplicação externa? E as interfaces das facades, como eu disponibilizo elas para os clientes que no caso seriam o .war e a aplicação externa acessarem remotamente?

3 - O DTO não tem haver com o sistema ser ou não distribuído e sim com a latência da rede, em diversas chamadas. Esse é um cenário que você precisa conhecer e estudar. Aqui tenho uma sugestão à você, pode trabalhar diretamente com suas entidades de domínio para operações que não requerem contexto transacional.

Eu concordo com a sugestão de trabalhar diretamente com as classes de domínio, mas como os clientes da aplicação (o .war e a aplicação externa) vão enxergar essas classes se vão estar em servidores separados. Acho que não é recomendável adicionar uma referencia no netbeans e empacotar o projeto .war com as classes de negocio, já que elas conteriam as regras de negócio do sistema e deveriam ficar apenas no servidor JBOSS, certo? Por isso pensei em passar DTO’s para os clientes da aplicação que ficariam em dois projetos .jar separados: um com os DTO’s e as interfaces das facades para o .war e outro para a aplicação externa. Poderia me explicar melhor como evitar o uso dos DTO’s nesse caso e a forma de mandar as classes de dominio para o cliente se isso for recomendavel nesse caso?

4 - Nomeclatura de projeto , não utilize Pattern como DTO no nome dos mesmos.

Faça uma abstração real , como Domain - Domínio, algo assim .

Espero ter ajudado em algo

legal, mas no caso dos dois projetos .ejb que nomes eu poderia dar a eles? um projeto .ejb conteria as facades utilizadas pelo .war e outro projeto .ejb conteria as facades para a aplicação externa. Poderia ser app-ejb.jar e app-ext-ejb.jar?

PS: Ale falei tudo isso sobre o profissional, pois estruturação é um dos primeiros problemas com aplicações distribuídas, mas acredite, vai haver muito mais pela frente, problemas reais sérios !!

Entao, estou tentando entender primeiramente essa parte da estruturação dos projetos que compõem a aplicação e como agrupar as diferentes classes da aplicação nesses projetos. Pensei na seguinte organização dos projetos, e gostaria q corrigisse oq está errado:

projeto war - contendo servlets, managed beans do jsf, jsp’s, etc.

projeto jar - contendo as interfaces das facades q disponibilizam serviços para .war. Iria junto com o .war no TOMCAT.

projeto ejb - contendo a implementação das facades utilizadas pelo war.

projeto jar - contendo as classes de negócio, dao’s, e todas as regras de negócio da aplicação. Seria o projeto principal da aplicação.

projeto ejb - contendo a implementação das facades utilizadas pela aplicação externa.

projeto jar - contendo as interfaces das facades q disponibilizam serviços para a aplicação externa. Ficaria na pasta lib do JBOSS que contém o .ear da aplicação externa, para que essa aplicação externa acesse a aplicação da qual estamos falando.

ao todo teriam sete projetos (contando .ear da aplicação) dentro do netbeans compondo a aplicação toda. Mas estou achando mta coisa e gostaria da sua opinião do que está errado e oq pode ser melhorado.

desculpe estar fazendo mais perguntas é que eu gostaria realmente de entender qual a melhor forma de organizar isso tudo e agradeço sinceramente as críticas e o empenho em tentar ajudar.

OBRIGADO KENOBI !!!

[alerodrigues]

[quote=Maracuja]Ué se sim sim… não entendi…

Não, o Business Delegate fica no war; as interfaces do EJB e os DTO’s e classes uteis por exemplo num projeto separado .jar, que você deve usar como lib nos dois projetos war e no jar EJB; Crie um unico .jar EJB, ou se quiser criar mais tb não vai ter problema, o que vc vai precisar é nome com que o app server vai bindar os seus EJB’s para utilizar no Service Locator!!![/quote]

humm e o projeto .jar com as interfaces dos ejb’s e as classes úteis eu crio esse projeto dentro do netbeans como uma biblioteca de classe java ou como um cliente de aplicação corporativa?

estou com essa dúvida pq na verdade ainda não sei mto ao certo para que serve aquele tipo de projeto: cliente de aplicação corporativa. Entao estou com dúvida nesse ponto tb.

valeu pela força tb maracuja

[Kenobi]

[code][quote=alerodrigues][quote=Kenobi]
1 - SessionFaçade você encapsula as chamadas remotas num único ponto de entrada, para lidar com as chamadas locais à outros EJBs. Logo não faz sentido você tê-lo no War, pois ele seria um SessionBean.

No caso eu teria dois pontos de chamadas remotas: as chamadas web vindas do .war e as chamadas externas vindas da outra aplicação, certo? A minha dúvida é se eu deveria ter dois projetos .jar contendo as interfaces de cada facade, já que o .war e a outra aplicação vão ficar em servidores distintos e por isso acredito eu que deveriam carregar as interfaces das facades, ficando a implementação no servidor JBOSS.

[/quote]

Na verdade para sua aplicação JBOSS não importa se você estará fazendo uma chamada de um container Web, ou via RMI desktop, você estará expondo à chamadas remotas e ponto. Poderão fazer acesso diversos outros sitemas.

2- Você pode modularizar a aplicação em diversos ejbs.jar, é uma prática recomendada para facilitar a manutenibilidade da sua aplicação.

A aplicação deveria ter dois ejbs.jar, um com as facades utilizadas pelo .war e outro com as facades utilizadas pela aplicação externa? E as interfaces das facades, como eu disponibilizo elas para os clientes que no caso seriam o .war e a aplicação externa acessarem remotamente?

No caso a aplicação deveria ter EJB´s dividido por módulos de negócios, poderia até usar o pattern Façade para separar os mesmos, já que o pattern pode ser usado para subdividir a aplicação.

Mas no seu caso, haverá apenas 1 EJB.jar que será dos façades e suas implementações.

Poderia na aplicação WEB ter apenas as interfaces para as chamadas.

Eu concordo com a sugestão de trabalhar diretamente com as classes de domínio, mas como os clientes da aplicação (o .war e a aplicação externa) vão enxergar essas classes se vão estar em servidores separados. Acho que não é recomendável adicionar uma referencia no netbeans e empacotar o projeto .war com as classes de negocio, já que elas conteriam as regras de negócio do sistema e deveriam ficar apenas no servidor JBOSS, certo? Por isso pensei em passar DTO’s para os clientes da aplicação que ficariam em dois projetos .jar separados: um com os DTO’s e as interfaces das facades para o .war e outro para a aplicação externa. Poderia me explicar melhor como evitar o uso dos DTO’s nesse caso e a forma de mandar as classes de dominio para o cliente se isso for recomendavel nesse caso?

Pera suas classes de domínio vão conter as regras de negócio ? Me explica isso direito, pq você pode trabalhar com o domínio de forma separada em ambos contextos.

legal, mas no caso dos dois projetos .ejb que nomes eu poderia dar a eles? um projeto .ejb conteria as facades utilizadas pelo .war e outro projeto .ejb conteria as facades para a aplicação externa. Poderia ser app-ejb.jar e app-ext-ejb.jar?

Novamente você não tem façade utilizado no War, não faz sentido. Você tem um único ponto de entrada para acessar localmente os outros serviços a fim de reduzir latência de rede. Logo, terá somente 1 Façade e o projeto Web fará uso do mesmo.

Entao, estou tentando entender primeiramente essa parte da estruturação dos projetos que compõem a aplicação e como agrupar as diferentes classes da aplicação nesses projetos. Pensei na seguinte organização dos projetos, e gostaria q corrigisse oq está errado:

projeto war - contendo servlets, managed beans do jsf, jsp’s, etc.

projeto jar - contendo as interfaces das facades q disponibilizam serviços para .war. Iria junto com o .war no TOMCAT.

projeto ejb - contendo a implementação das facades utilizadas pelo war.

projeto jar - contendo as classes de negócio, dao’s, e todas as regras de negócio da aplicação. Seria o projeto principal da aplicação.

Muito cuidado, pois você terá DAOS na estrutura Web também, esse seria o desenho ideal, como mencionei no post anterior.

projeto ejb - contendo a implementação das facades utilizadas pela
aplicação externa.

Não existe essa diferença, pois ambas serão externas ao container. O que você pode ter é outro façade com outras regras, uma outra interface implementada.

projeto jar - contendo as interfaces das facades q disponibilizam serviços para a aplicação externa. Ficaria na pasta lib do JBOSS que contém o .ear da aplicação externa, para que essa aplicação externa acesse a aplicação da qual estamos falando.

ao todo teriam sete projetos (contando .ear da aplicação) dentro do netbeans compondo a aplicação toda. Mas estou achando mta coisa e gostaria da sua opinião do que está errado e oq pode ser melhorado.

desculpe estar fazendo mais perguntas é que eu gostaria realmente de entender qual a melhor forma de organizar isso tudo e agradeço sinceramente as críticas e o empenho em tentar ajudar.

OBRIGADO KENOBI !!!
[/quote]

Bom para responder a todas as dúvidas de organização do seu código, packages e estruturação do seu código, até mesmo auxílio de ferramentas para isso, aconselho que assista ao vídeo - http://www.infoq.com/presentations/code-organization-large-projects

Abraço,

Kenobi

[alerodrigues]

Na verdade para sua aplicação JBOSS não importa se você estará fazendo uma chamada de um container Web, ou via RMI desktop, você estará expondo à chamadas remotas e ponto. Poderão fazer acesso diversos outros sitemas.
…
Mas no seu caso, haverá apenas 1 EJB.jar que será dos façades e suas implementações.
Poderia na aplicação WEB ter apenas as interfaces para as chamadas.

O projeto .war vai ficar em um servidor TOMCAT à parte, portanto ele teria q fazer chamadas remotas ao EJB certo? Oq eu gostaria era de separar as chamadas remotas que serão feitas pelo .war das que serão feitas por outras aplicações e disponibilizá-las apenas para quem pode fazê-las. Para isso eu teria um projeto .jar que iria junto com o .war disponibilizando as chamadas que o .war pode fazer, e outro projeto .jar que iria na pasta LIB do JBOSS disponibilizando as chamadas que as aplicações externas podem fazer à aplicação.

Estou errando dessa forma?
Se sim, o certo entao seria ter as interfaces diretamente no projeto .war? e se eu precisar passar algum DTO, crio ele direto no .war tb? e no caso das aplicações externas, ond eu coloco as interfaces da Session Facade para que elas tenham acesso?

Pera suas classes de domínio vão conter as regras de negócio ? Me explica isso direito, pq você pode trabalhar com o domínio de forma separada em ambos contextos.

As classes de domínio seriam por ex: Cliente, Funcionário, Aluno. Essas classes teriam os seus atributos e os seus métodos q executariam as regras de negócio da aplicação, contemplando o modelo de domínio rico com as classes possuindo dados e responsabilidades, ao contrário do anemic domain model, certo?

Imagino que a Façade por ex. chamaria uma determinada classe de domínio que executaria uma ação e após o término dessa ação, a Façade encapsularia o resultado dentro de um DTO e repassaria isso para o cliente. Isolando assim essas classes de domínio das outras camadas.

Dessa forma, o cliente carregaria consigo apenas um .jar com os DTO’s e as interfaces da Façade, mantendo a implementação e as classes do domínio somente com o .ear. Essa forma de pensar está errada? Como eu poderia trabalhar com o domínio de forma separada como vc disse?

Novamente você não tem façade utilizado no War, não faz sentido. Você tem um único ponto de entrada para acessar localmente os outros serviços a fim de reduzir latência de rede. Logo, terá somente 1 Façade e o projeto Web fará uso do mesmo.

O certo é ter uma Façade remota apenas com TODOS os métodos que podem ser chamados tanto pelo .war qt pelas aplicações externas? Não seria mais correto separar isso em duas Façades e disponibilizá-las apenas para quem pode usá-las?

Muito cuidado, pois você terá DAOS na estrutura Web também, esse seria o desenho ideal, como mencionei no post anterior.

As Servlets ou os Managed Beans do JSF podem acessar os DAO’s? esses acessos não deveriam ser feitos apenas pelas classes do domínio?

Bom para responder a todas as dúvidas de organização do seu código, packages e estruturação do seu código, até mesmo auxílio de ferramentas para isso, aconselho que assista ao vídeo - http://www.infoq.com/presentations/code-organization-large-projects

Eu assisti o video ontem à noite em casa, mas não ajudou mta coisa porque o meu inglês é péssimo. Mas valeu pela dica, vou salvar o link e correr atrás de um curso decente de inglês o mais rápido =P

valeu pela ajuda kenobi!

[alerodrigues]

Kenobi, eu pensei na seguinte estrutura agora:

1. app.ear -> seria o .ear da aplicação implantado no JBOSS.

2. app-api.jar -> conteria as interfaces da Façade com os métodos utilizados pelo .war e os DTO’s (se necessário). Iria dentro da pasta /lib do .war.

3. app-ejb.jar -> conteria as implementações das Façades, Entities Beans, classes do domínio, DAO’s etc. Seria o projeto principal.

4. app-ext.jar -> conteria as interfaces da Façade com os métodos utilizados pelas aplicações externas e os DTO’s (se necessário). Iria dentro da pasta LIB do JBOSS para ser utilizado por essas aplicações.

5. app-net.war -> seria o cliente WEB, acessaria o projeto principal através do app-api.jar e seria implantado no TOMCAT.

Essa estrutura tá boa ou continuo pensando da forma errada?

Abraços!

[aleck]

Alexandre,

Independente dos nomes que vc deu aos projetos, tudo se resume a um projeto principal contendo seus ejbs e um client contendo as interfaces e dependencias nos sistemas que irao utilizar.

[]s

[quote=alerodrigues]Kenobi, eu pensei na seguinte estrutura agora:

1. app.ear -> seria o .ear da aplicação implantado no JBOSS.

2. app-api.jar -> conteria as interfaces da Façade com os métodos utilizados pelo .war e os DTO’s (se necessário). Iria dentro da pasta /lib do .war.

3. app-ejb.jar -> conteria as implementações das Façades, Entities Beans, classes do domínio, DAO’s etc. Seria o projeto principal.

4. app-ext.jar -> conteria as interfaces da Façade com os métodos utilizados pelas aplicações externas e os DTO’s (se necessário). Iria dentro da pasta LIB do JBOSS para ser utilizado por essas aplicações.

5. app-net.war -> seria o cliente WEB, acessaria o projeto principal através do app-api.jar e seria implantado no TOMCAT.

Essa estrutura tá boa ou continuo pensando da forma errada?

Abraços![/quote]

[Kenobi]

[quote=alerodrigues]Kenobi, eu pensei na seguinte estrutura agora:

1. app.ear -> seria o .ear da aplicação implantado no JBOSS.

2. app-api.jar -> conteria as interfaces da Façade com os métodos utilizados pelo .war e os DTO’s (se necessário). Iria dentro da pasta /lib do .war.

3. app-ejb.jar -> conteria as implementações das Façades, Entities Beans, classes do domínio, DAO’s etc. Seria o projeto principal.

4. app-ext.jar -> conteria as interfaces da Façade com os métodos utilizados pelas aplicações externas e os DTO’s (se necessário). Iria dentro da pasta LIB do JBOSS para ser utilizado por essas aplicações.

5. app-net.war -> seria o cliente WEB, acessaria o projeto principal através do app-api.jar e seria implantado no TOMCAT.

Essa estrutura tá boa ou continuo pensando da forma errada?

Abraços![/quote]

Eu não usaria DTO´s, trabalharia diretamente com os pojos de domínio, mas se sua aplicação requer encapsulamento, para diminuir o tráfego de rede, tente deixar os DTOS num único jar, pois possivelmente, sua aplicação vai ter modificações e vai ter que sair caçando os DTOS em pelo menos duas distribuições pelo seu exemplo de estruturação.

[JMan]

Você pode criar uma camada Business Delegate no seu projeto .war, a acessar o seu Session Façade numa boa via um Service Locator por exemplo; as classes que precisarem ser compartilhadas, crie um projeto de “infra” e adicione como lib nos dois projetos!!!

Espero que ajude.

[JMan]

Ué se sim sim… não entendi…

Não, o Business Delegate fica no war; as interfaces do EJB e os DTO’s e classes uteis por exemplo num projeto separado .jar, que você deve usar como lib nos dois projetos war e no jar EJB; Crie um unico .jar EJB, ou se quiser criar mais tb não vai ter problema, o que vc vai precisar é nome com que o app server vai bindar os seus EJB’s para utilizar no Service Locator!!!