Hay muchos factores involucrados en hacer su elección. Lo primero que preguntaría es, ¿qué sabes? Si la respuesta es solo "mantener el sistema heredado", en esencia, estás empezando desde cero en términos de conocimiento de las nuevas tecnologías.
En primer lugar, quiero aclarar lo que perciben como un error en su pregunta original:
Estamos pensando en Silverlight, Flex y Rubí
- Silverlight es una tecnología de cliente, básicamente un tiempo de ejecución.
- Flex es el nombre de un SDK utilizado para compilar las aplicaciones para la plataforma Flash de Adobe .
- Ruby es un lenguaje de programación .
Parece que está examinando tecnologías múltiples y extremadamente diferentes diseñadas para propósitos muy diferentes. No se compararán muy bien.
Una comparación más directa sería comparar Silverlight con Flash Player a HTML/JavaScript. O para comparar el MXML de Flex con el XAML de .NET. Ruby, hasta donde sé, se usa principalmente en el lado del servidor, a menudo con HTML y JavaScript como interfaz. Si su solución de front-end está obligada a interactuar con los servicios web .NET y ColdFusion, no estoy seguro de por qué debería incluir una tercera tecnología del lado del servidor en la mezcla.
Dicho esto, voy a recomendar el uso de Flex/The Flash Payer como su tecnología de front-end y ColdFusion como su tecnología del lado del servidor. Hay una razón por la que recomiendo esto y es porque es lo que sé. Esperemos que alguien más conocedor de .NET/Silverlight/Ruby pueda compartir los beneficios de cada uno.
voy a examinar más en sus puntos, uno por uno:
Sourced by a company or user community that is robust enough to be
alrededor de los próximos 5-7 años (estamos realistas sobre esto).
Es mi expectativa de que Silverlight, la plataforma Flash, y Ruby estarán vivos y coleando para la próxima década.
La plataforma Flash y Flex específicamente tienen una comunidad vibrante. Creo que una de las mejores cosas que Adobe hace es fomentar la comunidad de desarrollo en torno a su plataforma y herramientas.
Flex sigue siendo nuevo y está creciendo, pero ha experimentado un gran crecimiento en los últimos años. Aunque Adobe no habla mucho sobre el número de desarrolladores, la mayoría de las estimaciones lo veo entre 250K-350K, que es más del doble de lo que era hace 3 años. Hay podcasts, un montón de blogs, más marcos de los que puede sacudir un palo en (RobotLEgs es el favorito actual), toneladas de conferencias (Mi favorito es 360|Flex) y lots of open source projects.
ColdFusion es más de 10 años de edad, se encuentra actualmente en su novena versión, y tiene una enorme comunidad próspera listas de correo (como House of Fusion y los foros de Adobe), un montón de podcasts (como CFHour y cfconvesations), blogs, libros, marcos (como Fusebox, Model Glue y Mach-II), open source projects y conferences.
Algunas personas dicen que es difícil encontrar desarrolladores de ColdFusion, y eso a veces es cierto porque la comunidad es relativamente pequeña en comparación con .NET. La última vez que vi estimaciones, estaban estimando 750,000 desarrolladores en todo el mundo. Puede tener problemas similares con los desarrolladores de Flex. Pero parece que ya tienes un equipo que quieres entrenar, por lo que quizás no estés buscando nuevos empleados y eso no será un problema.
También hay muchos grupos de usuarios de Adobe en todo el mundo. Siéntase libre de pasar por uno y/o pregunte al gerente del grupo acerca de la tecnología de su elección. La mayoría de los grupos que conozco son Flex o ColdFusion.
Añadiré que ColdFusion y Flex/Flash Platform provienen de Adobe y Adobe se ha tomado grandes molestias para asegurarse de que funcionan bien juntas. Creo que su integración no tiene paralelo.
Dicho todo esto, .NET tiene una gran compañía que también lo respalda, y una base de desarrolladores más grande que ColdFusion y/o Flex. Creo que es más probable que encuentre soluciones comerciales compatibles en el mundo .NET que en el espacio Flex o ColdFusion; pero no puede hablar por experiencia personal.
No pensé que Ruby tenía una compañía detrás, pero entendí que tenía una comunidad muy vibrante. Puede usar Ruby fácilmente para construir un backend en una aplicación de plataforma Flash o una de Silverlight.
Able to quickly interface to use stored procedures from Oracle and web
servicios producidos en ASP.NET y ColdFusion como fuentes de datos.
Ha mencionado la posibilidad de reemplazar Oracle. Yo recomendaría contra esto. Parece que vas a tener mucho trabajo por hacer. Si puede salir adelante con solo cambiar una sola "capa" de su aplicación a la vez, hágalo.
ColdFusion puede acceder rápida y fácilmente a los datos en Oracle, ya sea mediante procedimientos almacenados o consultas directas. No tengo dudas de que .NET puede hacer lo mismo. [y supongo que Ruby tampoco debería tener ningún problema con eso].
Silverlight y Flash Player (Flex) están diseñados como tecnologías de front-end y no recomendaría tratar de acceder a la base de datos directamente desde ellos. La mayoría de las aplicaciones que he visto utilizan una capa de middleware (como ColdFusion o .NET) para el acceso a la base de datos, y luego Flash solo accederá a esa capa intermedia. En una arquitectura de servicio de Model View Controller, a menudo puede implementar el modelo como el almacenamiento de base de datos (Oracle), los servicios en el middleware (ColdFusion/.NET) y la vista en la tecnología de front-end (Flash Player/Flex o Silverlight o HTML/AJAX). El controlador en una aplicación Flex/Flash probablemente se crearía en Flash/Flex. Supongo que Silverlight es similar.
Al usar ColdFusion, usará cfstoredproc para acceder a procedimientos almacenados, o cfquery para ejecutar consultas directamente en la base de datos. Usted pondría esas consultas en un servicio, y luego desde Flex/Flash Player accedería a esos datos usando RemoteObjects (que es un protocolo AMF que recomiendo usar) o WebService (para llamadas SOAP) o HTTPService (Para llamadas REST) AMF es un formato binario que puede generar tiempos de transferencia de datos mucho más rápidos entre el cliente y el servidor. También traducirá automáticamente los objetos del lado del servidor a los objetos del lado del cliente y viceversa. Ese es un toque muy agradable y evita que tenga que escribir sus propias rutinas de conversión.
Deployable on virtualized clients as well as thick client
máquinas Windows y Apple.
Supongo que no estoy seguro de lo que quiere decir con clientes virtualizados frente a clientes gruesos.
Flash Player y AIR se implementan fácilmente en Windows y Mac. Adobe está haciendo un gran trabajo para prepararse para la ola de dispositivos móviles si eso es importante para usted. Incluso a pesar de los argumentos de Adobe/Apple del año pasado, Adobe tiene un paquete para implementar en los dispositivos con iOS. Está en sus primeras etapas, pero espero ver algunas actualizaciones importantes en la primera mitad de este año.
Adobe ha sido criticado por su rendimiento en Mac y hay varias razones para ello. Pero, las cosas mejoran constantemente.
Sé que Silverlight tiene soporte para Mac, pero no sé hasta qué punto. No espero ver Silverlight en dispositivos móviles más allá del sistema operativo Windows Phone.
En términos de Ruby, probablemente no desee implementar Ruby en una máquina de escritorio de ninguna forma. Sin embargo, puede crear AJAX/HTML que funcione con el navegador de su elección (y/o utilizar un marco AJAX que se ocupe de los problemas de compatibilidad del navegador). Tal como están las cosas ahora, HTML/AJAX será probablemente su mejor opción para la implementación de dispositivos móviles, ya que la mayoría de los navegadores móviles se basan en Webkit, por lo que a menudo existe un alto nivel de coherencia en la forma en que las aplicaciones HTML se ejecutan en los dispositivos. Y dicho enfoque probablemente dará un mejor rendimiento que el uso de Flash [o Silverlight] en dicho dispositivo.
Extra points if there is some way to reuse the old Delphi code (but
vez más, estamos realistas por lo que no están esperando esto sucederá).
No puedo ayudarte aquí. Su mejor opción es volver a crear desde cero o intentar escribir alguna forma de herramienta de conversión/generador de código. No estoy seguro si esto último es práctico. Si convierte el código Delphi en objetos COM, como se sugiere en otra parte, se pueden usar desde ColdFusion de forma similar a cómo se pueden usar desde .NET.
¿Le sirve de ayuda? ¿Que mas te gustaria saber?
Un pensamiento en HTML5. Los navegadores actualmente no implementan construcciones HTML existentes por igual. Uno de los beneficios de Flash/Silverlight es la coherencia entre los navegadores. Nada me hace pensar que el sombrero HTML5 traerá coherencia entre navegadores. Si el póster original se puede estandarizar en un solo navegador, HTML (y JavaScript) será una gran opción. Como quiere admitir máquinas Windows y Apple, probablemente no pueda estandarizar en un solo navegador. Sospecho que pasar de Delphi a una aplicación HTML de "la vieja escuela" será una pesadilla de usabilidad. – JeffryHouser
Muchas gracias por su respuesta Justin. Nuestra tienda es principalmente C#, pero quería adoptar un enfoque independiente para la selección del nuevo entorno. Por supuesto, si todas las respuestas respaldan lo que has dicho, ¡no me decepcionará! – ProgramsUnlimited