Traduction des logiciels : vers une meilleure compréhension
par John Ghrist
Quel est l'un des plus grands obstacles aux ventes de logiciels américains sur
les marchés internationaux ? La langue, bien sûr. Bien que reconnu comme une langue
internationale, l'anglais n'est en fait pas aussi universel que cela.
Sur les marchés extérieurs aux pays anglo-saxons, les logiciels ne proposant que
des interfaces en anglais ont un net handicap, même s'ils s'agit d'applications
plus performantes, tout simplement parce que la plupart des utilisateurs demandent
une interface leur permettant de travailler dans leur propre langue.
Pour un éditeur anglo-saxon, la solution logique est donc de fournir une version
des produits les plus stratégiques dans les différentes langues. Mais trouver
les personnes compétentes pour traduire des supports techniques comme des interfaces
utilisateurs, des fichiers d'aide et de la documentation relève de la mission
impossible. Faut-il s'allouer les services de traducteurs en interne ? Faut-il
avoir recours à des services de traduction ? Ou encore utiliser un logiciel de
traduction ? Et une fois le choix effectué, comment mesurer l'impact et la qualité
du travail, des outils et des services de la solution retenue ?
Mapics, Inc. (et les sociétés l'ayant historiquement précédée) est venue à bout
de ce problème, en diffusant avec succès à l'étranger une solution de gestion
industrielle réputée sur AS/400.
Le produit a d'abord été traduit dans quelques-unes des langues européennes
vers le milieu des années 80
L’administration de l’AS/400 avec SNMP
par Mel Beckman
Suivre les performances, les événements et les configurations à distance, en utilisant
SMNP (Simple Network Management Protocol)
La plupart des gens qui entendent parler de l'administration de l'AS/400 à distance
pensent immédiatement à OpsNav (Operations Navigator). Effectivement, OpsNav permet
d'effectuer à distance une large gamme de tâches administratives : reconfiguration
de l'OS/400, démarrage et arrêt des services, et manipulation des files d'attente
de jobs et d'imprimantes. Pourtant, si OpsNav est un excellent outil pour contrôler
un AS/400 à distance, ce n'est pas vraiment un outil d'administration à distance
si, par administration, on entend : suivre les performances, surveiller les valeurs
système sensibles et réagir à des événements imprévus. Pour vraiment administrer
ou gérer un système, il faut considérer son comportement vis à vis de l'ensemble
du réseau, y compris de nombreuses unités non-AS/400, comme des commutateurs LAN,
des routeurs et des serveurs Windows.
Il est clair qu'OpsNav ne se hisse pas à ce niveau. Heureusement, l'OS/400 supporte
le protocole d'administration à distance le plus répandu : SNMP (Simple Network
Management Protocol). C'est un standard ouvert, hétérogène, qui permet de collecter
des statistiques de performances, suivre des événements et contrôler des unités
à distance. Comme SNMP est ouvert, les développeurs de produits SNMP disposent
d'un marché qui dépasse largement les simples utilisateurs d'AS/400, d'où une
concurrence féroce entre les produits. Le vainqueur c'est vous : avec un large
éventail d'outils logiciels SNMP proposé. Entrons dans les arcanes de SNMP " générique
" et de SNMP sur l'AS/400, puis intéressons-nous à quelques produits SNMP.
Améliorer SQL/400 avec des fonctions définies par l’utilisateur
par Michael Sansoterra
Les UDF permettent de créer une logique personnalisée et centralisée à l'intérieur
d'instructions SQL
SQL est un langage de requêtes puissant. Bien souvent, il peut extraire des données
et être codé plus rapidement qu'un programme en langage de haut niveau (HLL :
High-Level Language). Malheureusement, SQL/400 a toujours souffert d'une importante
lacune par rapport aux programmes HLL : il n'offrait pas la capacité de créer
une logique spécialisée et centralisée à l'intérieur d'instructions SQL. Avec
la V4R4, IBM y remédie par l'utilisation d'UDF (User-Defined Functions).
Les fonctions SQL se déclinent de 2 façons
De gré ou de force, les constructeurs adoptent une stratégie Linux
par René Beretz
A l'heure de l'adoption de Linux en entreprise, la stratégie des constructeurs
informatiques évolue considérablement.
La stratégie des constructeurs informatiques envers les systèmes d'exploitation
a changé. Les systèmes propriétaires n'ont plus le vent en poupe et la plupart
des sociétés vantent les standards. Mais du discours à la réalité, il reste du
chemin à parcourir. Ne serait-ce que dans le monde Unix, il reste des différences
bien réelles et une concurrence effective entre AIX d'IBM, HP-UX de Hewlett-Packard
ou Solaris de Sun. Les constructeurs ont cependant sauté sans trop d'états d'âme
sur la vague Linux qui a rattrapé également les groupes de travail qui se préoccupent
de convergence d'Unix. Il est fort probable que l'avenir des différents Unix va
donc dépendre de cet outsider.
De fait, poussés par l'engouement des développeurs, les entreprises commencent
à adopter Linux et il devient donc essentiel pour les constructeurs d'être présents
sur ce créneau. En outre, il leur offre l'opportunité de se repositionner sur
le marché de l'éducation et sur certains marchés étrangers.
Les constructeurs ont cependant sauté sans trop d'états d'âme sur la vague
Linux
L'attitude des constructeurs oscille entre deux extrêmes : certains ont élaboré
une vraie stratégie Linux : ils ont adopté une attitude dynamique qui devance
le marché : c'est le cas, en particulier, d'IBM, de Hewlett-Packard et de Silicon
Graphics.
D'autres sociétés se contentent de proposer des solutions Linux pour répondre
aux attentes de leurs clients : c'est le cas de Compaq ou de Dell. Entre les deux,
Sun accompagne le mouvement tout en protégeant ses acquis.
Mettre en place des stratégies d’accès distant
par Douglas Toombs
Il y a 5 ou 6 ans, deux grands acteurs s'affrontaient autour d'une proie alléchante,
baptisée « part de marché ». Celle qui remporterait la plus grosse part serait
adorée par les richissimes habitants consensuels d'un pays mystique répondant
au nom implacable de Wall Street. A l'époque cette part était entre les griffes
de Novell et Microsoft la convoitait.
Ceux de nos lecteurs qui fréquentent l'univers de l'informatique depuis suffisamment
longtemps pour se rappeler les premiers pas de Windows NT, savent que si Microsoft
a pu glisser un pied dans la porte (y compris de certains comptes Novell purs
et durs), c'est grâce à l'ajout à NT de services inexistants sur les autres plates-formes.
A l'époque, un de ces cadeaux gratuits les plus connus fut le service d'accès
à distance RAS. Ses concurrents les plus acharnés étaient les périphériques matériels
propriétaires et Novell NetWare Connect, mais leurs coûts de licences par port
étaient très élevés.
Windows NT s'est lentement infiltré dans les organisations en introduisant l'un
après l'autre des services gratuits répondant à des besoins spécifiques des consommateurs.
Malheureusement, bon nombre de ces " plus " n'ont pas atteint la même maturité
que Windows NT au fil des ans. Malgré quelques améliorations à chaque révision
du système d'exploitation, RAS s'est avéré insuffisant dans certains domaines
importants pour entreprises, en particulier pour ce qui est de gérer quel utilisateur
peut se connecter à un serveur RAS et à quel moment. Le RAS de NT n'est pas étranger
à la sécurité des domaines et aux stratégies de comptes, mais les administrateurs
veulent souvent pouvoir contrôler davantage les utilisateurs appelant de l'extérieur.
Pour répondre à leurs attentes, Microsoft a ajouté à Windows 2000 Server des stratégies
d'accès à distance que RAS peut appliquer aux connexions entrantes.
Qui veut un annuaire à 100 millions d’entrée ?
par Tony Redmond et Micky Balladelli
Tout le monde est conscient que la base de données SAM de Windows NT est un goulet d'étranglement pour les capacités d'évolution des domaines. En effet, la limite pratique de la SAM se situe à environ 40.000 comptes d'utilisateurs par domaine. Certaines entreprises, qui sont allées jusqu'aux limites supérieures de la SAM et ont créé de très grands domaines, ont constaté que ces derniers sont difficiles à gérer.Windows 2000 repose sur l'annuaire Active Directory (AD), qui est un référentiel des comptes d'utilisateurs et de nombreux autres types d'objets. On peut faire confiance à Microsoft pour ne pas répéter la même erreur une deuxième fois : AD est plus évolutif que la SAM. Mais jusqu'à quel point ? La question mérite d'être posée. Combien d'objets peut-on stocker dans un domaine, quelle est la taille de la base de données, est-elle administrable et quel type de performances peut-on attendre d'Active Directory ?
Pour le savoir, notre confrère américain Windows 2000 Magazine a créé une très grande base de données AD, dont ils ont démontré les capacités au Comdex de Las Vegas en novembre 1999 et lors du lancement de Windows 2000 à San Francisco en février 2000. Cette démonstration de l'évolutivité d'Active Directory montre que la base de données peut contenir 100 millions d'entrées dans un environnement de production réaliste. Avant d'expliquer comment la base de données de démonstration a été construite et de révéler ce que le processus de création a appris sur AD, revenons d'abord sur quelques principes de bases d'AD.
Utiliser des commandes Java dans le Qshell AS/400
par Dan Darnell
L'interpréteur
Qshell de l'AS/400 fournit un environnement permettant de saisir des commandes
Java et d'en visualiser les sorties
L'interpréteur QShell est l'un des éléments les plus importants ajoutés récemment à l'OS/400, en V4R2. Mais celui qui programme surtout en RPG ou en Cobol ne sait peut-être même pas que ce “ système dans le système ” existe. On peut utiliser QShell pour réaliser des tâches essentielles sur l'AS/400, comme la compilation et l'exécution de programmes Java. Etant donné que les environnements shell viennent du monde Unix, la plupart des “ vétérans ” de l'AS/400 trouveront leur utilisation et leur configuration non intuitives. Je me propose de vous familiariser avec la vie dans le shell, pour que vous utilisiez facilement le code Java et que vous compreniez mieux l'environnement qui constitue la base du support runtime Java de l'AS/400. Un coup d'oeil rapide à l'interface QShell et à une poignée d'outils Java intégrés sert d'introduction à l'environnement. Un prochain article expliquera quelques techniques pour maîtriser QShell.
QShell est l'un des éléments les plus importants ajoutés récemment à l'OS/400
Lire l'article
Optimisez vos techniques de lecture en boucle
par Jef Sutherland
Voici deux techniques de lecture en boucle que vous pourrez utiliser au quotidien dans vos programmes RPG.Cet article explique comment utiliser deux structures logiques de lecture en boucle dans une application RPG pour lire des enregistrements particuliers dans un fichier avec clé. Concrètement, dans une application RPG, on peut vouloir lire en boucle tous les enregistrements des ventes d'une certaine date, ou tous les articles appartenant à une certaine catégorie de produits. Avant de passer au RPG, voyons les fichiers avec clé, et comment déterminer si les fichiers physiques et logiques de l'AS/400 en comportent.
12 règles pour les gens ordinaires
par Roger PenceDans son nouveau livre, au titre résolument inspiré par le Web : Business@the Speed of Thought (Le travail à la vitesse de la pensée, Robert Laffont, pour l'édition française), Bill Gates énonce ses 12 règles pour réussir à l'âge du numérique. Quelqu'un qui possède 60 ou 70 milliards de dollars dans son escarcelle et élève ses propres saumons, peut-il fixer des règles pratiques utilisables par le reste d'entre nous ? Non, bien entendu. Permettez-moi d'énoncer modestement mes 12 règles pour les ateliers AS/400, à l'approche de l'âge du numérique
Lire l'article
Créer un historique de l’utilisation des disques AS/400
par Terry Smith
Au fil du temps, l'utilitaire Library History rassemble les informations sur la
taille des bibliothèques et les affiche en utilisant une interface Web
En tant qu'administrateur de base de données, je suis persuadé que l'on a jamais
trop d'espace disque sur un AS/400. C'est presque une loi de la nature que quelle
que soit la quantité d'espace dont on dispose, celui-ci est finalement utilisé.
Mais, s'il nous fallait rédiger le chèque pour acheter de nouveaux disques, nous
changerions peut être rapidement d'avis. Etant donné que le coût unitaire des
disques baisse au fil du temps, il n'est pas recommandé d'acheter plus d'espace
disque que l'on envisage d'en utiliser dans l'immédiat. L'idéal serait de suivre
et de planifier l'utilisation des unités disques de manière à acheter des disques
supplémentaires au fur et à mesure que les besoins se font sentir, afin de profiter
d'une part des baisses des prix, et d'autre part des nouvelles technologies. L'utilitaire
Library History procure une meilleure image de l'utilisation des disques AS/400,
permettant ainsi une meilleure prise de décisions d'achat de disques et une meilleure
utilisation de l'espace.
Library History permet une meilleure prise de décisions d'achat de disques
et une meilleure utilisation de l'espace
Cet utilitaire se divise en deux parties : un job batch qui peut être exécuté
périodiquement pour collecter des informations sur la taille des bibliothèques
AS/400n et un frontal Web pour afficher les informations historisées sous forme
de tableau ou de graphique. L'interface Web permet la représentation graphique
des données sans toutes les difficultés liées à la distribution des applications
client/serveur. Pour le déploiement Web, j'ai utilisé Net.Data d'IBM et un jeu
d'applets graphiques Java gracieusement fourni par la société Visual Engineering.
Il n'est donc pas nécessaire d'envisager un investissement particulier pour mettre
en oeuvre l'application Library History sur un AS/400.
A-t-on éclipsé l’AS/400 dans le Server Group ?
Selon certains critiques, le Server Group d'IBM, tout en appréciant la base AS/400
installée, considère NetFinity et RS/6000 comme ses étoiles montantes
Voilà deux ans qu'IBM a créé le "Server Group", pour veiller à la bonne intégration
réciproque de ses quatre gammes de serveurs, et à la couverture de toutes les
bases, spécialement en ce qui concerne la nouvelle demande émanant de Java, de
la Business Intelligence, des services Web et autres. Big Blue, déjà le plus important
fabricant de matériel au monde, a constaté que bon nombre de ses clients (y compris
dans les grands comptes) possédaient quantité de plates-formes différentes. Elle
en a logiquement déduit que les clients voulaient d'une part que ces "boîtes"
coopèrent, soient compatibles, et d'autre part n'avoir qu'un interlocuteur unique
au sein d'IBM. Une excellente idée, en théorie.
La difficulté, d'après certains critiques, consiste à s'assurer que tous les serveurs
sont présentés aux clients de manière équitable et objective. Et c'est une tâche
dans laquelle le Server Group s'est plutôt embrouillé jusqu'ici, déclare l'analyste
Tom Bittman, Vice President and Research Director Server Strategies du Gartner
Group, même s'il s'empresse d'ajouter que le groupe est en train de s'engager
dans la bonne direction.
Le programme VB Sockets règle l’horloge des PC
Cet utilitaire de synchronisation permet d'apprendre les bases de la programmation
des sockets TCP/IP
Le mécanisme sous-jacent fondamental permettant à deux ordinateurs quelconques
de communiquer entre eux est un jeu de programmes qui échangent des informations
en utilisant des profils binaires d'informations convenus. Cela semble être l'évidence
même, mais les développeurs d'applications de gestion que nous sommes oublions
facilement comment nos ordinateurs et applications se parlent, parce que généralement,
nous nous contentons de faire appel à des services de communications : serveurs
DDM, drivers ODBC, serveurs hôtes et files d'attente de données, sans nous soucier
des menus détails.
Parmi les exemples de services de communications TCP/IP les plus connus, on trouve
: FTP (File Transfer Protocol), Telnet, le Web (Hypertext Transfer Protocol, ou
HTTP) et les serveurs de courrier électronique. Ces serveurs communiquent avec
un interlocuteur, ou programme client, au moyen de profils binaires (ou protocoles)
convenus. Le succès de TCP/IP s'explique en partie par le fait que les mécanismes
permettant aux programmes TCP/IP de communiquer entre eux sont relativement simples
et bien documentés.
Le succès de TCP/IP s'explique en partie par ses mécanismes de communication
relativement simples et bien documentés
Cet article montre comment coder les programmes client et serveur
Visual Basic (VB) utilisant des protocoles TCP/IP pour communiquer. Le programme
client peut communiquer avec tout programme serveur correspondant ayant des possibilités
de communications TCP/IP, sur le LAN local ou sur Internet, et le programme serveur
peut communiquer avec tout programme client correspondant.
Outre le fait qu'ils montrent la manière de coder des programmes de communications
TCP/IP, les exemples de programmes client et serveur VB offrent une synchronisation
du temps très précise entre leurs plates-formes d'exécution respectives. Comme
les PC Intel souffrent d'une mauvaise réputation quant à la conservation de l'heure,
le fait de synchroniser un PC par rapport à un autre est une technique discutable.
En revanche, on peut utiliser le programme client VB conjointement au programme
serveur RPG de l'AS/400 pour synchroniser l'horloge d'un PC avec celle, plus exacte,
d'un AS/400.
Une configuration instantanée des sécurités grâce aux assistants
L'assistant de sécurités de l'AS/400 offre un point de départ raisonnable à une sécurité sur mesure.Les sécurités de l'AS/400 sont de plus en plus compliquées, pour plusieurs raisons: prédominance des applications client/serveur, adoption de standards comme POSIX et TCP/IP, et rythme effréné de la révolution Internet. Nombreux sont les responsables qui veulent tout comprendre des sécurités avant de modifier quoi que ce soit. Ils hésitent à modifier les structures de sécurité, par crainte de fermer des applications critiques ou de créer des brèches imprévues dans le système. Bien compréhensible, cette attitude n'en laisse pas moins le système en état de vulnérabilité. IBM répond avec AS/400 Security Wizard, un assistant livré avec Operations Navigator dans la V3R2M0 de Client Access pour Windows 95/NT. Cet assistant supprime la complexité en même temps qu'il propose un environnement permettant de modifier les structures de sécurité à moindre risque. Bien que la dernière version d'Operations Navigator soit nécessaire sur le client, on peut utiliser l'assistant pour configurer la sécurité sur n'importe quel AS/400 en V3R7 ou ultérieure de l'OS/400.
L'assistant de sécurité pose une suite de 10 ou 11 questions (en fonction des réponses) pour créer un profil de votre environnement de sécurité. La réponse à ces questions nécessite peu ou pas de connaissances des sécurités AS/400. Selon les réponses obtenues, l'assistant
-
produit un ensemble de recommandations concernant les valeurs système liées à la sécurité, des rapports et autres paramétrages divers
-
permet d'examiner et, le cas échéant, de remplacer certaines recommandations
-
crée un rapport administrateur et un nouveau rapport utilisateur
-
permet d'appliquer les recommandations ou de les sauvegarder pour complément d'analyse
-
offre une solution de repli en cas de difficultés après l'application des recommandations
En revanche, l'assistant ne peut pas :
-
se substituer à une politique de sécurité
-
garantir l'élimination de toute vulnérabilité
-
garantir qu'il n'y aura aucune violation des sécurités
L'assistant de sécurité constitue un excellent point de départ pour adapter les sécurités à votre environnement. Il peut vous procurer une protection relative pendant que vous développez une politique de sécurité ou étudiez la question de plus près.
Lire l'article
Windows 2000 : 10 raisons de migrer, 10 raisons d’attendre
La migration vers un nouvel OS demande de la réflexion et une bonne dose de planification. Mais avant de migrer votre réseau NT actuel vers Windows 2000, il vous faut comprendre les forces et faiblesses du nouvel OS. Cet article devrait vous aider à y voir plus clair.
Lire l'article
Utilisation de tableaux noirs avec des programmes trigger
Quand l'information envoyée avec un buffer de trigger ne suffit pas, les programmes
de service de type "tableaux noirs" peuvent relayer des données supplémentaires
entre applications et programmes triggers
Avant les panneaux de messages et la diffusion de courriers électroniques, on
utilisait des tableaux noirs pour afficher les informations importantes sur les
lieux publics. Aujourd'hui encore, les professeurs utilisent des tableaux noirs
face à leurs élèves, et comment, sans eux, les bistrots annonceraient-ils leur
plat du jour ? Vous ne savez peut-être pas que ces applications et les programmes
triggers qu'elles invoquent peuvent aussi recourir à une technique que je baptise
tableau noir pour échanger des informations.
Si vous n'avez besoin (outre les informations contenues dans le buffer de trigger)
que du nom du programme applicatif ayant déclenché le trigger, un tableau noir
est peut-être superflu. Il existe un moyen plus simple d'obtenir le nom de l'application
: envoyer un message fictif du trigger à l'application, puis extraire le message.
Pour plus d'informations à ce sujet, lisez “ Offrez la présentation du numéro
à vos programmes ”, NEWSMAGAZINE, avril 1999. En revanche, s'il vous faut relayer
des informations supplémentaires entre une application et son trigger, un tableau
noir est peut être parfaitement indiqué.
Se familiariser avec l’instruction SQL
L'instruction Select est incontournable…
Pour exécuter une requête SQL, l'utilisation de l'instruction Select est incontournable.
C'est pourquoi, j'entame cette série d'articles consacrée aux fondements du langage
SQL par un article qui présente la syntaxe de l'instruction Select.
La plupart des exemples de déclarations ci-dessous proviennent et ont été testés
en utilisant le SQL interactif (ISQL: Interactive SQL) de l'AS/400. ISQL est invoqué
à partir de la ligne de commande par la commande STRSQL (Start SQL). Pour obtenir
de plus amples renseignements sur ISQL, consultez l'article "Interactive SQL",
NEWS/400, août 1998.
Prédicat Between et sous-requêtes SQL
par Mike Cravitz Ce mois-ci, nous allons voir l'utilisation du prédicat Between dans la clause Where d'une requête SQL, dans le but de trouver une valeur située entre deux bornes Je vous présente aussi un puissant mécanisme, appelé sous-requête. Et, pour faire bonne mesure, je montre comment utiliser la fonction SQL Count pour renvoyer le nombre de lignes d'une table de résultat de requête. En route !
Lire l'article
IBM-Intel : la guerre des processeurs continue
par Frank G. Soltis
Les processeurs IBM continuent de surpasser ceux d'Intel lorsqu'il s'agit de serveurs
sur lesquels s'exécutent plusieurs applications
La plupart des lecteurs de ce magazine connaissent peu ou prou les plans d'IBM
en matière de processeurs pour l'AS/400. Il est donc intéressant de comparer les
plans d'IBM pour ses serveurs à l'offre processeurs d'Intel.
Les processeurs PowerPC présents dans les AS/400 actuels appartiennent à la famille
dite Star Series. Cette famille de microprocesseurs monopuces, 64 bits, a été
spécialement conçue à Rochester pour le type de tâches confiées aux serveurs sur
l'AS/400. Ces mêmes processeurs animent également les modèles RS/6000 affectés
à des tâches de gestion.
En septembre 1998, nous présentions le premier membre de la Star Series, dénommé
Northstar. C'était et c'est encore un microprocesseur de pointe.
En septembre 1999, nous présentions une version de Northstar plus rapide dénommée
Pulsar et utilisée uniquement dans le RS/6000.
Dans le courant de cette année, nous présenterons le nouveau processeur I-Star.
Il utilise les toutes dernières technologies semiconducteur d'IBM, y compris cuivre
et SOI (Silicon-On-Insulator), pour plus que doubler les performances de Northstar.
Au moment de son introduction, I-Star sera le microprocesseur destiné à des serveurs
le plus performant. Loin de s'endormir sur leurs lauriers, les ingénieurs de Rochester
sont en train de créer un autre membre de la Série Star : S-Star, qui pousse encore
plus loin les technologies semiconducteur pour obtenir une augmentation de performances
d'environ 50 % par rapport à I-Star. S-Star, qui devrait être le dernier membre
de la Star Series, apparaîtra dans l'AS/400 au cours de l'année 2001.
Solutions ERP 100% “ prêtes à l’emploi ” : la panacée ?
par Scott Steinacher
A l'exception des PC et de l'Internet, aucune innovation technologique n'a impacté le monde de l'entreprise plus profondément que les logiciels ERP (Enterprise Resource Planning). Au départ, d'une manière générale, les managers utilisaient les logiciels ERP pour automatiser les fonctions back-office de l'entreprise telles que la comptabilité, la finance et la gestion des ressources humaines. Plus récemment, les principaux éditeurs d'ERP s'intéressant désormais au traitement des commandes, à l'automatisation de la force de vente, à la gestion de la chaîne d'approvisionnement, à la planification des besoins et à bien d'autres processus pour les entreprises stratégiques, les ERP se sont éloignés de leur rôle traditionnel.
Au fur et à mesure que l'euphorie qui entoure les ERP gagne de nouveaux marchés, de nombreuses sociétés ne semblent que trop heureuses de se débarrasser de leurs logiciels spécifiques qui les ont si bien servis pendant de nombreuses années. A mon avis, certaines entreprises vont trop vite en besogne. En effet, dans de nombreux cas de figure, les applications développées en interne ne nécessitent probablement qu'un ravalement de façade, et non une retraite prématurée.
Il est par exemple possible de rendre les systèmes existants accessibles depuis le Web en attachant des rapports classiques aux messages électroniques émis sur l'Internet. Une autre alternative consiste à placer les rapports existants sur un intranet pour qu'ils puissent être consultés à l'aide d'un navigateur. Les interfaces graphiques des navigateurs peuvent remplacer les écrans passifs. Certes, les interfaces graphiques ne présentent peut-être aucun intérêt pour les applications de type back-office, mais pour fournir un accès aux données à des utilisateurs distants, l'Internet et les interfaces graphiques représentent désormais la norme.
Bien évidemment, les organisations qui ont plusieurs systèmes différents redondants ont probablement besoin d'une refonte en profondeur. Ainsi, au sein d'une organisation issue de fusions et d'acquisitions, il n'est pas rare de voir plusieurs applications distinctes remplir la même fonction (la saisie des commandes par exemple) dans des divisions différentes. Dans de tels cas, l'utilisation de logiciels ERP pour normaliser les systèmes et les processus de l'entreprise est probablement justifiée mais pas forcément déterminante. Construire des interfaces reliant les applications disparates existantes ou normaliser en se basant sur l'application la plus efficace peut représenter un coût moindre. Le fait est qu'il existe souvent des alternatives attrayantes aux ERP, mais que celles-ci ne sont pas toujours envisagées sérieusement.
Premier coup d’oeil : WebSphere Studio 3.02
par Paul Conte L'outil phare du développement d'applications Web d'IBM a beaucoup d'atouts. Mais aussi quelques lacunesWebSphere Studio (WSS) est l'outil vedette d'IBM pour le développement d'applications Web. Il permet de gérer HTML, image, son, applets Java, JSP (Java Server Page), servlets Java, et d'autres fichiers qui fournissent l'interface utilisateur d'une application et tout ou partie de sa logique de gestion. WSS contient des outils intégrés pour concevoir des pages HTML et JSP, y compris des outils de modification de scripts et d'images graphiques. WSS se connecte à VAJ (VisualAge for Java), inclus dans le package produit ou à d'autres environnements de développement intégrés (IDE : Integrated Development Environments) Java pour le développement de servlets et pour du code Java plus complexe. La figure 1 donne la liste complète des outils qui accompagnent WSS.
Le WSS Workbench constitue l'environnement central à partir duquel un concepteur lance les outils et modifie les composants des applications
WSS convient à un large éventail d'applications Web : des simples
sites Web constitués de pages HTML interconnectées, jusqu'aux sites Web dynamiques,
complexes, utilisant scripts, servlets et JSP. Le WSS Workbench (figure 2) constitue
l'environnement central à partir duquel un concepteur de pages Web ou un développeur
Java repère les fichiers applicatifs et lance les outils d'édition appropriés
pour modifier les composants des applications. Quand une application est prête
pour le déploiement, le responsable utilise le Workbench pour copier les fichiers
nécessaires dans les répertoires cible appropriés. Cette opération est appelée
publication (publishing) dans WSS. Une fois publiée, l'application peut être
proposée sur le Web via un serveur HTTP et, si l'application utilise des servlets
ou des JSP, un serveur d'application Web.
Avec WSS, une équipe de développement peut créer des applications Web à déployer
avec les produits HTTP Server et WAS (WebSphere Application Server) d'IBM, ou
avec des produits comparables d'autres fournisseurs (le serveur IIS HTTP de
Microsoft, le serveur d'applications WebLogic de BEA, par exemple). Bien que
WSS possède quelques options intégrées directement associées à WAS, les applications
intégrées à WSS ne sont nullement limitées à WAS, de même que WSS n'est pas
forcément le meilleur outil de développement pour des applications déployées
sur WAS. WSS a une forte dominante Java et, par conséquent, ne convient pas
bien à des applications Web fondées sur des plates-formes ASP (Active Server
Page) de Microsoft et COM+ (Common Object Model Plus).
|
Outils de WebSphere Studio et produits additionnels |
