WCF: ¡WTF! ¿WCF eleva el listón o solo el nivel de complejidad?

Normalmente uso Google para encontrar mis respuestas de WCF y comúnmente me encuentro en los siguientes blogs:

Blogs con valiosos artículos de WCF

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

Otros artículos valiosos que he encontrado

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

Estoy teniendo dificultades para ver cuándo debería o usaría WCF. ¿Por qué? Porque puse productividad y simplicidad en la parte superior de mi lista. Por qué el modelo ASMX fue tan exitoso, porque funcionó, y se consigue que funcione rápido. Y con VS 2005 y. NET 2.0 wsdl.exe estaba escupiendo servicios bastante agradables y obedientes.

En la vida real deberías tener muy pocos protocolos de comunicación en tu arquitectura. Esto lo mantiene simple y mantenible. Si necesita acceder a sistemas heredados, escriba datos específicos adaptadores para ellos para que puedan jugar en el bonito y hermoso mundo SOA.

WCF es mucho más potente que ASMX y lo extiende de varias maneras. ASMX se limita solo a HTTP, mientras que WCF puede usar varios protocolos para su comunicación (concedido, HTTP sigue siendo la forma en que la mayoría de la gente lo usará, al menos para servicios que necesitan ser interoperables). WCF también es más fácil de extender. Al menos, es posible extenderlo de maneras que ASMX no puede ser extendido. "Fácil" puede ser estirarlo. =)

La funcionalidad adicional ofrecida por WCF supera con creces la complejidad que añade, en mi opinión. También siento que el modelo de programación es más fácil. Los DataContracts son mucho más agradables que tener que serializar usando serialización XML con propiedades públicas para todo, por ejemplo. También es mucho más declarativo en la naturaleza, que también es agradable.

Espera.... ¿alguna vez usaste.NET Remoting, porque eso es lo real que está reemplazando? . NET Remoting es bastante complicado en sí mismo. Encuentro WCF más fácil y mejor diseñado.

No lo veo mencionado lo suficiente, pero puede todavía implementar servicios bastante simples con WCF, muy similares a los servicios ASMX. Por ejemplo:

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

Todavía tienes que registrar el punto final en tu web.config, pero eso no es tan malo.

Eliminar la verbosidad de los contratos de datos, servicios y operaciones separados ayuda mucho a hacer que WCF sea más manejable para mí.

VS2008 incluye el elemento de menú contextual "Agregar referencia de servicio" que creará el proxy detrás de escena.

Como se mencionó anteriormente, WCF no está pensado únicamente como un reemplazo para los tipos de servicios web ASMX, sino para proporcionar una metodología consistente, segura y escalable para todos los servicios interoperables, ya sea a través de HTTP, tcp, tuberías con nombre o transportes MSMQ.

Confesaré que tengo otros problemas con WCF (por ejemplo, reescribir firmas de métodos cuando exponiendo un servicio sobre basicHttp-ver aquí , pero en general creo que es un imrovement definido

Si está usando VS2008 y crea un proyecto WCF, automáticamente obtiene un arnés de prueba cuando presiona ejecutar/depurar y puede agregar una referencia sin tener que usar svcutil.

Mis pensamientos iniciales de WCF fueron exactamente los mismos! Aquí hay algunas soluciones:

1. Programe su propia capa proxy/cliente utilizando genéricos (consulte classes ClientBase, Binding). He encontrado esto fácil de trabajar, pero difícil de perfeccionar.
2. Usar una implementación de terceros de 1 (SoftwareIsHardwork es mi favorito actual)

WCF es un reemplazo para todas las tecnologías anteriores web service de Microsoft. También hace mucho más que lo que tradicionalmente se considera como "servicios web".

Los "servicios web" de WCF son parte de un espectro mucho más amplio de comunicación remota habilitada a través de WCF. Obtendrá un grado mucho mayor de flexibilidad y portabilidad haciendo las cosas en WCF que a través de ASMX tradicional porque WCF está diseñado, desde cero, para resumir todos los diferentes infraestructuras de programación distribuidas ofrecidas por Microsoft. Un endpoint en WCF se puede comunicar con la misma facilidad a través de SOAP / XML que a través de TCP / binary y cambiar este medio es simplemente un mod de archivo de configuración. En teoría, esto reduce la cantidad de código nuevo necesario al portar o cambiar las necesidades del negocio, los objetivos, etc.

ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Básicamente se puede ver WCF como tratando de agrupar lógicamente todas las diferentes formas de conseguir dos aplicaciones para comunicarse en el mundo de Microsoft; ASMX fue solo una de estas muchas formas y ahora está agrupada bajo el paraguas de capacidades de WCF.

Solo se puede acceder a los servicios web a través de HTTP y funciona en un entorno sin estado, donde WCF es flexible porque sus servicios pueden hospedarse en diferentes tipos de aplicaciones. Los escenarios comunes para el alojamiento de servicios WCF son IIS, WAS, Auto-alojamiento, Servicio de Windows Administrado.

La principal diferencia es que los Servicios Web utilizan XmlSerializer. Pero WCF Utiliza DataContractSerializer que es mejor rendimiento en comparación con XmlSerializer.

En qué escenarios debe utilizarse el Fondo de operaciones

• Un servicio seguro para procesar transacciones comerciales. Un servicio que
• suministra datos actuales a otros, como un informe de tráfico u otro
• servicio de monitoreo. Un servicio de chat que permite a dos personas
• comunicar o intercambiar datos en tiempo real. Una aplicación de dashboard
• que sondea uno o más servicios para obtener datos y los presenta en un lógico
• presentación. Exponer un flujo de trabajo implementado usando Windows Workflow
• Foundation como servicio WCF. Una aplicación de Silverlight para sondear a
• servicio para las últimas fuentes de datos.

Características de WCF

• Orientación al servicio
• Interoperabilidad
• Patrones de Mensajes Múltiples
• Metadatos del servicio
• Contratos de datos
• Seguridad
• Transportes múltiples y Codificaciones
• Mensajes fiables y en cola
• Mensajes duraderos
• Transacciones
• Soporte AJAX y REST
• Extensibilidad

Fuente: fuente principal del texto

MSDN? Por lo general, me va bastante bien con la referencia de la Biblioteca en sí, y por lo general espero encontrar artículos valiosos allí.

En términos de lo que ofrece, creo que la respuesta es la compatibilidad. Los servicios ASMX eran bastante Microsofty. Por no decir que no intentaran ser compatibles con otros consumidores; pero el modelo no se hizo para encajar mucho además ASP.NET páginas web y algunos otros consumidores personalizados de Microsoft. Mientras que WCF, debido a su arquitectura, permite que su servicio tenga endpoints basados en open estándares muy abiertos, por ejemplo REST, JSON, etc. además del JABÓN habitual. Otras personas probablemente tendrán una mucho más fácil consume mucho tiempo su servicio WCF que su ASMX one.

(Todo esto se deduce básicamente de la lectura comparativa de MSDN, por lo que alguien que sabe más debería sentirse libre de corregirme.)

WCF no debe ser considerado como un reemplazo para ASMX. A juzgar por cómo se posiciona y cómo está siendo utilizado internamente por Microsoft, es realmente una pieza de arquitectura fundamental que se utiliza para cualquier tipo de comunicación transfronteriza.

Creo que WCF realmente avanza en la implementación de servicios web ASMX de muchas maneras. En primer lugar, proporciona un modelo de objetos en capas muy agradable que ayuda a ocultar la complejidad intrínseca de las aplicaciones distribuidas. En segundo lugar, puede tener más que patrones de mensajería de repetición de solicitudes, incluidas las notificaciones asíncronas del servidor al cliente (imposible con HTTP puro), y en tercer lugar abstraer el protocolo de transporte subyacente de la mensajería XML y, por lo tanto, soportar elegantemente HTTP, HTTPS, TCP y otros. La compatibilidad con versiones anteriores de los servicios web de" 1-st generation " también es una ventaja. WCF utiliza XML standard como formato de representación interno. Esto podría ser percibido como ventaja o desventaja, especialmente con la creciente popularidad de "alternativas libres de grasa a XML" como JSON.

Las cosas difíciles que encuentro con WCF es administrar las configuraciones para clientes y servidores, y solucionar los problemas de las excepciones de estado con fallas no tan agradables.

Sería genial si alguien tuviera atajos o consejos para ellos.

Me parece que es un dolor; en que tengo. NET en ambos extremos, tienen los mismos dlls" contract " cargados en ambos extremos, etc. Pero luego tengo que meterme con muchos detalles como atributos "KnownType".

WCF también permite por defecto que solo 1 o 2 clientes se conecten a un servicio hasta que cambie mucha configuración. Cambiar la configuración del código no es fácil, enviar muchos archivos comfig no es una opción, ya que es demasiado difícil combinar nuestros cambios en cualquier cambio que un cliente pueda haber hecho en el momento de una actualización (¡tampoco queremos que los clientes jueguen con la configuración de WCF!)

. NET remoting tendía a funcionar la mayor parte del tiempo.

Creo que intentar pretender que las comunicaciones basadas en objetos de.NET a. NET son lo mismo que enviar bits de texto (xml) a un sistema desconocido, fue un paso demasiado lejos.

(Las pocas veces que hemos utilizado WCF para hablar con un sistema Java, encontramos que el XSD que el sistema java dio no coincidía con el XML que quería de todos modos, por lo que tuvo que codifica a mano muchas de las asignaciones XML.)