Tengo una biblioteca existente escrita en C# que envuelve una API de TCP/IP de nivel mucho más bajo y expone los mensajes que vienen del servidor desde un servidor (protocolo binario patentado) como eventos .NET. También proporciono llamadas de método sobre un objeto que maneja las complejidades de ordenar tipos .NET convenientes (como System.DateTime) hasta las codificaciones binarias y las estructuras de longitud fija que requiere la API (para los mensajes salientes al servidor). Existe un buen número de aplicaciones existentes (tanto internamente como utilizadas por terceros) creadas sobre esta biblioteca .NET.¿Alguna mejor opción que transferir desde C# a Java?
Recientemente, alguien que no quiere hacer todo el trabajo de abstracción del TCP/IP, nos ha abordado, pero su entorno no es estrictamente Windows (supongo * nix, pero no estoy 100% seguro), y han insinuado que su ideal sería algo invocable de Java.
¿Cuál es la mejor manera de mantener a sus necesidades, sin tener que:
- Puerto del código de Java ahora (incluyendo un archivo DLL no administrado que actualmente P/Invoke en la descompresión)
- Tener a mantener dos bases de código separadas yendo hacia adelante (es decir, hacer las mismas correcciones de errores y mejoras de características dos veces)
Una cosa que he considerado es volver a escribir la mayor parte de la funcionalidad central de TCP/IP en algo más multiplataforma (C/C++) y el n cambiar mi biblioteca .NET para que sea una capa delgada encima de esto (¿P/Invocar?), y luego también escribir una capa Java delgada similar sobre la misma (¿JNI?).
Pros:
- Yo sobre todo pasar mi tiempo escribiendo cosas sólo una vez.
Contras:
- mayor parte del código no administrado sería ahora - no es el fin del mundo, pero no es ideal desde el punto de vista de la productividad (para mí).
- más largo tiempo de desarrollo (no puede puerto de código C# sockets en C/C++ tan pronto como se acaba de migración a Java) [¿Qué tan cierto es esto?]
- En este punto, la API subyacente es sobre todo envuelto y la biblioteca es muy estable, por lo que probablemente no haya muchos desarrollos nuevos; puede que no sea tan malo simplemente transferir el código actual a Java y luego tener que corregir errores ocasionalmente o exponer nuevos campos dos veces en el futuro.
- Posible inestabilidad para mis aplicaciones cliente existentes mientras la versión en la que se ejecutan cambia drásticamente debajo de ellas. (Por encima de mi cabeza puedo pensar en problemas de 32/64 bits, problemas de endianness y errores generales que pueden surgir durante el puerto, etc.)
Otra opción que he considerado brevemente es de alguna manera manipular Mono hasta Java, para que pueda aprovechar todo el código C existente que ya tengo. Sin embargo, no estoy muy al tanto de cuán suave será la experiencia del desarrollador para los desarrolladores de Java que la tengan que consumir. Estoy bastante seguro de que la mayor parte del código debería ejecutarse sin problemas bajo Mono (bar la P/Invoke de descompresión que de todos modos debería portarse a C#).
Lo ideal sería que no quisiera agregar otra capa de TCP/IP, tuberías, etc. entre mi código y la aplicación cliente de Java si puedo ayudarlo (así que WCF a Java-side WS-DeathStar probablemente esté fuera) .Nunca he hecho ningún desarrollo serio con Java, pero me enorgullece el hecho de que la biblioteca es actualmente un pedazo de pastel para que un desarrollador externo se integre en su aplicación (siempre y cuando ejecute .NET por supuesto:)), y me gustaría poder mantener la misma facilidad de uso para cualquier desarrollador de Java que quiera la misma experiencia.
Así que si alguien tiene opiniones sobre las 3 opciones que he propuesto (puerto a Java & mantener dos veces, portar a C y escribir enlaces delgados para .NET y Java o, intente e integrar Java y Mono), o cualquier otras sugerencias Me encantaría escucharlos.
Gracias
Editar: Después de hablar directamente con el desarrollador en el cliente (es decir, la eliminación del teléfono roto También conocido como departamento de ventas) los requisitos han cambiado lo suficiente que esta cuestión ya no se aplica muy bien a mi situación inmediata. Sin embargo, dejaré la pregunta abierta con la esperanza de que podamos generar algunas más buenas sugerencias.
En mi caso particular, el cliente realmente ejecuta máquinas con Windows además de Solaris (¿quién no en estos días?) Y está feliz de que podamos escribir una aplicación (Servicio de Windows) en la parte superior de la biblioteca y proporcionar API TCP/IP más simple y más pequeña para que puedan codificar. Traduciremos sus mensajes simples en el formato que entiende el sistema downstream, y traduciremos las respuestas recibidas para que puedan consumir, de modo que puedan continuar interactuando con este sistema downstream a través de su aplicación Java.
Volviendo al escenario original después de pensar en esto por un par de semanas, yo tengo unas cuantas más comentarios:
Una biblioteca portátil basado en C con diferentes enlaces de lenguaje en la parte superior sería probablemente el camino a seguir si sabías desde el principio que necesitarías soportar múltiples idiomas/plataformas.
En * nix, puede un solo host proceso tanto un tiempo de ejecución de Java y un tiempo de ejecución Mono al mismo tiempo? Sé que en versiones anteriores de .NET no podía tener dos tiempos de ejecución de .NET diferentes en el mismo proceso, pero creo que lo arreglaron con .NET 4. Si esto es posible, ¿cómo se podría comunicar uno entre los dos? Idealmente, desearía algo tan simple como una llamada a un método estático y un delegado para generar respuestas.
Si no hay soporte para la interfaz directa entre Java fácil & Mono (métodos & delegados, etc.), se podría considerar el uso de algo así como ZeroMQ con Protocol Buffers o Apache Thrift como el formato de mensaje. Esto funcionaría en proceso, entre procesos y en la red debido al soporte de ZeroMQ para diferentes transportes.
He marcado su respuesta como correcta, porque mis requisitos terminaron cambiando. Sin embargo, no estoy muy satisfecho con esto, aún puede haber escenarios en los que se requiera este tipo de interoperabilidad después de un exhaustivo análisis de requisitos, por lo que aún espero que se presente una mejor respuesta. –
la respuesta corta: no, no creo que haya mejores opciones que la portación de C# a Java :) pero esa puede no ser una solución adecuada dado lo que el cliente necesita para el código, cuánto está dispuesto a pagar, etc. . –