¿Cómo genero código a partir del WSDL de ESRI GPServer?

Question

Estoy tratando de usar svcutil para generar código a partir de este wsdl de GPServer.

Entonces corro este comando:

svcutil GPServer.wsdl

Lo cual genera ESRI_Currents_World_GPServer.cs.

El código tiene comentarios que dicen que el generador de código "requiere información de esquema adicional", ¿hay algún otro archivo que pueda pasar a svcutil que tenga esta información adicional?

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://www.esri.com/schemas/ArcGIS/9.3", ConfigurationName="GPServerPort")]
public interface GPServerPort
{

    // CODEGEN: Parameter 'Result' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlArrayAttribute'.
    [System.ServiceModel.OperationContractAttribute(Action="", ReplyAction="*")]
    [System.ServiceModel.XmlSerializerFormatAttribute()]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(Patch))]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(Field[]))]
    [return: System.ServiceModel.MessageParameterAttribute(Name="Result")]
    GetJobInputValuesResponse GetJobInputValues(GetJobInputValuesRequest request);

Obtengo los mismos resultados con

svcutil GPServer.wsdl /ser:XmlSerializer

Me gustaría implementar la interfaz en un servicio web y hacer que aparezca para los clientes (como arcmap) como si fuera un servidor de arcgis. ¿Alguien ha hecho esto?

Actualización: Este artículo aborda el problema, pero la solución es cambiar su WSDL para que sea compatible con svcutil. ¿Puedo hacer eso?

Actualización 2 Parece que lo que estoy intentando hacer se llama "diseño basado en WSDL". Aquí hay una buena discusión. Esta descripción podría aplicarse tanto a ArcGIS desktop como a Microsoft office:

Y puede ser contra intuitivo para algunas personas. La aplicación cliente, en este caso, Microsoft Office, especifica el contrato en cable, el WSDL. Muchas personas tienen una perspectiva de diseño centrada en el servidor y asumen que el servidor define el contrato. Eso a menudo tiene sentido, pero no en este caso. Dado que hay tantas implementaciones de Microsoft Office por ahí, tiene sentido que el cliente defina el contrato.

Actualización 3 (Resumen simplificado) La API REST de Esri es abierta, pero incompleta. Algunas características admitidas por SOAP no son soportadas por REST, como cancelar un trabajo de GP. Dado que el WSDL es público, debería ser posible escribir un servicio de mapas que implemente tanto la API SOAP como la REST. ¿Alguien conoce alguna herramienta que me ayude a implementar un servicio de mapas que cumpla con el contrato SOAP de Esri?

Answer 1

Solo por diversión, intenté usar Storm que de alguna manera logra generar código y ejecutarlo contra ese WSDL. Así que esto se convierte en algo así como una buena noticia, mala noticia.

• Buena noticia: es posible generar código .NET a partir de ese WSDL que funcione
• Buena noticia: alguien más ha descubierto cómo hacerlo
• Buena noticia: es de código abierto, por lo que puedes ver cómo lo hicieron
• Mala noticia: utilizaron F#, que solo entiendo ligeramente