¿WCF sube el listón o solo el nivel de complejidad? [cerrado]

Entiendo el valor del modelo de servicio / host / cliente de tres partes que ofrece WCF. Pero, ¿soy solo yo o parece que WCF tomó algo bastante directo y sencillo (el modelo ASMX) e hizo un desastre?

¿Existe una alternativa al uso de la línea de comando de SvcUtil retroceder en el tiempo para generar el proxy? Con los servicios de ASMX, se proporcionó automáticamente un arnés de prueba; ¿Existe una buena alternativa hoy con WCF?

Aprecio que las cosas de WS * estén más estrechamente integradas con WCF y espero encontrar alguna recompensa para WCF allí, pero caramba, de lo contrario estoy perplejo.

Además, el estado de los libros disponibles para WCF es, en el mejor de los casos, abismal. Juval Lowy, un excelente autor, ha escrito un buen libro de referencia de O'Reilly "Programación de servicios WCF" pero no hace mucho (para mí de todos modos) para aprender ahora a usar WCF. El precursor de ese libro (y un poco mejor organizado, pero no mucho, como tutorial) es Learning WCF de Michele Leroux Bustamante. Tiene buenos lugares, pero está desactualizado y su sitio web correspondiente ya no está.

¿Tiene buenas referencias de aprendizaje de WCF además de seguir buscando en Google el bejebus de las cosas?

Bien, aquí vamos. Primero, el libro de Michele Leroux Bustamante se ha actualizado para VS2008. El sitio web del libro no ha desaparecido. Está activo en este momento y tiene toneladas de excelente información de WCF. En ese sitio web, proporciona un código actualizado compatible con VS2008 para todos los ejemplos de su libro. Si realiza un pedido en Amazon, obtendrá la reimpresión que se actualiza.

WCF no es solo un reemplazo de ASMX. Claro que puede (y lo hace bastante bien) reemplazar a ASMX, pero el beneficio real es que permite que sus servicios sean autohospedados. La mayor parte de la funcionalidad de WSE se ha incorporado desde el principio. El marco es altamente configurable y la capacidad de servir múltiples puntos finales a través de múltiples protocolos es asombrosa, en mi opinión.

Si bien aún puede generar clases de proxy desde la opción "Agregar referencia de servicio", no es necesario. Todo lo que realmente tiene que hacer es copiar su interfaz ServiceContract e indicarle a su código dónde encontrar el punto final para el servicio, y eso es todo. Puede llamar a métodos desde el servicio con muy poco código. Con este método, tiene un control total sobre la implementación. Independientemente del método que elija para generar una clase proxy, Michele muestra y utiliza ambos en su excelente serie de webcasts sobre el tema.

Michele tiene toneladas de material excelente y te recomiendo que consultes su (s) sitio (s) web. Aquí hay algunos enlaces que fueron increíblemente útiles para mí mientras estaba aprendiendo WCF. Espero que se dé cuenta de lo fuerte que es realmente WCF y de lo fácil que es implementarlo. La curva de aprendizaje es un poco empinada, pero las recompensas por su inversión de tiempo bien valen la pena:

• Webcasts de Michele: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• Sitio web del libro de Michele (vivo y actualizado para VS2008): http://www.thatindigogirl.com/

Te recomiendo que veas al menos uno de los webcasts de Michele. Ella es una presentadora muy efectiva y obviamente tiene un conocimiento increíble cuando se trata de WCF. Ella hace un gran trabajo desmitificando el funcionamiento interno de WCF desde cero.

Normalmente utilizo Google para encontrar mis respuestas WCF y normalmente me encuentro en los siguientes blogs:

Blogs con valiosos artículos 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 pongo la productividad y la sencillez en lo más alto de mi lista. ¿Por qué fue tan exitoso el modelo ASMX? Porque funcionó y lo hace funcionar rápido. Y con VS 2005 y .NET 2.0 wsdl.exe estaba arrojando servicios bastante buenos y compatibles.

En la vida real, debería tener muy pocos protocolos de comunicación en su arquitectura. Esto lo mantiene simple y fácil de mantener. Si necesita acceder a sistemas heredados, escriba adaptadores específicos para ellos para que puedan seguir el juego en el bonito y brillante mundo SOA.

WCF es mucho más poderoso que ASMX y lo extiende de varias maneras. ASMX está limitado 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 los servicios que deben ser interoperables). WCF también es más fácil de ampliar. Al menos, es posible extenderlo de manera que ASMX no se pueda extender. "Fácil" puede ser estirarlo. =)

La funcionalidad adicional ofrecida por WCF supera con creces la complejidad que agrega, en mi opinión. También siento que el modelo de programación es más sencillo. Los DataContracts son mucho más agradables que tener que serializar utilizando la serialización XML con propiedades públicas para todo, por ejemplo. También es de naturaleza mucho más declarativa, lo 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 veo que se mencione con suficiente frecuencia, pero aún puede 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 separados de datos, servicios y operaciones contribuye en gran medida a que WCF sea más manejable para mí.

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

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

Confesaré que tengo otros problemas con WCF (por ejemplo, reescribir las firmas de métodos al exponer un servicio sobre basicHTTP; consulte aquí , pero en general creo que es una mejora definitiva

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 sobre WCF fueron exactamente los mismos! Aquí tienes algunas soluciones:

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

WCF es un reemplazo para todas las tecnologías de servicios web anteriores de Microsoft. También hace mucho más de lo que tradicionalmente se considera "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 cosas en WCF que a través de ASMX tradicional porque WCF está diseñado, desde cero, para resumir todas las diferentes infraestructuras de programación distribuida que ofrece Microsoft. Un punto final en WCF se puede comunicar con la misma facilidad a través de SOAP / XML que a través de TCP / binario 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 transferir o cambiar las necesidades comerciales, los objetivos, etc.

ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Básicamente, puede ver que WCF trata de agrupar lógicamente todas las diferentes formas de hacer que dos aplicaciones se comuniquen en el mundo de Microsoft; ASMX fue solo una de estas muchas formas y, por lo tanto, ahora se agrupa 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 se pueden alojar en diferentes tipos de aplicaciones. Los escenarios comunes para hospedar servicios WCF son IIS, WAS, autohospedaje, servicio administrado de Windows.

La principal diferencia es que los servicios web utilizan XmlSerializer. Pero WCF usa DataContractSerializer, que es mejor en rendimiento en comparación con XmlSerializer.

En qué escenarios se debe usar WCF

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

Características de WCF

• Orientación al servicio
• Interoperabilidad
• Patrones de mensajes múltiples
• Metadatos de servicio
• Contratos de datos
• Seguridad
• Múltiples transportes y codificaciones
• Mensajes confiables y en cola
• Mensajes duraderos
• Actas
• Soporte AJAX y REST
• Extensibilidad

fuente: fuente principal de texto

MSDN? Por lo general, lo hago bastante bien con la referencia de la biblioteca en sí, y generalmente espero encontrar artículos valiosos allí.

En cuanto a lo que ofrece, creo que la respuesta es compatibilidad. Los servicios de ASMX fueron bastante Microsofty. Por no decir que no intentaron ser compatibles con otros consumidores; pero el modelo no se diseñó para adaptarse a muchas cosas además de las páginas web ASP.NET y algunos otros consumidores personalizados de Microsoft. Mientras que WCF, debido a su arquitectura, permite que su servicio tenga puntos finales basados ​​en estándares muy abiertos, por ejemplo, REST, JSON, etc. además del SOAP habitual. A otras personas probablemente les resultará mucho más fácil consumir su servicio WCF que su servicio ASMX.

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

WCF no debe considerarse un reemplazo de ASMX. A juzgar por cómo está posicionado y cómo lo utiliza internamente 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 notificaciones asincrónicas de servidor a cliente (imposible con HTTP puro) y, en tercer lugar, abstraer el protocolo de transporte subyacente de la mensajería XML y, por lo tanto, admitir de forma elegante HTTP, HTTPS, TCP y otros. La compatibilidad con versiones anteriores de los servicios web de "1ª generación" también es una ventaja. WCF usa el estándar XML como formato de representación interna. Esto podría percibirse como una ventaja o una desventaja, especialmente con la creciente popularidad de las "alternativas sin grasa a XML" como JSON.

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

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

Encuentro que es un dolor; ya que tengo .NET en ambos extremos, tengo los mismos dlls de "contrato" cargados en ambos extremos, etc. Pero luego tengo que jugar con muchos detalles como los atributos "KnownType".

WCF también tiene como valor predeterminado que solo permita que 1 o 2 clientes se conecten a un servicio hasta que cambie gran parte de la 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 muy difícil fusionar nuestros cambios con cualquier cambio que un cliente haya realizado en el momento de una actualización (tampoco queremos clientes jugando con la configuración de WCF!)

La comunicación remota de .NET tendía a funcionar la mayor parte del tiempo.

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

(Las pocas veces que hemos usado WCF para hablar con un sistema Java, descubrimos que el XSD que el sistema Java proporcionó no coincidía con el XML que quería de todos modos, por lo que tuvimos que codificar manualmente muchas de las asignaciones XML).