Le modèle d’importation implémenté par le système e-dec a été organisé en plusieurs catégories d’exigences fonctionnelles qui définissent les fonctionnalités développées dans ce système. Chaque catégorie correspond à un paquetage de fonctions ou tâches associées à un sous-domaine spécifique et bien délimité. Chacune de ces fonctionnalités ont été capturées à l’aide de cas d’utilisation qui décrivent, du point de vue métier, les conditions d’utilisation, les résultats de chaque cas, les relations, les priorités, les données, etc.
Figure 38: Délimitation en packages d’e-dec import
Dans la Figure 38 on montre l’ensemble des paquetages de ce modèle métier. Il s’agit en tout de sept paquetages hébergeant des cas d’utilisation isolés. Le paquetage appelé « declaration »
contient les cas d’utilisation liés aux opérations effectuées sur la déclaration d’importation.
On y trouve principalement les fonctionnalités suivantes :
Transmettre, sélectionner, saisir et refuser la déclaration d’importation
Transmettre le résultat
Calculer les redevances
Feuille de contrôle
Bulletin de délivrance
Le deuxième paquetage est délimité par les tâches de contrôle qui sont pour la plupart exécutées manuellement et existaient déjà dans l’ancien modèle MD90. En effet, avant ou après la déclaration proprement dite, le bureau douanier peut décider de la nécessité de procéder à un contrôle physique des marchandises. En plus, un transitaire est pour sa part tenu de présenter auprès des autorités douanières les justificatifs permettant de retirer la marchandise. Toutes ces opérations se font manuellement, soit au bureau de douane, soit chez le destinataire agrée et par conséquent il y a très peu d’interaction avec le système informatique si ce n’est que pour saisir les résultats des contrôles effectués. La même remarque s’applique au paquetage « Release » composé de deux cas d’utilisation, à savoir
« libérer l’envoi » et « enlever l’envoi ».
Le paquetage des fonctionnalités d’administration est appelé « backoffice ». On y trouve les cas d’utilisation concernant les collaborateurs de l’AFD, à savoir : la livraison des données statistiques et des documents échangés avec les transitaires, la correction de la déclaration, l’archivage des justificatifs, établissement et expédition des quittances, perception et remboursement des recettes et libération du traitement.
5.2.2 Architecture et technologies
Les nouvelles exigences métier présentées par l’AFD lors du lancement du projet e-dec correspondaient parfaitement aux situations pour lesquelles SOA est justifiée. Comment on peut lire dans [North 2007, p. 13] l’une des sources de valeur de SOA consiste en son potentiel à améliorer la productivité des utilisateurs en donnant la possibilité de remplacer un système « spaghetti » (lire les commentaires avancés par l’AFD) par une solution intégrée et unique aux yeux des utilisateurs. Par conséquent, e-dec a été conçue, entre autres fins, pour remplacer les nombreux outils servant aux tâches liées aux déclarations électroniques.
Le système e-dec est basé sur une architecture orientée services composés de quatre couches principales qui sont la couche de présentation, la couche de services métier, la couche de services génériques et la couche de données. La Figure 39 illustre ce partitionnement à plusieurs niveaux qui nous permet de relever quelques remarques importantes.
Tout d’abord, e-dec repose sur une architecture à accès multicanaux qui consiste à offrir aux clients plusieurs moyens d’invoquer les services qu’elle expose à l’extérieur. En effet, un client peut utiliser le service EdecImportService par l’intermédiaire d’une plateforme de
courrier électronique et peut aussi le faire par l’intermédiaire d’un service web. Dans tous les cas, les clients doivent respecter les formats de messages supportés par les deux canaux, en l’occurrence, le courriel admet XML et EDIFACT et pour le service web c’est sont les messages XML.
Figure 39: Architecture« e-dec ».Graphique tiré de [Innotvation Process Technology 2008, p. 10].
Le premier niveau de la Figure 39 est implémenté par un ESB qui se charge de coordonner une partie des étapes du processus d’importation. Le bus de services contient les services génériques qui ont un fort potentiel de réutilisation. N’importe quel autre projet comme ceux concernant l’exportation et le transit des marchandises, peut les réutiliser pour traiter la réception et la réponse des messages. Parmi ces services on trouve :
service de courriel (mail-service),
service d’identification (authentification et autorisation),
service de conversion de messages (EDIFACT / XML),
service d’archivage de données,
service de validation de messages XML,
service de génération des documents de la réponse.
La présence d’un ESB dans cette architecture se justifie par les nombreux avantages de cette technologie dans une SOA. En effet, un bus de services est une solution idéale pour résoudre les problèmes des connexions « point-to-point » qui surviennent lorsque l’architecture commence à se développer et que de plus en plus de services viennent s’y ajouter. Parmi ces difficultés il y a notamment la multiplication des connexions et les risques de dépendances physiques entre le consommateur et le fournisseur de service. Dans le document de présentation d’e-dec [Innotvation Process Technology 2008] l’auteur met en avant les capacités d’un ESB à améliorer l’évolutivité d’une SOA, notamment pour offrir des services supplémentaires aux clients. Dans l’absence d’un bus de service il faut recourir à la méthode d’intégration traditionnelle en développant les adaptateurs correspondants.
Un bus de service est un middleware capable de rendre transparente la localisation physique des services. Il est donc lui-même un service de routage qui joue le rôle d’intermédiaire actif entre les consommateurs et fournisseurs. Grâce à cette transparence de localisation l’autonomie des services est renforcée ce qui permet à chacun d’évoluer de manière indépendante sans provoquer des changements de configuration du côté des clients. La qualification « intermédiaire actif » se réfère à un ESB dont la fonctionnalité de routage ne se limite pas au simple transfère de messages et va jusqu’à inspecter le contenu des messages en fonction des politiques préétablies pour ensuite l’acheminer à la destination correcte. En plus de l’abstraction de localisation, un ESB peut aussi fournir des fonctionnalités de transformation des formats de messages (EDIFACT to XML), prendre en charge plusieurs protocoles de transport (HTTP, SMTP, POP3, JMS, etc.) et différents modèles d’échange de messages (synchrone et asynchrone). Cela ne peut que renforcer la qualité des services notamment en rapport avec la fiabilité dans la remise des messages, la disponibilité des services et le temps de réponse. La gestion des services et de l’infrastructure de l’ESB se fait au moyen d’une console connectée via JMX13 au ESB ce qui permet de configurer et surveiller le tout de manière centralisée.
Dans le cas d’e-dec, les services sont publiés dans un registre propriétaire accessible via un Sonic ESB. Selon les informations dont dispose l’auteur de ce travail il est impossible de dire si le registre est basé sur le standard UDDI. Quoi qu’il en soit, grâce à ce registre, « e-dec » dispose d’un emplacement central pour la publication des services. Au début du projet il était prévu de publier EdecImportService dans une zone de services partagée (SSZ) permettant d’effectuer des tâches de monitoring et de sécurité mais cela n’a pas été fait. Le service d’authentification et d’autorisation est basé sur un mécanisme centralisé de control d’accès de type LDAP. Ce faisant un utilisateur n’a pas besoin de s’identifier plusieurs fois pour utiliser l’ensemble des services ce qui serait très fastidieux dans un environnement distribué comme SOA. Or, l’implémentation de SOA avec un ESB peut être complétée avec une passerelle de sécurité et de routage complètement découplée de l’ESB. C’est justement l’intention du prototype de gouvernance qui est proposé dans ce travail. Il permettrait de développer les
13JMX est une API basée sur Java pour la gestion runtime des ressources matérielles et logicielles
activités de SLA monitoring pour le compte des transitaires et du service web. En plus, comme service intermédiaire, une telle passerelle permettrait de déléguer les traitements de sécurité et de transport comme par exemple, la conversion des requêtes JMS en requêtes HTTP, l’ implémentation d’un service d’authentification unique (SSO) et le contrôle d’accès (requête et réponses) dans les contextes d’intégration avec d’autres partenaires.
Le noyau de la plateforme « e-dec » est constitué d’un ensemble de services métier (business services) supportés par une couche métier de type J2EE. Ces services sont spécifiques au processus d’importation et pour cette raison ils ont un potentiel de réutilisation inférieur aux services d’application présentés auparavant. Voici la liste des services métier de la plateforme e-dec:
Service de sélection,
Service de calcul des redevances,
Service de test de plausibilité et service de quota.
Cette division en services métier et services d’application correspond tout à fait à la description de l’architecture SOA de la section 3.2. En effet, le service EdecImportServiceest un service de processus qui est spécifique au dédouanement des importations. Il compose par contre une série de services de base (services d’application ou de support) dans un flux d’orchestration supporté par la couche ESB. Bien que la Figure 39 ne le montre pas l’interaction entre les services du ESB et ceux de la couche métier se fait par l’intermédiaire des APIs JCA14 et JMS de Java. Grâce à l’interface JCA, qui sert à rendre plus transparent l’interaction entre un composant J2EE et le bus de service, EdecImportService compose le service d’archivage qui enregistre à son tour la déclaration d’importation. Ensuite, l’interface JMS permet au service basé sur la technologie EJB orienté message de communiquer lui aussi avec l’ESB.
14JCA était planifiée dès le début mais les sauvegardes de données ne sont que de simples opérations d’écriture dans un file system.
94