used - ruby vs python español

¿Qué hace BlazeDS Livecycle Data Services, que algo como PyAMF o RubyAMF no hacen?

Question

Estoy haciendo una revisión técnica y estoy buscando la integración de AMF con varios backends (Rails, Python, Grails, etc.).

Hay muchas opciones disponibles, la pregunta es, ¿qué hacen los productos de Adobe (BlazeDS, etc.) que algo como RubyAMF / pyAMF no tienen?

Answer 1

Buena pregunta. No soy un tipo ruby ​​(uso java con flex), pero lo que creo diferencia a blazeds vs comercial livecycle ds es

1. Soporte de protocolo de transmisión (rtmp) - competencia para cometas y tal, entrega de video
2. Algunas cosas avanzadas para hibernar objetos separados y un gran caché de conjuntos de resultados que no entiendo completamente ni necesito
   3. ¿apoyo? Podrían ser otros, pero esos son los que yo conozco en la parte superior de mi cabeza.

Answer 2

Adobe tiene dos productos: Livecycle Data Services ES (LCDS) y BlazeDS. BlazeDS contiene un subconjunto de funciones LCDS y se hizo de código abierto. Lamentablemente, los canales NIO (RTMP NIO / HTTP) y las funciones de gestión de datos se implementan solo en LCDS, no en BlazeDS.

BlazeDS se puede usar solo para integrar Flex con Java back-end. Ofrece no solo servicios remotos con la serialización AMF (como RubyAMF), sino también funciones de mensajería y colaboración: eche un vistazo a este enlace ( http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=lcoverview_3 .html ). También supongo que el soporte es mejor en comparación con RubyAMF / pyAMF.

Si su backend es JAVA y desea utilizar solo un producto gratuito, también puede utilizar GraniteDS o WebORB (competidores de BlazeDS)

Answer 3

Además de los canales NIO (RTMP), los LCDS incluyen también las características de "administración de datos".

Al utilizar esta función, básicamente implementa, en una clase de ActionScript, una interfaz tipo CRUD definida por LCDS, y obtiene:

• carga progresiva automática de la lista (cargas grandes de listas / cuadrículas de datos mientras se desplaza)
• gestión automática de crud (obtiene el objeto localmente en flash, lo modifica, lo envía de vuelta y DB se actualizará automáticamente)
• función para resolución de conflictos (si varios usuarios intentan actualizar el mismo registro al mismo tiempo)
• si recuerdo bien, también una mejor integración con el motor de flujo de trabajo de LiveCycle ES

OMI, puede ser muy rápido desarrollarse de esta manera, pero solo si solo tienes requisitos básicos y una arquitectura simple (olvídate de SOA, que de lo contrario funciona muy bien con Flex). Estoy bien con BlazeDS.

Answer 4

Las funciones de administración de datos para LCDS descritas aquí son ciertamente válidas, sin embargo, creo que no le permiten desarrollar una solución más rápido. Un desarrollador todavía tiene que escribir TODO el código de acceso a datos, ejecutar consultas, extraer datos de lectores de datos en objetos de valor. TODO esto se ha resuelto una docena de veces con generadores de código. Por ejemplo, el enfoque de gestión de datos en WebORB para Java (muy parecido a lo que sucede en WebORB para .NET y PHP) se basa en la generación de código que crea código tanto para el lado del cliente como para el lado del servidor. Usted obtiene todas las API de ActionScript fuera del generador de código para hacer CRUD completo.

Además, WebORB ofrece transmisión de video y funciones de mensajería en tiempo real, y VA MUCHO más allá de lo que combinan BlazeDS y LCDS, especialmente si se tiene en cuenta que el producto es gratuito. Solo busca en google.