10
votes

Création et exposition d'un service de savon et de sa WSDL de manière dynamique en C # (avec un auditeur TCP personnalisé!)

J'ai un serveur HTTP personnalisé construit en C # qui accepte les demandes de services de repos et répond avec XML ou JSON (selon les besoins de la clientèle). Les services de repos sont définis au moment de l'exécution d'une configuration basée sur la base de données, varient considérablement dans les paramètres d'entrée et les types de sortie, et il fonctionne magnifiquement en production.

Cependant, j'aimerais ajouter un accès aux savons aux mêmes services, avec des WSDLS appropriés également. Étant donné que les services disponibles ne sont pas codés dur, cela signifie:

  • Publication d'une WSDL générée au moment de l'exécution des définitions de la méthode de la base de données
  • analyse des demandes de savon entrantes, cartographiez-les dans ces définitions et en veillant à ce que les demandes soient conformes à la signature de la méthode avant de les manipuler
  • Une fois la réponse manipulée, la création d'une réponse de savon répondant au WDSL pour renvoyer les résultats

    Les documents de la documentation MS (et de Google) à l'aide de Visual Studio pour générer des services Web (et WSDLS) au moment de la conception, exposant des éléments à l'aide de Webmethods, ASP.NET MVC, etc. Ce n'est pas ce que je recherche, comme il y a ne sont pas des définitions de méthode à partir de laquelle générer les liaisons au moment de la conception.

    Est-ce que quelqu'un a des idées (par exemple des outils à outils pour l'analyse de savon brut) et des réflexions sur la génération de WSDLS à partir de signatures de méthodes créées dynamiquement, etc.? Une idée de la façon dont on pourrait aller construire de telles choses sinon? Je cherche à éviter de réinventer la roue si possible.

    PS: Clairement, il y a des éléments standardisés dans la structure .NET pour cela, car Visual Studio le fait pour vous - des idées Comment accéder à cela à un niveau inférieur, au moment de l'exécution?


3 commentaires

"Les services de repos sont définis à l'exécution d'une configuration basée sur la base de données" - je frissonnais quand je lis ça. N'est-ce pas une maintenance et dépannage de l'enfer?


Je m'occupe d'une situation très similaire me demandant si la réponse acceptée a fonctionné pour vous


NP-Hard - J'ai fait une épreuve de la preuve et cela a fait ce qui était destiné. Je n'ai rien lancé à la production, cependant, comme sur l'équilibre demandant aux clients de mettre en œuvre le service de repos semblait être un choix plus fiable que l'analyse manuelle, ainsi que des bugs pouvant être introduits à travers le processus complexe de pantalon manuellement des demandes de savon manuellement.


3 Réponses :


2
votes

SOAP est "juste" un protocole basé sur XML pour l'échange d'informations. La mise en œuvre de la prise en charge de la masse supérieure serait fastidieuse mais pas extrêmement compliquée en principe, je ne pense pas.

Les spécifications officielles SOAP peuvent être trouvées ici .


1 commentaires

C'est surtout le tédium (et le potentiel de bugs) que je cherche à éviter - espère plutôt une sorte de boîte à outils pour manipuler l'analyse de savon, etc. Je sais que Microsoft avait la boîte à outils de savon il y a environ 10 ans, mais il a été obsolète en faveur de VS Gérer tout ... Merci, cependant!



2
votes

Ne pas analyser le savon sauf si vous ne devez vraiment pas, laissez WCF faire le levage lourd pour vous, générer des services de service et de données dans C # code de vos définitions et compiler à l'exécution . Générez une implémentation de service qui accroche à votre code «statique» via une interface bien connue.

créer de manière dynamique des points de terminaison avec la liaison correcte pour les nouveaux contrats de service / contrats de données. Si les liaisons ne changent pas de manière dynamique, cela pourrait être défini dans vous app.Config, configurez-le également celui-ci en runtime.

Ajouter un point de terminaison MEX pour obtenir le WSDL publié.

pour "examiner" le trafic entrant Utilisez un messageInspector

Hôter auto-hébergeur Le service WCF / SOAP de votre serveur HTTP à l'aide de ServiceHost -> auto Hébergement de wcf

Quelques idées sur une autre approche.


5 commentaires

Il n'est peut-être pas assez clair de ma question initiale, mais les contrats de données et les liaisons font changent au moment de l'exécution, c'est pourquoi je n'utilise pas WCF. C'est le cas d'utilisation ici - un serveur et des contrats non-WCF / IIS qui changent (et sont souvent créés également) au moment de l'exécution.


Si les contrats et les liaisons changent comment vos clients utilisent-ils votre service? Doit être difficile à localiser le service?


J'ai reçu le contrat dynamique et il est adressé en générant de manière dynamique les contrats, comme pour l'hébergement, vous pouvez vous aider à héberger le service WCF / SOAP dans votre serveur HTTP à l'aide de ServiceHost msdn.microsoft.com/en-us/library/ms730158.aspx .


J'ai fait quelque chose de similaire avec WCF où la définition du contrat était axée sur les données, mais n'a pas été soumise à modification une fois définie dans la base de données. Toujours nécessaire pour être généré au moment de l'exécution: Stackoverflow .com / questions / 8864296 / ...


Les membres du client ont-ils également été générés à partir des mêmes données (à l'heure actuelle)?



6
votes

Pour créer un WSDL Dynamiquement, vous pouvez utiliser ServicederescriptionReFlector code>

par exemple: pour la classe p> xxx pré>

Vous pouvez utiliser ce code p > xxx pré>

mais depuis que vous avez dit p>

Publication d'une WSDL générée au moment de l'exécution des définitions de la méthode de la base de données p> blockQquote>

Vous devez créer le type code> au moment de l'exécution p> xxx pré>

maintenant, vous pouvez utiliser type code> à Créez WSDL P>

StringWriter wr = new StringWriter();
var r = new System.Web.Services.Description.ServiceDescriptionReflector();
r.Reflect(type, "http://somewhere.com");
r.ServiceDescriptions[0].Write(wr);
var wsdl = wr.ToString();


1 commentaires

C'est génial - j'ai déjà eu la création de type triée, mais le ServiceDescriptionReflector était exactement ce que je cherchais. Merci!