Construire un service web Java EE

Elle contient des informations sur les médecins gérés par l'application [RdvMedecins].

• ID : n° identifiant le médecin - clé primaire de la table
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• NOM : le nom du médecin
• PRENOM : son prénom
• TITRE : son titre (Melle, Mme, Mr)

Les clients des différents médecins sont enregistrés dans la table [CLIENTS] :

• ID : n° identifiant le client - clé primaire de la table
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• NOM : le nom du client
• PRENOM : son prénom
• TITRE : son titre (Melle, Mme, Mr)

Elle liste les créneaux horaires où les RV sont possibles :

• ID : n° identifiant le créneau horaire - clé primaire de la table (ligne 8)
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• ID_MEDECIN : n° identifiant le médecin auquel appartient ce créneau - clé étrangère sur la colonne MEDECINS(ID).
• HDEBUT : heure début créneau
• MDEBUT : minutes début créneau
• HFIN : heure fin créneau
• MFIN : minutes fin créneau

La seconde ligne de la table [CRENEAUX] (cf [1] ci-dessus) indique, par exemple, que le créneau n° 2 commence à 8 h 20 et se termine à 8 h 40 et appartient au médecin n° 1 (Mme Marie PELISSIER).

Elle liste les RV pris pour chaque médecin :

• ID : n° identifiant le RV de façon unique - clé primaire
• JOUR : jour du RV
• ID_CRENEAU : créneau horaire du RV - clé étrangère sur le champ [ID] de la table [CRENEAUX] - fixe à la fois le créneau horaire et le médecin concerné.
• ID_CLIENT : n° du client pour qui est faite la réservation - clé étrangère sur le champ [ID] de la table [CLIENTS]

Cette table a une sur les valeurs des colonnes jointes (JOUR, ID_CRENEAU) :

ALTER TABLE RV ADD CONSTRAINT UNQ1_RV UNIQUE (JOUR, ID_CRENEAU);

Si une ligne de la table[RV] a la valeur (JOUR1, ID_CRENEAU1) pour les colonnes (JOUR, ID_CRENEAU), cette valeur ne peut se retrouver nulle part ailleurs. Sinon, cela signifierait que deux RV ont été pris au même moment pour le même médecin. D'un point de vue programmation Java, le pilote JDBC de la base lance une SQLException lorsque ce cas se produit.

La ligne d'id égal à 3 (cf [1] ci-dessus) signifie qu'un RV a été pris pour le créneau n° 20 et le client n° 4 le 23/08/2006. La table [CRENEAUX] nous apprend que le créneau n° 20 correspond au créneau horaire 16 h 20 - 16 h 40 et appartient au médecin n° 1 (Mme Marie PELISSIER). La table [CLIENTS] nous apprend que le client n° 4 est Melle Brigitte BISTROU.

Rappelons l'architecture de notre application client / serveur :

Le projet Netbeans :

La couche [JPA] est configurée par les fichiers [persistence.xml] et [sun-resources.xml] ci-dessus. Ces deux fichiers sont générés par des assistants déjà rencontrés :

• la génération du fichier [sun-resources.xml] a été décrite au pararaphe , page .
• la génération du fichier [persistence.xml] a été décrite au pararaphe , page .

Le fichier [persistence.xml] généré doit être modifié de la façon suivante :

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="dbrdvmedecins" transaction-type="JTA">
    <provider>org.hibernate.EJB.HibernatePersistence</provider>
    <jta-data-source>jdbc/dbrdvmedecins</jta-data-source>
    <properties>
      <!-- Dialecte -->
      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect"/>
    </properties>
  </persistence-unit>
</persistence>

• ligne 3 : le type de transactions est JTA : les transactions seront gérées par le conteneur EJB3 de Glassfish
• ligne 4 : une implémentation Jpa / Hibernate est utilisée. Pour cela, la bibliothèque Hibernate a été ajoutée au serveur Glassfish (cf paragraphe , page ).
• ligne 5 : la source de données JTA utilisée par la couche Jpa a le nom JNDI « jdbc/dbrdvmedecins ».
• ligne 8 : cette ligne n'est pas générée automatiquement. Elle doit être ajoutée à la main. Elle indique à Hibernate, que le SGBD utilisé est MySQL5.

La source de données "jdbc/dbrdvmedecins" est configurée dans le fichier [sun-resources.xml] suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Resource Definitions //EN" "http://www.sun.com/software/appserver/dtds/sun-resources_1_3.dtd">
<resources>
  <jdbc-resource enabled="true" jndi-name="jdbc/dbrdvmedecins" object-type="user" pool-name="dbrdvmedecinsPool">
    <description/>
  </jdbc-resource>
  <jdbc-connection-pool ...>
    <property name="URL" value="jdbc:mysql://localhost/dbrdvmedecins"/>
    <property name="User" value="root"/>
    <property name="Password" value="()"/>
  </jdbc-connection-pool>
</resources>

• lignes 8-10 : les caractéristiques Jdbc de la source de données (Url de la base, nom et mot de passe de l'utilisateur). La base de données MySQL dbrdvmedecins est celle décrite au paragraphe , page .
• ligne 7 : les caractéristiques du pool de connexions associé à cette source de données

Rappelons l'architecture de notre application client / serveur :

Le projet Netbeans :

Le package [rdvmedecins.entites] implémente la couche [Jpa].

Nous avons vu au paragraphe , page comment générer automatiquement les entités Jpa d'une application. Nous n'utiliserons pas ici cette technique mais définirons nous-mêmes les entités. Celles-ci reprendront cependant une bonne partie du code généré au paragraphe , page . Ici, nous souhaitons que les entités [Medecin] et [Client] soient des classes filles d'une classe [Personne].

La classe Personne est utilisée pour représenter les médecins et les clients :

package rdvmedecins.entites;
...
@MappedSuperclass
public class Personne implements Serializable {
  // caractéristiques d'une personne

  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "ID")
  private Long id;
  @Version
  @Column(name = "VERSION", nullable = false)
  private Integer version;

  @Column(name = "TITRE", length = 5, nullable = false)
  private String titre;
  @Column(name = "NOM", length = 30, nullable = false)
  private String nom;
  @Column(name = "PRENOM", length = 30, nullable = false)
  private String prenom;

  // constructeur par défaut
  public Personne() {
  }

  // constructeur avec paramètres
  public Personne(String titre, String nom, String prenom) {
    // on passe par les setters
...
  }

  // constructeur par recopie
  public Personne(Personne personne) {
    // on passe par les setters
 ...
  }

  // toString
  @Override
  public String toString() {
    return "[" + titre + "," + prenom + "," + nom + "]";
  }

// getters et setters
....
}

• ligne 3 : on notera que la classe [Personne] n'est pas elle-même une entité (@Entity). Elle va être la classe parent d'entités. L'annotation @MappedSuperClass désigne cette situation.

L'entité [Client] encapsule les lignes de la table [clients]. Elle dérive de la classe [Personne] précédente :

package rdvmedecins.entites;
....
@Entity
@Table(name = "CLIENTS")
public class Client extends Personne implements Serializable {

  // constructeur par défaut
  public Client() {
  }

  // constructeur avec paramètres
  public Client(String titre, String nom, String prenom) {
    // parent
    super(titre, nom, prenom);
  }

  // constructeur par recopie
  public Client(Client client) {
    // parent
    super(client);
  }
}

• ligne 3 : la classe [Client] est une entité Jpa
• ligne 4 : elle est associée à la table [clients]
• ligne 5 : elle dérive de la classe [Personne]

L'entité [Medecin] qui encapsule les lignes de la table [medecins] suit le même modèle :

package rdvmedecins.entites;
...
@Entity
@Table(name = "MEDECINS")
public class Medecin extends Personne implements Serializable {

  // constructeur par défaut
  public Medecin() {
  }

  // constructeur avec paramètres
  public Medecin(String titre, String nom, String prenom) {
    // parent
    super(titre, nom, prenom);
  }

  // constructeur par recopie
  public Medecin(Medecin medecin) {
    // parent
    super(medecin);
  }
}

L'entité [Creneau] encapsule les lignes de la table [creneaux] :

package rdvmedecins.entites;
....
@Entity
@Table(name = "CRENEAUX")
public class Creneau implements Serializable {

  // caractéristiques d'un créneau de RV
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  @Column(name = "ID")
  private Long id;
  @Version
  @Column(name = "VERSION", nullable = false)
  private Integer version;
  @ManyToOne
  @JoinColumn(name = "ID_MEDECIN", nullable = false)
  private Medecin medecin;
  @Column(name = "HDEBUT", nullable = false)
  private Integer hdebut;
  @Column(name = "MDEBUT", nullable = false)
  private Integer mdebut;
  @Column(name = "HFIN", nullable = false)
  private Integer hfin;
  @Column(name = "MFIN", nullable = false)
  private Integer mfin;

  // constructeur par défaut
  public Creneau() {

  }

  // constructeur avec paramètres
  public Creneau(Medecin medecin, Integer hDebut,Integer mDebut, Integer hFin, Integer mFin) {
    // on passe par les setters
...
  }

  // constructeur par recopie
  public Creneau(Creneau creneau) {
    // on passe par les setters
...
  }

  // toString
  @Override
  public String toString() {
    return "[" + getId() + "," + getVersion() + "," + getMedecin() + "," + getHdebut() + ":" + getMdebut() + "," + getHfin() + ":" + getMfin() + "]";
  }

  // setters - getters
...
}

• les lignes 15-17 modélisent la relation "plusieurs à un" qui existe entre la table [creneaux] et la table [medecins] de la base de données : un médecin a plusieurs créneaux, un créneau appartient à un seul médecin.
   

  Cacher/Afficher le codeSélectionnez

  1.
  2.
  3.
  4.
  5.
  6.
  7.
  8.
  9.
  10.
  11.
  12.
  13.
  14.
  15.
  16.
  17.
  18.
  19.
  20.
  21.
  22.
  23.
  24.
  25.
  26.
  27.
  28.
  29.
  30.
  31.
  32.
  33.
  34.
  35.
  36.
  37.
  38.
  39.
  40.
  41.
  42.
  43.
  44.
  45.
  46.
  

  package rdvmedecins.entites;
  ...
  @Entity
  @Table(name = "RV")
  public class Rv implements Serializable {
    // caractéristiques
  
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "ID")
    private Long id;
    @Column(name = "JOUR", nullable = false)
    @Temporal(TemporalType.DATE)
    private Date jour;
    @ManyToOne
    @JoinColumn(name = "ID_CLIENT", nullable = false)
    private Client client;
    @ManyToOne
    @JoinColumn(name = "ID_CRENEAU", nullable = false)
    private Creneau creneau;
  
    // constructeur par défaut
    public Rv() {
    }
  
    // constructeur avec paramètres
    public Rv(Date jour, Client client, Creneau creneau) {
      // on passe par les setters
  ...
    }
  
    // constructeur par recopie
    public Rv(Rv rv) {
      // on passe par les setters
  ...
    }
  
    // toString
    @Override
    public String toString() {
      return "[" + getId() + "," + new SimpleDateFormat("dd/MM/yyyy").format(getJour()) + "," + getClient() + "," + getCreneau() + "]";
    }
  
  // getters et setters
  ...
  }
  

  L'entité [Rv] encapsule les lignes de la table [rv] :

• les lignes 15-17 modélisent la relation "plusieurs à un" qui existe entre la table [rv] et la table [clients] (un client peut apparaître dans plusieurs Rv) de la base de données et les lignes 18-20 la relation "plusieurs à un" qui existe entre la table [rv] et la table [creneaux] (un créneau peut apparaître dans plusieurs Rv).

La classe d'exception [] de l'application est la suivante :

package rdvmedecins.exceptions;

import javax.EJB.ApplicationException;

@ApplicationException(rollback=true)
public class RdvMedecinsException extends RuntimeException {

  private static final long serialVersionUID = 1L;

  // champs privés
  private int code = 0;

  // constructeurs
  public RdvMedecinsException() {
    super();
  }

  public RdvMedecinsException(String message) {
    super(message);
  }

  public RdvMedecinsException(String message, Throwable cause) {
    super(message, cause);
  }

  public RdvMedecinsException(Throwable cause) {
    super(cause);
  }

  public RdvMedecinsException(String message, int code) {
    super(message);
    setCode(code);
  }

  public RdvMedecinsException(Throwable cause, int code) {
    super(cause);
    setCode(code);
  }

  public RdvMedecinsException(String message, Throwable cause, int code) {
    super(message, cause);
    setCode(code);
  }

  // getters - setters
...
}

• ligne 6 : la classe dérive de la classe [RuntimeException]. Le compilateur ne force donc pas à la gérer avec des try / catch.
• ligne 5 : l'annotation @ApplicationException fait que l'exception ne sera pas "avalée" par une exception de type [EJBException].

Pour comprendre l'annotation @ApplicationException revenons à l'architecture utilisée côté serveur :

L'exception de type [RdvMedecinsException] sera lancée par les méthodes de l'EJB de la couche [dao] à l'intérieur du conteneur EJB3 et interceptée par celui-ci. Sans l'annotation @ApplicationException le conteneur EJB3 encapsule l'exception survenue, dans une exception de type [EJBException] et relance celle-ci. On peut ne pas vouloir de cette encapsulation et laisser sortir du conteneur EJB3 une exception de type [RdvMedecinsException]. C'est ce que permet l'annotation @ApplicationException. Par ailleurs, l'attribut (rollback=true) de cette annotation indique au conteneur EJB3 que si l'exception de type [RdvMedecinsException] se produit à l'intérieur d'une méthode exécutée au sein d'une transaction avec un SGBD, celle-ci doit être annulée. En termes techniques, cela s'appelle faire un rollback de la transaction.

L'interface java [] de la couche [dao] est la suivante :

package rdvmedecins.dao;
...
public interface IDao {

  // liste des clients
  public List<Client> getAllClients();
  // liste des Médecins
  public List<Medecin> getAllMedecins();
  // liste des créneaux horaires d'un médecin
  public List<Creneau> getAllCreneaux(Medecin medecin);
  // liste des Rv d'un médecin, un jour donné
  public List<Rv> getRvMedecinJour(Medecin medecin, String jour);
  // trouver un client identifié par son id
  public Client getClientById(Long id);
  // trouver un client idenbtifié par son id
  public Medecin getMedecinById(Long id);
  // trouver un Rv identifié par son id
  public Rv getRvById(Long id);
  // trouver un créneau horaire identifié par son id
  public Creneau getCreneauById(Long id);
  // ajouter un RV
  public Rv ajouterRv(String jour, Creneau creneau, Client client);
  // supprimer un RV
  public void supprimerRv(Rv rv);
}

L'interface locale [IDaoLocal] de l'EJB se contente de dériver l'interface [IDao] précédente :

package rdvmedecins.dao;

import javax.EJB.Local;

@Local
public interface IDaoLocal extends IDao{
}

Il en est de même pour l'interface distante [IDaoRemote] :

package rdvmedecins.dao;

import javax.EJB.Remote;

@Remote
public interface IDaoRemote extends IDao {
}

L'EJB [DaoJpa] implémente les deux interfaces, locale et distante :

package rdvmedecins.dao;
...
@Stateless(mappedName="rdvmedecins.dao")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class DaoJpa implements IDaoLocal,IDaoRemote {
...
}

• la ligne 3 indique que l'EJB distant porte le nom "rdvmedecins.dao"
• la ligne 4 indique que toutes les méthodes de l'EJB se déroulent au sein d'une transaction gérée par le conteneur EJB3.
• la ligne 5 montre que l'EJB implémente les interfaces locale et distante.

Le code complet de l'EJB est le suivant :

package rdvmedecins.dao;
...
@Stateless(mappedName="rdvmedecins.dao")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class DaoJpa implements IDaoLocal,IDaoRemote {

  @PersistenceContext
  private EntityManager em;

  // liste des clients
  public List<Client> getAllClients() {
    try {
      return em.createQuery("select c from Client c").getResultList();
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 1);
    }
  }

  // liste des médecins
  public List<Medecin> getAllMedecins() {
    try {
      return em.createQuery("select m from Medecin m").getResultList();
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 2);
    }
  }

  // liste des créneaux horaires d'un médecin donné
  // medecin : le médecin
  public List<Creneau> getAllCreneaux(Medecin medecin) {
    try {
      return em.createQuery("select c from Creneau c join c.medecin m where m.id=:idMedecin").setParameter("idMedecin", medecin.getId()).getResultList();
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 3);
    }
  }

  // liste des Rv d'un médecin donné, un jour donné
  // medecin : le médecin
  // jour : le jour
  public List<Rv> getRvMedecinJour(Medecin medecin, String jour) {
    try {
      return em.createQuery("select rv from Rv rv join rv.creneau c join c.medecin m where m.id=:idMedecin and rv.jour=:jour").setParameter("idMedecin", medecin.getId()).setParameter("jour", new SimpleDateFormat("yyyy:MM:dd").parse(jour)).getResultList();
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 4);
    }
  }

  // ajout d'un Rv
  // jour : jour du Rv
  // creneau : créneau horaire du Rv
  // client : client pour lequel est pris le Rv
  public Rv ajouterRv(String jour, Creneau creneau, Client client) {
    try {
      Rv rv = new Rv(new SimpleDateFormat("yyyy:MM:dd").parse(jour), client, creneau);
      em.persist(rv);
      return rv;
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 5);
    }
  }

  // suppression d'un Rv
  // rv : le Rv supprimé
  public void supprimerRv(Rv rv) {
    try {
      em.remove(em.merge(rv));
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 6);
    }
  }

  // récupérer un client donné
  public Client getClientById(Long id) {
    try {
      return (Client) em.find(Client.class, id);
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 7);
    }
  }

  // récupérer un médecin donné
  public Medecin getMedecinById(Long id) {
    try {
      return (Medecin) em.find(Medecin.class, id);
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 8);
    }
  }

  // récupérer un Rv donné
  public Rv getRvById(Long id) {
    try {
      return (Rv) em.find(Rv.class, id);
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 9);
    }
  }

  // récupérer un créneau donné
  public Creneau getCreneauById(Long id) {
    try {
      return (Creneau) em.find(Creneau.class, id);
    } catch (Throwable th) {
      throw new RdvMedecinsException(th, 10);
    }
  }
}

• ligne 8 : l'objet EntityManager qui gère l'accès au contexte de persistance. A l'instanciation de la classe, ce champ sera initialisé par le conteneur EJB grâce à l'annotation @PersistenceContext de la ligne 7.
• ligne 15 : requête JPQL qui retourne toutes les lignes de la table [clients] sous la forme d'une liste d'objets [Client].
• ligne 22 : requête analogue pour les médecins
• ligne 32 : une requête JPQL réalisant une jointure entre les tables [creneaux] et [medecins]. Elle est paramétrée par l'id du médecin.
• ligne 43 : une requête JPQL réalisant une jointure entre les tables [rv], [creneaux] et [medecins] et ayant deux paramètres : l'id du médecin et le jour du Rv.
• lignes 55-57 : création d'un Rv puis persistance de celui-ci en base de données.
• ligne 67 : suppression d'un Rv en base de données.
• ligne 76 : réalise un select sur la base de données pour trouver un client donné
• ligne 85 : idem pour un médecin
• ligne 94 : idem pour un Rv
• ligne 103 : idem pour un créneau horaire
• toutes les opérations avec le contexte de persistance em de la ligne 9 sont susceptibles de rencontrer un problème avec la base de données. Aussi sont-elles toutes entourées par un try / catch. L'éventuelle exception est encapsulée dans l'exception "maison" RdvMedecinsException.

Le module EJB une fois compilé donne naissance à un  :

Nous construisons tout d'abord un projet Netbeans de type "Web Application" :

• en [1], on crée un nouveau projet dans la catégorie "Java Web" [2] de type "Web Application" [3].

  

• en [4], on donne un nom au projet et en [5] on précise le dossier dans lequel il doit être généré
• en [6], on fixe le serveur d'application qui va exécuter l'application web
• en [7], on fixe le contexte de l'application
• en [8], on valide la configuration du projet.

  

• en [9], le projet généré.

Le service web que nous construisons va utiliser l'EJB du projet précédent [10]. Aussi a-t-il besoin de référencer le .jar du module EJB [10].

• en [11], on ajoute un projet Netbeans aux bibliothèques du projet web [12]

  

• en [13], on sélectionne le dossier du module EJB dans le système de fichiers et on valide.

  

• en [14], le module EJB a été ajouté aux bibliothèques du projet web.

En [15], nous implémentons le service web avec la classe [WsDaoJpa] suivante :

package rdvmedecins.ws;
...
@WebService()
public class WsDaoJpa implements IDao {

  @EJB
  private IDaoLocal dao;

  // liste des clients
  @WebMethod
  public List<Client> getAllClients() {
    return dao.getAllClients();
  }

  // liste des médecins
  @WebMethod
  public List<Medecin> getAllMedecins() {
    return dao.getAllMedecins();
  }

  // liste des créneaux horaires d'un médecin donné
  // medecin : le médecin
  @WebMethod
  public List<Creneau> getAllCreneaux(Medecin medecin) {
    return dao.getAllCreneaux(medecin);
  }

  // liste des Rv d'un médecin donné, un jour donné
  // medecin : le médecin
  // jour : le jour
  @WebMethod
  public List<Rv> getRvMedecinJour(Medecin medecin, String jour) {
    return dao.getRvMedecinJour(medecin, jour);
  }

  // ajout d'un Rv
  // jour : jour du Rv
  // creneau : créneau horaire du Rv
  // client : client pour lequel est pris le Rv
  @WebMethod
  public Rv ajouterRv(String jour, Creneau creneau, Client client) {
    return dao.ajouterRv(jour, creneau, client);
  }

  // suppression d'un Rv
  // rv : le Rv supprimé
  @WebMethod
  public void supprimerRv(Rv rv) {
    dao.supprimerRv(rv);
  }

  // récupérer un client donné
  @WebMethod
  public Client getClientById(Long id) {
    return dao.getClientById(id);
  }

  // récupérer un médecin donné
  @WebMethod
  public Medecin getMedecinById(Long id) {
    return dao.getMedecinById(id);
  }

  // récupérer un Rv donné
  @WebMethod
  public Rv getRvById(Long id) {
    return dao.getRvById(id);
  }

  // récupérer un créneau donné
  @WebMethod
  public Creneau getCreneauById(Long id) {
    return dao.getCreneauById(id);
  }
}

• ligne 4, la classe [WsdaoJpa] implémente l'interface [IDao]. Rappelons que cette interface est définie dans l'archive de l'EJB de la couche [dao] sous la forme suivante :

package rdvmedecins.dao;
...
public interface IDao {

  // liste des clients
  public List<Client> getAllClients();
  // liste des Médecins
  public List<Medecin> getAllMedecins();
  // liste des créneaux horaires d'un médecin
  public List<Creneau> getAllCreneaux(Medecin medecin);
  // liste des Rv d'un médecin, un jour donné
  public List<Rv> getRvMedecinJour(Medecin medecin, String jour);
  // trouver un client identifié par son id
  public Client getClientById(Long id);
  // trouver un client idenbtifié par son id
  public Medecin getMedecinById(Long id);
  // trouver un Rv identifié par son id
  public Rv getRvById(Long id);
  // trouver un créneau horaire identifié par son id
  public Creneau getCreneauById(Long id);
  // ajouter un RV
  public Rv ajouterRv(String jour, Creneau creneau, Client client);
  // supprimer un RV
  public void supprimerRv(Rv rv);
}

• ligne 3 : l'annotation @WebService fait de la classe [WsDaoJpa] un service web.
• lignes 6-7 : la référence de l'EJB de la couche [dao] sera injectée par le serveur d'applications dans le champ de la ligne 7. C'est l'implémentation locale IDaoLocal qui est ici injectée parce que le service web s'exécute dans la même Jvm que l'EJB.
• toutes les méthodes du service web sont taguées avec l'annotation @WebMethod pour en faire des méthodes visibles aux clients distants. Une méthode non taguée avec l'annotation @WebMethod serait interne au service web et non visible aux clients distants. Chaque méthode M du service web se contente d'appeler la méthode M correspondante de l'EJB injecté en ligne 7.

La création de ce service web est reflétée par une nouvelle branche dans le projet Netbeans :

On voit en [1] le service web WsDaoJpa et en [2] les méthodes qu'il expose aux clients distants.

Rappelons l'architecture du service web en construction :

Les composantes du service web que nous allons déployer sont :

• [1] : le module web que nous venons de construire
• [2] : le module EJB que nous avons construit lors d'une étape précédente et dont dépend le service web

Pour les déployer ensemble, il faut rassembler les deux modules dans un projet Netbeans dit "d'entreprise" :

En [1] on crée un nouveau projet d'entreprise [2, 3].

• en [4,5], on donne un nom au projet et on fixe son dossier de création
• en [6], on choisit le serveur d'application sur lequel sera déployée l'application d'entreprise
• en [7], un projet d'entreprise peut avoir trois composantes : application web, module EJB, application cliente. Ici, le projet est créé sans aucune composante. Celles-ci seront rajoutées ultérieurement.

  

• en [8], l'application d'entreprise nouvellement créée.

  

• en [9], cliquer droit sur [Java EE Modules] et ajouter un nouveau module
• en [10], seuls les modules Netbeans actuellement ouverts dans l'IDE sont présentés. Ici nous sélectionnons le module web [serveur-webservice-1-EJB-dao-jpa-hibernate] et le module EJB [serveur-EJB-dao-jpa-hibernate] que nous avons construits.
• en [11], les deux modules ajoutés au projet d'entreprise.

Il nous reste à déployer cette application d'entreprise sur le serveur Glassfish. Pour la suite, le SGBD MySQL doit être lancé afin que la source de données JDBC "jdbc/dbrdvmedecins" utilisée par le module EJB soit accessible.

• en [1], on lance le serveur Glassfish
• si le module EJB [serveur-EJB-dao-jpa-hibernate] est déployé, on le décharge [2]
• en [3], on déploie l'application d'entreprise

  

• en [4], elle est déployée. On voit qu'elle contient les deux modules : Web et EJB.

Nous montrons maintenant comment déployer le service web lorsqu'on ne dispose pas du code source du module EJB mais seulement son archive .jar.

Le nouveau projet Netbeans du service web sera le suivant :

Les éléments notables du projet sont les suivants :

• [1] : le service web est implémenté par un projet Netbeans de type [Web Application].
• [2] : le service web est implémenté par la classe [WsDaoJpa] déjà étudiée
• [3] : l'archive de l'EJB de la couche [dao] qui permet à la classe [WsDaoJpa] d'avoir accès aux définitions des différentes classes, interfaces, entités des couches [dao] et [jpa].

Nous construisons ensuite le projet d'entreprise nécessaire au déploiement du service web :

• [1], on crée une application d'entreprise [ea-rdvmedecins], au départ sans aucun module.
• en [2], on ajoute le module web [serveur-webservice-EJB-dao-jpa-hibernate] précédent
• en [3], le résultat.

Telle quelle, l'application d'entreprise [ea-rdvmedecins] ne peut pas être déployée sur le serveur Glassfish à partir de Netbeans. On obtient une erreur. Il faut alors déployer à la main l'archive ear de l'application [ea-rdvmedecins] :

• l'archive [ea-rdvmedecins.ear] est trouvée dans le dossier [dist] [2] de l'onglet [Files] de Netbeans.
• dans cette archive [3], on trouve les deux éléments de l'application d'entreprise :
• l'archive de l'EJB [serveur-EJB-dao-jpa-hibernate]. Cette archive est présente parce qu'elle faisait partie des bibliothèques référencées par le service web.
• l'archive du service web [serveur-webservice- EJB-dao-jpa-hibernate].
• l'archive [ea-rdvmedecins.ear] est construite par un simple Build [4] de l'application d'entreprise.
• en [5], l'opération de déploiement qui échoue.

Pour déployer l'archive [ea-rdvmedecins.ear] de l'application d'entreprise, nous procédons comme il a été montré lors du déploiement de l'archive de l'EJB [serveur-EJB-dao-jpa-hibernate.jar] au paragraphe , page . Nous utilisons de nouveau le client web d'administration du serveur Glassfish. Nous ne répétons pas des étapes déjà décrites.

Tout d'abord, on commencera par "décharger" l'application d'entreprise déployée au paragraphe , page  :

• [1] : sélectionnez la branche [Enterprise Applications] du serveur Glassfish
• en [2] sélectionner l'application d'entreprise à décharger puis en [3] la décharger
• en [4] l'application d'entreprise a été déchargée

• en [1], choisissez la branche [Enterprise Applications] du serveur Glassfish
• en [2], déployez une nouvelle application d'entreprise
• en [3], sélectionnez le type [Enterprise Application]
• en [4], désignez le fichier .ear du projet Netbeans [ea-rdvmedecins]
• en [5], déployez cette archive

• en [6], l'application a été déployée

• en [7], le service web [WsDaoJpa] apparaît dans la branche [Web Services] du serveur Glassfish. On le sélectionne.

• en [8], on a diverses informations sur le service web. La plus intéressante pour un client est l'information [9] : l'uri du service web.
• en [10], on peut tester le service web

  

• en [11], l' à laquelle on a ajouté le paramètre ?tester. Cette uri présente une page de test. Toutes les méthodes (@WebMethod) exposées par le service web sont affichées et peuvent être testées. Ici, on teste la méthode [13] qui demande la liste des clients.

  

• en [14], nous ne présentons qu'une vue partielle de la page de réponse. Mais on peut voir que la méthode getAllClients a bien renvoyé la liste des clients. La copie d'écran nous montre qu'elle envoie sa réponse dans un format XML.

Un service web est entièrement décrit par un fichier XML appelé fichier WSDL :

• en [1] dans l'outil web d'administration du serveur Glassfish, sélectionnez le service web [WsDaoJpa]
• en [2], suivez le lien [View WSDL]

  

• en [3] : l'uri du fichier WSDL. C'est une information importante à connaître. Elle est nécessaire pour configurer les clients de ce service web.
• en [4], la description XML du service web. Nous ne commenterons pas ce contenu complexe.

Nous créons un projet Netbeans pour "jouer" les tests déjà joués avec un client EJB avec, cette fois-ci, un client pour le service web dernièrement déployé. Nous suivons ici une démarche analogue à celle décrite au paragraphe 14.2.1, page 115 de [ref1].

• en [1], un projet Java classique
• en [2], la classe de test
• en [3], le client utilise l'archive de l'EJB pour avoir accès aux définitions de l'interface de la couche [dao] et des entités Jpa. On rappelle que cette archive est dans le sous-dossier [dist] du dossier du module EJB.

Pour accéder au service web distant, il est nécessaire de générer des classes proxy :

Dans le schéma ci-dessus, la couche [2] [C=Client] communique avec la couche [1] [S=Serveur]. Pour dialoguer avec la couche [S], le client [C] est amené à créer une connexion réseau avec la couche [S] et à dialoguer avec elle selon un protocole précis. Les connexions réseau sont des connexions TCP et le protocole de transport est HTTP. La couche [S] qui représente le service web est implémentée par une servlet Java exécutée par le serveur Glassfish. Nous n'avons pas écrit cette servlet. Sa génération est automatisée par Glassfish à partir des annotations @Webservice et @WebMethod de la classe [WsDaoJpa] que nous avons écrite. De même, nous allons automatiser la génération de la couche [C] du client. On appelle parfois la couche [C], une couche proxy du service web distant, le terme proxy désignant un élément intermédiaire dans une chaîne logicielle. Ici, le proxy C est l'intermédiaire entre le client que nous allons écrire et le service web que nous avons déployé.

Avec Netbeans 6.5, le proxy C peut être généré de la façon suivante (pour la suite, il faut que le service web soit actif sur le serveur Glassfish) :

• en [1], ajouter un nouvel élément au projet Java
• en [2], sélectionner la branche [Web services]
• en [3], sélectionner [Web Service Client]

  

• en [4], fournir l'uri du fichier WSDL du service web. Cette uri a été présentée au paragraphe , page .
• en [5], laisser la valeur par défaut [JAX-WS]. L'autre valeur possible est [JAX-RPC]
• après avoir validé l'assistant de création du proxy du service web, le projet Netbeans a été enrichi d'une branche [Web Service References] [6]. Cette branche montre les méthodes exposées par le service web distant.

• dans l'onglet [Files] [7], des codes sources Java ont été rajoutés [8]. Ils correspondent au proxy C généré.
• en [9] le code de l'une des classes. On y voit [10] qu'elles ont été placées dans un paquetage [rdvmedecins.ws]. Nous ne commenterons pas le code de ces classes qui est de nouveau assez complexe.

Pour le client Java que nous sommes en train de construire, le proxy C généré sert d'intermédiaire. Pour accéder à la méthode M du service web distant, le client Java appelle la méthode M du proxy C. Le client Java appelle ainsi des méthodes locales (exécutées dans la même Jvm) et de façon transparente pour lui, ces appels locaux sont traduits en appels distants.

Il nous reste à savoir appeler les méthodes M du proxy C. Revenons à notre classe de test JUnit :

En [1], la classe de test [MainTestsDaoRemote] est celle déjà utilisée lors du test de l'EJB de la couche [dao] :

package dao;
...
public class MainTestsDaoRemote {

  // couche [dao] testée
  private static IDaoRemote dao;

  @BeforeClass
  public static void init() throws NamingException {
  }

  @Test
  public void test1() {
...
  }
}

• ligne [13], le test test1 est conservé à l'identique.
• ligne [9], le contenu de la méthode [init] a été supprimé.

A ce stade, le projet présente des erreurs car la méthode de test [test1] utilise les entités [Client], [Medecin], [Creneau], [Rv] qui ne sont plus dans les mêmes packages qu'auparavant. Elles sont dans le package du proxy C généré. On supprime les instructions import concernées et on les régénère par l'opération Fix Imports.

Revenons au code de la classe de test [MainTestsDaoRemote] :

package dao;
...

public class MainTestsDaoRemote {

  // couche [dao] testée
  private static IDaoRemote dao;

  @BeforeClass
  public static void init() throws NamingException {
}

La méthode [init] de la ligne 10 doit initialiser la référence de la couche [dao] de la ligne 7. Il nous faut savoir comment utiliser le proxy C généré, dans notre code. Netbeans nous aide dans cette démarche.

• sélectionner en [1] la méthode [getAllClients] du service web puis, avec la souris, tirer cette méthode pour aller la déposer au sein de la méthode [init] de la classe de test.

On obtient le résultat [2]. Ce squelette de code nous montre comment utiliser le proxy C généré :

    try { // Call Web Service Operation
      rdvmedecins.ws.WsDaoJpaService service = new rdvmedecins.ws.WsDaoJpaService();
      rdvmedecins.ws.WsDaoJpa port = service.getWsDaoJpaPort();
      // TODO process result here
      java.util.List<rdvmedecins.ws.Client> result = port.getAllClients();
      System.out.println("Result = "+result);
    } catch (Exception ex) {
      // TODO handle custom exceptions here
}

• la ligne [5] nous montre que la méthode [getAllClients] est une méthode de l'objet de type [WsDaoJpa] défini ligne 3. Le type [WsDaoJpa] est une interface présentant les mêmes méthodes que celles exposées par le service web distant.
• ligne [3], l'objet [WsDaoJpa port] est obtenu à partir d'un autre objet de type [WsDaoJpaService] défini ligne 2. Le type [WsDaoJpaService] représente le proxy C généré localement.
• l'accès au service web distant peut échouer, aussi l'ensemble du code est-il entouré d'un try / catch.
• les objets du proxy C sont dans le package [rdvmedecins.ws]

Une fois ce code compris, on voit que la référence locale du service web distant peut être obtenue par le code :

WsDaoJpa dao=new WsDaoJpaService().getWsDaoJpaPort();

Le code de la classe de test JUnit devient alors le suivant :

package dao;

import rdvmedecins.ws.Client;
import rdvmedecins.ws.Creneau;
import rdvmedecins.ws.Medecin;
import rdvmedecins.ws.Rv;
import rdvmedecins.ws.WsDaoJpa;
import rdvmedecins.ws.WsDaoJpaService;
...

public class MainTestsDaoRemote {

  // couche [dao] testée
  private static WsDaoJpa dao;

  @BeforeClass
  public static void init(){
    dao=new WsDaoJpaService().getWsDaoJpaPort();
  }

  @Test
  public void test1() {
...
  }

  // méthode utilitaire - affiche les éléments d'une collection
  private static void display(String message, List elements) {
 ...
  }
}

Nous sommes désormais prêts pour les tests :

En [1], le test JUnit est exécuté. En [2], il est réussi. Si on regarde les affichages sur la console Netbeans, on trouve des lignes comme les suivantes :

Liste des clients :
rdvmedecins.ws.Client@1982fc1
rdvmedecins.ws.Client@676437
rdvmedecins.ws.Client@1e4853f
rdvmedecins.ws.Client@1e808ca

Côté serveur, l'entité [Client] a une méthode toString qui affiche les différents champs d'un objet de type [Client]. Lors de la génération automatique du proxy C, les entités sont créées dans le proxy C mais avec seulement les champs privés accompagnés de leurs méthodes get / set. Ainsi la méthode toString n'a pas été générée dans l'entité [Client] du proxy C. Ce qui explique l'affichage précédent. Ceci n'enlève rien au test JUnit : il a été réussi. On considèrera désormais qu'on a un service web opérationnel.