Data Quality et SOA

1. WHITE PAPER: SOA WHITE PAPER / Data Quality meets SOA – la qualité des données mise au service des processus métier Les fonctions de qualité des données étaient déjà mises à disposition comme services dans les environnements Unix, Windows et Linux, bien avant que les analystes de Gartner aient inventé le concept de la SOA. Le développement de cette architecture répondait essentiel- lement à des raisons d’ordre technique. L’implémentation des architectures orien- tées services impose par ailleurs de nouvelles exigences aux services de qualité des données à mesure qu’augmentent les possibilités et la valeur ajoutée apporté- es par ces architectures. __________________________ Tous les noms d’entreprises, de produits et les logos mentionnés dans cette publication sont des noms commerciaux et/ou des marques déposées des entreprises respectives. Page 1

2. WHITE PAPER: SOA Point de départ : les services de qualité des données Pour mieux appréhender l’importance des architectures orientées services dans la mise à disposition et l’utilisation des fonctions de qualité des données, il convient d’abord de jeter un coup d’œil sur les fonctions typiques de qualité des données. APPLICATION A: Une application classique est, par exemple, la validation d’une adresse postale en utilisant des données de référence comportant les noms de rues et de localités ainsi que les dépendances des codes postaux des villes, des rues et des numéros des maisons. Contrairement au simple accès à la base de données, le système doit dans ce cas trouver l’adresse correcte même si les données saisies sont incomplètes ou contiennent des erreurs d’audition ou de frappe. Le but étant d’atteindre une haute exactitude des résultats pour corriger automatiquement – autant que possible – les adresses erronées. APPLICATION B: Une autre application est la recherche de doublons dans le stock de données. Dans ce cas aussi, l’objectif est d’assurer une identification sûre et rapide même si les données saisies – objet métier, partenaire commercial, produit ou opportunité de vente – sont incomplètes, divergentes ou erro- nées. Cela permet, d’un côté, d’augmenter la productivité de l’utilisateur en simplifiant la recherche et, de l’autre, d’éviter la création de doublons, c’est-à-dire la présence d’enregistrements doubles se rap- portant au même objet dans le monde réel. Ainsi, on obtient une représentation cohérente, complète et univoque des objets réels dans la base de données. Un objectif important dans le cadre de l’optimisation Outre le temps de réponse, la possibilité d’intégrer de la qualité des données est d’éviter, dès le les services de qualité des données dans divers départ, l’enregistrement de données incomplètes environnements informatiques revêt également une ou erronées dans la base de données. Les anoma- importance primordiale. Pour atteindre cet objectif, lies éventuelles doivent être détectées au moment il est indispensable de découpler les services de de la saisie des données, puis éliminées auto- qualité de données des consommateurs du service matiquement ou notifiées à l’utilisateur pour qu’il et d’utiliser un protocole client/serveur. C’est pour procède lui-même à leur élimination. Grâce à des cette raison que cette fonctionnalité a été dévelop- index de recherche spécialisés, la recherche dans pée et utilisée dans le domaine de la qualité des une base de données contenant entre 1 000 000 données, du moins pour les applications exigean- et 100 000 000 enregistrements ne dure qu’une tes, avant même que les architectures orientées ser- fraction de seconde, même en cas d’utilisation vices ne furent inventées. De cette manière, il a été d’orthographes différentes. De tels temps de répon- possible à la fois de répondre aux hautes exigences se requièrent toutefois une mise en cache intelligen- en matière de temps de réponse et d’assurer la mise te des index. Une solution efficace pour atteindre à disposition d’une série de fonctionnalités pour les cet objectif serait d’implémenter le logiciel comme multiples environnements existants. service central mis à disposition par l’un de vos propres serveurs. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 2

3. WHITE PAPER: SOA Du « client lourd » à l’architecture trois-tiers Layered Architecture LAYERED ARCHITECTURE L’architecture typique au début du monde client/ FAT CLIENT serveur se composait d’une base de données qui, outre l’enregistrement des données de transac- ROLE tion et des données de base, permettait d’établir Name Customer une communication asynchrone entre les différents Street Supplier composants du système, rendant ainsi possible Postcode Reseller leur découplage. Les messages étaient écrits sur la base de données par l’émetteur, puis lus à partir de cet emplacement par le récepteur. Cette méthode exigeait toutefois une scrutation (polling) périodique de la table pour savoir s’il y avait des messages nouveaux ou non traités. La logique métier était implémentée en grande partie sur des clients « lourds ». Les tâches pouvant être exécutées en mode batch étaient implémentées via des processus tournant en arrière-plan qui avaient accès à la base de données. Par ailleurs, les fonctions interactives destinées à la validation des adresses ou à l’identification des doublons lors de la saisie étaient, en règle géné- rale, intégrées dans l’interface graphique. L’appel des fonctions s’effectuait habituellement via des interfaces propriétaires. Des spécifications telles que DCE1 ou CORBA2, dont le but était la standardisa- tion des interfaces pour assurer la communication entre les différents composants distribués, sont res- tées limitées et n’ont pas pu prendre l’essor souhaité. 1 http://en.wikipedia.org/wiki/Distributed_Computing_Environment 2 http://en.wikipedia.org/wiki/CORBA © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 3

4. LAYERED ARCHITECTURE WHITE PAPER: SOA FAT CLIENT CLIENT Cette situation a totalement changé dans les der- nières années. Le point de ROLE départ fût surtout la mise ROLE Name Customer Name Customer au point de plusieurs standards dans le cadre de la spécification JEE (Java Enterprise Edition)3 et, par Street Supplier Street Supplier Postcode suite, le développement d’implémentations plus la Reseller Postcode Reseller performantes de ces standards comme solutions commerciales ou Open Source. APPLICATION SERVER LA SIMPLE INTÉGRATION DANS LE SERVEUR D’APPLICATIONS – QUE CE SOIT SUR LA BASE D’UNE ARCHITECTURE JEE OU .NET – EST AINSI PASSÉE AU PREMIER PLAN. Ce fut ensuite Microsoft qui suivit en développant, pour le monde Windows, une plate-forme indé- pendante des langages (.NET), ainsi que les services d’entreprise .NET4. L’on disposait ainsi d’un logiciel d’infrastructure performant qui permettait, indépendamment de la plate-forme choisie (JEE, .NET), de découpler dans une large mesure la logique métier de la couche présentation et de l’implémenter sur le serveur dans une couche indi- viduelle. Ceci a entraîné un changement des exigences envers les services de qualité des données. Ces derniers étant désormais largement accessibles depuis la logique métier, du côté serveur. La simple intégration dans le serveur d’applications – que ce soit sur la base d’une architecture JEE ou .NET – est ainsi passée au premier plan. 3 http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition 4 http://en.wikipedia.org/wiki/.NET_Framework © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 4

5. WHITE PAPER: SOA SOAP, protocole clé pour une SOA optimale Pour pouvoir tirer le meilleur parti de la SOA, il Proprietary Protocol fallait d’abord établir un protocole standard pour la mise à disposition et l’utilisation des services. Cette condition a été parfaitement remplie avec la création du protocole de services Web « SOAP5 ». Pris en charge pratiquement par tous les composants d’infrastructure et middleware, ce protocole assure une complète interopérabilité entre fournisseurs de services, middleware et consommateurs de services. Ainsi, on évite la nécessité de mettre en place des liaisons pour utiliser des protocoles non libres dans les middleware propriétaires, ce qui ouvre la voie au déploiement de composants middleware puissants. Dans cette catégorie, on trouve le concept de l’Enterprise Service Bus (ESB)6 qui permet un couplage lâche entre les différents composants avec un fort accent sur le routage des messages, tout comme les moteurs qui peuvent directement exécuter les flux de travail définis dans un langage d’exécution de processus métier (BPEL)7 . Les services Web basés sur SOAP sont ainsi deve- nus un instrument incontournable pour la mise à disposition de services interactifs de qualité des don- nées dans les Architectures d’Entreprises modernes. Il s’agit là surtout de services qui fonctionnent selon le modèle requête/réponse, où le consommateur de service initie une requête (par ex. « valider l’adresse indiquée ») et le service répond directe- 5 http://en.wikipedia.org/wiki/SOAP 6 http://en.wikipedia.org/wiki/Enterprise_service_bus 7 http://en.wikipedia.org/wiki/BPEL © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 5

6. WHITE PAPER: SOA ment avec une confirmation, une proposition de SOAP Protocol rectification ou une série d’adresses considérées correctes. Cette façon de procéder correspond au caractère interactif de la validation, dont le but est d’assister l’utilisateur lors de la saisie d’un objet métier tout en lui offrant des possibilités d’intervention en cas de problèmes. Toutefois, cette fonction- nalité n’est plus implémentée de façon isolée dans la couche présentation, mais plutôt intégrée dans un processus métier d’ordre supérieur. LA RELATION ENTRE L’IMPLÉMENTATION DES PROCESSUS MÉTIER ET LES FONCTIONS DE QUALITÉ DES DONNÉES DEVIENT AINSI TRÈS CLAIRE, DE MÊME QUE LE RÔLE IMPORTANT DE CES DERNIÈRES DANS LE SUCCÈS DU PROCESSUS MÉTIER EN QUESTION. Ceci est le cas , par exemple, pour l’implémenta- tion d’un processus de commande dans une application e-business ou bien pour l’implémentation d’un processus pour la conversion et qualification de leads dans une application CRM ou tout autre processus similaire. La relation entre l’implémenta- tion des processus métier et les fonctions de qualité des données devient ainsi très claire, de même que le rôle important de ces dernières dans le suc- cès du processus métier en question. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 6

7. WHITE PAPER: SOA Cas clients Orange Les clients de l’opérateur de télécommunications C’est également dans cet environnement qu’Uniserv Orange peuvent prendre contact avec l’entreprise met à disposition ses services de qualité des don- par l’intermédiaire de divers nées pour la validation, restructuration et normalisa- canaux. Ils peuvent visiter le site tion des adresses clients. Cette approche orientée Internet de l’entreprise, appeler services permet d’utiliser les mêmes services dans le centre d’appel ou se rendre divers processus et différents canaux de commu- à une boutique d’un opérateur nication. Qu’il s’agisse de la saisie d’un nouveau partenaire d’Orange. Mais, client Orange ou de la modification d’une adresse indépendamment de la méthode de contact choi- existante, et quel que soit le canal de contact utilisé sie par le client, il est impératif que les processus pour le lancement d’un processus, l’architecture correspondants gardent toujours le même niveau de orientée services mise en place garantit une ges- qualité. L’exactitude des adresses clients constitue à tion cohérente des processus en cours et l’accès cet égard un élément très important pour garantir la de ceux-ci aux mêmes services. Un haut niveau de qualité des processus. qualité des données d’adresses est ainsi garanti à l’échelle de toute l’entreprise. Sur le plan technique, on trouve un serveur d’applications libre JOnAS (Java Open Application Server). Ce serveur JEE joue un rôle central dans la mise en œuvre des services nécessaires à l’implémentation des processus métier d’Orange. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 7

8. WHITE PAPER: SOA Customer Cases WinGroup AG L’allemand WinGroup AG, groupe prestataire de services dans le domaine Ventes et Marketing offre à ses clients une vaste palette de services dans une multitude de domaines : centres d’appels, sociétés de publipos- tage, dialogue marketing et services informatiques. Afin d’assurer un niveau élevé et constant de quali- té des processus pour l’ensemble des domaines de services et des applications spécifiques au client, WinLogic – filiale du groupe WinGroup AG – a développé, sur la base d’un ESB, une architecture orientée services. Cet ESB représente un intergiciel servant à connecter toutes les applications de l’entreprise aux services centraux disponibles. Dans le domaine de la qualité des données, cette liaison concerne les solutions Uniserv pour la recherche de doublons et la validation d’adresses. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 8

9. WHITE PAPER: SOA REST : une alternative légère à SOAP Même si les protocoles basés sur SOAP semblent inadéquats pour ce scénario d’utilisation en raison être la solution idéale pour l’intégration dans les de l’overhead inhérent au protocole SOAP. Les ser- middlewares d’entreprise classiques, il existe néan- vices Web RESTful offrent à cet égard beaucoup moins des applications pour lesquelles l’utilisation plus de souplesse. L’appel des services s’effectue d’autres alternatives comme les services RESTful8 via le protocole http et les arguments d’appel sont est plus avantageuse. Ceci est surtout le cas si ensuite encodés dans les URL. Lors d’un appel à l’accès aux services de qualité des données doit partir de JavaScript, le résultat est fourni – dans le s’effectuer directement au niveau de la couche cas idéal – au format JSON9. Il en résulte un code présentation (basée sur HTML/AJAX). Un scénario JavaScript que l’interpréteur JavaScript du navi- typique est celui des outils d’aide à la saisie qui complètent automatiquement les données en cas LES SERVICES AINSI ÉLABORÉS PEUVENT de saisie partielle ou offrent des propositions sur la ÊTRE PARFAITEMENT UTILISÉS DANS base des informations partielles saisies. Les outils LES APPLICATIONS WEB 2.0 TYPIQUES. d’aide à la saisie sont naturellement intégrés dans la couche présentation. Cependant, ils ont des exigences beaucoup plus élevées concernant les gateur peut directement interpréter pour fournir le temps de réponse, étant donné qu’ils sont appelés résultat de l’appel sous forme d’objets JavaScript. avec fréquence lors de la saisie (en général après Les services ainsi élaborés peuvent être parfai- la saisie de chaque caractère). tement utilisés dans les applications Web 2.0 typiques. Bien que les services utilisés à cet effet dans le domaine de la saisie d’adresses soient les mêmes que ceux utilisés pour la validation d’adresses, les services Web basés sur SOAP s’avèrent parfois 8 http://en.wikipedia.org/wiki/REST 9 http://en.wikipedia.org/wiki/JSON © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 9

10. WHITE PAPER: SOA SOAP – les différences subtiles Même en adaptant les interfaces propriétaires à La spécification SOAP offre deux possibilités pour la communication basée sur SOAP, il reste à sur- définir, dans WSDL, la liaison entre la structure XML monter les obstacles liés à l’apprentissage. La du paquet et les constructions du langage de pro- description des paquets échangés dans le cadre grammation qui interprète ou met à disposition le d’une communication basée sur SOAP se fait en paquet. Le « style rpc » correspond – comme l’acro- utilisant le méta-format appelé WSDL (Web Service nyme l’indique – au classique appel de procédure Description Language). distante (RPC). Il modélise les opérations comme des appels de méthodes qui ne diffèrent pas des LORS DU DÉVELOPPEMENT DU WSDL10, appels locaux. Ceux-ci constituent une solution IL FAUT VEILLER À CE QUE LES TYPES DE idéale si on veut appeler le service Web en utili- DONNÉES UTILISÉS SOIENT RÉELLEMENT sant un langage de programmation orienté objet tel PRIS EN CHARGE PAR TOUS LES LANGA- que Java ou C#. Le « style Document » est, quant GES ET SYSTÈMES CIBLES DANS […] à lui, approprié pour modéliser des contenus com- DOIT ÊTRE CONSOMMÉ plexes. Ces derniers pouvant être représentés dans un document XML avec son schéma XML associé. Lors du développement du WSDL10, il faut veiller Ceci permet, d’un côté, d’effectuer la validation à ce que les types de données utilisés soient réel- par rapport au schéma XML à l’aide d’outils XML lement pris en charge par tous les langages et standard et de l’autre, d’utiliser ces outils ou des systèmes cibles dans lesquels le service doit être frameworks appropriés pour traiter ultérieurement consommé. Cet aspect n’est pas si important quand le document, le modifier ou le préparer pour la il s’agit de tâches de développement réalisées au couche de présentation. Les deux variantes ont leurs sein de l’entreprise avec une infrastructure logicielle avantages et leurs inconvénients. Dans le cas où les homogène (par ex. JEE ou .NET). Mais il devient services doivent être appelés depuis plusieurs envi- essentiel si l’on veut utiliser un service de qualité ronnements, l’utilisation des deux variantes pourrait des données dans plusieurs environnements dont même s’avérer nécessaire. certains étaient peut-être inconnus jusqu’à présent. 10 http://en.wikipedia.org/wiki/Web_Services_Description_Language © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 10

11. WHITE PAPER: SOA De par leur nature, les services Web sont sans état. sont requises, il ne faut en aucun cas procéder à Cela signifie que, dans le cas idéal, ils ne fournis- une implémentation ad hoc de la gestion et de la sent pas de résultats partiels. Le résultat de l’appel synchronisation de l’accès aux ressources pour le est donc un résultat total : les appels consécutifs service Web correspondant. Au lieu de cela, il faut sont toujours indépendants l’un de l’autre. utiliser les pools de ressources fournis par la plupart des applications serveur ou disponibles en tant CES DEUX DERNIERS POINTS DOIVENT, qu’extensions Open Source. Un pooling efficace et EN PARTICULIER, FAIRE L’OBJET D’UN configurable sera ainsi assuré. REDESIGN – DU MOINS PARTIEL – Ces deux derniers points doivent, en particulier, SI L’ON VEUT METTRE À DISPOSITION LA faire l’objet d’un redesign – du moins partiel – si FONCTIONNALITÉ EXISTANTE COMME l’on veut mettre à disposition la fonctionnalité exis- SERVICE WEB. tante comme service Web. Les services Web doivent être extensibles. L’absence d’états précédemment décrite constitue à cet égard une condition indispensable. De plus, le service Web ne doit avoir accès qu’à un nombre très limité de ressources globales (voire même à aucune ressource). Dans le cas où ces dernières © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 11

12. WHITE PAPER: SOA L’architecture SOA estompe la différence entre le mode « On Premise » et « On Demand » La mise à disposition de services logiciels et d’ap- interventions doivent être réalisées pour chaque plications sur Internet – connue sous les appella- pays dont les adresses doivent être validées. tions « Software on Demand11 », « Software as a L’utilisation de telles solutions ne devient alors inté- Service » (SaaS) ou « Cloud Computing » – est un ressante que si le volume de données est assez thème qui gagne de plus en plus d’importance. important. Cette restriction peut être contournée via On tend souvent à souligner les différences pro- la mise à disposition du service en mode SaaS. fondes et fondamentales entre les logiciels ins- tallés localement « On Premise » et ceux utilisés LA MANIÈRE DONT UN SERVICE EST MIS via Internet « On Demand ». Or, ceci n’est pas À DISPOSITION NE JOUE AUCUN RÔLE le cas du point de vue de la SOA. En effet, la DANS LE CADRE D’UNE ARCHITECTURE manière dont un service est mis à disposition ne ORIENTÉE SERVICES. joue aucun rôle dans le cadre d’une architecture orientée services. La mise à disposition d’un service via Internet – en alternative au serveur local Dans ce cas, seules les transactions réellement réa- – offre des possibilités d’utilisation intéressantes, lisées sont facturées. L’utilisation d’une architecture notamment dans le domaine des services de qua- orientée services permet de combiner librement lité des données destinés à la validation et à la les services installés localement avec ceux utilisés rectification par comparaison avec des données via Internet ou de les interchanger. Cette utilisation de référence. combinée permet de trouver la solution optimale pour chaque utilisateur et de la modifier par la Les données de référence requises pour le service suite pour l’adapter aux nouvelles conditions envi- doivent être actualisées régulièrement. Cela exige ronnantes une intervention manuelle régulière et le paiement de frais d’abonnement aux fournisseurs des don- nées. En cas d’utilisation de répertoires de codes postaux spécifiques aux pays, ces dépenses et 11 http://en.wikipedia.org/wiki/Software_as_a_Service © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 12

13. WHITE PAPER: SOA Conclusions Sur la base des expériences précédemment décrites, on peut tirer les conclusions suivantes en tenant compte de deux aspects : ASPECT UN: Quelles sont les exigences qui doivent être remplies pour que les fonctions de qualité des données puissent être intégrées dans un environnement SOA ? – Les fonctions doivent être accessibles via SOAP. – De plus, il faut vérifier s’il y a moyen d’obtenir Ainsi, elles pourront être intégrées dans pra- des avantages économiques ou techniques en tiquement toutes les infrastructures pour une utilisant un scénario alternatif dans lequel le implémentation orientée services des processus service est mis à disposition via Internet, et si le métier. Toutefois, il faut veiller à ce que le map- fournisseur de services supporte un tel scénario. page entre les éléments XML de la description du service et les constructions correspondantes de l’environnement serveur soit applicable. – Si l’utilisation est prévue dans la couche présen- tation, il faudra vérifier si l’implémentation d’un service RESTful est nécessaire. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 13

14. WHITE PAPER: SOA ASPECT DEUX: Quels sont les aspects à tenir en compte si l’on veut que des fonctions de validation, d’enrichissement et de mise en forme des données deviennent compatibles avec l’architecture SOA ? – Les scenarii d’utilisation doivent être clairement – L’extensibilité du service doit être assurée. Si le définis. La question importante ici est de savoir service Web a besoin de ressources globales si les services seront utilisés dans le cadre de (par. ex. une connexion à la base de données), la logique métier ou de la logique de présen- celles-ci doivent être gérées dans le conteneur tation. Dans le premier cas, l’intégration s’ef- du serveur en utilisant un pool de ressources fectue dans le serveur d’applications, dans le adéquat. Autrement, ces ressources risquent de bus de services d’entreprise (ESB) ou dans un se transformer en un véritable obstacle à l’ex- moteur BPEL. Dans le deuxième, l’intégration se tensibilité du service. fait dans l’interface graphique qui peut avoir des exigences spécifiques. C’est en fonction – Le service doit être accessible sur le réseau. Il de ces facteurs que l’on pourra décider de la doit donc fonctionner indépendamment du fait solution la plus appropriée (services basés sur qu’il soit mis à disposition sur un réseau local SOAP et/ou services RESTful). ou sur le réseau Internet. Ceci étend énormé- ment les possibilités d’utilisation. – Les systèmes et les langages cibles dans lesquels le service sera utilisé doivent être définis. Sur la base de cette définition, on pourra déci- der du degré de complexité de la modélisation (en relation avec les structures XML utilisées et Pour de plus amples renseignements les types de données XML des résultats d’ap- n‘hésitez pas à consulter la page web suivante pels). www.uniserv.com ou à nous contacter directement: – Le service doit être conçu sans états, c’est-à- dire qu’il doit fonctionner sans mémorisation d’états internes entre deux appels. Si un état est requis entre les appels, celui-ci devra être remis Nous sommes heureux de vous conseiller et vous lors de l’appel suivant ou rendu persistant de accompagner tout au long de votre projet. manière appropriée. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 14

15. WHITE PAPER: SOA Uniserv Uniserv est le plus grand fournisseur européen spécialisé en solutions de qualité des données à travers un portefeuille de logiciels utilisables au niveau internati- onal ainsi que des services pour la qualité des données dans le domaine de la BI et des applications CRM, Data Warehousing, eBusiness et Markting direct et de données. Avec plusieurs milliers d’installations dans le monde entier, Uniserv soutient des centaines de clients dans leurs efforts visant à reproduire une vision d’ensemble du client dans MIGRATION DE leurs bases de données clients. Uniserv emploie plus de DONNÉES 110 personnes en son siège de Pforzheim ainsi que dans E-BUSINESS sa filiale de Paris et dessert, dans tous les secteurs et à échelle internationale, de nombreux clients de renommée ERP comme, par exemple, ADAC, Allianz, BMW, Commerz- bank, DBV Winterthur, Deutsche Bank, Deutsche Börse COMPLIANCE Group, France Telecom, Greenpeace, GEZ, Heineken, CRM Johnson & Johnson, Nestlé, Payback, PSA Peugeot Cit- roën ainsi que Time Life et Union Investment. Pour en savoir plus, SOA consultez www.uniserv.com MARKETING DIALOGUE & MDM/CDI DIRECT ON PREMISE/ ON DEMAND BI/BDW CPM Expérience: Position sur le marché: Employés: PLUS DE 40 ANS LE PLUS GRAND PLUS DE 110 PERSONNES FOURNISSEUR EUROPÉEN UNISERV SARL Contact: Bât. Le Sisley PARIS NORD 2 • 23 Allée des Impressionnistes +33 1 48 63 91 91 BP 53421 VILLEPINTE • 95944 ROISSY CH DE GAULLE CEDEX •France E contact-france@uniserv.com • www.uniserv.com © Copyright Uniserv • Pforzheim / Allemagne • All rights reserved. © UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 15

Data Quality et SOA

Data Quality et SOA

Data Quality et SOA

Recomendados

Más contenido relacionado

Was ist angesagt?

Was ist angesagt?(19)

Destacado

Destacado(20)

Similar a Data Quality et SOA

Similar a Data Quality et SOA(20)

Más de Uniserv

Más de Uniserv(16)

Data Quality et SOA