"mejor" manera de comunicarse entre .NET 1.1 y .NET 3.5

Por mejor que decir:"mejor" manera de comunicarse entre .NET 1.1 y .NET 3.5

coste de desarrollo más barato (1,1 proyecto es poco probable que vivir> 6 meses)
migración más fácil de WCF o similares

Por la comunicación entre quiero decir:

la comunicación a distancia entre equipos
más probables restricciones de firewall

Con .Net 1.1 las opciones parecen ser: tomas de corriente, la comunicación remota, y varios sabores de servicio web.

La opción de usar DataTables binarios serializados sobre sockets se ha propuesto como una solución, pero desconfío de esto.

ACTUALIZACIÓN: El "Servidor" en este caso es Windows Embedded Standard con .Net 1.1. En esta etapa, no podemos agregar ningún componente nuevo a la imagen, como IIS, ASP o MSMQ, etc. Téngalo en cuenta

Fuente

2010-01-11 Schneider

Remoting está presente en 1.1 ... si WCF se basa en conceptos similares, ¿no le daría una ruta de actualización sin problemas? – Schneider

Tendría cuidado al pensar que el proyecto 1.1 desaparecería tan pronto. A veces uno piensa que algo se irá en 6 meses y luego 8 años después piensa: "Wow, todavía estamos usando eso". como puedo ver los servidores de Windows 2000 que todavía uso donde trabajo incluso en 2010. –

JB, te sigo. en este caso, los tiempos de ciclo a través de lanzamientos son bastante constantes ... solo admitimos 2 lanzamientos a la vez (antiguo + actual), el 1.1 ya ha estado en el campo durante un tiempo, por lo que la próxima versión importante entrará en la cola en desuso. – Schneider

Dado que con el tiempo migrará a WCF, le recomendamos que construya un servicio WCF inmediatamente, utilizando BasicHttpBinding, que admite los antiguos servicios web de estilo ASMX, es decir, WS-BasicProfile 1.1. Sería capaz de consumir fácilmente este servicio desde su aplicación .NET 1.1.

También puede considerar usar MsmqIntegrationBinding en WCF, donde su aplicación .NET 1.1 publicaría/recibiría mensajes del MSMQ.

Es posible que desee echa un vistazo a los siguientes artículos relacionados:

Fuente

2010-01-11 10:13:25

El "servidor" en esta instancia es la aplicación 1.1. ¿Funcionará esto al revés? Consumir el servicio web 1.1 de WCF? – Schneider

Sí, un cliente WCF que utiliza BasicHttpBinding puede consumir servicios web ASMX. Incluso el método MSMQ con el cliente que usa MsmqIntegrationBinding sigue siendo una opción. –

Desearía que la gente dejara de votar por esto;) Lo mejor que puedo resolver es que no podemos usar los servicios web en esta etapa debido a la dependencia IIS – Schneider

Los enchufes deberían ser bastante triviales. ¿Qué tipo de datos necesitas enviar? Si solo se trata de cadenas simples/otros tipos primitivos, puede obtener un diseño básico de xml y enviarlo.

Fuente

2010-01-11 09:39:56

La aplicación es esencialmente un editor de datos remoto, así que piense en datos relacionales u objetos comerciales (TBD) – Schneider

Hmm, aún así, si los datos son lo suficientemente simples, deberían funcionar. Sin embargo, podría investigar primero la opción de Mark, suponiendo que puedas hacer que los ASMX se conecten y envíen objetos reales, la vida podría ser mucho mejor. –

WebServices (basado en asmx) debe funcionar entre los dos sin problemas.

Fuente

2010-01-11 09:41:02

¿Es posible alojar un ASMX dentro de un proceso normal (no ASP.NET)? – Schneider

No. Eso no es práctico. ¿Por qué tendrías que hacer esto? –

porque el servidor es realmente un dispositivo incrustado que ejecuta un servicio que no es ASP.NET – Schneider

Usamos tanto servicios remotos como web en nuestro código para comunicar 1.1 < -> 3.5. Hemos encontrado que los servicios web son los más fáciles de transportar de 1.1 a 3.5.

Fuente

2010-01-11 09:42:31

¿Qué tan similares son las interfaces WS que 1.1 puede producir con lo que obtendrá con WCF? (¡mi 1.1 está un poco oxidado!) es decir, si la aplicación 1.1 fue eventualmente reemplazada por la 3.5 sería buena si la transición del cliente fuera bastante parecida. 1.1 no es compatible con los genéricos, por ejemplo .. – Schneider

Parece que puede crear un 1.1 WS compatible con WCF, que tal vez el camino a seguir, hasta que pueda conseguir que todos sus clientes actualicen. –

¿El costo de portabilidad de cualquiera de ellos es significativo? – Schneider

En .NET 1.1, realmente no puede tener tablas de datos serializadas binariamente. En 1.1, y de forma predeterminada en 2.0, cuando serializa un DataSet o DataTable con un BinaryFormatter, todo lo que obtiene es la serialización XML almacenada en una matriz de bytes, con la infinidad que podría esperar de todas esas etiquetas repetidas.

En .NET 2.0 y versiones posteriores, puede configurar RemotingFormat = SerializationFormat.Binary en un DataSet o DataTable para obtener verdadera serialización binaria compacta, pero no creo que sea una opción en .NET 1.1.

Fuente

2010-01-14 00:19:36

muy interesante. me da un poco de munición para derribar los sockets + conjuntos de datos binarios. gracias – Schneider

Lo creas o no, después de algunas investigaciones, Remoting en realidad parece un muy buen candidato para esto:

Da una API similar a WCF
Se nivel mucho más alto que los zócalos
Soporta múltiples "canales" (HTTP o TCP)
Es bastante fácil migrar a WCF (se necesitan cambios de código).

Por lo que yo puedo trabajar de salida Servicio Web es "demasiado duro" el 1,1 por el hecho de que requiere ASP.NET, que no tenemos + generalmente demasiado configuración.

Enchufes es un nivel demasiado bajo.

MSMQ está fuera simplemente debido a la alta barrera de entrada (similar a los Servicios Web) ... no podemos añadir nuevos componentes a nuestros compilación de Windows Embedded (la máquina 1.1) y sospecho MSMQ no viene ", como estándar".

Fuente

2010-01-14 04:52:06 Schneider

¿Ha considerado escribir un servicio WCF de estilo REST? Escribir uno en .NET 3.5 es ridículamente fácil, y consumir el servicio es igual de fácil. Este es un excelente tutorial para crear y consumir servicios REST: http://www.robbagby.com/rest/rest-in-wcf-blog-series-index/ Al hacerlo, se elimina la necesidad de configurar ASP.NET en IIS para alojar su aplicación .NET 3.5. WCF se puede alojar fácilmente en cualquier tipo de aplicación, como un servicio de Windows o una aplicación de consola o incluso la aplicación WinForms. – ajawad987

problema es que el servidor es .net 1.1 ... sin IIS disponible. Necesitamos estar alojados por nosotros mismos (como 3.5), no estamos seguros de que pueda estar en 1.1. Además, ningún WCF en 1.1 necesitaría utilizar un REST de terceros, o un REST propio ... luego comienza a sonar como demasiado trabajo – Schneider

No necesita utilizar la serialización incorporada para serializar los objetos DataTable. Una DataTable es solo un grupo de columnas y filas. Simplemente debe recorrer las filas de la tabla y serializar cada una.

Dependiendo de sus compensaciones, puede copiar el DataTable en un Objeto de Transferencia de Datos equivalente, luego binaria serializar ese objeto. Tal objeto consistiría en una matriz de objetos que reflejan la estructura del DataTable. El objeto tendría una propiedad para cada columna del DataTable.

De esta manera, evitará la serialización de los metadatos de la tabla, y debería obtener una serialización binaria fácil y rápida.

Dado esto, evitaría Remoting. Es cierto que la estructura es similar a la de WCF, pero no es compatible. Ya es bastante malo que estés atascado usando casi la versión más obsoleta de .NET, realmente no quieres confiar en una tecnología que, en sí misma, es obsoleta.

Las tomas no son bonitas, pero son bien entendidas. Si tiene cuidado, creará un código de socket que es relativamente fácil de mantener, al menos durante el tiempo que deba seguir con .NET 1.1.

Es posible que desee consultar las nuevas clases agregadas en .NET 2.0 (TcpClient, por ejemplo) y crear una API similar. De esta forma, si alguna vez puede actualizar la imagen a .NET 2.0, entonces le resultará más fácil aprovechar el código que Microsoft tendrá que mantener.

Fuente

2010-01-14 05:46:40

algunos pensamientos interesantes. pero el estado de soporte de Remoting no me preocupa hasta ahora ... sí, su legado, pero todavía es compatible y ampliamente utilizado por .NET. Preferiría eso que confiar en un código de socket propio – Schneider

"mejor" manera de comunicarse entre .NET 1.1 y .NET 3.5

Respuesta

Cuestiones relacionadas