Analyse d'un ensemble de données .NET renvoyé par un service Web .NET en Java

Question

Je dois consommer un service Web hébergé .NET à partir d'une application Java. L'interopérabilité entre les deux est généralement très bonne. Le problème que je rencontre est que le développeur de l'application .NET a choisi d'exposer les données en utilisant l'objet .NET DataSet. Il y a beaucoup d'articles écrits pourquoi vous ne devriez pas le faire et comment il rend difficile l'interopérabilité:

• http://www.hanselman.com/blog/ReturningDataSetsFromWebServicesIsTheSpawnOfSatanAndRepresentsAllThatIsTrulyEvilInTheWorld.aspx
• http://www.lhotka.net/weblog/ThoughtsOnPassingDataSetObjectsViaWebServices.aspx
• http://aspnet.4guysfromrolla.com/articles/051805-1.aspx
• http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes

Mon problème est que Bien que cela ne soit pas recommandé, je suis obligé de consommer un service web qui retourne un DataSet avec Java. Lorsque vous générez un proxy pour quelque chose comme ça avec autre chose que .NET vous finissez essentiellement avec un objet qui ressemble à ceci:

@XmlElement(namespace = "http://www.w3.org/2001/XMLSchema", required = true) 
    protected Schema schema; 
    @XmlAnyElement(lax = true) 
    protected Object any; 

Ce premier champ est le schéma réel qui doit décrire le DataSet. Quand je le traite en utilisant JAX-WS et JAXB en Java, cela amène tout XS-Schema en tant qu'objets Java à représenter ici. Marcher dans l'arbre des objets de JAXB est possible mais pas joli. Le champ any représente le code XML brut du DataSet figurant dans le schéma spécifié par le schéma.

La structure de l'ensemble de données est assez cohérente mais les types de données changent. J'ai besoin d'accéder aux informations de type et le schéma varie d'un appel à l'autre. J'ai cependant quelques options mais aucune ne semble être une bonne option.

• Essayer de générer des objets Java à partir du schéma en utilisant JAXB à l'exécution semble être une mauvaise idée. Ce serait trop lent car cela devrait arriver à chaque fois.
• Brute force marcher l'arbre de schéma en utilisant les objets JAXB que JAX-WS apporté.
• Peut-être au lieu d'utiliser JAXB pour analyser le schéma, il serait plus facile de traiter comme XML et utiliser XPath pour essayer de trouver le tapez les informations dont j'ai besoin.

Existe-t-il d'autres options que je n'ai pas envisagées? Existe-t-il une bibliothèque Java pour analyser facilement les objets DataSet? Qu'ont fait d'autres personnes qui peuvent avoir des situations similaires?

Answer 1

Malheureusement, je ne pense pas qu'il y ait une réponse facile ici. Ce que je ferais est de créer un service Web Proxy dans .NET que vous pourriez appeler à partir de Java qui recevrait l'ensemble de données, le transformer en quelque chose de plus consommable et le renvoyer ensuite à votre code Java.

Answer 2

Votre application Java s'exécute-t-elle sur un serveur? Si c'est le cas, installez Mono sur le serveur et utilisez ADO.NET intégré à Mono pour convertir le jeu de données en quelque chose que Java peut comprendre. L'avantage est que toute l'interprétation de l'ensemble de données est faite pour vous en mono. Vous pouvez même utiliser IKVM pour rester dans le monde de la langue Java. Quoi qu'il en soit, dans le monde Mono, vous pouvez avoir un service local qui peut faire la conversion, ou simplement avoir un utilitaire qui convertit le Dataset dans le système de fichiers dans un format que Java peut comprendre.

Answer 3

Avez-vous envisagé d'utiliser XSLT sur le XML brut retourné pour le masquer et le manipuler plus facilement?

Je l'ai utilisé cette approche pour convertir une valeur de retour complexe en quelque chose de similaire à

<ops> 
    <set name="foo" value="bar"/> 
    <set name="foo2" value="bar2" /> 
    .... 
</ops> 

Cela déplace la logique dans un langage bien adapté pour traiter XML au lieu de handcoding en Java.