Diferencia entre revisiones de «MediaFranca: Arquitectura»
| Línea 12: | Línea 12: | ||
MediaFranca esta pensado para ser utilizado desde varios tipos de dispositivos, espesificamente desde una aplicacion web y aplicaciones moviles, por lo tanto su arquitectura inicial debe contemplar una comunicacion trasnparente al tipo de aplicacion en desarrollo, es por esto que trabajar con estandares en servicios web se transforma en una necesidad. [Mas detalles en la seccion "Sobre los Servicios Web"] | MediaFranca esta pensado para ser utilizado desde varios tipos de dispositivos, espesificamente desde una aplicacion web y aplicaciones moviles, por lo tanto su arquitectura inicial debe contemplar una comunicacion trasnparente al tipo de aplicacion en desarrollo, es por esto que trabajar con estandares en servicios web se transforma en una necesidad. [Mas detalles en la seccion "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 rapido, ordenado y estable, ofrece, nativamente, el despliege de REST a travez de sus controladores, | |||
El desarrollo del CORE de mediaFranca se desarrollara utilizando el frameWork "RubyOnRails", este aparte de otorgar un ambiente de desarrollo rapido, ordenado y estable, ofrece, nativamente, el despliege de REST a travez de sus controladores, po'''Texto en negrita'''r lo cual a travez de la misma url, cambiando solo el tipo de documento a consultar, podremos accesar tanto HTML como XML. | |||
Ejemplo: | Ejemplo: | ||
| Línea 20: | Línea 22: | ||
* '''www.mediafranca.cl/talk/1''' el sistema debiese retornar la interfaz web, con el mismo hilo de conversacion. | * '''www.mediafranca.cl/talk/1''' el sistema debiese retornar la interfaz web, con el mismo hilo de conversacion. | ||
'''Base de Datos, MongoDB''' | '''Base de Datos, MongoDB''' | ||
Tomando en consideracion que una meta es mantener la escalabilidad a lo largo del tiempo independiente la etapa del proyecto, se analizaron multiples motores de bases de dato, entre ellas, las mas conocidas del mundo relacional y tambien 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 documentacion existente y los conectores (relativamente INmaduros) que existen para el frameWork rubyOnRails. | Tomando en consideracion que una meta es mantener la escalabilidad a lo largo del tiempo independiente la etapa del proyecto, se analizaron multiples motores de bases de dato, entre ellas, las mas conocidas del mundo relacional y tambien 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 documentacion 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 aplicacion 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://nginx.org/en/ Nginx]: Servidor web Ruso, ultimamente a acaparado un importante numero de seguidores y aplicaciones que utilizan este servidor. | |||
Seguramente para una version 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 desicion "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 simultaneas). | |||
== Sobre los Servicios web == | == Sobre los Servicios web == | ||
Revisión del 10:44 14 jun 2010
Sobre la Arquitectura
La primera investigacion 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 consideracion 2 aspectos principales:
- Estandares de servicios web
- Escalabilidad
Esto tiene repercuciones en 2 capas distintas de la aplicacion (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, espesificamente desde una aplicacion web y aplicaciones moviles, por lo tanto su arquitectura inicial debe contemplar una comunicacion trasnparente al tipo de aplicacion en desarrollo, es por esto que trabajar con estandares en servicios web se transforma en una necesidad. [Mas detalles en la seccion "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 rapido, ordenado y estable, ofrece, nativamente, el despliege de REST a travez de sus controladores, poTexto en negritar lo cual a travez 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 arbol xml con todo el hilo de la conversacion "1", xml utilizable (Parseable) por cualquier lenguaje de programacion para generar cualquier tipo de aplicacion.
- www.mediafranca.cl/talk/1 el sistema debiese retornar la interfaz web, con el mismo hilo de conversacion.
Base de Datos, MongoDB
Tomando en consideracion que una meta es mantener la escalabilidad a lo largo del tiempo independiente la etapa del proyecto, se analizaron multiples motores de bases de dato, entre ellas, las mas conocidas del mundo relacional y tambien 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 documentacion 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 aplicacion 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, ultimamente a acaparado un importante numero de seguidores y aplicaciones que utilizan este servidor.
Seguramente para una version 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 desicion "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 simultaneas).
Sobre los Servicios web
Para la version 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) deberan desplegar metodos compatibles con las operaciones definidas en REST.
La documentacion de los servicios web debiese efectuarse en esta misma wiki.
