Web Service wrapper

Question

Estoy escribiendo un dll que hace referencia a algún servicio WCF. El dll funciona como una puerta de enlace del servicio y todas las llamadas lo están pasando. Probablemente puede haber llamadas concurrentes.

He hecho referencia al servicio pero ahora no puedo decidir cómo escribir las funciones del contenedor correctamente.

¿Hay algún ejemplo o mejor práctica para esta funcionalidad?

Answer 1

Haría el envoltorio que coincida con la interfaz del servicio web. También sería una buena idea para envolver todos los objetos expuestos. Básicamente crea un proxy. Lo que encuentro realmente útil para este tipo de cosas es crear una interfaz que coincida con la API e implementarla. De esta forma, puede crear una versión ficticia de la DLL para probarla sin la sobrecarga (o los costos potenciales) asociados con la llamada WCF. También lo haría mucho más simple si necesita reemplazar la llamada WCF con un proveedor alternativo en el futuro.

Como ejemplo, supongamos que tenemos un servicio WCF a un proveedor externo para procesar un pago. Algo como esto:

void ProcessPayment(float amount); 

Podríamos enganchar esto fácilmente en nuestro código. El problema es que un simple cambio en la interfaz nos llevaría a tener que hacer cambios en cualquier lugar donde se haga referencia al código. Lo mismo sería necesario si cambiamos de proveedores a otra persona, incluso si la interfaz era casi idéntica. Agregando algo así como una interfaz simple:

interface IPaymentProvider 
{ 
    void ProcessPayment(float amount); 
} 

Desacoplaríamos por completo nuestro código del servicio WCF. Fácilmente podríamos construir una clase como esta:

class PaymentProviderAWrapper : IPaymentProvider 
{ 
    void ProcessPayment() 
    { 
     // Call the WCF service 
    } 
} 

Que podríamos cargar dinámicamente con un marco de inyección de fábrica o la dependencia como Spring.NET. El cambio a un proveedor de B sería tan simple como crear un nuevo envoltorio:

class PaymentProviderBWrapper : IPaymentProvider 
{ 
    void ProcessPayment() 
    { 
     // Call provider B's Native DLL 
    } 
} 

Cambiar su código de proveedor de A a B sería tan simple como cambiar un parámetro de configuración.

Incluso si compilamos la biblioteca directamente en nuestro código, todo lo que tendríamos que hacer es cambiar la lógica de construcción para usar la nueva biblioteca. El resto de nuestra aplicación no cambiaría en absoluto. Solo una recompilación simple.

Answer 2

En respuesta a la respuesta de Graymatter, no veo cuál es la diferencia entre llamar a un contenedor de servicios que expone las mismas llamadas y luego reenviar las llamadas al servicio real, y simplemente llamar al servicio, suponiendo un one-to- un mapeo en llamadas individuales y ningún cambio en el enlace de transporte.

La única razón por la que querría crear un contenedor en primer lugar es que la interfaz expuesta de alguna manera no cumple con sus requisitos por sí misma. Hay varias razones es posible que desee hacer esto, pero unos pocos de los más comunes:

1. traducción Protocolo - el servicio no está expuesta a través del correcto transporte de enlace para sus necesidades
2. composición de servicios - las operaciones de la interfaz son demasiado granular y no representan operaciones de nivel empresarial.
3. Autenticación: quizás requiera una capa de autenticación en la parte superior del punto final que está consumiendo.

Entonces, ¿cómo envolver el extremo de servicio depende de qué quiere envolver el servicio ...