Cloud, SOA, Distributed computing, RPC same potential pitfalls !

It is a while since client/server technology has been first introduced. Technologies have been improving with RPC, distributed computing, SOA, ESB, cloud, ... but the same doubts are always around the corner : this technology XY does not work, is not performing, ... even if we have with web2.0, daily, in front of us, a proof that distributed computing and cloud works.

What is the root cause of these concerns ? This is mainly coming from the lack of understanding of what is happening behind the scene. Even with primitive client/technology, developers could ignore what was happening behind their SQL statements or their stored procedures. Network latency, network stacks, marshalling/unmarshalling are more and more hidden from the developer. Therefore, today as in the past, granularity is not so much in focus. This leads to too small or too big services that are either not efficient or not responsive enough. Executing a simple addition through the network has never been and is still not a good idea neither is transferring 1GB of data to call a service.

These problems are also coming from a common pitfall : the lack of IT urbanization. Without a clear vision of the services to implement coming from a functional map of the essence of the information system, services tend to be multiple, redundant and, in one word,  inadequate. If such a map is not defined, it is then very difficult to have any control on the service granularity. As an example, some organizations are using service directories to try to organize and manage the profusion of services that have been created having in mind mainly a technical approach.

To ensure success, a list of services should be defined before hand matching design principles and non functional requirements (like granularity) so that the use of services is performing as expected. This approach is also preventing redundant services which are creating maintenance nightmares... as with more old fashioned technologies!

Outils de Workflow

Pour les outils de workflow, comme pour beaucoup d'autres technologies, les concepts ne datent pas d’hier. Ces outils tentent de donner un support informatique à la mise en place de procédures opérationnelles. Les directions de l’Organisation de nombreuses sociétés ont utilisé des outils de cette nature d’abord pour modéliser les processus, puis pour les mettre en œuvre. Des consortiums ont travaillé depuis des années sur la normalisation des outils qui sont restés très souvent confinés au monde du traitement documentaire.


L’objectif de ces outils est de décrire, souvent à travers une interface graphique, les différentes étapes d’une procédure mettant en relation différents intervenants et une demandant le respect d’une séquence. Après avoir été descriptifs, ces outils ont proposé des moteurs permettant alors de mettre en œuvre opérationnellement les procédures décrites. Ces outils ont ainsi permis la collaboration des différents intervenants en orchestrant les échanges et les validations. Le passage du descriptif à l’interactif a d’ailleurs alimenté bien des querelles entre Directions Informatiques et Directions de l’Organisation !


Comme mentionné plus haut, ces outils ont été utilisés pour des procédures documentaires. N’ayant aucun lien profond avec le reste du système d’information, ils ne pouvaient pas orchestrer les échanges inter applicatifs même si, technologiquement, ils en avaient depuis longtemps la capacité.
Si on imagine facilement l’importance de la formalisation des procédures, l’émergence des processus de normalisation Iso ayant matérialisé cette nécessité, on sait moins que la plupart des systèmes d’information des entreprises cachent dans leurs applicatifs des procédures implicites dont la connaissance disparaît au fil des années.


Pour illustrer ceci on peut prendre le cas de ces entreprises qui disposent de filiales en différents points du globe, chacune opérant sur des systèmes différents. Le groupe cherchant néanmoins à mettre en place des traitements consolidés pour dégager des économies d’échelle, la mise en place d’échanges inter applicatifs devient alors essentielle. Inévitablement, au gré des restructurations, ces règles d’échanges évoluent impliquant une reconfiguration du système d’information.
On parle alors de rigidité du système d’information car, l’adaptation du système aux nouvelles règles métier est longue voire pénible. Pour réaliser ces adaptations, on est souvent obligé de se réapproprier les règles d’origine dont la connaissance a été perdue, puis on tente d’implémenter les nouvelles règles dans tous les applicatifs concernés.
Le monde du Workflow, jusqu’à la naissance de la SOA, restait étranger à ces problèmes d’intégration et d’échanges inter applicatifs

Intégration de Services et Urbanisme

Sans remonter aux origines de l’informatique, l’intégration de service existe depuis longtemps. On trouve dans les Remote Procedure Call (RPC) des tentatives d’intégration de systèmes ; ceci a trouvé un prolongement dans DCE , Corba, J2EE et finalement dans les fameux WebServices.
L’intégration de service par opposition à l’intégration de données consiste à rendre accessible des traitements à une application cliente. Il ne s’agit pas de fournir à cette application cliente des données extraites d’une base mais bien de fournir à la demande des traitements utilisant les données fournies par l’utilisateur.

Les raisons qui poussent à la mise en œuvre de ce type d’intégration sont nombreuses mais la principale, Graal de l’informatique depuis des années, est la réutilisation. En effet, ces technologies d’intégration rendent possible la réutilisation d’une partie d’un système exposé sous la forme d’un service.
Pour illustrer ceci, on peut prendre l’exemple souvent observé du système legacy fournissant des fonctionnalités indispensables au bon fonctionnement de l’entreprise. Malheureusement, ces ressources sont plus ou moins verrouillées dans une architecture fermée ou dans une technologie ancienne et par ailleurs, le coût de portage de l’ancienne application dans une architecture plus ouverte s’avère plus que prohibitif voire impossible. Les technologies telles que celles mentionnées précédemment ont alors été utilisées pour fournir des services de base à de nouvelles applications apportant de nouvelles fonctionnalités.

Un exemple concret vécu au début des années 90 : une entreprise disposait d’un moteur de calcul financier de plus d’un million de lignes de Fortan 66 associé à une base de données propriétaire elle aussi assez vaste. Arrivent à cette époque les stations de travail sous Unix, qui donnent aux utilisateurs des possibilités ergonomiques et graphiques sans précédent. Mais comment bénéficier des ressources du « legacy » sur les stations de travail sans porter dans le nouvel environnement le moteur de calcul et ses données ? La définition d’une abstraction de ce moteur de calcul a permis l'implémentation sur le système legacy d’un service utilisable par les nouvelles applications développées sur les stations de travail

Cet exemple qui présente une réutilisation pragmatique et plutôt technique montre cependant la composante fonctionnelle inhérente à l’intégration de service. Le sujet n’est pas que technique : qui dit intégration de service dit définition des fonctionnalités de ce service.
Dans certaines entreprises, une analyse plus en amont et plus fonctionnelle de la réutilisation a été menée à travers les travaux d’urbanisation du système d’information. L’intégration de service peut être le support de ces réflexions sur la réutilisation permettant de donner une réalité aux concepts manipulés par les urbanistes.