> Tech > Bref historique de DRDA

Bref historique de DRDA

Tech - Par iTPro - Publié le 24 juin 2010
email

IBM a développé DRDA en 1988 et 1989 et la première version a été publiée en 1990. En 1992, IBM a introduit DRDA dans les produits de gestion de base de données de tous les membres de la famille DB2, dans l'OS/400 V2R2M1. A cette époque, la fonctionnalité de DRDA

Bref historique de DRDA

était limitée à  ce que
l’on appelait alors la RUW (remote unit
of work). RUW restreignait une application
à  l’utilisation d’un seul serveur
de base de données pendant la durée
d’une transaction unique (unit of
work). Toutefois, l’application pouvait
se connecter à  d’autres serveurs ou à  la
base de données locale aux frontières
de l’unit-of-work.

En V3R1, IBM a étendu le support à  DUW (distributed unit of work). DUW
est fondé sur un « commit » en deux
phases, un procédé qui permet aux applications
de se connecter à  de multiples
serveurs, d’accéder aux données,
et d’appliquer des mises à  jour
multisystèmes dans une seule transaction.

Jusqu’à  la V4R2, les utilisateurs
iSeries de DRDA étaient limités à  utiliser
APPC (Advanced Program to
Program Communications) d’IBM
comme protocole de communication.
La V4R2 a introduit TCP/IP mais cette
amélioration n’utilisait pas le commit
en deux phases et était par conséquent
limitée à  RUW. La V4R4 permettait
d’échanger de grands objets de base
de données entre systèmes, y compris
des BLOB (binary large objects) et des
CLOB (character large objects). La
V4R5 renforçait la sécurité en permettant
de crypter les mots de passe utilisés
pour les requêtes de connexion
TCP/IP. Enfin, la V5R1 ajoutait deux
fonctions DRDA plus marquantes :
DUW dans l’environnement TCP/IP et
la possibilité pour les procédures cataloguées
appelées de renvoyer des jeux
de résultats multiples.

Cette dernière fonction permet
aux utilisateurs de créer des procédures
stockées qui ouvrent un ou plusieurs
curseurs associés aux instructions
SQL SELECT et retransmettent
tout ou partie des données à  l’application,
à  la conclusion d’une instruction
SQL CALL. Elle peut aussi renvoyer des
données en provenance d’un tableau en mémoire (in-storage array) comme
un jeu de résultats. En V5R1, cette
fonction n’est disponible qu’avec des
clients non-iSeries ; toutefois, IBM reconnaît
que le support côté client sur
l’iSeries est une exigence à  court
terme.

Pendant la décennie 1990, plusieurs
fournisseurs de logiciels indépendants
ont offert des produits côté
client qui fournissent l’accès base de
données iSeries aux applications PC et
Unix. En termes DRDA, on les appelle
Application Requesters, et la plupart
d’entre eux sont des drivers ODBC. La
mise en oeuvre de serveurs DRDA non-
IBM a été plus lente. En attendant que
cette situation change, les clients
ont une possibilité : utiliser DB2
DataJoiner ou DB2 Relational Connect
d’IBM. Ces produits middleware utilisent
des protocoles DRDA et non-
DRDA pour accéder aux données à  partir
de serveurs hétérogènes multiples,
et ils peuvent même joindre des données
multisources dans une requête
distribuée unique.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro - Publié le 24 juin 2010