Listo una serie de arquitecturas que el topology generator podría tener. Tenemos que tomar la decisión de diseño de definir hacía donde queremos ir, pero antes tenemos que entender que es lo que queremos.

Mi visión es la siguiente: El topologyGenerator es una herramienta que me permite obtener desde una red (está red puede ser real o no), una representación de la misma en algún output que me sea conveniente. Lo que seguro voy a tener es alguien que tiene conocimiento de dicha red cuya existencia es independiente del topology generator, y un conocimiento del output que deseo generar. El proveer ambos conocimientos al topology generator es responsabilidad del usuario que utilice la herramienta.

Entendiendo que es lo que quiero, veamos un ejemplo de arquitectura para lo recien explicado:

1 - Proxy + Builders

¿Que es cada cosa?

- Providers : Va a ser el elemento de la arquitectura que sepa como comunicarse con el pibe que sabe cual es la red. El provider sabe como hacer los pedidos, y como entiende la respuesta, este mismo componente va a ser el encargado de traducir los pedidos a una representación estandar. Por ejemplo si pido hosts al provider, este me va a devolver elementos de la clase host, y no un JSON pelado que podría perfectamente ser la respuesta del source (el caso de ONOS por ejemplo). El provider entonces se va a dividir en 2: * Proxy: Porque sabe como realizar los requests al pibe que conoce la red * NetworkRepresentationBuider: Porque sabe como es la respuesta de cada cosa que le piden, y va a utilizar la representación del topologyGenerator para crear el estandar de los pedidos. De nuevo el ejemplo es que si recibo un JSON por una API, y me pidieron hosts, no voy a devolver el JSON, sino instancias de la clase Host

- NetworkTopologyProvider: Representa el componente al cual se le van a realizar los pedidos sobre la red, por ejemplo: Dame los hosts, dame los links, dame los routers, preguntar sobre caminos entre nodos de la red, costos, etc.

- NetworkTopologyRepresentation: Va a ser el componente que represente a todos los elementos CONCRETOS de la red. Defino elementos concretos o físicos, como links, routers, hosts. La idea de este pibe es que cuando querramos buildear, vamos a buildear está representación. Lo importante que hay que entender de este NetworkTopologyRepresentation es que NO QUIERO que tenga TODA LA INFORMACIÓN que posee la entidad externa que conoce a la red, sino la información básica de los elementos de la red para, en caso de ser necesario, pedir dicha información. (Quiero que sea lazy loading, de manera de tener escalabilidad).

-NetworkTopologyBuilder: Va a ser el componente que va a interactuar con la representación de la red (el componente explicado antes) para pedir la información necesaria para generar el output deseado. A su vez, este pibe va a hablar con los builders concretos implementados por el usuario para generar el output deseado.

- Builders: Son los encargados de poseer el conocimiento de como generar el output (el cual pueden ser muchos archivos, un archivo, un request a una api, etc.). Estos pibes van a pedirle cosas al NetworkTopologyBuilder, quien va a ser el encargado de proveer la información de nuevo de una manera estandar para todos.

Con esta arquitectura busco:

- Escalabilidad: Cuando por ejemplo digo que la representación de la red debería ser lazy loading, ya que está claro que si pido absolutamente todo, y la red es muy grande, esto puede tardar mucho (además de que en muchos casos puede influir a no ser una buena solución, ya que si estoy usando una api en donde tengo un límite en la cantidad d requests, no está bueno ir y pedir cosas q dsp no uso).

- Modificabilidad: Entiendo que los endpoints van a variar, por lo que hay que enfocarse en responder los problemas: * Agregar un nuevo source (componente externo a la arquitectura que posee info de la red) * Agregar un nuevo output (conocimiento externo de la arquitectura que me dice como y que tengo que generar ) Creo que está arquitectura responde bien al problema, ya que cualquiera de los problemas de arriba se responde directamente con agregar un nuevo provider y agregar un nuevo builder respectivamente. El concepto de tener una nueva entidad en mi dominio del problema => agregar un nuevo componente creo que es un buen punto de la arquitectura.

Lo malo de está arquitectura es:

- Pido alta disponibilidad a los providers, no estoy pensando en una cache incluso al ser lazy loading, por lo que el topologyGenerator anda <=> tengo conexión al componente externo q conoce la red. No está bueno.

- La seguridad de está arquitectura es un chiste.

-- AndresLaurito - 2016-09-30