Múltiples servicios WCF que hacen referencia a los mismos contratos de datos

Question

Estoy creando un conjunto de servicios WCF que comparten contratos de datos comunes (o entidades, si lo prefiere). Estos son objetos simples de transferencia de datos que están decorados con atributos DataContract y DataMember. Estoy especificando el nombre y el espacio de nombres. Al tratar de seguir los principios de la recomendación de IDesign de promediar 12 miembros por contrato de servicio, estoy dividiendo mi proyecto de servicio en múltiples servicios.

Mis contratos de datos se encuentran en un conjunto separado que puedo proporcionar a nuestros clientes si están usando .Net. Pueden indicar su referencia de servicio a los tipos de reutilización en los ensamblados a los que se hace referencia. Sin embargo, si no están usando .net y usan 2 servicios que usan la misma entidad, supongo que obtendrán un mensaje de referencia ambiguo. Puedo ver esto en Visual Studio si no hago referencia al dll de contrato de datos.

Mi pregunta es, ¿hay algo que pueda hacer en mis servicios, o que puedan hacer en una aplicación cliente para evitar tener que calificar de qué proxy proviene el contrato de datos?

Answer 1

También tiendo a mantener todos mis contratos de datos en un ensamblaje al que hacen referencia múltiples servicios y numerosas aplicaciones cliente, que funciona muy bien pero nunca he intentado consumir el servicio fuera de .NET.

¿Podría ser útil saber qué tecnología están utilizando para consumir el servicio que no sea .NET? ¿Qué está arrojando el ambiguo mensaje de referencia?

Answer 2

Tengo varios servicios que comparten objetos en mi extremo. No estoy seguro de por qué estás teniendo este problema. En mi caso, puedo acceder a los objetos de esta manera. . . .

cliente SERVICE1 = new SERVICE1()

client.CommonLibrary.Address. . .

service2 client2 = new service2()

client2.CommonLibrary.Address. . . .

Answer 3

Depende de qué herramientas estén utilizando en el lado del cliente. Por ejemplo, con Axis2 para Java, la herramienta wsdl2java puede compartir tipos utilizando el modificador -u.

how can I share proxy objects across multiple Axis2 web service clients?

Answer 4

Desde mi entender y trabajar con WCF, ya sea uno de los contrato de datos utilizado por la aplicación cliente no importa siempre y cuando el nombre completo es el mismo y tiene los mismos miembros de datos. Internamente, solo crea el objeto dinámicamente y reasigna esas propiedades de miembro de datos usando el setter público.

Un mejor enfoque Creo que es para refactorizar su contrato de datos para que ponga todo en común en más de un servicio en un ensamble y se refiera a ellos, por lo tanto no tendrá problemas ambiguos o conflictivos, independientemente de cuántos servicios sean utilizado por la aplicación del cliente.

Answer 5

Buen artículo que describe cómo resolver este problema. Sharing DataContracts between WCF Services

Answer 6

Generamos nuestros proxies de servicio no a través del asistente de Visual Studio sino mediante archivos por lotes personalizados que llaman a slsvcutil.exe (como usamos Silverlight).No se puede especificar una asignación de espacio de nombres utilizando el parámetro/n de esta manera:

"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^ 
http://ServiceUrl/MyService.svc^ 
**/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^** 
/n:*,CLR.Namepsace.MyService^ 
/r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^ 
/ct:System.Collections.ObjectModel.ObservableCollection`1^ 
/edb^ 

Así que todos los contratos de datos con el espacio de nombres http://youruri.org/CustomerService/DataContracts se generan a la CLR.Namespace.CustomerService CLR espacio de nombres en el archivo de proxy y así sucesivamente. Dado que ha generado este proxy por adelantado en el mismo ensamblado de proxy, puede cortar todo el espacio de nombres de su segundo archivo y todo funciona bien: escribimos una pequeña herramienta para el último paso. Todos los demás espacios de nombres de contrato se generarán en CLR.Namepsace.MyService namspace (vea el asterisco que significa "capturar todo")

El proceso requiere cierta preparación, ya que debe crear manualmente los archivos por lotes, pero una vez hecho esto funciona bien.