EJB: Entity Beans com Container-Managed Persistence

Um Pouco de Teoria para Entender o Exemplo

Lembrando o que é um Entity Bean

• Um Entity Bean representa um "business object" armazenado de forma persistente
  • Um "Business Object" nada mais é do que uma entidade do domínio do problema
  • Exemplos: clientes, pedidos, produtos, ...
• O mecanismo de persistência é tipicamente um banco de dados relacional
• Tipicamente:
  • Cada Entity Bean corresponde a uma tabela do BD
  • Cada instância do Bean corresponde a uma linha (um registro) da tabela
  • Os atributos do Bean são as colunas da tabela
• Apresentamos a seguir 4 grandes diferenças entre Entity Beans e Session Beans

Persistência

• O estado de um entity bean é salvo num mecanismo de armazenamento permanente, tipicamente um banco de dados

Acesso Compartilhado

• Entity beans podem ser compartilhados por múltiplos clientes
• Devido a este compartilhamento, precisamos do conceito de transação e de tratamento adequado de concorrência

Chave Primária

• Cada entity bean tem um Object Identifier (OID) único (a chave primária)
• Útil para localizar uma instância particular

Relacionamentos

• Entity beans podem estar relacionados com outros entity beans, como tabelas num banco de dados
  • O bean AlunoEJB pode estar relacionado com o bean DisciplinaEJB porque alunos se matriculam em disciplinas

Sobre Container-Managed Persistence

• Há duas formas de implementar a persistência:
  • Codificada pelo programador (Bean-Managed Persistence - BMP)
  • Tratada automaticamente pelo Container (Container-Managed Persistence - CMP)
• Parece melhor deixar o Container tratar da persistência
  • Todas as chamadas de acesso ao BD são tratadas pelo container
  • Relacionamentos também são tratados pelo container
    • Container-Managed Relationships - CMR
  • BMP existe porque, no início, J2EE não tratava bem relacionamentos em CMP
  • Mesmo hoje, há situações especiais em que é melhor controlar melhor o código SQL usado para acessar o Banco de Dados
• Com CMP, especificamos o mapeamento entre os atributos do bean e o BD através de Deployment Descriptor
  • Isso poupa muito trabalho
  • Também tem a vantagem de deixar a aplicação independente do gerenciador de BD

Esquema Abstrato

• O esquema abstrato deve ser especificado no Deployment Descriptor para que o container possa gerar as chamadas para acessar o BD
• O esquema é "abstrato" para diferenciá-lo do esquema lógico implementado no BD (as tabelas e colunas particulares existentes no BD)
• Usando CMP, poderemos definir vários métodos para localizar uma ou mais instâncias de beans
  • Fazemos isso com "finder methods" ou "select methods"
    • Finder methods são expostos a clientes na Home interface
    • Select methods não são expostos a clientes. São usados na classe de implementação
      • São usados para localizar EJBs relacionados com um outro EJB
  • Exemplos de finder methods:
    • findByPrimaryKey("836")
      • Todo bean tem que ter isso
    • findByLastName("Silva")
    • findInRange(20.0, 99.0)
• Para cada finder method, exceto findByPrimaryKey, o programador deve especificar no Deployment Descriptor apenas um statement na linguagem EJB QL (semelhante a SQL)
  • O container vai executar esta query quando se chama o finder method
• É útil manter um diagrama do esquema abstrato
  • Um exemplo segue
  • Falaremos mais de relacionamentos adiante

Campos Persistentes

• Os campos persistentes de um entity bean são armazenados num BD
• Esses atributos são o estado do bean
  • Esse estado é sincronizado automaticamente com o BD pelo container
  • Tipicamente, o bean corresponde a uma tabela e cada atributo a uma coluna da tabela
• Esses atributos são virtuais no sentido de que não são declarados no bean
  • Basta haver métodos "getter" e "setter" para que o container automaticamente tome conta dos atributos e de seu mapeamento para o BD

Campos de Relacionamentos

• Um campo de relacionamento é como uma chave estrangeira num BD
  • Identifica um bean relacionado
• Tais campos também são virtuais e são definidos através de métodos de acesso
  • Porém, campos de relacionamento não representam o estado do bean
• Falamos mais sobre relacionamentos adiante (direção/navegabilidade)

Multiplicidade em Relacionamentos Container-Managed

• Há 4 tipos de multiplicidades:
  • Um-para-um: Cada instância de um bean está relacionada a exatamente uma instância de outro bean
    • Numa biblioteca, haveria um relacionamento um-para-um entre uma cópia de um livro (ExemplarLivroEJB) e o usuário ao qual este exemplar está emprestado (UsuarioEJB)
  • Um-para-muitos: Cada instância de um bean está relacionada a várias instâncias de outro bean
    • Um pedido de compra (PedidoEJB) pode conter vários itens (ItemEJB)
  • Muitos-para-um: Várias instâncias de um bean estão relacionadas a exatamente uma instância de outro bean
    • No exemplo anterior, do ponto de vista de ItemEJB, o relacionamento com PedidoEJB é Muitos-para-um
  • Muitos-para-muitos: Várias instâncias de um bean estão relacionadas a várias instâncias de outro bean
    • Num sistema de matrícula de uma universidade, o bean AlunoEJB teria uma relação muitos-para-muitos com o bean DisciplinaEJB, já que um aluno se matricula em várias disciplinas e cada disciplina tem vários alunos

Direção/Navegabilidade em Relacionamentos Container-Managed

• Num relacionamento bidirecional, cada entity bean tem um campo de relacionamento que referencia o outro bean
• Através de um relacionamento, o código de um bean pode acessar o bean relacionado
• Relacionamentos também podem ser unidirecionais, quando apenas um dos beans "conhece" o outro
• Queries especificadas em EJB QL podem navegar nos relacionamentos
  • A navegabilidade depende da direção do relacionamento

O Ciclo de Vida de um Entity Bean

• No pool, a instância de um bean não está associada a uma entidade com identidade específica
  • Isto é, todas as instâncias são iguais e não há estado mantido
• "ejbCreate" significa que o objeto tem identidade nova e deverá ser criado no banco de dados
• "ejbRemove" significa que o objeto com esta identidade deve ser removido do BD
• "ejbActivate" e "ejbPassivate" significam que o container está tentando recuperar recursos escassos

Resumo da Applicação RosterApp

• A aplicação RosterApp mantém a lista de jogadores (roster) para vários esportes em várias "ligas" (divisões)
• Há 5 componentes na aplicação
  • RosterAppClient: Um "application client" que acessa o bean de sessão RosterEJB através da interface remota
  • RosterEJB: bean de sessão que serve de "façade" para a aplicação
    • Uma "façade" é um ponto de acesso único para um sistema
  • PlayerEJB, TeamEJB, e LeagueEJB: O bean RosterEJB acessa esses entity beans através de suas interfaces locais
    • Cada bean pode ter interfaces remotas e locais
    • Usar uma interface local significa que esses 3 beans não são acessados remotamente
• Os 3 beans de entidade usam CMP para campos e relacionamentos
• Os beans TeamEJB e PlayerEJB têm relacionamento bidirecional, muitos-para-muitos
  • Certos jogadores participam de mais de um esporte
• Os beans LeagueEJB e TeamEJB têm relacionamento bidirecionais com multiplicidade um-para-muitos
  • Uma liga tem muitos times mas um time pertence a uma única liga
• A figura abaixo mostra os componentes e relacionamentos
  • As linhas tracejadas indicam que JNDI será usado para localizar o alvo
  • As linhas sólidas representam os relacionamentos mantidos pelo container

O Código do Entity Bean PlayerEJB

• Representa um jogador
• Precisamos de 3 coisas:
  • Uma Interface Local (LocalPlayer)
  • Uma Interface Home Local (LocalPlayerHome)
  • Uma Classe de Implementação (PlayerBean)
• O código está no diretório src/cmproster

A Interface Local

• A interface define os business methods e os métodos de acesso que um cliente local pode chamar
• Os métodos de acessos para campos persistentes são:
  • getPlayerID()
  • getName()
  • getPosition()
  • getSalary()
• O método de acesso para relacionamentos é:
  • getTeams()
• Os métodos seguintes são business methods
  • getleagues()
  • getSports()
• Observe que o cliente não poderá chamar os métodos "set" correspondendo aos "get" acima, já que não aparecem na interface em LocalPlayer
  • Porém, os métodos "set" serão criados no EJB

package team;

import java.util.*;
import javax.ejb.*;

public interface LocalPlayer extends EJBLocalObject {
  public String getPlayerId();
  public String getName();
  public String getPosition();
  public double getSalary();
  public Collection getTeams();
  public Collection getLeagues() throws FinderException;
  public Collection getSports() throws FinderException;
}

A Interface Home Local

• A interface local home define os métodos de criação (create), de localização (finder) e home que podem ser chamados por clientes locais
• Um método home é semelhante a um método estático: é um método que se aplica a todos os entity beans de uma certa classe
  • Isso é diferente de um business method que se aplica a uma instância com identidade particular
  • Durante a execução de um método home, não há estado a ser acessado
  • Tipicamente, um home method localiza uma coleção de instâncias de beans e chama business methods à medida que itera na coleção
• Finder methods localizam instâncias de beans e iniciam com "find"
  • O Deployment Descriptor vai conter statements em EJB QL para acessar o BD
• Aqui está LocalPlayerHome.java:

package team;

import java.util.*;
import javax.ejb.*;

public interface LocalPlayerHome extends EJBLocalHome {
    
  public LocalPlayer create (String id, String name, String position,
                             double salary)
                     throws CreateException;
  
  public LocalPlayer findByPrimaryKey (String id)
                     throws FinderException;
  
  public Collection findByPosition(String position) 
                    throws FinderException;

  public Collection findByHigherSalary(String name) 
                    throws FinderException;

  public Collection findBySalaryRange(double low, double high) 
                    throws FinderException;

  public Collection findByLeague(LocalLeague league) 
                    throws FinderException;

  public Collection findBySport(String sport) 
                    throws FinderException;

  public Collection findByCity(String city) 
                    throws FinderException;

  public Collection findAll() 
                    throws FinderException;

  public Collection findNotOnTeam() 
                    throws FinderException;

  public Collection findByPositionAndName(String position, 
                    String name)
                    throws FinderException;

  public Collection findByTest (String parm1, String parm2, String parm3)
                    throws FinderException;

}

A Classe de Implementação

• A classe é public e abstract
• Os métodos que devem ser declarados são:
  • Os métodos abstratos de acesso (get e set) para os campos persistentes
  • Os métodos abstratos de acesso (get e set) para os relacionamentos
  • Métodos abstratos de seleção ("select methods" - ver adiante)
  • Os métodos home
  • Os business methods
• Pouco código deve ser escrito num entity bean com CMP
  • Chamadas de acesso ao BD não são escritos :-)
  • O estado persistente é representado por campos virtuais persistentes definidos através de métodos abstratos (get, set), mas nenhum código de acesso é necessário
  • Os relacionamentos são representados por campos virtuais de relacionamento definidos através de métodos abstratos (get, set), mas nenhum código de acesso é necessário
  • O método findByPrimaryKey() para localizar instâncias particulares é implementado pelo container
  • Métodos especiais de descoberta de instâncias (Finder Methods) são implementados pelo container e o desenvolvedor deve apenas fornecer os statements em EJB QL
    • Fazem parte da interface home
  • Métodos especiais de seleção (Select Methods) são implementados pelo container
    • São métodos como os "finders" mas são acessados "internamente" pelo próprio bean e não participam de interfaces (nem home, nem local, nem remota)
  • ejbCreate deve retornar null
• Por exemplo, aqui está PlayerBean.java

package team;

import java.util.*;
import javax.ejb.*;
import javax.naming.*;
import util.Debug;

public abstract class PlayerBean implements EntityBean {

  private EntityContext context;

  // Access methods for persistent fields

  public abstract String getPlayerId();
  public abstract void setPlayerId(String id);
  
  public abstract String getName();
  public abstract void setName(String name);

  public abstract String getPosition();
  public abstract void setPosition(String position);

  public abstract double getSalary();
  public abstract void setSalary(double salary);

  // Access methods for relationship fields

  public abstract Collection getTeams();
  public abstract void setTeams(Collection teams);

  // Select methods

  public abstract Collection ejbSelectLeagues(LocalPlayer player)
                  throws FinderException;

  public abstract Collection ejbSelectSports(LocalPlayer player)
                  throws FinderException;

  // Business methods

  public Collection getLeagues() throws FinderException {

    LocalPlayer player = 
        (team.LocalPlayer)context.getEJBLocalObject();
    return ejbSelectLeagues(player);
  }

  public Collection getSports() throws FinderException {

    LocalPlayer player = 
        (team.LocalPlayer)context.getEJBLocalObject();
    return ejbSelectSports(player);
  }

  // EntityBean  methods

  public String ejbCreate (String id, String name, String position,
    double salary) throws CreateException {

    Debug.print("PlayerBean ejbCreate");
    setPlayerId(id);
    setName(name);
    setPosition(position);
    setSalary(salary);
    return id;
  }
       
  public void ejbPostCreate (String id, String name, String position,
    double salary) throws CreateException { }

  public void setEntityContext(EntityContext ctx) {
    context = ctx;
  }
  
  public void unsetEntityContext() {
    context = null;
  }
  
  public void ejbRemove() {
    Debug.print("PlayerBean ejbRemove");
  }
  
  public void ejbLoad() {
    Debug.print("PlayerBean ejbLoad");
  }
  
  public void ejbStore() {
    Debug.print("PlayerBean ejbStore");
  }
  
  public void ejbPassivate() { }
  
  public void ejbActivate() { }

} // PlayerBean class

Métodos de acesso

• Um entity bean com CMP tem campos virtuais para atributos persistentes e relacionamentos
• Como se pode ver acima, basta definir os métodos abstratos get e set
  • O resto é feito no Deployment Descriptor e pelo Container
• Os métodos de acesso para campos persistentes seguem:

public abstract class PlayerBean implements EntityBean {

  // ...

  // Access methods for persistent fields

  public abstract String getPlayerId();
  public abstract void setPlayerId(String id);
  
  public abstract String getName();
  public abstract void setName(String name);

  public abstract String getPosition();
  public abstract void setPosition(String position);

  public abstract double getSalary();
  public abstract void setSalary(double salary);
  // ...
}

• Métodos de acesso para relacionamento
  • Um jogador pode pertencer a vários times
  • Em PlayerEJB, temos um campo virtual de relacionamento chamado "teams" que será definido no Deployment Descriptor
  • Na classe PlayerBean class, os Métodos de acesso para relacionamento são:

  // Access methods for relationship fields

  public abstract Collection getTeams();
  public abstract void setTeams(Collection teams);

Métodos de Seleção

• Um método de seleção acessa um banco de dados e retorna vários objetos
• Precisamos especificar a forma de acessar o BD usando a linguagem de query EJB QL, semelhante a SQL
  • Este statement está no Deployment Descriptor
• Nossa classe PlayerBean não precisa implementar métodos de seleção
  • São implementados automaticamente pelo container
• Os métodos de seleção não são expostas em interfaces local ou remota
  • Só podem ser usadas pelos business methods do entity bean
• Temos os seguintes Select Methods:

  // Select methods

  public abstract Collection ejbSelectLeagues(LocalPlayer player)
                  throws FinderException;

  public abstract Collection ejbSelectSports(LocalPlayer player)
                  throws FinderException;

Business Methods

• Os dois business methods usados aqui existem apenas para encapsular os Select Methods
  • Por motivos técnicos (para facilitar a vida do container), os Select Methods não são acessados pelo cliente
  • No código abaixo, getEJBLocalObject() retorna o objeto que implementa a "interface local", isto é, a instância do EJB
    • É como se fosse "this" no mundo EJB
    • Lembre que o bean não implementa as interfaces local ou remota

  // Business methods

  public Collection getLeagues() throws FinderException {

    LocalPlayer player = 
        (team.LocalPlayer)context.getEJBLocalObject();
    return ejbSelectLeagues(player);
  }

  public Collection getSports() throws FinderException {

    LocalPlayer player = 
        (team.LocalPlayer)context.getEJBLocalObject();
    return ejbSelectSports(player);
  }

Callback methods

• Estão quase todos vazios, porque o container já faz tudo
• O ejbCreate inicializa o estado da instância do bean:

  public String ejbCreate (String id, String name, String position,
    double salary) throws CreateException {

    Debug.print("PlayerBean ejbCreate");
    setPlayerId(id);
    setName(name);
    setPosition(position);
    setSalary(salary);
    return id;
  }

• ejbRemove é chamado imediatamente antes de remover a linha do BD
• ejbPostCreate deve ter os mesmos parâmetros que ejbCreate
  • O que esse método faz é estranho e você não deve se preocupar com ele aqui
  • Veja a especificação EJB para detalhes
  • Tem a ver com o uso de "this" no meio do método ejbCreate
  • Este método é usado para acertar um campo de relacionamento na inicialização
    • Relacionamentos não podem ser inicializados em ejbCreate
• ejbLoad é chamado logo depois que o estado do bean é lido do BD
• ejbStore é chamado logo antes de salvar o estado do bean no BD

• O leitor pode examinar os outros dois entity beans TeamEJB e LeagueEJB
  • São muito semelhantes: não há muito código

Os Deployment Descriptors para RosterApp

• Use deploytool para examinar o arquivo RosterApp.ear
• Queremos focar em coisas novas do deployment descriptor, principalmente o tratamento de persistência e relacionamentos

RosterApp

• Selecione o nodo RosterApp (a aplicação inteira)

Orelha General:

• Temos 2 arquivos EJB JAR: team-ejb.jar e roster-ejb.jar
• Temos um Application Client: roster-ac.jar
• Para ver isso no deployment descriptor, examine o DD da aplicação inteira, application.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'http://java.sun.com/dtd/application_1_3.dtd'>

<application>
  <display-name>RosterApp</display-name>
  <description>Application description</description>
  <module>
    <ejb>roster-ejb.jar</ejb>
  </module>
  <module>
    <java>roster-ac.jar</java>
  </module>
  <module>
    <ejb>team-ejb.jar</ejb>
  </module>
</application>

Orelha JNDI Names:

• Temos a lista de nomes JNDI para os EJBs
  • No DD, isso fica na parte dependente de servidor J2EE, no arquivo sun-j2ee-ri.xml da aplicação

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE j2ee-ri-specific-information PUBLIC '-//Sun Microsystems Inc.//DTD J2EE Reference Implementation 1.3//EN' 'http://localhost:8000/sun-j2ee-ri_1_3.dtd'>
<j2ee-ri-specific-information>
...
  <enterprise-beans>
    <module-name>team-ejb.jar</module-name>
    <unique-id>0</unique-id>
    <ejb>
      <ejb-name>LeagueEJB</ejb-name>
      <jndi-name>MyLeague</jndi-name>
...
    </ejb>

• A tabela de References contém 2 entradas:
  • RosterClient faz referência ao "coded name" ejb/SimpleRoster que correponde a MyRoster
    • MyRoster já foi definido acima
    • RosterClient aparece no DD sun-j2ee-ri.xml de roster-ac.jar (veja abaixo)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE j2ee-ri-specific-information PUBLIC '-//Sun Microsystems Inc.//DTD J2EE Reference Implementation 1.3//EN' 'http://localhost:8000/sun-j2ee-ri_1_3.dtd'>

<j2ee-ri-specific-information>
  <app-client>
    <ejb-ref>
      <ejb-ref-name>ejb/SimpleRoster</ejb-ref-name>
      <jndi-name>MyRoster</jndi-name>
    </ejb-ref>
  </app-client>
</j2ee-ri-specific-information>

• A segunda referência é do tipo "Resource" e especifica o nome JNDI do banco de dados acessado pelos Entity beans contidas no módulo TeamJAR (jdbc/cloudscape)
  • Isso acessa um banco de dados (CloudscapeDB) já criado no produto Cloudscape e já registrado no servidor J2EE
  • Isso já vem pronto quando você instala o J2EE SDK
  • Veja como aparece no DD sun-j2ee-ri.xml da aplicação

<j2ee-ri-specific-information>
...
  <enterprise-beans>
    <module-name>team-ejb.jar</module-name>
    <unique-id>0</unique-id>
    <ejb>
      <ejb-name>LeagueEJB</ejb-name>
...
    </ejb>
    <ejb>
      <ejb-name>TeamEJB</ejb-name>
...
    </ejb>
    <ejb>
      <ejb-name>PlayerEJB</ejb-name>
...
    </ejb>
...
    <cmpresource>
      <ds-jndi-name>jdbc/Cloudscape</ds-jndi-name>
      <default-resource-principal>
        <name></name>
        <password></password>
      </default-resource-principal>
    </cmpresource>
  </enterprise-beans>
</j2ee-ri-specific-information>

RosterClient

• Selecione o nodo RosterClient
• Orelha JAR FILE:
  • Pode-se ver que há 2 DDs e uma classe (RosterClient.class)
  • Os DDs são application-client.xml e sun-j2ee-ri.xml

• Orelha EJB Refs:
  • O cliente acessa apenas o EJB de sessão com as referência ejb/SimpleRoster
  • Observe também que o acesso é remoto
• Isso tudo pode ser verificado no DD application-client.xml abaixo

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE application-client PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application Client 1.3//EN' 'http://java.sun.com/dtd/application-client_1_3.dtd'>

<application-client>
  <display-name>RosterClient</display-name>
  <ejb-ref>
    <ejb-ref-name>ejb/SimpleRoster</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>roster.RosterHome</home>
    <remote>roster.Roster</remote>
  </ejb-ref>
</application-client>

RosterJAR

• Selecione o nodo RosterJAR, contendo o bean de sessão RosterEJB
  • Orelha "General":
    • Package roster: Os arquivos necessários para o RosterEJB são a classe de implementação, a interface remota e a interface home
    • Package team: inclui as interfaces locais para as entity beans acessados pelo bean de sessão RosterEJB
    • Package util: contém as classes de apoio para a aplicação
• Selecione o nodo RosterEJB
• Orelha "General":
  • Veja que RosterEJB é um bean de sessão com estado e com acesso remoto (acessado por um cliente remoto)
  • Já que não há acesso local, os campos "Local Interfaces" estão vazios
  • Veja isso no DD ejb-jar.xml de roster-ejb.jar

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

<ejb-jar>
  <display-name>RosterJAR</display-name>
  <enterprise-beans>
    <session>
      <display-name>RosterEJB</display-name>
      <ejb-name>RosterEJB</ejb-name>
      <home>roster.RosterHome</home>
      <remote>roster.Roster</remote>
      <ejb-class>roster.RosterBean</ejb-class>
      <session-type>Stateful</session-type>
      <transaction-type>Container</transaction-type>
      <ejb-local-ref>
        <ejb-ref-name>ejb/SimpleLeague</ejb-ref-name>
        <ejb-ref-type>Entity</ejb-ref-type>
        <local-home>team.LocalLeagueHome</local-home>
        <local>team.LocalLeague</local>
        <ejb-link>LeagueEJB</ejb-link>
      </ejb-local-ref>
      <ejb-local-ref>
        <ejb-ref-name>ejb/SimpleTeam</ejb-ref-name>
        <ejb-ref-type>Entity</ejb-ref-type>
        <local-home>team.LocalTeamHome</local-home>
        <local>team.LocalTeam</local>
        <ejb-link>TeamEJB</ejb-link>
      </ejb-local-ref>
      <ejb-local-ref>
        <ejb-ref-name>ejb/SimplePlayer</ejb-ref-name>
        <ejb-ref-type>Entity</ejb-ref-type>
        <local-home>team.LocalPlayerHome</local-home>
        <local>team.LocalPlayer</local>
        <ejb-link>PlayerEJB</ejb-link>
      </ejb-local-ref>
      <security-identity>
        <description></description>
        <use-caller-identity></use-caller-identity>
      </security-identity>
    </session>
  </enterprise-beans>
</ejb-jar>

• Orelha "EJB Refs"
  • O bean RosterEJB acessa 3 entity beans: PlayerEJB, TeamEJB, e LeagueEJB
  • Observe que o acesso é local
  • Selecione uma linha (digamos ejb/SimpleLeague) e observe que o nome LeagueEJB aparece no campo "Enterprise Bean Name"
    • Isto é usado se um componente fizer acesso local a um entity bean
  • Tudo isso é mostrado no DD acima

TeamJAR

• Selecione o nodo TeamJAR, contendo 3 entity beans
• Orelha "General":
  • Há 2 packages: team com os EJBs e util com classes de apoio
• Orelha "Relationships":
  • Aqui você define os relacionamentos entre entity beans com CMP
  • Dois relacionamentos são definidos aqui: TeamEJB-PlayerEJB e LeagueEJB-TeamEJB
    • No relacionamento TeamEJB-PlayerEJB o bean TeamEJB bean é chamado EJB A e o bean PlayerEJB é EJB B (poderia ser o contrário sem problemas)
    • Selecione o relacionamento TeamEJB-PlayerEJB e clique em Edit
      • Vê como o relacionamento pode ser definido
      • Collection é usado quando pode haver duplicação
      • Set é usado quando não pode haver duplicação
    • Para o outro relacionamento (LeagueEJB-TeamEJB), o "cascading delete" está ligado (ao deletar a liga, os teams somem)

• Veja isso no DD ejb-jar.xml de team-ejb.jar
  • Ver também este artigo interessante

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>

<ejb-jar>
  <display-name>TeamJAR</display-name>
  <enterprise-beans>
    <entity>
      <display-name>LeagueEJB</display-name>
      <ejb-name>LeagueEJB</ejb-name>
      <local-home>team.LocalLeagueHome</local-home>
      <local>team.LocalLeague</local>
      <ejb-class>team.LeagueBean</ejb-class>
      <persistence-type>Container</persistence-type>
      <prim-key-class>java.lang.String</prim-key-class>
      <reentrant>False</reentrant>
      <cmp-version>2.x</cmp-version>
      <abstract-schema-name>League</abstract-schema-name>
      <cmp-field>
        <description>no description</description>
        <field-name>leagueId</field-name>
      </cmp-field>
      <cmp-field>
        <description>no description</description>
        <field-name>name</field-name>
      </cmp-field>
      <cmp-field>
        <description>no description</description>
        <field-name>sport</field-name>
      </cmp-field>
      <primkey-field>leagueId</primkey-field>
      <security-identity>
        <description></description>
        <use-caller-identity></use-caller-identity>
      </security-identity>
    </entity>
    <entity>
      <display-name>TeamEJB</display-name>
      <ejb-name>TeamEJB</ejb-name>
...
    </entity>
    <entity>
      <display-name>PlayerEJB</display-name>
      <ejb-name>PlayerEJB</ejb-name>
      <local-home>team.LocalPlayerHome</local-home>
      <local>team.LocalPlayer</local>
      <ejb-class>team.PlayerBean</ejb-class>
      <persistence-type>Container</persistence-type>
      <prim-key-class>java.lang.String</prim-key-class>
      <reentrant>False</reentrant>
      <cmp-version>2.x</cmp-version>
      <abstract-schema-name>Player</abstract-schema-name>
      <query>
        <description></description>
        <query-method>
          <method-name>findNotOnTeam</method-name>
          <method-params />
        </query-method>
        <ejb-ql>select object(p) from Player p 
where p.teams is empty</ejb-ql>
      </query>
...
    </entity>
  </enterprise-beans>
  <relationships>
    <ejb-relation>
      <description>Team To Player</description>
      <ejb-relation-name></ejb-relation-name>
      <ejb-relationship-role>
        <ejb-relationship-role-name>TeamEJB</ejb-relationship-role-name>
        <multiplicity>many</multiplicity>
        <relationship-role-source>
          <ejb-name>TeamEJB</ejb-name>
        </relationship-role-source>
        <cmr-field>
          <cmr-field-name>players</cmr-field-name>
          <cmr-field-type>java.util.Collection</cmr-field-type>
        </cmr-field>
      </ejb-relationship-role>
      <ejb-relationship-role>
        <ejb-relationship-role-name>PlayerEJB</ejb-relationship-role-name>
        <multiplicity>many</multiplicity>
        <relationship-role-source>
          <ejb-name>PlayerEJB</ejb-name>
        </relationship-role-source>
        <cmr-field>
          <cmr-field-name>teams</cmr-field-name>
          <cmr-field-type>java.util.Collection</cmr-field-type>
        </cmr-field>
      </ejb-relationship-role>
    </ejb-relation>
    <ejb-relation>
      <description>League-Team</description>
      <ejb-relation-name></ejb-relation-name>
      <ejb-relationship-role>
        <ejb-relationship-role-name>LeagueEJB</ejb-relationship-role-name>
        <multiplicity>one</multiplicity>
        <relationship-role-source>
          <ejb-name>LeagueEJB</ejb-name>
        </relationship-role-source>
        <cmr-field>
          <cmr-field-name>teams</cmr-field-name>
          <cmr-field-type>java.util.Collection</cmr-field-type>
        </cmr-field>
      </ejb-relationship-role>
      <ejb-relationship-role>
        <ejb-relationship-role-name>TeamEJB</ejb-relationship-role-name>
        <multiplicity>many</multiplicity>
        <cascade-delete />
        <relationship-role-source>
          <ejb-name>TeamEJB</ejb-name>
        </relationship-role-source>
        <cmr-field>
          <cmr-field-name>league</cmr-field-name>
        </cmr-field>
      </ejb-relationship-role>
    </ejb-relation>
  </relationships>
...
 </ejb-jar>

• Selecione o nodo PlayerEJB para examinar um entity bean
  • Orelha "General":
    • Vemos as classes de implementação e as interfaces
    • Já que o entity bean PlayerEJB usa CMP, possui interfaces locais e não permite acesso remoto
  • Orelha "Entity":
    • Os radio buttons do topo definem o tipo de persistência
      • Versão 1.0 não suporta relacionamentos
    • Indicam-se os campos que devem persistir
      • Não escolha campos de relacionamentos (como teams)
    • O "Abstract Schema Name" é Player e será usado quando montarmos os queries em EJB QL
    • Podemos ver essas coisas no DD mostrado acima
  • Dialog Box Finder/Select Methods:
    • Clique em "Finder/Select Methods"
    • Você pode editar os queries em EJB QL (ver capítulo adiante)
    • Tanto finder methods quanto select methods têm query em EJB QL
    • Podemos ver essas coisas também no DD mostrado acima
  • Dialog Box "Entity Deployment Settings":
    • Clique em "Deployment Settings"
    • Você vê como o CMP será tratado
    • O que vemos aqui é particular para o J2EE SDK e poderá ser diferente em outro servidor
    • Aqui, você vê que um BD relacional é usado para armazenar a informação

• O servidor J2EE acessa o BD usando SQL
  • Os statements SQL são configurados aqui também
  • Você pode gerar o SQL automaticamente (clique em "Generate Default SQL")
  • Pode editar o SQL depois se desejado
  • Clique em "Container Methods" para ver o que mais pode ser configurado:

• Dialog Box "Database Deployment Settings":
  • Clique em "Deployment Settings" e em "Database Settings"
  • Informe o nome JNDI do banco de dados (jdbc/Cloudscape)
  • Não precisa preencher o "User Name" e "Password" com cloudscape

Chamadas de Métodos em RosterApp

• Queremos mostrar interações entre componentes quando a aplicação está executando
• Para tanto, discutiremos a seqüência de chamadas de métodos para funcionalidade particular
• Acompanhe com o código fonte no diretório src/cmproster

Criação de um Jogador

RosterClient

• RosterClient chama o business method createPlayer do session bean RosterEJB

      Context initial = new InitialContext();
      Object objref = initial.lookup("java:comp/env/ejb/SimpleRoster");

      RosterHome home = 
          (RosterHome)PortableRemoteObject.narrow(objref, 
                                       RosterHome.class);
      Roster myRoster = home.create();
      // ...
      myRoster.createPlayer(
                 new PlayerDetails(
                   "P1", "Phil Jones", "goalkeeper", 100.00));

• No código acima, Roster é a interface remota do bean RosterEJB
• PlayerDetails encapsula informação sobre um jogador particular

RosterEJB

• O método createPlayer do bean de sessão RosterEJB cria uma nova instância do bean de entidade PlayerEJB
• O acesso a PlayerEJB é local e o método create está definido na interface local LocalPlayerHome

  public void createPlayer(PlayerDetails details) { 

    Debug.print("RosterBean createPlayer");
    try {
      LocalPlayer player = playerHome.create(details.getId(), 
          details.getName(), details.getPosition(), details.getSalary());
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  }

• De onde veio a referência playerHome?
  • Aqui está o ejbCreate de RosterBean

  public void ejbCreate() throws CreateException {

    Debug.print("RosterBean ejbCreate");
    try {
      playerHome = lookupPlayer();
      teamHome = lookupTeam();
      leagueHome = lookupLeague();
    } catch (NamingException ex) {
      throw new CreateException(ex.getMessage());
    }
  }

  private LocalPlayerHome lookupPlayer() throws NamingException {
     
    Context initial = new InitialContext();
    Object objref = initial.lookup("java:comp/env/ejb/SimplePlayer");
    return (LocalPlayerHome) objref;
  }

PlayerEJB

• Para criar o jogador, o método ejbCreate atribui os parâmetros aos campos persistentes do bean
  • Depois que ejbCreate termina, o container vai usar um statement SQL SELECT para inserir a informação no banco de dados
• Aqui está o código do ejbCreate

  public String ejbCreate (String id, String name, String position,
    double salary) throws CreateException {

    Debug.print("PlayerBean ejbCreate");
    setPlayerId(id);
    setName(name);
    setPosition(position);
    setSalary(salary);
    return id;
  }

Adição de um Jogador a um Time

RosterClient

• RosterClient chama o business method addPlayer de RosterEJB
• Os parâmetros P1 e T1 são as chaves primárias das instâncias de PlayerEJB e TeamEJB respectivamente

      myRoster.addPlayer("P1", "T1");

RosterEJB

• O método addPlayer faz 2 coisas:
  • Localiza as instâncias desejadas de PlayerEJB e TeamEJB usando findByPrimaryKey
  • Depois, chama o método addPlayer do bean TeamEJB

  public void addPlayer(String playerId, String teamId) { 

    Debug.print("RosterBean addPlayer");
    try {
      LocalTeam team = teamHome.findByPrimaryKey(teamId);
      LocalPlayer player = playerHome.findByPrimaryKey(playerId);
      team.addPlayer(player);
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  }

TeamEJB

• O bean TeamEJB tem um campo de relacionamento chamado "players"
• Os métodos de acesso deste campo virtual são:

  public abstract Collection getPlayers();
  public abstract void setPlayers(Collection players);

• O método addPlayer obtém a coleção de objetos LocalPlayer
• Depois, o jogador é adicionado à coleção:
  • No banco de dados, isso vai adicionar um registro à tabela que mantém o relacionamento

  public void addPlayer(LocalPlayer player) {

    Debug.print("TeamBean addPlayer");
    try {
      Collection players = getPlayers();
      players.add(player);
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  }

Remoção de um Jogador

RosterClient

• Para remover o jogador P4, o cliente chama removePlayer do bean de sessão RosterEJB:
  • Isso não está no código de RosterClient.java porque este cliente não remove jogadores

  myRoster.removePlayer(“P4”);

RosterEJB

• O método removePlayer usa findByPrimaryKey para localizar a instância de PlayerEJB
• Depois, o método remove dessa instância é chamado
• Isso fará com que o container remova a linha da tabela do BD correspondendo a esta instância
• O container também remove essa instância do campo de relacionamento "players" do entity bean TeamEJB

  public void removePlayer(String playerId) { 

    Debug.print("RosterBean removePlayer");
    try {
      LocalPlayer player = playerHome.findByPrimaryKey(playerId);
      player.remove();
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  }

Remoção de um Jogador de um Time

RosterClient

• Para remover jogador P2 do time T1, o cliente chamaria o método dropPlayer do bean de sessão RosterEJB:

  myRoster.dropPlayer(“P2”, “T1”);

RosterEJB

• O método dropPlayer usa findByPrimaryKey para localizar as instâncias de PlayerEJB e TeamEJB
• Depois, o business method dropPlayer do entity bean TeamEJB é chamado

  public void dropPlayer(String playerId, String teamId) {

    Debug.print("RosterBean dropPlayer");
    try {
        LocalPlayer player = playerHome.findByPrimaryKey(playerId);
        LocalTeam team = teamHome.findByPrimaryKey(teamId);
        team.dropPlayer(player);
    } catch (Exception ex) {
        throw new EJBException(ex.getMessage());
    }
  }

TeamEJB

• O método dropPlayer atualiza o relacionamento TeamEJB-PlayerEJB
• Primeiro a coleção de objetos de tipo LocalPlayer é acessada e o método remove é chamado:

  public void dropPlayer(LocalPlayer player) {

    Debug.print("TeamBean dropPlayer");
    try {
      Collection players = getPlayers();
      players.remove(player);
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  }

Obtenção dos Jogadores de um Time

RosterClient

• O cliente pode obter os jogadores de um time através do método getPlayersOfTeam do bean de sessão RosterEJB
• Este método retorna um ArrayList de objetos de tipo PlayerDetails
• Este objeto contém 4 atributos que são cópia dos campos persistentes
• Aqui está a chamada do cliente:

      playerList = myRoster.getPlayersOfTeam("T2");

RosterEJB

• O método getPlayersOfTeam do bean RosterEJB localiza o objeto de tipo LocalTeam do time alvo usando findByPrimaryKey
• Em seguida, o método getPlayers do entity bean TeamEJB é chamado:

  public ArrayList getPlayersOfTeam(String teamId) { 

    Debug.print("RosterBean getPlayersOfTeam");
    Collection players = null;

    try {
      LocalTeam team = teamHome.findByPrimaryKey(teamId);
      players = team.getPlayers();
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }

    return copyPlayersToDetails(players);
  } // getPlayersOfTeam

  private ArrayList copyPlayersToDetails(Collection players) {

    ArrayList detailsList = new ArrayList();
    Iterator i = players.iterator();

    while (i.hasNext()) {
      LocalPlayer player = (LocalPlayer) i.next();
      PlayerDetails details = new PlayerDetails(player.getPlayerId(),
          player.getName(), player.getPosition(), player.getSalary());
      detailsList.add(details);
    }

    return detailsList;
  } // copyPlayersToDetails

TeamEJB

• O método getPlayers do entity bean TeamEJB é um método de acesso do campo de relacionamento "players":

  public abstract Collection getPlayers();

• Este método está exposto a clientes locais, já que está definido na interface local LocalTeam:

  public Collection getPlayers();

• Com uma referência ao campo de relacionamento, o cliente pode manipular este relacionamento
• Por exemplo, um cliente local do entity bean TeamEJB poderia remover um jogador de um time assim:

  LocalTeam team = teamHome.findByPrimaryKey(teamId);
  Collection players = team.getPlayers();
  players.remove(player);

• Se você quiser evitar que um cliente possa alterar um relacionamento, use a técnica da próxima seção

Obtenção de uma Cópia dos Jogadores de um Time

• Queremos mostrar:
  • Como filtrar a informação passada ao cliente remoto
  • Como inibir a modificação de um relacionamento por um cliente local

RosterClient

• Se quiser esconder o salário de um jogador de um cliente remoto, você obrigaria o cliente a chamar o método getPlayersOfTeamCopy do bean RosterEJB
• Este método também retorna um ArrayList de objetos de tipo PlayerDetails
• Porém, tais objetos são diferentes: o salário foi zerado
• Aqui está a chamada feita pelo cliente:

  playerList = myRoster.getPlayersOfTeamCopy("T5");

RosterEJB

• Ao contrário do método getPlayersOfTeam, o método getPlayersOfTeamCopy não chama o método de acesso getPlayers
  • Ele chama o business method getCopyOfPlayers
• Como resultado, getPlayersOfTeamCopy não pode modificar o relacionamento
  • Não está manipulando um campo de relacionamento

  public ArrayList getPlayersOfTeamCopy(String teamId) { 

    Debug.print("RosterBean getPlayersOfTeamCopy");
    ArrayList playersList = null;

    try {
      LocalTeam team = teamHome.findByPrimaryKey(teamId);
      playersList = team.getCopyOfPlayers();
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }

    return playersList;

  } // getPlayersOfTeamCopy

TeamEJB

• O método getCopyOfPlayers é mostrado abaixo
  • Observe como o salário é zerado

  public ArrayList getCopyOfPlayers() {

    Debug.print("TeamBean getCopyOfPlayers");
    ArrayList playerList = new ArrayList();
    Collection players = getPlayers();

    Iterator i = players.iterator();
    while (i.hasNext()) {
      LocalPlayer player = (LocalPlayer) i.next();
      PlayerDetails details = new PlayerDetails(player.getPlayerId(),
                              player.getName(), player.getPosition(), 0.00);
      playerList.add(details);
    }

    return playerList;
  }

Localização de Jogadores por Posição

RosterClient

• O cliente chama o método getPlayersByPosition do bean RosterEJB

  playerList = myRoster.getPlayersByPosition("defender");

RosterEJB

• O "finder method" findByPosition do entity bean PlayerEJB é usado:

  public ArrayList getPlayersByPosition(String position) {

    Debug.print("RosterBean getPlayersByPosition");
    Collection players = null;

    try {
      players = playerHome.findByPosition(position);
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }

    return copyPlayersToDetails(players);
  } // getPlayersByPosition

PlayerEJB

• O método findByPosition está definido na interface LocalPlayerHome:

  public Collection findByPosition(String position) 
                    throws FinderException;

• Este método não é implementado pelo desenvolvedor, mas pelo container
• Basta que o desenvolvedor forneça o EJB QL apropriado no Deployment Descriptor:

  SELECT DISTINCT OBJECT(p) FROM Player p WHERE p.position = ?1

• A ferramenta deploytool traduz isso para SQL

Obtenção dos Esportes de um Jogador

RosterClient

• Aqui está o cliente:

  sportList = myRoster.getSportsOfPlayer("P28");

RosterEJB

• Aqui está getSportsOfPlayer:
  • Já que um outro ArrayList é construído, não poderá haver alterações feitas pelo cliente

  public ArrayList getSportsOfPlayer(String playerId) { 

    Debug.print("RosterBean getSportsOfPlayer");
    ArrayList sportsList = new ArrayList();
    Collection sports = null;

    try {
      LocalPlayer player = playerHome.findByPrimaryKey(playerId);
      sports = player.getSports();
    } catch (Exception ex) {
      throw new EJBException(ex.getMessage());
    }
  
    Iterator i = sports.iterator();
    while (i.hasNext()) {
      String sport = (String) i.next();
      sportsList.add(sport);
    }
    return sportsList;
  } // getSportsOfPlayer

PlayerEJB

• O método getSports é um wrapper para o método ejbSelectSports
  • Métodos "select" só podem ser chamados pelo próprio bean

  public Collection getSports() throws FinderException {

    LocalPlayer player = 
        (team.LocalPlayer)context.getEJBLocalObject();
    return ejbSelectSports(player);
  }

• Este método select é declarado no próprio bean:

  public abstract Collection ejbSelectSports(LocalPlayer player)
                  throws FinderException;

• O desenvolvedor precisa fornecer o EJB QL:

  SELECT DISTINCT t.league.sport FROM Player p, IN (p.teams) AS t WHERE p = ?1

• Isso será traduzido para SQL pelo deploytool

Compilação, Deployment e Execução de RosterApp

Compilação

• ant cmproster

Deployment

• Com cloudscape e J2EE no ar, use deploytool
• Abra o arquivo RosterApp.ear (já pronto)
• Faça deployment com Tools->Deploy
  • Peça para retornar o "Client JAR" no arquivo src/cmproster/earpronto/RosterAppClient.jar

Execução do Cliente

• Numa janela de comando, vá para o diretório src/cmproster/earpronto
• set APPCPATH=RosterAppClient.jar (Windows)
• APPCPATH=RosterAppClient.jar export APPCPATH(Unix)
• Execute o cliente:

C:\..\src\cmproster\earpronto>runclient -client RosterApp.ear -name RosterClient -textauth
Initiating login ...
Username = null
Enter Username:guest
Enter Password:guest123
Binding name:`java:comp/env/ejb/SimpleRoster`
P6 Ian Carlyle goalkeeper 555.0
P7 Rebecca Struthers midfielder 777.0
P10 Terry Smithson midfielder 100.0
P8 Anne Anderson forward 65.0
P9 Jan Wesley defender 100.0

T5 Crows Orland
T2 Gophers Manteca
T1 Honey Bees Visalia

P2 Alice Smith defender 505.0
P5 Barney Bold defender 100.0
P9 Jan Wesley defender 100.0
P22 Janice Walker defender 857.0
P25 Frank Fletcher defender 399.0

L2 Valley Basketball
L1 Mountain Soccer

Unbinding name:`java:comp/env/ejb/SimpleRoster`

• Para entender o resultado, aqui está o código do cliente:

/*
 *
 * Copyright 2001 Sun Microsystems, Inc. All Rights Reserved.
 * 
 * This software is the proprietary information of Sun Microsystems, Inc.  
 * Use is subject to license terms.
 * 
 */

package client;

import java.util.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import util.*;
import roster.*;

public class RosterClient {

  public static void main(String[] args) {
    try {
      Context initial = new InitialContext();
      Object objref = initial.lookup("java:comp/env/ejb/SimpleRoster");

      RosterHome home = 
          (RosterHome)PortableRemoteObject.narrow(objref, 
                                       RosterHome.class);

      Roster myRoster = home.create();

      insertInfo(myRoster);
      getSomeInfo(myRoster);

      // getMoreInfo(myRoster);

      System.exit(0);

    } catch (Exception ex) {
      System.err.println("Caught an exception:");
      ex.printStackTrace();
    }
  } // main


  private static void getSomeInfo(Roster myRoster) {

    try {

      ArrayList playerList;
      ArrayList teamList;
      ArrayList leagueList;

      playerList = myRoster.getPlayersOfTeam("T2");
      printDetailsList(playerList);

      teamList = myRoster.getTeamsOfLeague("L1");
      printDetailsList(teamList);

      playerList = myRoster.getPlayersByPosition("defender");
      printDetailsList(playerList);


      leagueList = myRoster.getLeaguesOfPlayer("P28");
      printDetailsList(leagueList);

    } catch (Exception ex) {
      System.err.println("Caught an exception:");
      ex.printStackTrace();
    }

  } // getSomeInfo

  private static void getMoreInfo(Roster myRoster) {

    try {

      LeagueDetails leagueDetails;
      TeamDetails teamDetails;
      PlayerDetails playerDetails;
      ArrayList playerList;
      ArrayList teamList;
      ArrayList leagueList;
      ArrayList sportList;

      leagueDetails = myRoster.getLeague("L1");
      System.out.println(leagueDetails.toString());
      System.out.println();

      teamDetails = myRoster.getTeam("T3");
      System.out.println(teamDetails.toString());
      System.out.println();

      playerDetails = myRoster.getPlayer("P20");
      System.out.println(playerDetails.toString());
      System.out.println();

      playerList = myRoster.getPlayersOfTeam("T2");
      printDetailsList(playerList);

      teamList = myRoster.getTeamsOfLeague("L1");
      printDetailsList(teamList);

      playerList = myRoster.getPlayersByPosition("defender");
      playerList = myRoster.getAllPlayers();
      playerList = myRoster.getPlayersNotOnTeam();
      playerList = myRoster.getPlayersByPositionAndName("power forward", 
          "Jack Patterson");
      playerList = myRoster.getPlayersByCity("Truckee");
      playerList = myRoster.getPlayersBySport("Soccer");
      playerList = myRoster.getPlayersByLeagueId("L1");
      playerList = myRoster.getPlayersByHigherSalary("Ian Carlyle");
      playerList = myRoster.getPlayersBySalaryRange(500.00, 800.00);
      playerList = myRoster.getPlayersOfTeamCopy("T5");

      leagueList = myRoster.getLeaguesOfPlayer("P28");
      printDetailsList(leagueList);

      sportList = myRoster.getSportsOfPlayer("P28");
      printDetailsList(sportList);

    } catch (Exception ex) {
      System.err.println("Caught an exception:");
      ex.printStackTrace();
    }

  } // getMoreInfo

  private static void printDetailsList(ArrayList list) {

    Iterator i = list.iterator();
    while (i.hasNext()) {
      Object details = (Object)i.next();
      System.out.println(details.toString());
    }
    System.out.println();
  } // printDetailsList


  private static void insertInfo(Roster myRoster) {

    try {
      // Leagues

      myRoster.createLeague(new LeagueDetails(
         "L1", "Mountain", "Soccer"));

      myRoster.createLeague(new LeagueDetails(
         "L2", "Valley", "Basketball"));

      // Teams

      myRoster.createTeamInLeague(new TeamDetails(
         "T1", "Honey Bees", "Visalia"), "L1");

      myRoster.createTeamInLeague(new TeamDetails(
         "T2", "Gophers", "Manteca"), "L1");
      
      myRoster.createTeamInLeague(new TeamDetails(
         "T3", "Deer", "Bodie"), "L2");

      myRoster.createTeamInLeague(new TeamDetails(
         "T4", "Trout", "Truckee"), "L2");

      myRoster.createTeamInLeague(new TeamDetails(
         "T5", "Crows", "Orland"), "L1");

      // Players, Team T1

      myRoster.createPlayer(new PlayerDetails(
         "P1", "Phil Jones", "goalkeeper", 100.00));
      myRoster.addPlayer("P1", "T1");

      myRoster.createPlayer(new PlayerDetails(
         "P2", "Alice Smith", "defender", 505.00));
      myRoster.addPlayer("P2", "T1");

      myRoster.createPlayer(new PlayerDetails(
         "P3", "Bob Roberts", "midfielder", 65.00));
      myRoster.addPlayer("P3", "T1");

      myRoster.createPlayer(new PlayerDetails(
         "P4", "Grace Phillips", "forward", 100.00));
      myRoster.addPlayer("P4", "T1");

      myRoster.createPlayer(new PlayerDetails(
         "P5", "Barney Bold", "defender", 100.00));
      myRoster.addPlayer("P5", "T1");

      // Players, Team T2

      myRoster.createPlayer(new PlayerDetails(
         "P6", "Ian Carlyle", "goalkeeper", 555.00));
      myRoster.addPlayer("P6", "T2");

      myRoster.createPlayer(new PlayerDetails(
         "P7", "Rebecca Struthers", "midfielder", 777.00));
      myRoster.addPlayer("P7", "T2");

      myRoster.createPlayer(new PlayerDetails(
         "P8", "Anne Anderson", "forward", 65.00));
      myRoster.addPlayer("P8", "T2");

      myRoster.createPlayer(new PlayerDetails(
         "P9", "Jan Wesley", "defender", 100.00));
      myRoster.addPlayer("P9", "T2");

      myRoster.createPlayer(new PlayerDetails(
         "P10", "Terry Smithson", "midfielder", 100.00));
      myRoster.addPlayer("P10", "T2");

      // Players, Team T3

      myRoster.createPlayer(new PlayerDetails(
         "P11", "Ben Shore", "point guard", 188.00));
      myRoster.addPlayer("P11", "T3");

      myRoster.createPlayer(new PlayerDetails(
         "P12", "Chris Farley", "shooting guard", 577.00));
      myRoster.addPlayer("P12", "T3");

      myRoster.createPlayer(new PlayerDetails(
         "P13", "Audrey Brown", "small forward", 995.00));
      myRoster.addPlayer("P13", "T3");

      myRoster.createPlayer(new PlayerDetails(
         "P14", "Jack Patterson", "power forward", 100.00));
      myRoster.addPlayer("P14", "T3");

      myRoster.createPlayer(new PlayerDetails(
         "P15", "Candace Lewis", "point guard", 100.00));
      myRoster.addPlayer("P15", "T3");

      // Players, Team T4

      myRoster.createPlayer(new PlayerDetails(
         "P16", "Linda Berringer", "point guard", 844.00));
      myRoster.addPlayer("P16", "T4");

      myRoster.createPlayer(new PlayerDetails(
         "P17", "Bertrand Morris", "shooting guard", 452.00));
      myRoster.addPlayer("P17", "T4");

      myRoster.createPlayer(new PlayerDetails(
         "P18", "Nancy White", "small forward", 833.00));
      myRoster.addPlayer("P18", "T4");

      myRoster.createPlayer(new PlayerDetails(
         "P19", "Billy Black", "power forward", 444.00));
      myRoster.addPlayer("P19", "T4");

      myRoster.createPlayer(new PlayerDetails(
         "P20", "Jodie James", "point guard", 100.00));
      myRoster.addPlayer("P20", "T4");

      // Players, Team T5

      myRoster.createPlayer(new PlayerDetails(
         "P21", "Henry Shute", "goalkeeper", 205.00));
      myRoster.addPlayer("P21", "T5");

      myRoster.createPlayer(new PlayerDetails(
         "P22", "Janice Walker", "defender", 857.00));
      myRoster.addPlayer("P22", "T5");

      myRoster.createPlayer(new PlayerDetails(
         "P23", "Wally Hendricks", "midfielder", 748.00));
      myRoster.addPlayer("P23", "T5");

      myRoster.createPlayer(new PlayerDetails(
         "P24", "Gloria Garber", "forward", 777.00));
      myRoster.addPlayer("P24", "T5");

      myRoster.createPlayer(new PlayerDetails(
         "P25", "Frank Fletcher", "defender", 399.00));
      myRoster.addPlayer("P25", "T5");

      // Players, no team

      myRoster.createPlayer(new PlayerDetails(
         "P26", "Hobie Jackson", "pitcher", 582.00));
     
      myRoster.createPlayer(new PlayerDetails(
         "P27", "Melinda Kendall", "catcher", 677.00));

      // Players, multiple teams

      myRoster.createPlayer(new PlayerDetails(
         "P28", "Constance Adams", "substitue", 966.00));
      myRoster.addPlayer("P28", "T1");
      myRoster.addPlayer("P28", "T3");

    } catch (Exception ex) {
        System.err.println("Caught an exception:");
        ex.printStackTrace();
    }

  } // insertInfo


} // class

• Exercício: desenvolva um cliente Web para RosterApp

Chaves Primárias para Container-Managed Persistence

• Se sua chave primária não for uma das classes disponíveis na biblioteca Java (String, ...), você deve fornecer uma "classe de chave primária"
  • Isso seria necessário, por exemplo, se sua chave consistir de vários campos (chave primária composta)

A Classe de Chave Primária

• No exemplo a seguir, a classe the PurchaseOrderKey representa uma chave composta para o entity bean PurchaseOrderEJB
  • A chave têm dois campos: productModel e vendorId

public class PurchaseOrderKey implements java.io.Serializable {
  public String productModel;
  public String vendorId;

  public PurchaseOrderKey() { };

  public String getProductModel() {
    return productModel;
  }

  public String getVendorId() {
    return vendorId;
  }

  public boolean equals(Object other) {
    if (other instanceof PurchaseOrderKey) {
      return (productModel.equals(
               ((PurchaseOrderKey)other).productModel) &&
               vendorId.equals(
               ((PurchaseOrderKey)other).vendorId));
    }
    return false;
  }

  public int hashCode() {
    return productModel.concat(vendorId).hashCode();
  }
}

• Ao usar CMP, uma classe de chave primária deve obedecer as regras seguintes:
  • A classe é public
  • Todos os campos são public
  • Os campos são um subconjunto dos campos persistentes
  • A classe tem um construtor default público
  • A classe implementa os métodos hashCode() e equals(Object)
  • A classe é serializável

Chaves Primárias na Classe de Implementação (Entity Bean class)

• Métodos ejbCreate devem retornar como um objeto da classe da chave primária
  • Já que o valor em si não importa (com CMP), retorne null

public PurchaseOrderKey ejbCreate (String vendorId,
                                   String productModel,
                                   String productName)
                        throws CreateException {

  setVendorId(vendorId);
  setProductModel(productModel);
  setProductName(productName);
  return null;
}

Geração de Valores de Chaves Primárias

• Opta-se frequentemente por usar números únicos como chaves primárias que não são campos "de business" da aplicação
  • Chama-se isso "Identidade baseada na existência"
  • Usar campos "de business" se chama "Identidade baseada em valor"
• Neste caso, o container pode gerar os números automaticamente:
  • No Deployment Descriptor, a classe de chave primária é declarada como java.lang.Object
  • O campo de chave primária não é especificado
  • Na interface home, o argumento do método findByPrimaryKey deve ser java.lang.Object
  • O tipo de retorno do método ejbCreate deve ser java.lang.Object

cmp programa