Tengo que portar una aplicación VB 6.0 a VB.Net (Framework 3.5). La aplicación usa MSMQ en gran medida. Estoy tratando de descubrir cuáles son las ventajas de usar WCF sobre good ole System.Messaging. ¿Hay algún inconveniente potencial al usar System.Messaging?Uso de MSMQ - System.Messaging versus WCF
creo que esta cita del "Motley Queue" sitio web ("web": excelente enlace) lo resume mejor:
* El modelo de programación de WCF se centra alrededor de sus operaciones comerciales. Con él, puede dejar de administrar sus transacciones de mensajes, establecer propiedades de mensaje, buscar mensajes en una cola, verificar NACKS, reintentar mensajes, etc. En su lugar, puede comenzar a pensar en el mundo en términos de operaciones comerciales (por ejemplo, CreatePurchaseOrder) y centrarse en tu lógica de negocios. Deja el tedio a WCF. *
Eso es en pocas palabras lo que WCF intenta lograr, lo libera de una gran cantidad de plomería e intriga y le permite concentrarse en los problemas de su negocio que desea resolver.
¡Mi voto es para WCF! :-)
Marc
Ir con WCF le da un camino claro. Aunque dudo que System.Messaging vaya a ninguna parte (consulte System.Runtime.Remoting), se producirá un nuevo desarrollo en WCF y le dará la oportunidad de migrar a otras tecnologías a medida que surjan. Le libera de estar atado a la implementación de transporte específico.
El modelo de programación WCF también es muy limpio y agradable.
Deberías echarle un vistazo al Motley Queue website. Hay una buena comparación en System.Messaging vs WCF. WCF va a ser mucho más limpio y fácil de usar.
No estoy de acuerdo si WCF es más fácil/más limpio que System.Messaging, que, admitámoslo, tiene una API bastante simple (en general) y es relativamente simple de usar, si eso es todo lo que te importa. Sin embargo, WCF tiene algunas cosas buenas, pero no es simple de ninguna manera.
En cuanto a si encuentra algún problema, bueno ... eso depende en gran medida de cómo su aplicación VB está utilizando actualmente MSMQ y qué tipo de datos está enviando. Utilizará el enlace MsmqIntegrationBinding, lo que ayuda un poco, pero es posible que tenga que recurrir a algunos trucos para manejar la deserialización de mensajes de forma exitosa si su aplicación VB no envía mensajes en un formato que WCF puede usar de manera inmediata.
Personalmente amo MSMQ, y me gustaría ir con eso.
El principal 'gotcha' para mí, era que estás limitado a 4 megas por mensaje. Si está serializando un gráfico de objeto grande, es un problema, pero trivial de arreglar con solo serializar primero en el disco y enviar el nombre de archivo.
MSMQ puede no obtener "nuevas características", como uno de los otros carteles comentó, pero en mi humilde opinión, es estable, muy escalable, y tiene todas las características que necesito tal cual.
WCF con MSMQ mediante la unión Net.Msmq resuelve un montón de complejidades debajo de la cual no necesita preocuparse por.
-Es más fácil de implementar (solo se requiere una configuración de tiempo). Siga esta publicación para comprender el proceso de configuración de WCF & MSMQ usando Net.Msmq vinculante Setup MSMQ with WCF using Net.Msmq binding
-Las colas de Reintentos y Poison se pueden implementar haciendo solo algunos cambios en la configuración. Buen artículo para configurar el reintentos y las colas de envenenamiento Poison and Retry message handling with MSMQ using WCF Net.Msmq binding
-En caso de que tenga varios suscriptores del servicio, el mismo servicio se puede alojar en varios protocolos. es decir, crear múltiples puntos finales para http, net.Msmq.
Revisé el [System.Runtime.Remoting summary en MSDN] (http://msdn.microsoft.com/en-us/library/system.runtime.remoting (v = VS.100) .aspx), pero No veo ninguna referencia a System.Messaging. ¿Podría ser más específico sobre lo que quería que viéramos en Remoting? –
System.Messaging no va a desaparecer, al igual que System.Remoting no va a desaparecer. Ambas son tecnologías bastante bien arraigadas, así que espere un montón de advertencia antes de que desaparezcan. – Mark