data quality et soa

15
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 nou- velles 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. WHITE PAPER / Data Quality meets SOA – la qualité des données mise au service des processus métier WHITE PAPER: SOA

Upload: uniserv

Post on 28-Nov-2014

1.426 views

Category:

Business


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Data Quality et SOA

Page 1

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 nou-velles 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.

WHITE PAPER / Data Quality meets SOA – la qualité des données mise au service des processus métier

WHITE PAPER: SOA

Page 2: Data Quality et SOA

Page 2© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

APPLICATION A: Une application classique est, par exemple, la validation d’une adresse postale en utili-sant 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.

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.

Un objectif important dans le cadre de l’optimisation de la qualité des données est d’éviter, dès le départ, l’enregistrement de données incomplètes ou erronées dans la base de données. Les anoma-lies éventuelles doivent être détectées au moment de la saisie des données, puis éliminées auto-matiquement ou notifiées à l’utilisateur pour qu’il procède lui-même à leur élimination. Grâce à des index de recherche spécialisés, la recherche dans une base de données contenant entre 1 000 000 et 100 000 000 enregistrements ne dure qu’une fraction de seconde, même en cas d’utilisation d’orthographes différentes. De tels temps de répon-se requièrent toutefois une mise en cache intelligen-te des index. Une solution efficace pour atteindre cet objectif serait d’implémenter le logiciel comme service central mis à disposition par l’un de vos propres serveurs.

Outre le temps de réponse, la possibilité d’intégrer les services de qualité des données dans divers environnements informatiques revêt également une importance primordiale. Pour atteindre cet objectif, il est indispensable de découpler les services de qualité de données des consommateurs du service et d’utiliser un protocole client/serveur. C’est pour cette raison que cette fonctionnalité a été dévelop-pée et utilisée dans le domaine de la qualité des données, du moins pour les applications exigean-tes, avant même que les architectures orientées ser-vices ne furent inventées. De cette manière, il a été possible à la fois de répondre aux hautes exigences en matière de temps de réponse et d’assurer la mise à disposition d’une série de fonctionnalités pour les multiples environnements existants.

Page 3: Data Quality et SOA

Page 3© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

Du « client lourd » à l’architecture trois-tiersLayered Architecture

L’architecture typique au début du monde client/serveur se composait d’une base de données qui, outre l’enregistrement des données de transac-tion et des données de base, permettait d’établir une communication asynchrone entre les différents composants du système, rendant ainsi possible 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 pro-cessus 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é.

LAYERED ARCHITECTURE

Name

Street

Postcode

Customer

ROLE

Supplier

Reseller

Name

Street

Postcode

Customer

Supplier

Reseller

FAT CLIENT CLIENT

APPLICATION SERVER

ROLE

WHITE PAPER: SOA

1 http://en.wikipedia.org/wiki/Distributed_Computing_Environment

2 http://en.wikipedia.org/wiki/CORBA

Page 4: Data Quality et SOA

Page 4© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

Cette situation a totalement changé dans les der-nières années. Le point de départ fût surtout la mise au point de plusieurs standards dans le cadre de la spécification JEE (Java Enterprise Edition)3 et, par la suite, le développement d’implémentations plus performantes de ces standards comme solutions commerciales ou Open Source.

Ce fut ensuite Microsoft qui suivit en développant, pour le monde Windows, une plate-forme indé-pendante des langages (.NET), ainsi que les ser-vices 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 exi-gences envers les services de qualité des données. Ces derniers étant désormais largement acces-sibles 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

LAYERED ARCHITECTURE

Name

Street

Postcode

Customer

ROLE

Supplier

Reseller

Name

Street

Postcode

Customer

Supplier

Reseller

FAT CLIENT CLIENT

APPLICATION SERVER

ROLE

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.

Page 5: Data Quality et SOA

Page 5© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

SOAP, protocole clé pour une SOA optimalePour pouvoir tirer le meilleur parti de la SOA, il 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 compo-sants d’infrastructure et middleware, ce protocole assure une complète interopérabilité entre fournis-seurs 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 à dis-position 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

Proprietary Protocol

Page 6: Data Quality et SOA

Page 6© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

ment avec une confirmation, une proposition de 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’interven-tion 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.

Ceci est le cas , par exemple, pour l’implémenta-tion d’un processus de commande dans une appli-cation 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.

SOAP Protocol

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.

Page 7: Data Quality et SOA

Page 7© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

Cas clientsOrangeLes clients de l’opérateur de télécommunications Orange peuvent prendre contact avec l’entreprise

par l’intermédiaire de divers canaux. Ils peuvent visiter le site Internet de l’entreprise, appeler le centre d’appel ou se rendre à une boutique d’un opérateur partenaire d’Orange. Mais,

indépendamment de la méthode de contact choi-sie par le client, il est impératif que les processus correspondants gardent toujours le même niveau de qualité. L’exactitude des adresses clients constitue à cet égard un élément très important pour garantir la qualité des processus.

Sur le plan technique, on trouve un serveur d’appli-cations 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.

C’est également dans cet environnement qu’Uniserv met à disposition ses services de qualité des don-nées pour la validation, restructuration et normalisa-tion des adresses clients. Cette approche orientée services permet d’utiliser les mêmes services dans divers processus et différents canaux de commu-nication. Qu’il s’agisse de la saisie d’un nouveau client Orange ou de la modification d’une adresse existante, et quel que soit le canal de contact utilisé pour le lancement d’un processus, l’architecture orientée services mise en place garantit une ges-tion cohérente des processus en cours et l’accès de ceux-ci aux mêmes services. Un haut niveau de qualité des données d’adresses est ainsi garanti à l’échelle de toute l’entreprise.

Page 8: Data Quality et SOA

Page 8© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

Customer CasesWinGroup AGL’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’ap-pels, 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’en-treprise 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.

Page 9: Data Quality et SOA

Page 9© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

REST : une alternative légère à SOAP

LES SERVICES AINSI ÉLABORÉS PEUVENT ÊTRE PARFAITEMENT UTILISÉS DANS LES APPLICATIONS WEB 2.0 TYPIQUES.

Même si les protocoles basés sur SOAP semblent être la solution idéale pour l’intégration dans les middlewares d’entreprise classiques, il existe néan-moins des applications pour lesquelles l’utilisation d’autres alternatives comme les services RESTful8 est plus avantageuse. Ceci est surtout le cas si l’accès aux services de qualité des données doit s’effectuer directement au niveau de la couche présentation (basée sur HTML/AJAX). Un scénario typique est celui des outils d’aide à la saisie qui complètent automatiquement les données en cas de saisie partielle ou offrent des propositions sur la base des informations partielles saisies. Les outils 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 temps de réponse, étant donné qu’ils sont appelés avec fréquence lors de la saisie (en général après la saisie de chaque caractère).

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

inadéquats pour ce scénario d’utilisation en raison de l’overhead inhérent au protocole SOAP. Les ser-vices Web RESTful offrent à cet égard beaucoup plus de souplesse. L’appel des services s’effectue via le protocole http et les arguments d’appel sont ensuite encodés dans les URL. Lors d’un appel à partir de JavaScript, le résultat est fourni – dans le cas idéal – au format JSON9. Il en résulte un code JavaScript que l’interpréteur JavaScript du navi-

gateur peut directement interpréter pour fournir le résultat de l’appel sous forme d’objets JavaScript. Les services ainsi élaborés peuvent être parfai-tement utilisés dans les applications Web 2.0 typiques.

8 http://en.wikipedia.org/wiki/REST

9 http://en.wikipedia.org/wiki/JSON

Page 10: Data Quality et SOA

Page 10© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

SOAP – les différences subtiles

10 http://en.wikipedia.org/wiki/Web_Services_Description_Language

LORS DU DÉVELOPPEMENT DU WSDL10, IL FAUT VEILLER À CE QUE LES TYPES DE DONNÉES UTILISÉS SOIENT RÉELLEMENT PRIS EN CHARGE PAR TOUS LES LANGA-GES ET SYSTÈMES CIBLES DANS […]DOIT ÊTRE CONSOMMÉ

Même en adaptant les interfaces propriétaires à la communication basée sur SOAP, il reste à sur-monter les obstacles liés à l’apprentissage. La description des paquets échangés dans le cadre d’une communication basée sur SOAP se fait en utilisant le méta-format appelé WSDL (Web Service Description Language).

Lors du développement du WSDL10, il faut veiller à ce que les types de données utilisés soient réel-lement pris en charge par tous les langages et systèmes cibles dans lesquels le service doit être consommé. Cet aspect n’est pas si important quand il s’agit de tâches de développement réalisées au sein de l’entreprise avec une infrastructure logicielle homogène (par ex. JEE ou .NET). Mais il devient essentiel si l’on veut utiliser un service de qualité des données dans plusieurs environnements dont certains étaient peut-être inconnus jusqu’à présent.

La spécification SOAP offre deux possibilités pour définir, dans WSDL, la liaison entre la structure XML du paquet et les constructions du langage de pro-grammation qui interprète ou met à disposition le paquet. Le « style rpc » correspond – comme l’acro-nyme l’indique – au classique appel de procédure distante (RPC). Il modélise les opérations comme des appels de méthodes qui ne diffèrent pas des appels locaux. Ceux-ci constituent une solution idéale si on veut appeler le service Web en utili-sant un langage de programmation orienté objet tel que Java ou C#. Le « style Document » est, quant à lui, approprié pour modéliser des contenus com-plexes. Ces derniers pouvant être représentés dans un document XML avec son schéma XML associé.

Ceci permet, d’un côté, d’effectuer la validation par rapport au schéma XML à l’aide d’outils XML standard et de l’autre, d’utiliser ces outils ou des frameworks appropriés pour traiter ultérieurement le document, le modifier ou le préparer pour la couche de présentation. Les deux variantes ont leurs avantages et leurs inconvénients. Dans le cas où les services doivent être appelés depuis plusieurs envi-ronnements, l’utilisation des deux variantes pourrait même s’avérer nécessaire.

Page 11: Data Quality et SOA

Page 11© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

De par leur nature, les services Web sont sans état. Cela signifie que, dans le cas idéal, ils ne fournis-sent pas de résultats partiels. Le résultat de l’appel est donc un résultat total : les appels consécutifs sont toujours indépendants l’un de l’autre.

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

CES DEUX DERNIERS POINTS DOIVENT, EN PARTICULIER, FAIRE L’OBJET D’UN REDESIGN – DU MOINS PARTIEL – SI L’ON VEUT METTRE À DISPOSITION LA FONCTIONNALITÉ EXISTANTE COMME SERVICE WEB.

sont requises, il ne faut en aucun cas procéder à une implémentation ad hoc de la gestion et de la synchronisation de l’accès aux ressources pour le service Web correspondant. Au lieu de cela, il faut utiliser les pools de ressources fournis par la plupart des applications serveur ou disponibles en tant qu’extensions Open Source. Un pooling efficace et configurable sera ainsi assuré.Ces deux derniers points doivent, en particulier, faire l’objet d’un redesign – du moins partiel – si l’on veut mettre à disposition la fonctionnalité exis-tante comme service Web.

Page 12: Data Quality et SOA

Page 12© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

L’architecture SOA estompe la différence entre le mode « On Premise » et « On Demand »

11 http://en.wikipedia.org/wiki/Software_as_a_Service

LA MANIÈRE DONT UN SERVICE EST MIS À DISPOSITION NE JOUE AUCUN RÔLE DANS LE CADRE D’UNE ARCHITECTURE ORIENTÉE SERVICES.

La mise à disposition de services logiciels et d’ap-plications sur Internet – connue sous les appella-tions « Software on Demand11 », « Software as a Service » (SaaS) ou « Cloud Computing » – est un thème qui gagne de plus en plus d’importance. On tend souvent à souligner les différences pro-fondes et fondamentales entre les logiciels ins-tallés localement « On Premise » et ceux utilisés via Internet « On Demand ». Or, ceci n’est pas le cas du point de vue de la SOA. En effet, la manière dont un service est mis à disposition ne joue aucun rôle dans le cadre d’une architecture orientée services. La mise à disposition d’un ser-vice via Internet – en alternative au serveur local – offre des possibilités d’utilisation intéressantes, notamment dans le domaine des services de qua-lité des données destinés à la validation et à la rectification par comparaison avec des données de référence.

Les données de référence requises pour le service doivent être actualisées régulièrement. Cela exige 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

interventions doivent être réalisées pour chaque pays dont les adresses doivent être validées. L’utilisation de telles solutions ne devient alors inté-ressante que si le volume de données est assez important. Cette restriction peut être contournée via la mise à disposition du service en mode SaaS.

Dans ce cas, seules les transactions réellement réa-lisées sont facturées. L’utilisation d’une architecture orientée services permet de combiner librement les services installés localement avec ceux utilisés via Internet ou de les interchanger. Cette utilisation combinée permet de trouver la solution optimale pour chaque utilisateur et de la modifier par la suite pour l’adapter aux nouvelles conditions envi-ronnantes

Page 13: Data Quality et SOA

Page 13© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

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 environne-ment SOA ?

WHITE PAPER: SOA

ConclusionsSur la base des expériences précédemment décrites, on peut tirer les conclusi-ons suivantes en tenant compte de deux aspects :

– Les fonctions doivent être accessibles via SOAP. Ainsi, elles pourront être intégrées dans pra-tiquement toutes les infrastructures pour une implémentation orientée services des processus métier. Toutefois, il faut veiller à ce que le map-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.

– De plus, il faut vérifier s’il y a moyen d’obtenir des avantages économiques ou techniques en utilisant un scénario alternatif dans lequel le service est mis à disposition via Internet, et si le fournisseur de services supporte un tel scénario.

Page 14: Data Quality et SOA

Page 14© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

WHITE PAPER: SOA

– Les scenarii d’utilisation doivent être clairement définis. La question importante ici est de savoir si les services seront utilisés dans le cadre de la logique métier ou de la logique de présen-tation. Dans le premier cas, l’intégration s’ef-fectue dans le serveur d’applications, dans le bus de services d’entreprise (ESB) ou dans un moteur BPEL. Dans le deuxième, l’intégration se fait dans l’interface graphique qui peut avoir des exigences spécifiques. C’est en fonction de ces facteurs que l’on pourra décider de la solution la plus appropriée (services basés sur SOAP et/ou services RESTful).

– Les systèmes et les langages cibles dans les-quels 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 les types de données XML des résultats d’ap-pels).

– 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 lors de l’appel suivant ou rendu persistant de manière appropriée.

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 ?

– L’extensibilité du service doit être assurée. Si le service Web a besoin de ressources globales (par. ex. une connexion à la base de données), celles-ci doivent être gérées dans le conteneur du serveur en utilisant un pool de ressources adéquat. Autrement, ces ressources risquent de se transformer en un véritable obstacle à l’ex-tensibilité du service.

– Le service doit être accessible sur le réseau. Il doit donc fonctionner indépendamment du fait qu’il soit mis à disposition sur un réseau local ou sur le réseau Internet. Ceci étend énormé-ment les possibilités d’utilisation.

Pour de plus amples renseignementsn‘hésitez pas à consulter la page web suivante www.uniserv.com ou à nous contacter directement:

Nous sommes heureux de vous conseiller et vous accompagner tout au long de votre projet.

Page 15: Data Quality et SOA

Page 15© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved.

UniservUniserv 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 leurs bases de données clients. Uniserv emploie plus de 110 personnes en son siège de Pforzheim ainsi que dans sa filiale de Paris et dessert, dans tous les secteurs et à échelle internationale, de nombreux clients de renommée comme, par exemple, ADAC, Allianz, BMW, Commerz-bank, DBV Winterthur, Deutsche Bank, Deutsche Börse Group, France Telecom, Greenpeace, GEZ, Heineken, Johnson & Johnson, Nestlé, Payback, PSA Peugeot Cit-roën ainsi que Time Life et Union Investment.

Pour en savoir plus, consultez www.uniserv.com

Expérience: PLUS DE 40 ANS

Position sur le marché:LE PLUS GRAND FOURNISSEUR EUROPÉEN

Employés: PLUS DE 110 PERSONNES

MARKETING DIALOGUE &

DIRECT

BI/BDW

CPM

CRM

ERP

E-BUSINESS

MIGRATION DE

DONNÉES

SOA

ON PREMISE/ON DEMAND

MDM/CDI

COMPLIANCE

UNISERV SARL Bât. Le Sisley PARIS NORD 2 • 23 Allée des Impressionnistes BP 53421 VILLEPINTE • 95944 ROISSY CH DE GAULLE CEDEX •France E [email protected] • www.uniserv.com© Copyright Uniserv • Pforzheim / Allemagne • All rights reserved.

WHITE PAPER: SOA

Contact:+33 1 48 63 91 91