Solicitud patrón/respuesta en la implementación de SOA

Question

En algunos proyectos de empresa-como (.NET, WCF) vi que todos los contratos de servicios aceptan un solo parámetro Request y siempre vuelven Response:

[DataContract] 
public class CustomerRequest : RequestBase { 
     [DataMember] 
     public long Id { get; set; } 
} 

[DataContract] 
public class CustomerResponse : ResponseBase { 
     [DataMember] 
     public CustomerInfo Customer { get; set; } 
} 

donde RequestBase/ResponseBase contienen material común como ErrorCode, Context, etc. Los cuerpos de ambos métodos de servicio y proxies están envueltos en try/catch, por lo que la única manera de verificar si hay errores es mirando ResponseBase.ErrorCode (que es una enumeración).

Quiero saber cómo se llama esta técnica y por qué es mejor en comparación con pasar lo que se necesita como parámetros de método y usando mecanismos estándar de paso/fallas de contexto WCF?

Answer 1

El patrón del que está hablando se basa en el desarrollo de Contract First. Sin embargo, no es necesario que use el patrón de bloque de error en WCF, aún puede devolver las "faultexceptions" al cliente, en lugar de usar el bloque Error Xml. El bloque Error se ha utilizado durante mucho tiempo y, por lo tanto, muchas personas están acostumbradas a su uso. Además, otros desarrolladores de plataforma (Java, por ejemplo) no están tan familiarizados con faultExceptions, a pesar de que es un estándar de la industria.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

El patrón de petición/respuesta es muy valioso en SOA (Service Oriented Architecture), y lo recomiendo usarlo en lugar de crear métodos que toman en los parámetros y pasar de nuevo a un valor o un objeto. Verá los beneficios cuando comience a crear sus mensajes. Como se mencionó anteriormente, evolucionaron a partir del primer desarrollo del contrato, donde uno crearía los mensajes primero usando XSD y generaría sus clases basadas en los XSD. Este proceso se usó en servicios web clásicos para garantizar que todos sus tipos de datos se serializaran correctamente en SOAP. Con la llegada de WCF, el datacontractserializer es más inteligente y sabe cómo serializar tipos que anteriormente no se serializarían correctamente (por ejemplo, ArrayLists, List, etc.).

Los beneficios del modelo de solicitud-respuesta son:

• Puede heredar la totalidad de su solicitud y las respuestas de los objetos de la base donde se puede mantener la consistencia de las propiedades comunes (bloque de error, por ejemplo).
• Los servicios web deberían, por naturaleza, requerir la menor documentación posible. Este patrón permite eso. Tomemos por ejemplo un método como public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request);. El cliente sabrá por defecto qué pasar y qué están obteniendo, también, cuando crean la solicitud, pueden ver lo que se requiere y lo que es opcional. Supongamos que esta solicitud tiene propiedades como Carriers [Flag Enum] (obligatorio), StartDate (obligatorio), EndDate (obligatorio), PriceRange (opcional), MinSeats Available (Option), etc. Obtiene el punto.
• Cuando el usuario recibió la respuesta, puede contener muchos más datos que el objeto de devolución habitual. Bloque de error, información de seguimiento, lo que sea, use su imaginación.
  En el ejemplo BusScheduleResponse, esto podría devolver varias matrices de información de programación de bus para múltiples operadores.

Espero que esto ayude.

Una palabra de advertencia. No se confunda y piense que estoy hablando de generar su propio [MessageContract] s. Sus solicitudes y respuestas son DataContracts. Solo quiero asegurarme de no estar confundiéndote. Nadie debería crear sus propios MessageContracts en WCF, a menos que tengan una buena razón para hacerlo.