Contract-First SOA con WCF

Question

Esta pregunta es más una investigación para descubrir qué están haciendo las personas en la comunidad, en situaciones prácticas, que una pregunta específica. He buscado bastante sobre esto, y aunque he encontrado muchos blogueros que abogan por el diseño del servicio por contrato y algunos comentarios que los respaldan, todavía tengo que encontrar mucha información práctica sobre la implementación del contrato con WCF, los pros y los contras de hacerlo en un entorno del mundo real, etc. Recientemente he realizado una investigación exhaustiva sobre SOA, principalmente a través de los libros de Thomas Erl, y uno de los conceptos principales que defiende es el diseño de contrato primero.

Mis preguntas son las siguientes:

1. ¿Cómo aborda el diseño del servicio de primer contrato con .NET y WCF?
2. ¿Hay otras herramientas además de svcutil que puedan generar tanto el cliente como el servicio a partir del contrato? (Cualquier cosa que se integre con VS sería ideal)
3. ¿Qué profesionales del mundo real ha encontrado con el diseño de primer contrato y wCF?
4. ¿Qué inconvenientes del mundo real ha encontrado con el diseño de primer contrato y WCF?

Uno de los principales problemas con el desarrollo de contrato primero parece ser el de herramientas. Svcutil es lo único que he encontrado que puede generar código de servicio a partir de un contrato, y tiene un resultado bastante pobre. Su archivo único, repleto de atributos y artefactos de generación de código, y básicamente necesita ser regenerado y reemplazado cada vez que se actualiza el contrato. Preferiría un mejor enfoque, preferiblemente algo que no requiera reemplazo de regeneración. Estoy de acuerdo con crear manualmente el contrato del lado del servicio, incluso, suponiendo que sea práctico en un escenario del mundo real.

EDITAR:

Mientras que WCSF resolvió mis necesidades inmediatas, aprendí sobre Protocol Buffers y Service Factory son herramientas interesantes que estoy seguro de que me ayudarán en el futuro.

Answer 1

WSCF proporciona una herramienta de contrato primero con integración VS. Echale un vistazo. (gratis)

A partir del 6 de julio, hay una versión binaria con un programa de instalación.

Answer 2

Utilizo un enfoque de contrato primero, generalmente (pero no siempre) usando la misma representación de tipo en cada extremo.

En realidad, para usar WCF no necesita ningún proxy especial, etc. puede usar sus tipos .NET normales en ambos extremos y no usar svcutil.exe en absoluto . Obtener un servicio de trabajo es tan simple como agregar & Quot; ABC & Quot; en el archivo de configuración y usando algo como:

public sealed class WcfClient<T> : System.ServiceModel.ClientBase<T>
    where T : class
{
    public T Service { get { return base.Channel; } }
}

Ahora puedes usar:

using(var client = new WcfClient<IMyService>()) {
    int i = client.Service.SomeMethod("abc");
}

y todo lo que tiene en el cliente (y servidor) es su interfaz IMyService.

---

Para otras herramientas; protobuf-net es una implementación del " protocolo de búferes " de Google; API, que tiene un DSL para describir datos y servicios en un & Quot; contrato primero & Quot; (y portátil / interoperable) - por ejemplo (un archivo .proto):

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}
message SearchResponse {
  repeated string result = 1; 
}
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

La herramienta protobuf-net (que mantengo) incluye un " protogen " utilidad para transformar este DSL en C # / VB; y una de las opciones (para C #, al menos, necesitaría verificar VB) es emitir una implementación de proxy WCF completa (con su elección de métodos de sincronización o asíncrona); muy similar a svcutil, pero (debido a la relación protobuf-net) incluye el atributo personalizado [ProtoBehavior] en los contratos de operación para que use el serializador protobuf-net en lugar de DataContractSerializer (más rápido y más eficiente, pero diferente ).

Para integración VS; Estoy trabajando exactamente en eso ( prueba ).

Answer 3

Prefiero el desarrollo por contrato primero. He utilizado el Service Factory para este propósito. Me ha permitido generar tanto el servicio como el código del cliente sin personalización.

Con la personalización , también pudimos generar objetos de transferencia de datos correspondientes a objetos de Entity Framework, junto con el código para traducir de uno a otro; registro automático de excepciones; y documentación HTML de los servicios.

Esto se suma a las reglas de análisis de código que vienen con Service Factory, que ayudan a evitar que un desarrollador se dispare en el pie al elegir opciones incompatibles de WCF.

Answer 4

En WCF, tiene cierta diversidad en cómo se ve 'contrato primero'. Puede hacer un 'contrato de código primero' donde sus contratos de datos y servicios se expresan como tipos .NET con el marcado de atributo correcto. Puede comenzar con WSDL y generar los contratos de servicio y datos, o puede comenzar con el esquema XML para su contrato de datos y expresar el contrato de servicio como código. El camino a seguir realmente depende de la naturaleza del contrato y de cómo se utilizará.

Si está implementando algo para una especificación WSDL, la generación de código de WSDL es la opción obvia, y generar de forma manual no es un gran problema. Puede activar la generación desde un evento de compilación del proyecto (o ingresar a msbuild) si desea que los cambios en el archivo WSDL se propaguen de inmediato.

Si tiene un esquema existente (XSD) que desea usar como contrato de datos, o prefiere desarrollar su contrato de datos de esa manera para una reutilización más fácil en otras plataformas, puede generar tipos de esquema usando xsd.exe ( o una alternativa de terceros). En este caso, usaría sus tipos serializables en XML en su contrato de servicio orientado a códigos como esto :.

Si está desarrollando los clientes y servidores usted mismo en .NET, y sus clientes pueden obtener sus ensambles de contratos o están contentos de generar clientes a partir de metadatos de servicio (por ejemplo, WSDL), modelar sus contratos en código es una gran experiencia. Usando & Quot; tipos conocidos & Quot; esquema, puede admitir modelos de herencia en su contrato de datos, que puede ser muy poderoso. Puede omitir la generación de código de cliente por completo (como se menciona en otras respuestas) haciendo referencia directa al ensamblaje del contrato en su cliente. Es muy productivo y elegante, pero debes ser consciente de que puedes crear desafíos de interoperabilidad si te apetece demasiado.

Answer 5

La forma en que hacemos esto se describe en este video:

http://www.dnrtv.com/default.aspx?showNum=103

La idea es que no usamos la generación de código, por lo tanto, evitamos la necesidad de regenerar el código cuando cambia el contrato.

El contrato está entonces en código y se puede cambiar, si hay una discrepancia entre el cliente y el servidor, aparecerá en un error de compilación.