

Le Power Play d’IBM
par Frank G. Soltis - Mis en ligne le 13/07/2005 - Publié en Octobre 2004
Connaissez-vous la différence entre les processeurs POWER et PowerPC ?
En hockey, il y a power play quand une équipe a un ou deux joueurs de plus
à cause des sanctions infligées à l'adversaire. La possibilité qu'a l'équipe avantagée
de marquer est bien supérieure pendant un power play. Peut-être « power
play » est aussi un bon moyen de décrire la récente promotion par IBM de
son processeur Power. Alors que tant d'autres fournisseurs s'efforcent d'imposer
leurs nouvelles technologies processeur sur le marché, IBM démontre
qu'elle est encore le premier fournisseur en la matière ...Pendant de nombreuses années, IBM a fabriqué des processeurs de pointe
pour ses propres produits. Cette technologie propriétaire n'était partagée avec
personne en dehors d'IBM. Cela a commencé à changer au début des années
90 quand IBM a collaboré avec Motorola et Apple pour créer un nouveau processeur
RISC à un seul chip qu'on appellerait PowerPC. Depuis lors, de plus en
plus de produits de multiples fournisseurs ont commencé à utiliser la technologie
Power. Ainsi, en 2002, ce sont plus de 18 millions de processeurs Power
qui ont été livrés. Et pas seulement pour des serveurs IBM.
Aujourd'hui, on trouve deux variantes
du nom Power : POWER (comme
dans POWER4 et POWER5) et
PowerPC. Des deux, le nom PowerPC
est de loin le plus connu à cause de l'utilisation
généralisée des chips PowerPC
dans toutes sortes d'appareils : téléphones
cellulaires, PDA, stations de travail
et serveurs d'entrée de gamme. Le
nom Power, quoi que beaucoup moins
connu en dehors d'IBM, est en train de
gagner ses galons de meilleure architecture
processeur pour des serveurs haut de gamme. Récemment IBM a commencé
à promouvoir POWER comme nom de famille général.
La relation entre POWER et PowerPC est pourtant simple. La définition de
l'architecture de base est la même pour les deux. Ils ne diffèrent que par les extensions
apportées à cette architecture pour des processeurs spécifiques. Par
exemple, l'architecture POWER est principalement destinée aux serveurs, c'est
pourquoi de récentes moutures des processeurs POWER contiennent des extensions
favorisant les fonctions serveur, comme le partitionnement logique.
En revanche, un processeur PowerPC destiné à un téléphone cellulaire n'a nul besoin du partitionnement logique, mais il appréciera certaines
extensions à caractère téléphonique.Ils se distinguent aussi par le niveau de disponibilité. La
technologie PowerPC est à l'entière disposition des OEM.
Ouverte et extensible, on peut la personnaliser pour les applications
les plus diverses. Il s'en suit que différentes implémentations
des processeurs PowerPC contiennent souvent
différentes extensions selon la destination du processeur. De
plus, les processeurs d'architecture PowerPC sont proposés
par de multiples sources autres qu'IBM.
IBM l'offre. S'il est vrai que les processeurs POWER étaient, à
l'origine, destinés aux seuls serveurs IBM, cela aussi a commencé
à changer. Dans un futur très proche, on commencera
à voir les tout derniers processeurs POWER dans des
produits proposés par d'autres fournisseurs. Ensemble, ces
deux architectures processeur couvrent tout l'éventail de
l'informatique, des appareils manuels les plus petits jusqu'aux
plus puissants superordinateurs du monde.
Les perspectives des processeurs PowerPC et POWER
d'IBM vont désormais bien au-delà de la décennie. Comme il
y a encore beaucoup de confusion dans l'esprit de nombreux
clients OS/400 à propos des similitudes et des différences
entre ces deux architectures (voir l'encadré « La vérité au sujet
de la PlayStation 3 et de l'OS/400 » pour un exemple), il est
instructif d'y regarder de plus près. Sans rentrer dans des détails
fastidieux, nous allons voir comment ces deux architectures
ont été développées et quelle est leur relation réciproque.

Trucs & Astuces iSeries : RPG, .NET
Les trucs & astuces de la semaine du 30 Mai au 5 Juin 2005
Lire l'article
Fichiers texte : une première
par Scott Klement - Mis en ligne le 23/11/2005 - Publié en Mars 2005
Dans l'article « Introduction aux fichiers stream » (iSeries News janvier 2005
ou www.itpro.fr, Club Abonnés), j'expliquais les principes de base des fichiers
stream : comment les ouvrir, comment les lire et comment y écrire. Je développe
ces points en expliquant tout ce qui concerne les fichiers texte.
On peut utiliser les fichiers texte pour de nombreuses actions très différentes
: l'exemple le plus courant est un échange de données entre systèmes.
Les formats courants comme XML et CSV sont des types de fichiers texte utilisés
chaque jour dans des transactions de gestion. Les fichiers HTML qui constituent
le World Wide Web sont un
genre de fichiers texte. Mais avant
de comprendre tous ces fichiers
texte spécialisés, il faut commencer
par apprendre les principes de
base.

Quelques conseils pour gérer l’IFS avec iSeries Nav
par Greg Hintermeister - Mis en ligne le 19/10/2005 - Publié en Janvier 2005
Je suis concepteur d'interaction utilisateur chez IBM. A ce titre, il m'arrive souvent
de créer des maquettes des futurs produits. Je montre des modèles, des comportements
et des interactions des produits, afin que mes pairs puissent les examiner
et les commenter. Pour accomplir ce travail, j'ai utilisé de nombreux outils
et leur suis resté fidèle au fil des ans. Récemment, j'ai été amené à accomplir une
tâche simple et, si j'avais seulement pris le
temps de prendre connaissance des améliorations
apportées à ces outils familiers, je
l'aurais faite en un clin d'oeil. Mais, la force de
l'habitude aidant, j'ai utilisé une version antérieure
de l'outil avec lequel je me sentais très
à l'aise. Par la suite, j'ai découvert que si
j'avais consacré un peu plus de temps à me
renseigner sur la dernière version des outils,
j'aurais gagné beaucoup de temps.

D’autres outils Web pour les programmeurs iSeries
par Phil Coulthard et George Farr - Mis en ligne le 21/09/2005 - Publié en Décembre 2004
Nous continuons ici à présenter aux programmeurs iSeries les outils Web inclus
dans WDSc (WebSphere Development Studio Client), que tous les programmeurs
RPG et Cobol possèdent. Dans les articles précédents (voir l'encadré « Articles précédents
»), nous décrivions l'architecture MVC (model-view-controller) des applications
modernes et montrions comment le framework Struts se prête à l'utilisation
de cette architecture pour construire des applications Web. Nous avions aussi commencé
à décrire les outils Web qui facilitent la construction d'une nouvelle application
Web par-dessus Struts, en utilisant RPG ou Cobol pour la logique de gestion du
troisième niveau (modèle). Nous continuons notre périple en abordant la partie
vraiment intéressante, celle où nous écrirons réellement un fragment opérationnel
d'application Web, et ce avec deux seuls ingrédients : le code RPG existant et nos
compétences RPG actuelles.
Nos deux articles précédents étaient basés sur WDSc 5.1.0, mais depuis le 16
juillet nous disposons de WDSc 5.1.2, améliorée à plusieurs égards. Cet article s'appuie
donc sur cette nouvelle release particulièrement riche. S'il nous arrive d'utiliser
une amélioration propre à la 5.1.2, nous le mentionnerons.

Travailler avec des API, deuxième partie
par Paul Morris - Mis en ligne le 6/07/2005 - Publié en Octobre 2004
Apprenez à utiliser un espace utilisateur, à le remplir de données, à extraire des
enregistrements, et bien plus
Dans la 1ère partie de cet article
(iSeries News février 2004 ou www.itpro.
fr), nous avons examiné deux programmes
ILE RPG - un qui appelait des
API en utilisant une PLIST et un qui les
appelait en utilisant des appels prototypés
- pour voir en quoi les programmes
différaient. Dans cette 2e
partie, nous continuons à nous intéresser
aux API. Nous verrons comment
employer un espace utilisateur, le remplir
avec des données, en extraire des
enregistrements, et utiliser d'autres
API ...

Créer des triggers DB2 avec SQL
par Jeff Sutherland - Mis en ligne le 23/11/2005 - Publié en Mars 2005
Je suis un inconditionnel des triggers de DB2 que j'utilise depuis des années.
Les triggers font merveille quand il s'agit de vérifier des données, de détecter
une modification de fichier (add, delete, change) ou de lancer d'autres
processus en fonction d'un changement intervenu dans une base de données,
sans retoucher les applications existantes.

Utiliser des règles pour traiter le spam
Mis en ligne le 19/10/2005 - Publié en Septembre 2004
Quand on utilise une stratégie tag-and-deliver pour combattre
le spam, il faut fournir aux utilisateurs un moyen automatisé
de traiter le spam qu'il reçoivent. Les règles de traitement
de messages sont un moyen d'automatiser cette tâche.

La problématique des éditions des documents d’entreprise
par Didier Adriaenssens - Mis en ligne le 21/09/2005 - Publié en Décembre 2004
De manière générique, les documents
issus des spools peuvent être
qualifiés d'archaïques et de figés.
L'attente du monde de l'AS/400 (I5)
est de rajeunir son image par les présentations
écran mais aussi par la
forme des éditions. La problématique
qui se pose étant de pouvoir
bénéficier d'une impression « dynamique
» dans laquelle les polices, les
couleurs et la disposition se modifient
en fonction de la nature des
données et de la destination des documents.
C'est le principe du mappage
qui consiste à s'appuyer sur les
données pour déterminer la mise en
forme des documents à la volée.

DB2 UDB simplifie l’administration et le développement d’application
par Kent Milligan - Mis en ligne le 6/07/2005 - Publié en Octobre 2004
C'est un défi sans cesse renouvelé que d'adapter vos solutions iSeries aux exigences
toujours plus grandes de la communauté utilisatrice. Les utilisateurs
exigent des fonctions plus élaborées de leurs applications et veulent accéder
aux données provenant de diverses unités et interfaces. Pour se tenir à flot, les
développeurs d'applications ont besoin
d'une boîte à outils très étoffée. DB2 UDB
pour iSeries en V5R3 ajoute beaucoup de
nouvelles options au kit base de données
qu'utilisent les programmeurs iSeries, administrateurs
et autres DBA (database administrators)
de data warehouse ...

Protéger vos systèmes avec Event Viewer
par Kathy Ivens - Mis en ligne le 23/11/2005 - Publié en Septembre 2004
Quand un événement notable survient sur un ordinateur,
l'OS l'écrit dans un journal. L'Event Viewer (eventvwr.exe)
est le réceptacle de ces journaux d'événements. La plupart
des administrateurs n'ouvrent Event Viewer qu'en cas de
grave problème. Et beaucoup d'entre eux admettent ne
l'utiliser que sur les serveurs. Ces deux pratiques sont
critiquables sur le plan administratif, parce que la consultation
régulière des journaux d'événements intercepte des
problèmes avant qu'ils ne deviennent graves. Il est important
de savoir utiliser Event Viewer. C'est pourquoi j'en donne
une vue d'ensemble et indique comment je l'utilise.

Pas prêt pour une solution antispam?
par Joseph Neubauer - Mis en ligne le 19/10/2005 - Publié en Septembre 2004
Le flot commence doucement : un courriel, puis un autre, et encore un
autre. Des personnes se plaignent au Help desk de recevoir des courriels publicitaires
qui ne leur sont pas adressés, et les utilisateurs se plaignent de recevoir
des annonces scabreuses, voire pornographiques. Vous passez des heures
à scruter les fichiers log et à suivre les messages et, finalement, parvenez à la
conclusion qu'une solution antispam s'impose. Il est clair qu'elle serait bénéfique
pour la société, mais les décideurs refusent quand même.

Configurer et administrer WebSphere
par Don Denoncourt - Mis en ligne le 14/09/2005 - Publié en Décembre 2004
Quand WebSphere est devenu disponible sur l'iSeries pour la première fois,
les sites utilisateurs étaient rares et espacés. Mais, dès lors que le logiciel applicatif
Web propre à l'iSeries se multiplie, WebSphere Express devient un produit iSeries
incontournable. Les applications Web les plus marquantes sont iSeries Access for
Web (iAW), Host Access Transformation Services (HATS) et WebFacing ...Mais beaucoup
d'entreprises ne tirent pas profit de ces produits tout simplement parce que
l'installation et la configuration d'un serveur WebSphere les effraient. Qu'ils se rassurent
: WebSphere Express est d'utilisation facile. Cet article est un tutoriel sur la
configuration et l'administration d'un serveur WebSphere. Il s'adresse précisément
à un administrateur ou à un opérateur iSeries qui n'est expert ni en réseau ni en
Java.

Pagination côté serveur avec SQL Server
par Andrew Rosca - Mis en ligne le 6/07/2005 - Publié en Octobre 2004
Une procédure stockée simple vous permet de contrôler les flux de données et
d'accéder à des millions d'enregistrements
Les applications Web utilisent fréquemment la pagination d'enregistrements
afin de présenter de très grandes quantités de données aux utilisateurs. Par
exemple, il n'est pas rare qu'un moteur de recherche Internet retourne des dizaines
de milliers de résultats en réponse à une requête d'un utilisateur. Si le
moteur renvoyait l'ensemble des résultats en une seule fois, le système destinataire
serait complètement saturé. C'est pourquoi la pagination décompose
les données en blocs de taille fixe rendant possible la gestion des résultats et
réduisant la quantité d'informations transférées en une seule fois du serveur
vers le client ...L'application ne propose que quelques enregistrements à la fois
aux utilisateurs, en commençant de préférence par les informations les plus
pertinentes. Non seulement la pagination facilite la compréhension et la
consultation des données, mais elle améliore également les performances de
l'application, car la récupération et l'affichage de volumes élevés d'informations
créent une charge inutile qui peut ralentir votre système. Si ce dernier pagine
les enregistrements correctement, les utilisateurs d'un moteur de recherche
n'auront vraisemblablement pas besoin de consulter plus d'une ou
deux pages de résultats.
Malheureusement, de nombreux programmeurs n'ont pas conscience de
certains aspects importants de la pagination sur le plan des performances.
Dans un environnement IIS et SQL Server classique, la méthode la plus fréquente
de mise en oeuvre de la pagination
consiste à utiliser les fonctionnalités
de pagination de l'objet ADO Recordset
standard, notamment les propriétés
AbsolutePage, PageSize et PageCount.
Pour les volumes de données relativement
faibles (entre quelques dizaines et
quelques centaines d'enregistrements),
ces fonctionnalités sont parfaitement appropriées
et la charge qu'elles génèrent
n'affecte pas sensiblement les performances.
Toutefois, à mesure que le
nombre d'enregistrements augmente, cette technique perd en efficacité et entraîne
une baisse sensible des performances de l'application.
Dans les applications gérant des volumes importants de données, par
exemple une application d'approvisionnement qui affiche des nombres élevés
de commandes, un site de rencontres gérant des milliers d'utilisateurs ou un
site de commerce électronique qui affiche des centaines de produits en réponse
à une recherche d'un utilisateur, vous avez besoin de techniques de pagination côté serveur sophistiquées.
Cet article présente un exemple simple
de technique de codage que j'utilise
pour des tables contenant plusieurs
millions d'enregistrements.

Création d’un mauvais exemple
Mis en ligne le 23/11/2005 - Publié en Décembre 2004
Lorsque vous écrivez un exemple de code afin de reproduire
une violation de la sécurité, l'un des défis à relever réside
dans le fait qu'un tel code, par définition, intègre de mauvaises
pratiques. En lisant les exemples de code de l'article
principal, vous pouvez être amené à effectuer des commentaires
du type « Je ne ferais pas... » ou « Cela ne poserait pas
de problème de... ». Toutefois, le rôle d'un exemple susceptible
de soulever les critiques des lecteurs est de montrer
toute l'utilité de certaines bonnes pratiques.

YUKON : une mine d’or
par Michael Otey - Mis en ligne le 10/10/2005 - Publié en Octobre 2004
Yukon, dont la livraison est prévue en 2005, est la dernière version de
Microsoft SQL Server. Il marque la fin d'un cycle de développement de 5 ans
pour Microsoft. La firme a ajouté tellement de nouvelles fonctions à Yukon
qu'il est impossible de les énumérer toutes dans un seul article. Voici donc 13
pépites d'or que l'on risque fort de trouver dans la prochaine release notable
de SQL Server.

Outils Web pour programmeurs iSeries : tous les détails
par Phil Coulthard et George Farr - Mis en ligne le 07/09/2005 - Publié en Novembre 2004
Nous poursuivons ici l'itinéraire entamé en octobre 2003. Jusqu'ici, nous
avons couvert les outils RPG et Cobol qui constituent l'étape Meilleurs Outils,
ainsi que l'outil IBM WebFacing et l'outil IBM Host Access Transformation pour
l'étape Meilleure Interface Utilisateur. Nous nous sommes intéressés à l'étape
Meilleure Architecture pour construire des applications Web dans les règles de
l'art, avec la logique de gestion RPG ou Cobol, et nous avons présenté le framework
Struts open-source qui peut servir de point de départ de votre nouvelle
application Web. Ici, nous approfondissons
les outils Web présents dans WDSc (WebSphere Development
Studio Client) pour en montrer les détails. Nous commençons par voir comment
créer un projet Web à partir de zéro puis nous montrons comment
mettre en place l'information de configuration iSeries. Nous concluons par le
diagramme de page qui vous aidera à créer visuellement des applications
iSeries basées Struts.

Les files d’attente
par Sameer Dandage - Mis en ligne le 6/07/2005 - Publié en Octobre 2004
Si une légère attente n'est pas critique, la solution de réplication TRQU est faite
pour vous
Aujourd'hui, de plus en plus d'entreprises doivent rendre leurs données disponibles
sur de multiples serveurs et sur des sites distants, en préservant une synchronisation
la plus étroite possible entre les données de chacun des sites. Dès
lors qu'il existe plusieurs copies des données stratégiques, la disponibilité de ces
dernières s'en trouve améliorée. Par exemple, en cas de défaillance d'un site, vous
pouvez dévier le trafic vers un autre site ou serveur ...Par ailleurs, les administrateurs
de base de données (DBA) peuvent répartir la charge sur plusieurs serveurs,
afin d'éviter la surcharge de l'un deux et améliorer les temps de réponse aux requêtes
des utilisateurs, en particulier si le serveur est situé à proximité de ceux-ci.
Envisageons quelques instants un scénario illustrant les besoins de failover et
de répartition de la charge pour un système de base de données qui inclut une application
à trois niveaux sur deux sites géographiquement
distincts. Chaque site utilise un
serveur Web, un serveur d'applications et un
serveur de base de données. Lorsque le fonctionnement
du système est optimum, le serveur
Web et le serveur d'applications de
chaque site distribuent leurs requêtes utilisateur
entre les deux serveurs de base de données
afin qu'ils puissent se répartir la charge
de travail. Toutefois, en cas d'indisponibilité
d'un des deux serveurs de base de données ou
d'une des bases de données, les serveurs Web
et d'applications peuvent basculer toutes leurs requêtes vers le serveur de base de
données de l'autre site. Dès que le premier serveur de base de données est de
nouveau opérationnel, le processus de répartition des requêtes utilisateur entre
les deux est rétabli.
Lorsqu'une organisation utilise un site actif et maintient l'autre en lecture
seule, les tâches du DBA sont relativement simples. En revanche, son travail devient
très vite complexe si l'organisation décide de placer plusieurs sites en mode
actif et de synchroniser les données entre eux. Pour répondre à ce cas de figure,
SQL Server propose une option : la réplication transactionnelle. L'objet de cet article
n'étant pas d'expliquer les fondements de ce mécanisme, vous trouverez plus
d'informations sur le sujet en lisant la rubrique « Réplication transactionnelle » de
la documentation en ligne de SQL Server.
SQL Server 2000 propose deux options de réplication transactionnelle permettant
d'actualiser les données au niveau de l'abonné (Subscriber). Pour la première,
intitulée « Réplication transactionnelle avec mise à jour immédiate des
Subscribers », SQL Server utilise une validation à deux phases afin de mettre à jour
simultanément dans la même transaction l'éditeur (Publisher) et le Subscriber. La
validation à deux phases verrouille la ligne concernée sur tous les sites participant à la réplication lorsqu'une mise à jour est effectuée sur l'un
d'eux. Ce mécanisme de verrouillage élimine toute latence
entre le moment où un Subscriber est mis à jour et le moment
où le Publisher reflète la mise à jour en question. Pour
que cette option fonctionne, le Publisher et le Subscriber
doivent toutefois être en cours d'exécution et connectés en
permanence, faute de quoi les utilisateurs ne peuvent pas effectuer
de mises à jour sur le Subscriber.
La deuxième option est la « Réplication transactionnelle
avec mises à jour en file d'attente », que j'abrégerai en TRQU
(Transactional Replication with Queued Updates) dans cet
article. A la différence de la première option, la solution
TRQU requiert une certaine latence entre le moment d'une
mise à jour sur le Subscriber et le moment où celle-ci est répercutée
sur le Publisher. Mais cette approche présente un
inconvénient : une ligne peut être mise à jour avec des données
différentes sur plusieurs sites simultanément et la cohérence
des données entre les sites ne sera pas assurée tant
qu'un mécanisme de résolution des conflits n'aura pas
éliminé cette incohérence. Vous définissez des règles de
résolution, telles que « l'éditeur gagne » (Publisher wins) ou
« l'abonné gagne » (Subscriber wins), dans la configuration
TRQU. En conséquence de quoi, les mises à jour sur un site
peuvent remplacer celles effectuées sur un autre. L'approche
TRQU présente l'avantage suivant : le Publisher et le
Subscriber ne doivent pas être connectés en permanence
et le Publisher peut être arrêté pendant la mise à jour d'un
Subscriber. Par conséquent, la réplication TRQU garantit aux
utilisateurs une disponibilité plus élevée d

Comment éviter les attaques par injection de code SQL
par William Sheldon - Mis en ligne le 23/11/2005 - Publié en Décembre 2004
Au moment de définir votre infrastructure de sécurité, la protection des
données de votre organisation constitue votre principal objectif. SQL Server, en tant
que référentiel de données, devient le centre de votre univers axé sur la sécurité.
Pour sécuriser vos données, vous avez exécuté l'outil MBSA (Microsoft Baseline
Security Analyzer), limité les communications avec la base de données, mis en
oeuvre le protocole IPSec (Internet
Protocol Security) afin de crypter vos communications
et peut-être même ajouté un
pare-feu séparé. Malgré tout, il reste un
moyen pour les intrus d'attaquer votre
base de données : par le biais des applications
qu'elle prend en charge. Toute stratégie
de sécurité comporte un maillon
faible et, du point de la conception, l'élément
le plus faible de votre stratégie sera
l'application Web car elle constitue le principal
point d'entrée pour les intrus, les autres chemins d'accès possibles ayant normalement
été verrouillés. Toutefois, une gestion incorrecte de ce point d'entrée
peut rendre vos données vulnérables à l'attaque potentiellement dévastatrice
qu'est l'injection de code SQL. Ce type d'attaque est extrêmement dommageable
car elle permet aux intrus d'exécuter des commandes directement sur votre base
de données.