Según avanzamos en el diseño de la nueva versión de TwinPanel, se hace necesario "prototipar" determinadas cosas. De este modo, podemos capturar requisitos no visibles a primera vista, y comprobar en cierto modo la viabilidad de algunas propuestas.
Por eso, presentamos el primer prototipo escrito teniendo en cuenta parte del nuevo diseño. Básicamente está formado por dos partes: el entorno de objetos distribuidos y los clientes (aunque, en este caso, sólo hay uno ;) )
Aunque el prototipo es funcional, no está escrito a fuego, por lo que es posible que cambien muchas cosas. Aún así, vamos a desgranarlo un poco, para entenderlo bien.
Distributed Component Platform
El nombre todavía no es definitivo, pero de alguna forma hay que llamarlo. DCP es el conjunto de objetos (plugins, factorías, etc.) que dan servicio a los clientes. De el forman parte los sirvientes que presentan un modelo de datos o de acceso para determinado recurso, así como las factorías utilizadas para la gestión de estos componentes.
En el prototipo hay dos factorías. La primera gestiona los plugins que proveen modelos de acceso a determinado recurso. Tiene un método, getThingFromURI, que analiza una URI, y crea un sirviente para dar acceso a esa URI. El objeto que se retorna puede tener diferentes interfaces, dependiendo de los plugins que soporte. En el prototipo, sólo hay uno registrado, que presenta una interfaz de tipo FILE, y que soporta el esquema HTTP.
La segunda factoría, gestiona modelos de datos. Aunque la interfaz tiene varios métodos, el más interesante es simpleCreateDataModel, que crea un sirviente para un modelo de acceso determinado. Los plugins de esta factoría son capaces de "entender" y manipular el recurso, presentando una interfaz para manipularlo. El único plugin registrado en el prototipo es HTMLDir, que reconoce el formato HTML, lo "parsea" y genera una estructura de directorios con el contenido servido.
Cliente
La otra parte del prototipo es el cliente. Su cometido es sencillo: obtiene los proxies a las factorías antes mencionadas, y crea los sirvientes adecuados para explorar una URI de tipo HTTP (como "http://www.google.es"). Crea una interfaz gráfica muy sencilla (a modo de Skin) con un IconView para mostrar el modelo generado a partir del HTML.
He de remarcar que es un prototipo, por lo que no está depurado, no es tolerante a fallos y puede comportarse de forma indefinida, aunque por lo general, hará lo que le dices :) El código fuente está disponible para todo el que lo quiera probar. Depende de python-zeroc-ice y de pyicebox. Para probarlo, es necesario lanzar por un lado el DCP, usando:
$ ./launchFactories.sh
y por otro, el cliente, de una forma parecida a:
$ ./Client.py --Ice.Config=client.cfg http://www.google.es
Conclusiones
Todavía quedan muchas cosas por pulir:
- Es necesario definir un mecanismo para registrar los plugins en las factorías correspondientes. En caso de que sea la factoría quien los cargue, es necesario establecer una interfaz para los plugins (interfaz que se implementará en el módulo).
- Definir el mecanismo de interacción entre plugins, es decir, es necesario especificar aquellas interfaces que cierto plugin es capaz de manipular.
- Se han de especificar las relaciones entre componentes activos, inactivos y no instanciados, así como los protocolos de reutilización, compartición y limpieza de recursos.
- Es preciso determinar si es escalable o no, y la forma de hacerlo escalable. Por ejemplo, en un recurso con múltiples ficheros ¿se debería crear un sirviente por cada nodo? ¿Se podría utilizar un default servant?
Algo que he visto bastante acertado es la separación entre la "plataforma de componentes" y los clientes. Esto nos permite mucha flexibilidad a la hora de diseñar diferentes interfaces de usuario, o de hacer pruebas a la plataforma. También hace más sencillo entender todo como conjunto (divide y vencerás), y escribir sus partes, siempre que estas sean lo más ortogonales posible.
Descargas
No comments:
Post a Comment