Développement des applications d'accès aux données

Les applications d'accès aux données permettent de manipuler des données hors des sources de données pour une utilisation dans votre environnement de gestion d'application.

Pourquoi et quand exécuter cette tâche

Vous pouvez accéder à des données de différentes manières :
  • en utilisant les API standard ou étendues,
  • en utilisant des beans CMP,
  • en utilisant des beans BMP, des beans de session ou des composants Web,
  • en utilisant SDO (Service Data Objects).

Procédure

  1. Choisissez comment implémenter l'accès aux données.

    Le modèle de programmation Enterprise JavaBeans (EJB) prévoit plusieurs types distincts de composants côté serveur : les beans entity, session et pilotés par messages, et les servlets. Parmi ces différents types de composants, les beans entity sont généralement utilisés pour modéliser des composants métier dans une application. Les beans possèdent à la fois un état et un comportement.

    L'état des beans entity est persistant et stocké dans une base de données. Lorsque des modifications sont apportées à un bean entity, son état est synchronisé avec l'enregistrement qui le représente dans la base de données. Deux types de beans entity sont fournis par le modèle EJB, l'un et l'autre se distinguant par le mécanisme utilisé pour la persistance des données. Ces deux types sont les beans CMP (Container-Managed Persistence, ou persistance gérée par le conteneur) et les beans BMP (Bean-Managed Persistence, ou persistance gérée par le bean).

    • Dans le cas d'un bean BMP, le développeur produit manuellement du code pour gérer la persistance de l'état du bean.
    • Dans le cas de beans CMP, c'est le conteneur EJB qui gère l'état persistant du bean. La gestion de l'état persistant d'un bean est une tâche complexe. Aussi, l'utilisation de beans CMP permet aux développeurs de se concentrer sur la logique métier en délégant la tâche de persistance au conteneur.

      L'utilisation d'un bean CMP Compte est typique dans une application bancaire ; de même, l'emploi d'un bean CMP Client est généralisé dans les applications de gestion de la clientèle. Comme les beans CMP sont des objets, l'accès à leurs données (état) est réalisé au moyen d'accesseurs de zones. Par exemple, il est probable qu'un bean Client comporte des zones telles que nom et numTelephone. L'accès en consultation et en modification à de telles données peut s'effectuer à l'aide de méthodes getNom()/setNom() et getNumTelephone()/setNumTelephone(). En tant que développeur, vous n'avez pas à vous soucier de la manière dont ces données sont stockées et récupérées dans la base de données dorsale ; vous pouvez considérer que l'intégrité des données est maintenue par le conteneur.

    Pour plus d'informations sur le développement des beans entity, voir la rubrique Développement des beans enterprise.
    Conseils :
    • [AIX Solaris HP-UX Linux Windows][z/OS]Pour optimiser l'efficacité des demandes d'applications aux bases de données relationnelles, envisagez l'utilisation du langage SQLJ (SQL in Java™) lorsque vous développez des beans BMP et CMP. Cette option est disponible pour les applications qui utilisent le pilote JDBC DB2 Universal pour accéder aux bases de données DB2.

      [z/OS]Ce pilote n'est toutefois pas requis dans le cas de beans BMP dorsaux SQLJ qui accèdent à DB2 for z/OS ; ce schéma nécessite le pilote DB2 Legacy for z/OS (requis avec le fournisseur JDBC local DB2 for z/OS (RRS)).

    • [AIX Solaris HP-UX Linux Windows][z/OS]Considérez également l'utilisation de la persistance du curseur pour obtenir d'éventuels gains de performances. Pour plus d'informations, voir la rubrique "Prise en charge de la persistance du curseur d'une application JDBC".
    • [IBM i]Pensez à utiliser la persistance du curseur pour optimiser l'efficacité des demandes d'applications aux bases de données relationnelles.

    Une alternative au développement de beans entity consiste à utiliser la structure SDO (Service Data Objects), qui est une structure unifiée dédiée au développement d'applications de données. Avec SDO, vous n'avez pas besoin de connaître une API propre à une technologie pour pouvoir accéder aux données et les utiliser. Vous devez uniquement connaître l'API SDO qui vous permet de manipuler des données provenant de plusieurs sources, y compris de bases de données relationnelles, de composants EJB d'entité, de pages XML, de services Web, de ressources JCA (Java Connector Architecture), de pages JSP, etc.

  2. Recherchez une source de données ou une fabrique de connexions en utilisant une référence de ressource. Pour plus d'informations, voir la rubrique Recherche des sources de données avec des références de ressource pour l'accès relationnel. N'exécutez pas cette étape si vous utilisez des beans CMP. Le conteneur d'EJB gère ce processus pour les beans CMP.
    Pour exécuter des applications sur WebSphere Application Server, votre code doit utiliser des références de ressources sur les sources de données ou les fabriques de connexions nommées logiquement. Le mappage des références de ressources vers des ressources réelles a généralement lieu lors de l'assemblage. Ces ressources sont configurées par l'administrateur d'Application Server.
    • Pour accéder aux bases de données relationnelles, les administrateurs doivent configurer un fournisseur JDBC et des sources de données associées, qui travaillent avec l'adaptateur de ressources relationnelles intégré à WebSphere.
    • Pour accéder à des bases de données non relationnelles, les administrateurs doivent installer un adaptateur de ressources JCA (Java Platform, Enterprise Edition (Java EE) Connector Architecture) sur un serveur d'applications et configurer les fabriques de connexions associées.

    L'implémentation de contexte de travail fournit un mécanisme permettant à un adaptateur de ressources de contrôler les contextes dans lesquels des instances de travail soumises par l'adaptateur de ressources au gestionnaire de travaux du produit sont exécutées. En soumettant une instance de travail qui implémente l'interface WorkContextProvider, l'adaptateur de ressources peut propager différents types de contexte à WebSphere Application Server. Puis le serveur d'applications, s'il prend en charge le type de contexte propagé, définit celui-ci comme contexte d'exécution de l'instance de travail.

  3. Obtenez une connexion à une source de données ou à une fabrique de connexions Voir la section "Obtention de connexions" de la rubrique Cycle de vie d'une connexion, pour plus de détails. N'exécutez pas cette étape si vous utilisez des beans CMP. Le conteneur EJB gère ce processus pour les beans CMP.

    L'architecture de gestion des connexions pour les accès relationnels et procéduraux aux systèmes d'information d'entreprise (EIS) est fondée sur la spécification JCA (Java EE Connector Architecture). Le gestionnaire de connexions (CM), qui gère et met en pool les connexions dans un serveur d'applications, est capable de gérer les connexions obtenues via les adaptateurs de ressources définis par la spécification JCA, mais aussi celles qui sont obtenues via les sources de données définies par la spécification des extensions JDBC.

  4. [z/OS]Utilisez l'identité de l'unité d'exécution pour attribuer un propriétaire à la connexion. Pour plus d'informations, voir la rubrique "Utilisation du support d'identité d'unité d'exécution".

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_impdatacc
Nom du fichier : tdat_impdatacc.html