Diferencia entre revisiones de «MediaFranca: Arquitectura»

De Casiopea
(Sobre la Arquitectura)
Línea 1: Línea 1:
 
== Sobre la Arquitectura ==
 
== Sobre la Arquitectura ==
  
La primera investigacion 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]]
  
La meta inicial propuesta por el equipo indica que mediaFranca debe ser pensado tomando en consideracion 2 aspectos principales:
+
La meta inicial propuesta por el equipo indica que mediaFranca debe ser pensado tomando en consideración 2 aspectos principales:
* Estandares de servicios web
+
* Estándares de servicios web
 
* Escalabilidad
 
* 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 [http://www.area-europa.net/images/protocolo_IP.png Mod. Iso/Osi])
+
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, 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, 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 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.
+
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 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.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 conversacion.
+
* '''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 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 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 aplicacion aun no se ha investigado en detalle, pero han habido algunas aproximaciones y buenas referencias.
+
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, ultimamente a acaparado un importante numero de seguidores y aplicaciones que utilizan este servidor.
+
* [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 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).
+
 
 +
 
 +
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 version 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) deberan desplegar metodos compatibles con las operaciones definidas en REST.
+
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 documentacion de los servicios web debiese efectuarse en esta misma wiki.
 
  
== Sobre el desarrollo de los clientes ==
+
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.

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.