Diferencia entre revisiones de «MediaFranca: Arquitectura»
Sin resumen de edición |
|||
Línea 1: | Línea 1: | ||
== Sobre la Arquitectura == | == Sobre la Arquitectura == | ||
La primera | La primera investigación sobre la arquitectura y maquinaria a implementar en mediafraca a arrojado los siguientes resultados. | ||
[[Archivo:MediaFrancaArq1.png]] | [[Archivo:MediaFrancaArq1.png]] | ||
La meta inicial propuesta por el equipo indica que mediaFranca debe ser pensado tomando en | 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 | * Escalabilidad | ||
Esto tiene | 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 [http://www.area-europa.net/images/protocolo_IP.png Mod. Iso/Osi]) | ||
MediaFranca esta pensado para ser utilizado desde varios tipos de dispositivos, | 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''' | '''Ruby on Rails''' | ||
El desarrollo del CORE de mediaFranca se desarrollara utilizando el frameWork "RubyOnRails", este aparte de otorgar un ambiente de desarrollo | 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, po'''Texto en negrita'''r lo cual a través de la misma url, cambiando solo el tipo de documento a consultar, podremos accesar tanto HTML como XML. | ||
Ejemplo: | Ejemplo: | ||
* '''www.mediafranca.cl/talk/1.xml''', debiese retornar un | * '''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 | * '''www.mediafranca.cl/talk/1''' el sistema debiese retornar la interfaz web, con el mismo hilo de conversación. | ||
Línea 27: | Línea 27: | ||
'''Base de Datos, MongoDB''' | '''Base de Datos, MongoDB''' | ||
Tomando en | 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 [http://es.wikipedia.org/wiki/NoSQL NoSQL], finalmente se estudio el comportamiento de [http://www.mongodb.org/ MongoDB] y [http://en.wikipedia.org/wiki/CouchDB 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''' | '''Servidor de Aplicaciones''' | ||
El servidor de aplicaciones en el cual se desplegara la | 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. | ||
* [http://code.macournoyer.com/thin/ Thin]: Servidor Web minimalista (En extremo) es una buena alternativa, con bastantes estudios a su favor. | * [http://code.macournoyer.com/thin/ Thin]: Servidor Web minimalista (En extremo) es una buena alternativa, con bastantes estudios a su favor. | ||
* [http://nginx.org/en/ Nginx]: Servidor web Ruso, | * [http://nginx.org/en/ Nginx]: Servidor web Ruso, últimamente a acaparado un importante numero de seguidores y aplicaciones que utilizan este servidor. | ||
Seguramente para una | |||
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 == | == Sobre los Servicios web == | ||
Para la | Para la versión inicial de mediaFranca se determino que este desplegara WebServices [http://es.wikipedia.org/wiki/Representational_State_Transfer 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. |
Revisión del 10:50 14 jun 2010
Sobre la Arquitectura
La primera investigación sobre la arquitectura y maquinaria a implementar en mediafraca a arrojado los siguientes resultados.
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.