L'émergence de l'offre d'objets métier

L'industrie du logiciel n'est pas restée passive face à la maturation d'une formalisation plus poussée des objets métiers. Depuis que le succès d'Internet a rendu populaire les techniques et les outils orientés objet, leurs déclinaisons naturelles - du point de vue des grands éditeurs - les objets métier, font de plus en plus souvent partie de l'offre de ces sociétés ou de celle des SSII.

De 1990 à 1995 : l'interface graphique moteur de la généralisation des composants logiciels

Chez les fournisseurs d'outils logiciels, tout d'abord, la généralisation des modèles objets comme ActiveX de Microsoft ou Corba de l'OMG a permis au composant logiciel de passer de la brochure publicitaire - où elle n'était qu'une formule bien creuse trop souvent visible - aux produits eux-mêmes, acquérant au passage d'authentiques quartiers de noblesse. Bien sûr, les outils logiciels s'adressant avant tout aux programmeurs et aux informaticiens, les premiers objets métier qui se virent rapidement généralisés furent évidemment ceux des métiers de programmeur ou d'informaticien. C'est ainsi qu'il faut comprendre l'arrivée des toolkits graphiques, ou catalogues d'objets graphiques préfabriqués qui, depuis le début des années 1990, se sont imposés dans le développement des applications informatiques. D'ailleurs l'évolution chronologique de ces catalogues et leurs enrichissements successifs par composition, addition ou spécialisation, reflète fidèlement les niveaux successifs d'abstraction du modèle d'objets métier que nous présentons ici. Ainsi on passe de l'objet bouton ou champ de saisie de texte, par exemple, - abstraction déjà utile des primitives de dessin et de gestion d'événements à qui est chargé d'écrire une interface utilisateur graphique - à des objets fenêtre, composés de nombreux boutons et champs de saisie interdépendants, puis à de véritables formulaires dans lesquels les données et les requêtes vers les systèmes de gestion de base de données leurs sont en plus associées. Les éditeurs d'outils de développement comme Neuron Data, Powersoft, Oracle, Nat Systèmes, Microsoft, Centura - encore appelé Gupta à l'époque, du nom de son fondateur - ont tous suivi ce mouvement d'abstraction croissante à partir de composants élémentaires pour les interfaces graphiques. C'est aussi dans ce mouvement qu'il faut comprendre la spécialisation de certains éditeurs dans des fonctions précises, communes à un grand nombre d'applications de gestion ou industrielles. Des éditeurs d'outils comme Forté, Visix, Dynasty, Ilog, RogueWave et d'autres ont su s'emparer de segments de marché importants en concourant à banaliser les composants logiciels dans des domaines applicatifs ou industriels spécifiques.

L'adoption et la publication de la norme Corba d'une part, la généralisation progressive du modèle OLE dans les systèmes d'exploitation et les applications de Microsoft d'autre part, ont souvent poussé les éditeurs de progiciels à reconsidérer l'architecture de leurs produits. Parce que le modèle objet, une fois adopté, porte en lui les fruits d'une réduction des coûts de développement et de maintenance des progiciels en question et que l'infrastructure - systèmes d'exploitation, interface graphique, protocoles des réseaux, bases de données, services, etc. - se trouvait maintenant prête à accueillir ces objets de grain plus important, les grands éditeurs de progiciels du marché ne tardèrent guère à annoncer la décomposition de leurs monolithes logiciels en briques métier.

De 1994 à 1997 : Du composant logiciel aux objets métier propriétaires

On constate deux courants caractéristiques de cette seconde vague des objets. De composants logiciels, encore réservés aux spécialistes informatiques ou aux programmeurs, ils visent maintenant d'autres métiers que ceux liés au développement informatique à proprement parler.

C'est l'époque des premières tentatives de commercialisation de frameworks , ou canevas applicatifs, destinés soit à des domaines applicatifs particuliers, soit à l'ensemble des tâches de développement informatique prises dans leur ensemble. On gardera en mémoire l'exemple - malheureux - de Taligent, société créée en commun par IBM et Apple Computer en 1992, pour le développement et la commercialisation d'un canevas applicatif complet. Se fondant sur des travaux internes de recherche et développement engagés par Apple Computer depuis le milieu des années 1980 - qui se concrétisèrent dans Object Pascal , une version orientée objet du vénérable langage de programmation Pascal, et MacApp un canevas applicatif dédié au Macintosh - Taligent reprit à son compte le projet Pink d'Apple Computer, qui regroupait ces développements initiaux, et des projets similaires internes à IBM - qui avaient, quant à eux, démarrés dans la suite de l'AS/400, et avec la société, depuis disparue, Metaphor/Patriot Partners dans laquelle IBM était investie. Au début de 1994, le constructeur Hewlett-Packard devait rejoindre les deux fondateurs, leur amenant ses propres travaux - NewWave et son interface graphique, en particulier. Le produit de Taligent, CommonPoint, était un canevas applicatif complet, écrit en C++, bénéficiant de toutes les idées modernes de l'orienté objet, indépendant du système d'exploitation et du système de fenêtrage avec pour cible AIX, HP-UX, OS/2, MacOS, NT et Windows 95. Taligent devait cesser ses activités indépendantes à la fin 1995 et ses équipes furent réintégrées à IBM. L'ampleur de la tâche et le temps nécessaire pour la mener à bien avait été largement sous-estimés par les uns et les autres. Et puis le World Wide Web devenait clairement le killer app de l'Internet naissant.

C'est une histoire similaire que l'on peut conter à propos d'OpenDoc un projet d'interface graphique universelle, elle aussi indépendante des systèmes d'exploitation et des environnements de fenêtrage. OpenDoc est, comme CommonPoint, un canevas mais dédié cette fois au développement d'interfaces graphiques. OpenDoc était le fer de lance de Component Integration Laboratories (CI Labs), une entité juridique volontairement neutre sur le plan commercial, fondée par Apple, Novell et IBM. Recrutant d'autres membres, comme Oracle, Adobe ou Lotus, sa mission était la promotion d'OpenDoc comme le modèle des documents composés. OpenDoc emprunte tout à la fois aux travaux sur l'interface graphique du Macintosh d'Apple Computer, à ceux d'IBM sur les modèles objet - et en particulier à SOM (System Object Model ), une architecture au départ imaginée pour Presentation Manager dans le système d'exploitation OS/2 et qu'IBM amèmera en conformité à la norme Corba. Il est à noter que CI Labs proposait déjà un produit, ComponentGlue, assurant la compatibilité entre OpenDoc et son modèle concurrent, OLE de Microsoft, et développé à l'origine par Novell. L'OMG devait adopter au printemps 1997 OpenDoc comme modèle de documents composés dans CorbaFacilities, l'une des extensions de la norme Corba. Il est clair là aussi, que même si ces développements étaient contemporains de la diffusion du World Wide Web, entraînant celle de ses formats HTML (Hypertext Mark-up Language ) et HTTP (Hypertext Transfer Protocol ) devenues aujourd'hui des évidences, CommonPoint ou OpenDoc représentaient en fait le summum de la capitalisation de l'expérience de l'orienté objet des compagnies Apple, IBM et de leurs alliés - souvent bien antérieure à la décennie des années 1990. A tel point qu'en 1996, à la conférence des développeurs d'Apple Computer, à San Jose en Californie, Marc Andreesen le fondateur charismatique de Netscape Communications annonçait, pratiquement sous les vivats, le support d'OpenDoc dans les navigateurs de sa companie ! Inutile de dire que Netscape a changé de cap depuis...

De son côté, Microsoft, quoique qu'illustrant une approche des marchés totalement opposée aux méthodes consensuelles de structures comme l'OMG ou CI Labs, partageait les mêmes idées : l'objectif majeur du modèle concurrent de Microsoft, OLE, était bien de s'affranchir de la dichotomie application-feuille de travail qui sous-tendait toutes les interfaces graphiques du moment - ne faisant en cela que suivre avec Windows ce que le Macintosh avait su établir dès 1984 sur un micro-ordinateur - et de la remplacer à terme par la métaphore du document, composé d'objets assemblés dynamiquement. C'est tout le sens de l'intégration des applications dans une " suite " de logiciels de bureautique comme Microsoft Office. C'est finalement un troisième modèle, celui de la page Web, qui s'est imposé ces dernières années, prenant de vitesse à la fois Microsoft et ses concurrents à l'OMG ou ailleurs.

Second mouvement analogue, sensible cette fois chez les grands éditeurs de progiciels fonctionnels comme Oracle, SAP, Baan ou d'autres : la décomposition de ces grands ensembles, souvent devenus longs et difficiles à installer et paramétrer puis lourds à maintenir et mettre au point, en un assemblage d'objets métier reprenant chacune des fonctions importantes dans le souffle nouveau des technologies objet. SAP, on l'a vu, a su en quelques années faire évoluer le produit R/3 d'une architecture centralisée et compartimentée à une décomposition en véritables objets métier bien adaptés à des applications de type client-serveur. D'autres éditeurs tracent cette voie, comme Baan ou PeopleSoft dans leurs marchés respectifs. Notons à nouveau que c'est à ce niveau d'abstraction que la capture des processus de l'organisation dans le système d'information, et leurs représentations efficaces dans les familles d'applications informatiques, requiert à la fois des objets métier, mais également des règles métier pour l'orchestration de ces objets dans les familles applicatives qu'ils engendrent.

Enfin, les objets métier et les composants logiciels suscitent également le développement des méthodologies d'analyse et de conception ainsi que d'une nouvelle génération d'outils de génie logiciel adaptés à une approche centrées sur les composants logiciels. Des éditeurs d'outils comme Rational aux États-Unis, Select Software Tools en Angleterre, ou encore Softeam en France ont su accompagner et anticiper le mouvement vers les composants logiciels en adaptant leur offre méthodologique et leurs outils. Notons également, qu'autour du repository , ou dictionnaire de données, se joue aussi une bataille importante - à la fois technique et commerciale - dans laquelle sont engagés Microsoft et Texas Instruments, mais aussi Platinum et IBM. Il faut finalement mentionner les éditeurs, les équipes de consultants et les SSII qui, dès aujourd'hui, proposent parfois des composants logiciels prêts à l'emploi - du pré-fabriqué qui resterait facile à adapter - comme Lyon Consultants, Ingenia ou Azur en France, mais, de manière encore plus significative - nous y reviendrons plus bas -, IBM avec le projet San Francisco et JavaSoft avec les Enterprise Java Beans.

Depuis 1997 : des objets métier ouverts ?

C'est peut-être de 1997 que l'on pourra dater la naissance d'une réelle problématique des objets métier dans l'industrie du logiciel. Que constate-t-on en effet ? Des signaux éminemment contradictoires sont reçus simultanément par l'observateur attentif : d'une part l'échec commercial patent des premières tentatives d'établissement de canevas d'objets techniques puis métier universels - et ce, par les plus grands acteurs du marché, IBM, Apple, Microsoft, etc. ; d'autre part le succès déferlant d'Internet et du World Wide Web, qui s'impose en moins de deux ans comme le modèle de documents universel, ouvert, et réparti. Ce dernier complémenté par Java - dont le coup de génie de Sun Microsystems restera de l'avoir indissolublement couplé au Web, par les applets - rend d'autant plus urgent et nécessaire le recours aux objets métier pour toute la nouvelle classe d'applications qu'il fait fleurir. Pas d'intranet sans objets et règles métier ; pas d'extranet ou d'applications Internet sans canevas ouvert d'objets métier qui coopérent.

Le facteur qui assure le succès de l'un au détriment des tentatives premières des autres - même si celles-ci reposent sur des développements antérieurs, longuement mûris et affinés dans les laboratoires de recherche industrielle des constructeurs et des éditeurs - est finalement le caractère ouvert - voire même anarchique - du Web et de Java. Les objets métier qu'Internet, intranets et extranets requièrent et imposent sont, contrairement à ceux des générations antérieures, ouverts de par la nature même du réseau qui leur sert d'infrastructure. Les idées sous-jacentes ne sont pas nouvelles : dans bien des cas ce sont le mêmes dont il y a à peine cinq ans Microsoft, l'OMG, Apple ou IBM se faisaient les champions - chacun déroulant son plaidoyer pro domo. Leur mise en œuvre et leur implémentation a, par contre, changé du tout au tout en quelques années, voire même en quelques mois. Il a fallu bien peu de temps à Microsoft pour acclimater son modèle propriétaire aux nouvelles contraintes du Web : sous le nom ActiveX voici la mutation hybride applet - composant OLE, qui réussit à concilier l'ouvert et le propriétaire, l'objet technique et l'objet métier, les langages C++ et Java ! L'OMG a rapidement concocté des mappings entre son langage de description d'objets, IDL, et le nouveau prodige de la classe, Java. Sun, depuis toujours un des membres actifs de l'OMG, a travaillé à la démonstration de la faisabilité et de la robustesse de l'utilisation de Java pour les objets (clients autant que serveurs) à la norme Corba. Enfin avec la version 1.1 du Java Development Kit (JDK), on a vu apparaître ce qui pourrait être la première lueur d'une véritable architecture ouverte pour des objets métier : les prémices d'un modèle générique, Java Beans, qui promet de capitaliser sur les expériences, bonnes ou mauvaises, des modèles objet qui l'ont précédé et de réaliser une nouvelle tentative d'implémentation des idées modernes de l'orienté objet.

Java Beans est un modèle de composants logiciels qui se plaque sur les objets de grain plus fin du langage de programmation Java. Comme les modèles précédemment décrits ici, son origine est à chercher dans l'idée des documents composites. On imagine, cette fois dans le monde de la programmation Java, que la métaphore de l'application disparaît au profit de celle du document - mouvement d'autant plus naturel que le succès initial de Java surgit précisément de cette même idée incarnée par l'applet dans la page Web. Ces objets, contenus dans un document, sont appelés des Beans et sont écrits en Java, mettant parfois en jeu une seule classe Java, parfois plusieurs ou même plusieurs dizaines. Le document est, comme dans tous les modèles précédents, construit interactivement par des opérations graphiques de glisser-déposer et d'édition visuelle. Dans la version 1.0 du Beans Development Kit (BDK) on trouve donc toutes les classes Java qui facilitent la construction de documents qui assemblent ces différents Beans. Comme chaque composant est en fait un programme exécutable, le document résultant ressemble de plus en plus à une application complète elle-même. A nouveau, ces classes Java du BDK ne font que définir des événements qui règlent d'une part les échanges d'information entre le contenant et les contenus (la couleur de fond du Beans doit être celle du document, par exemple) ainsi qu'entre les contenus, entre les Beans qui exposent ainsi les événements auxquels ils réagissent. Ainsi un document, ou une application, ainsi assemblée peut découvrir à l'exécution les fonctions des composants Beans qui la constituent, ce qui permet évidemment la substitution d'un composant par un autre ou le recours à des services similaires à ceux que l'on trouve dans les modèles ActiveX ou Corba.

Dans la version 1.0 du BDK, les sources d'inspiration pour ces modèles de circulation d'événements et d'assemblage de composants Beans sembleront familières à ceux qui connaissent Corba et les design patterns récemment venus sur le devant de la scène. En effet, le mécanisme de publication d'un composant Bean, par exemple, repose soit sur une description explicite de ses propriétés et de ses méthodes, appellée un BeanInfo, et qui rappelle quelque peu l'IDL de la norme Corba, pour permettre l'appel de ces propriétés et méthodes suivant ce qui s'apparenterait à une invocation dynamique dans Corba ; soit sur une description implicite qiu repose sur l'effort du programmeur dans le respect d'une convention de nommage de ces propriétés et de ces méthodes suivant une forme imposée, qui assure que cette information puisse être reconstituée à l'exécution par la machine virtuelle Java. Du côté de l'assemblage, le BDK 1.0 ne va pas plus loin que la mise en relation de composants entre eux en mettant finalement bout à bout l'émission d'événements des uns avec la réception d'événements des autres. Dans cette version l'effort a clairement porté sur l'homogénéisation des classes Java fournies dans l'atelier de développement : toutes les classes d'interfaces utilisateur graphiques (AWT) ont été réécrites avec le nouveau modèle événementiel - une tâche qui est tout sauf triviale. La version suivant du BDK, publique et ouverte à commentaires sur le site Web de JavaSoft, propose un enrichissement considérable des mécanismes de composition des composants Beans. En particulier, les aficionados des modèles objet notent que les composants Beans vont pouvoir être composés ou agrégés, à la façon des objets COM de Microsoft, exposant partiellement ou totalement les composants qu'ils contiennent. Cette convergence des idées directrices des modèles objet antérieurs dans Java Beans devrait petit à petit permettre à ce dernier système de gommer les différences majeures entre composants Corba, applets et ActiveX. De fait, la version 1.0 du BDK offre déja un mécanisme d'encapsulation automatique qui permet à un contenant ActiveX de voir un composant Beans comme un contenu ActiveX. Un véritable intégration bidirectionnelle est prévisible dans les nouvelles versions.

Sur la base de Java Beans, l'idée des objets métier a été récemment adoptée par deux grands industriels, IBM et Sun Microsystems, comme cheval de bataille pour créer une image de langage de développement d'applications professionnelles autour de Java. Lotus, après l'échec de Corel sur Java en 1997, s'essaye également au difficile exercice de la livraison d'une suite bureautique écrite entièrement en Java. Contrairement à son malheureux prédecesseur canadien, qui avait choisi de créer des applets pour chacun des élements de sa suite, Lotus, avec e-Suite, livre de véritables applications Java qui mettent à profit le modèle Beans pour autoriser l'assemblage, la subsitution et l'enrichissement fonctionnel par adjonction et suppression de composants logiciels Java Beans. La maison mère, IBM, livre au printemps 1998 les premiers fruits d'une initiative de coopération entre éditeurs de logiciels proches d'elle, démarrée fin 1996, pour la réalisation d'une véritable bibliothèque de composants logiciels - ici aussi conformes au modèle Java Beans - dans le domaine de l'informatique de gestion. Plus de cinquante éditeurs indépendants participent au projet San Francisco qui, poursuivant plus loin encore ce mouvement de décomposition des grands progiciels que nous avons évoqué, choisit le langage de programmation Java et le modèle Beans comme plateforme de développement. Sun Microsystems n'est pas en reste qui, dans l'élargissement significatif des plateformes Java rendu public à la grand-messe JavaOne en 1997, a annoncé les Enterprise Java Beans, une collection de composants Java Beans pour l'informatique de gestion sur une architecture client-serveur ou répartie.

Si les idées, finalement, diffèrent peu d'une génération à l'autre de composants logiciels commercialement disponibles, il ne faut guère s'en étonner : les concepts sont établis en fait depuis longtemps raffinés par la pratique et la recherche. Par contre on peut mesurer les progrès considérables faits dans l'implémentation de ces idées dans des produits et des architectures immédiatement utilisables pour des applications concrètes. Chaque génération est un saut important par rapport à la précédente : on passe de l'application au document, et corrélativement du développement à l'assemblage, puis du document propriétaire ou document ouvert, pour finalement retourner du document ouvert à l'application ouverte, chaque composant ayant acquis son autonomie à l'intérieur du groupe dynamique qui constitue - qui engendre, devrait-on dire - l'application. Poussé par le Web, le langage de programmation Java et la plateforme de développement et de déploiement que toute une industrie s'affaire à lui construire aujourd'hui représentent la meilleure chance de banalisation et d'adoption rapide des objets métier dans le développement professionnel d'applications pour l'entreprise.