Diferencia entre revisiones de «MediaFranca: Arquitectura»

De Casiopea
Sin resumen de edición
Línea 3: Línea 3:
La primera investigación sobre la arquitectura y maquinaria a implementar en mediafraca a arrojado los siguientes resultados.
La primera investigación sobre la arquitectura y maquinaria a implementar en mediafraca a arrojado los siguientes resultados.


[[Archivo:MediaFrancaArq1.png]]
[[Archivo:MediaFrancaArq1.png|thumb]]


__TOC__
__TOC__

Revisión del 22:47 7 sep 2010

Sobre la Arquitectura

La primera investigación sobre la arquitectura y maquinaria a implementar en mediafraca a arrojado los siguientes resultados.

MediaFrancaArq1.png

La meta inicial propuesta por el equipo indica que mediaFranca debe ser pensado tomando en consideración 2 aspectos principales:

  • Estándares de servicios web
  • Escalabilidad

Esto tiene repercusiones en 2 capas distintas de la aplicación (pensando en el modelo ISO/OSI, Los Servicios Web repercuten en la capa 6 y la escalabilidad (en este momento) fue pensada para la capa 4 y 5 Mod. Iso/Osi)

MediaFranca esta pensado para ser utilizado desde varios tipos de dispositivos, específicamente desde una aplicación web y aplicaciones móviles, por lo tanto su arquitectura inicial debe contemplar una comunicación transparente al tipo de aplicación en desarrollo, es por esto que trabajar con estándares en servicios web se transforma en una necesidad. [Mas detalles en la sección "Sobre los Servicios Web"]


Ruby on Rails

El desarrollo del CORE de mediaFranca se desarrollara utilizando el frameWork "RubyOnRails", este aparte de otorgar un ambiente de desarrollo rápido, ordenado y estable, ofrece, nativamente, el despliegue de REST a través de sus controladores, poTexto en negritar lo cual a través de la misma url, cambiando solo el tipo de documento a consultar, podremos accesar tanto HTML como XML.

Ejemplo:

  • www.mediafranca.cl/talk/1.xml, debiese retornar un árbol xml con todo el hilo de la conversación "1", xml utilizable (Parseable) por cualquier lenguaje de programación para generar cualquier tipo de aplicación.
  • www.mediafranca.cl/talk/1 el sistema debiese retornar la interfaz web, con el mismo hilo de conversación.


Base de Datos, MongoDB

Tomando en consideración que una meta es mantener la escalabilidad a lo largo del tiempo independiente la etapa del proyecto, se analizaron múltiples motores de bases de dato, entre ellas, las mas conocidas del mundo relacional y también las del no relacional (el naciente movimiento NoSQL, finalmente se estudio el comportamiento de MongoDB y CouchDB quedandose inicialmente por la primera, MongoBD, por la cantidad de documentación existente y los conectores (relativamente INmaduros) que existen para el frameWork rubyOnRails.


Servidor de Aplicaciones

El servidor de aplicaciones en el cual se desplegara la aplicación aun no se ha investigado en detalle, pero han habido algunas aproximaciones y buenas referencias.

  • Thin: Servidor Web minimalista (En extremo) es una buena alternativa, con bastantes estudios a su favor.
  • Nginx: Servidor web Ruso, últimamente a acaparado un importante numero de seguidores y aplicaciones que utilizan este servidor.


Seguramente para una versión inicial trabajaremos con apache y passenger rails ya que es lo que se encuentra instalado en el servidor de la E[AD], para una primera etapa esta bien, pero claramente si se espera que el sistema escale no es una decisión "muy" apropiada (falta analizar estabilidad vs eficiencia, claramente apache se jacta de tener una respetable estabilidad, pero su rendimiento decae al momento de analizar muchos (cientos) de llamadas simultáneas).

Sobre los Servicios web

Para la versión inicial de mediaFranca se determino que este desplegara WebServices REST (Representational State Transfer). De este modo, los controladores que se definan (a partir de los requerimientos funcionales) deberán desplegar métodos compatibles con las operaciones definidas en REST.

La documentación de los servicios web debiese efectuarse en esta misma wiki.