Salut,
 
Questions d'architecture ...
 
Mon client souhaite à tout prix (    ) des interfaces XML entre les divers applicatifs et les diverses bases de données.
Qu'en pensez-vous ?
 
Après maintes recherches, je ne vois pas quels sont les avantages réels d'interfaces XML par rapport à une architecture client serveur ?
Comment fonctionne une telle interface ? S'agit il de transmettre des fichiers XML à un serveur de données pour qu'il prenne en charge l'intégration des données dans les tables de la base ? dans ce cas il me semble que ce ne serait pas très performant    
De plus avec une interface XML qu'en est-il des interrogations SQL ? des éventuels curseurs, recordsets, datasets ou autres ?
 
Avez-vous des liens intéressants qui me permettraient de prendre connaissance de telles architectures ?
 
Merci    

1/ explique à ton client que le XML, c'est plus "in the wind", maintenant c'est l'Ajax, comme le produit à chiotte qui est à la mode
2/ explique ensuite que faire des requête XML en JavaScript pour gérer un import de fichiers, c'est pas forcément très heureux comme méthode
3/ à la limite, ouvre un bouquin qui parle de "webservices" : ce sont des services applicatifs disposant d'une interface de communication SOAP (donc en XML) capable de faire des traîtements et d'y répondre. rien ne t'empêche donc de faire ce qu'il désire avec cette techno.
3bis/ en plus c'est pratique un webservice, parcequ'on peut les utiliser de façon totalement transparente depuis les programes fournisseurs/consommateurs de données.
 
à noter que là où ton client a raison, c'est que si d'un point de vue perfs c'est pas top, d'un point de vue homogénéité (et donc maintenance) des applications "interface", c'est tout bénéfice.
 
en gros, acheter un second serveur de la mort qui tue pour délester celui qu'on a trop chargé à cause de ça, ça tourne dans les 5 à 6000 €.
 
faire appel à 12 prestataires de services pour maintenir 35 applications totalement hétérogènes parcequ'on a modifié une table dans une base, ç coûte plus de 60 000 €
 
donc je me mets dans le caleçon du client, et j'approuve
 
webservice me semble le plus approprié

OK pour le webservice ...
Mais le problème de la connexion à la base est seulement déporté. En fait le webservice doit mettre à jour (insert, update, delete) et interroger la base en mode client/serveur, non ? Est-ce que je me trompe ?    

qu'entends-tu par client/serveur ?
 
de toute façon, le SGBD lui-même, à la base, c'est une application client/serveur
 
le webservice peut être appelé par n'importe quoi, aussi bien un batch en local qui "poste" un fichier XML brut, tout comme un site web distant, ou une application win32.

Merci. Je comprend à peu près la problematique
 
De manière générale le webservice est une méthode de communication possible entre des applications et une base de données Oracle, par exemple.
 
Y a-t-il d'autres moyens que le webservice pour effectuer des interfaces XML ?  
Existe t-il des outils, coté Oracle qui prennent en charge des flux XML pour la mise à jour des données, et des requêtes XML pour l'interrogation des données ?
 

Non, un WebService, c'est un service déporté, disposant d'une interface XML générique (donc n'importe qui peut communiquer avec lui sans nécessiter un cahier des charges proprio).
 
Par contre, un WebService n'est en rien "destiné" à la communication entre une appli et une base de données.
 
Rien n'empêche deux bases de données de communiquer via ce moyen, ou deux applis entre elles.
 
Sinon, oui, Oracle dispose des outils nécessaires pour créer un flux XML à partir de ses propres données, et vice-versa. Je te déconseille cependant de te base "uniquement" dessus.
 
Car le rôle d'un SGBD, c'est d'être remplaçable facilement. Si tu fais des choses trop spécifiques (le support XML dans les SGBD ne fait l'objet d'aucune norme) tu vas devoir tout refaire le jour où vous changerez de SGBD, ou plus simplement, le jour où Oracle décidera de modifier l'implémentation du truc dans ses produits.
 
Avec un langage de haut niveai tel que C# ou Java, un WebService, ça s'écrit de façon totalement transparente. A aucun moment tu ne traîtes du XML. Tu crées une classe avec des méthodes tout ce qu'il y a de plus simple, et c'est au moment de la compilation que le Framework va se débrouiller pour faire les interfaces XML. Idem pour l'utilisation d'un WebService à distance depuis C# ou Java : tu instancies un instance de la classe du WebService dans ton programme, et tu exécute les méthodes du WebService comme d'il s'agissait de simples méthodes.
 
Donc pas besoin de te soucier de la génération/parsing du XML. Toi tu travaillera avec les données "réelles" et correctement typées.
 
Par contre, ça te permet d'avoir des interfaces parfaitement génériques pour l'ensemble de tes bases, et surtout, ça permet, depuis une application du genre script batch ou autre langage pas prévu pour utiliser des webservices, de passer via ses interfaces en utilisant des flux XML fais main.
 
Bref, pour moi les webservices entre entièrement dans le cadre de la demande de ton client.
 
Ou alors, ce qu'il demande, c'est un EDI, et à ce moment, tu lui fais en acheter un, tu vas pas t'amuser à en écrire un...

Merci Msieur