2010-08-24 15 views
6

Estoy escribiendo un software para un nuevo dispositivo de hardware al que quiero que cualquier tipo de aplicación nueva de terceros pueda acceder si así lo desean.¿Debo usar CORBA, MessagePack RPC o Thrift, o algo completamente diferente?

El software será un proceso nativo (C++) que debería poder ser consultado por juegos de terceros y aplicaciones que quieran admitir el dispositivo de hardware. Esas aplicaciones de terceros también deberían poder recibir eventos del proceso nativo, suscrito. Por lo tanto, aparte del proceso nativo, también proporcionaré bibliotecas de "conectores" a los desarrolladores de terceros, para todas las plataformas/idiomas que puedan elegir (Java, C++, Python, etc.) para incrustarlos en sus aplicaciones para que puedan conectarse fácilmente. al dispositivo sin necesidad de escribir ningún código adicional. Quiero apuntarme a todas las plataformas de SO de escritorio/laptop, y tener una idea bastante buena de las funciones que quiero exponer, pero idealmente no quiero estar demasiado atascado (es decir, quiero que sea elegantemente escalable desde el cliente y el servidor). perspectivas).

Estoy buscando la fiabilidad en el futuro, el rendimiento, la facilidad de mantenimiento en el futuro, y la flexibilidad de idiomas multiplataforma en el futuro, y la facilidad de desarrollo, en ese orden.

¿Qué debo usar?

CORBA, MessagePack-RPC, Thrift, o algo completamente distinto?

(he omitido ICE debido a su licencia)

+4

CORBA es * antiguo *. También es pesado y obsoleto. Es casi seguro que hay una mejor solución. – skaffman

+4

skaffman, los adjetivos antiguo, pesado y obsoleto no me desaniman. La cantidad de memoria por ORB es solo de unos pocos megabytes, lo que puede ser malo para los integrados, pero absolutamente perfecto para las computadoras de escritorio, y el rendimiento es rápido. Me preocupa la velocidad de rendimiento, la flexibilidad multiplataforma, la facilidad de desarrollo, la facilidad de mantenimiento y la fiabilidad en el futuro. Mientras sea el mejor en estos departamentos en general, no importa lo que los demás "piensen" al respecto, ni tampoco tiene que ser "la última moda", ganaría. Solo me pregunto si es lo mejor para lo que estoy haciendo. – Navigateur

+1

Simplemente no podemos responder a una pregunta de este tipo sin conocer sus requisitos, qué software es/hace, el público objetivo, ruta de actualización, plataformas en las que se ejecutará, etc. –

Respuesta

1

CORBA es la única cosa "RPC" gratuita que funcionaría para mi sistema en este momento, aunque escale muy mal. Thrift aún no es compatible con Windows. Ni siquiera MessagePack-RPC está disponible en todos los idiomas y sistemas operativos, a pesar de que todavía está en desarrollo. Si CORBA fuera elegantemente escalable, probablemente no se habría quedado obsoleto.

Protocolo Los búferes y la mensajería funcionarían, tendría que desarrollar una implementación tanto de cliente como de servicio para cada plataforma/idioma. También sería muy escalable. He decidido sobre esto.

+0

¿Por qué crees que CORBA "escala muy mal"? Hay muchos sistemas de gran volumen que usan CORBA en la actualidad. –

+2

Agregar una nueva propiedad, ¿se maneja de forma elegante en CORBA cuando las personas están utilizando clientes antiguos con el nuevo servidor, o nuevos clientes con una versión anterior del servidor (ambos son posibles en mi caso)? Mi impresión es que CORBA se rompe. Esto es malo, no tenía que haber sido así ... CORBA habría conquistado el mundo si se las hubiera arreglado para agregar y eliminar propiedades y funciones. La gente quiere actualizar sus arquitecturas todo el tiempo: cualquier versión, restricción y manejo requerido debe ser el trabajo del desarrollador fuera de CORBA. RPC en sí mismo debe ser 100% escalable/descartable. – Navigateur

+1

No hay muchos sistemas RPC que manejen las versiones sin problemas. Una de las razones es que incurriría en una sobrecarga excesiva en cada llamada CORBA. –

2

Si antigua y el peso pesado no te desanime, obsoleto definitivamente debe. De todos modos, puedo decirles lo que hemos estado usando Google Protocol Buffers en el trabajo recientemente, y son bastante fáciles de usar.

Desde la perspectiva del desarrollador, todo lo que necesita hacer es tener una compilación de GPB (que realmente no es tan difícil), y luego generará los archivos fuente para usted. El resultado final es una interfaz de paso de mensaje de transporte de mensaje binario multiplataforma (piense en XML y RMI limitada, no en la funcionalidad similar a MPI).

Lo usamos en Windows para hablar con un sistema Linux basado en el brazo (TS-7200 del brazo integrado) que ejecuta el mismo software. que yo sepa, es compatible con muchos idiomas.

+0

¿Es este mensaje? ¡Muy interesante! Dada la flexibilidad, ¿cómo recomendarías que use protobuf en mi situación? Sé que es "como prefiera", pero quiero que cada parte nueva de mi sistema sea compatible con versiones anteriores de todas las partes antiguas. (esto está mirando hacia el futuro, todavía no he empezado). ¿Cuál es la MEJOR manera de lograr esto? – Navigateur

+0

Si realiza una búsqueda en Google, puede encontrar cierta documentación en su repositorio, que incluye algunas prácticas recomendadas. Realmente depende de tu situación exacta. Esto no es estrictamente mensajes; es un método de serialización binaria multiplataforma/sistema cruzado. Si lo desea simplemente para la transferencia de datos, puede hacerlo. Si desea construir un marco RMI, puede hacerlo. –

4

Thrift o paquete de mensajes es la mejor opción en el futuro. Ambos son elegantes, livianos y no agregan muchas latencias a su proceso. Tienen soporte para la mayoría de los lenguajes comunes, y están en desarrollo activo. En la etapa actual, preferiría el ahorro personal, pero el paquete de mensajes parece prometer muchas funciones.

El ahorro de pensamiento podría no ser tan amigable para Windows como lo deseamos, pero la gente lo está usando en Windows. Esta es una guía básica para ahorrar en las ventanas. http://wiki.apache.org/thrift/ThriftInstallationWin32 Solo instalar y obtener el compilador Thrift puede ser problemático en Windows. El uso de los archivos generados depende del idioma que elija y muchos de los idiomas tienen una buena compatibilidad para ejecutar los archivos mediante la importación de bibliotecas de ahorro.(Java es muy fácil, MAVEN artefacto)

Hay una discusión sobre los marcos de RPC disponibles en RPC frameworks available?

CORBA según la edad me está engorroso y muy pesado.

0

Actualmente estoy usando Apache Thrift para un proyecto de Hospital Manager. Es mejor que CORBA en muchas áreas, sin mencionar que es liviano y mucho más fácil de implementar y comprender. La curva de aprendizaje para Thrift es definitivamente sutil en comparación con CORBA, pero la documentación para Thrift es lo peor.

Estoy usando un servidor Ruby Thrift al que se conectan los clientes de Obj-C y Java. El analizador de Thrift o "compilador" hace un buen trabajo generando archivos fuente para los idiomas que desee, aunque es demasiado detallado. Definitivamente buscaría implementar Thrift, o Google ProtoBuffs si estuviera comenzando un nuevo proyecto, ya que CORBA está muy desactualizado, y podría no implementar nuevas tecnologías en el futuro, sin mencionar que hay muchas vulnerabilidades y exploits que apuntan a CORBA que no lo harán. obtener un parche ya que no está en desarrollo, presentando algunos agujeros de seguridad graves en su nuevo proyecto.

Thrift admite muchos lenguajes de programación: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml y Delphi en el momento de escribir este documento. El soporte de múltiples idiomas es clave, creo, para el propósito de su proyecto.

+1

Fui con ZeroMQ al final. Quizás quieras revisarlo. Es realmente genial porque puedes hacerlo tan extensible como quieras (en términos de agregar/quitar propiedades, etc.). – Navigateur

Cuestiones relacionadas