Cuál es nuestro producto final, la unidad básica para un desarrollador de aplicaciones?
- ejecutable
- aplicación
- daemon
y
- configuración
- ini
- xml
- json
- ...
El resto del mundo:
- sistemas operativos, sistema de ficheros, drivers
- hardware, routers, firewalls
- máquinas virtuales, bases de datos
- ...
lo tenemos que conocer, pero
no es nuestro mundo.
Sómos usuarios de esos mundos.
Nuestro elemento mas básico?
- el ejecutable (@exe)
- su configuración (@config)
Normalicemos
@exe
y
@config
Cómo normalizamos @exe?
- Idénticos parámetros de ejecución en lÃnea de comando.
Cómo normalizamos @config?
- Usando el formato más sencillo para su representación: JSON
Normalicemos @exe al estilo Unix:
$> yunetaAgentt --help Usage: yunetaAgentt [OPTION...] json-config... yunetaAgentt -- Yuneta Real Test Agent -S, --start start the program (as daemon) -K, --stop stop the program (as daemon) -f, --config-file=JSON-FILE use settings from json config file -e, --extra-config-file=JSON-FILE use extra settings from json config file -p, --settings check and print the settings -P, --final-settings check and print the final settings -o, --log-oids log the mib oids -v, --version print program version -r, --role print role name -?, --help print this help Report bugs to <niyamaka at yuneta.io>
Avancemos más en la normalización:
Dotemos de personalidad a
@exe
Cómo?
Asignándole:
- un #rol
y opcionalmente
- un #nombre
@exe tiene que informar claramente cuál es su #rol y #nombre
$> yunetaAgentt --role yuno 'yunetaAgentt' '' '1.0.0' '1.0.0' '[6997]' '[2162]' $>
@exe tiene que ser capaz de correr como
daemon
y estar protegido de
muerte súbita.
$> yunetaAgentt --start $> ps -e |grep yuneta 1309 ? 00:00:00 yunetaAgentt 1310 ? 00:00:07 yunetaAgentt $> yunetaAgentt --stop
Normalicemos @config.
Configuración flexible, que podrá residir en:
- código
- fichero
- en lÃnea de comando
Tendrá:
- zonas fijas
- zonas variables.
Normalicemos @config.
La configuración final será la suma de
- @config-interna
- @config-ficheros
- @config-lÃnea-comando.
$> watchfs \ -f 'default.json' \ -e '3071.json' \ '{"yuno": {"__routerPort__": 3333}}'
Normalicemos @config.
Las zonas fijas
no pueden ser modificadas, ni desde fichero, ni desde lÃnea de comando.
Las zonas variables
sà pueden ser modificadas.
PRIVATE char fixed_config[]= { "yuno": { "__yuno_role__": "mq" } }; PRIVATE char variable_config[]= { "yuno": { "__yuno_name__": "" } };
A este @exe y @config,
dotado de
#rol
y opcionalmente con
#nombre,
lo llamaremos
#yuno,
el hijo de #yuneta.
Normalicemos los #yunos.
Un yuno puede correr de manera
solitaria (standalone),
pero la tendencia es compartir, comunicarse.
Yuneta facilita la vida del desarrollador y del operador, y permite que los yunos se puedan
relacionar, comunicar, compartir
Normalicemos los #yunos.
Dotemos a los
#yunos
de la capacidad de
intercomunicarse
entre ellos.
De una manera sencilla, usando mensajes
#json
y simplemente conociendo del destinatario su
#rol
#nombre
Normalicemos los #yunos.
Todo #yuno que quiera intercomunicarse necesita activar un
routerPort
$> yunetaAgentt --role yuno 'yunetaAgentt' '' '1.0.0' '1.0.0' '[6997]' '[2162]' $>
El routerPort del yuno agente del reino en preproducción es el 6997
Ejemplo de mensaje entre #yunos
~ { "iev_dst_yuno": "Ph2e", "iev_dst_role": "h2email", "iev_dst_srv": "persist", "iev_event": "EV_REMOVE_IEVENT", "iev_src_yuno": "Pems", "iev_src_role": "emailsender", "iev_src_srv": "router", "iev_kw": { "store": "*", "room": "*", "shelf": "*", "owner": 0, "reference": "5-055A4B97D-0A6EE8E1-0000000040043B54-0000C5FD" } }
Los #yunos interconectados se organizan en
#reinos de yunos
Un #reino de yunos se aloja en un
servidor fÃsico,
servidor virtual,
o container.
Sólo en sistemas
linux
o
compatibles POSIX.
Para gestionar el #reino se crea la figura del yuno
agente
El yuno agente gestiona el
despliegue configuración operación
de los yunos ciudadanos del reino.
El agente del reino.
Consta de dos yunos y dos ambientes:
preproducción:
yunetaAgentt (daemon)
yuneta-t (CLI)
producción:
yunetaAgent (daemon)
yuneta (CLI)
$> yuneta-t Wellcome to Yuneta CLI. Type help for assistance. yuneta-t> ? quit Exit of yuneta help Display help install yuno Install new yuno update yuno Update a yuno remove yuno Remove a yuno activate yuno Mark a version as 'official' to start/stop deactivate yuno Unmark the current 'official' version to start/stop list yuno List yunos install conf Install new config of yuno update conf Update config of yuno remove conf Remove config of yuno activate conf Mark config as 'official' to start/stop deactivate conf Unmark the current 'official' config to start/stop list conf List configurations clean yuno Clean binaries and configurations run yuno Run the activated version of a yuno kill yuno Kill the running yuno play yuno Play the running yuno pause yuno Pause the running yuno top List state of activated yunos stats yuno Get statistics from matched yunos command yuno Execute command in matched yunos yuneta-t>
En el #reino de nivel 1, el implementado hasta ahora,
el agente
despliega y controla #yunos
despliega y controla @configuraciones,
pero no controla routerPorts.
El diseñador de #reinos tiene que definir en cada yuno su
routerPort
y la interconexión entre ellos explicitamente con
rutas estáticas.
Existen
yunos solitarios (standalone)
y yunos que prefieren acogerse a la dictadura benévola de un
reino.
En el reino de primer nivel, el agente sólo es la puerta de entrada y salida, y el registro central de los yunos moradores.
En el reino de primer nivel, los yunos organizan ellos mismos su identidad (routerPort) en el reino.
Los yunos se apuntan en lista pública de ids, y van cogiendo números consecutivos.
El yuno informa al agente de su id.
FUTURO
El reino de nivel 2 tendrá yunos especializados además del agente: observador, visualizador, tasker, yunos semi-humanos, ...
El reino de nivel 2 ya no será un recinto autogestionado por el diseñador de reinos.
El agente asignará los id's y existirá un servicio DNS para localizar a un yuno por su rol y nombre.
Se podrán unir #reinos para formar #imperios de yunos.
Y se podrán unir #imperios de yunos para formar #galaxias de imperios de reinos de yunos.
Será la base para implementar BPM
FUTURO
Agente de nivel 2 (FUTURE): dos tipos de reinos,
reino de nombre único
y
reino sin nombre o con nombre no-único.
Lo que es arriba es abajo.
Reino de nombre único, puede estar clonado por seguridad:
activo/pasivo
árbol jerárquico distribuido.
Reino sin nombre único
puede ser clonado sin lÃmite para multiplicar su fuerza.
El agente de nivel 2 controla el despliegue de yunos en los reinos bajo su control.
Los #yunos entre sà intercambian mensajes mediante los modelos:
request-response,
subscribe-publish,
o direct-send.
Estos mismos modelos se usan también en el interior de los #yunos.
Los #yunos internamente están organizados como un árbol invertido y jerárquico de objetos llamados GObjs.
(Lo que es arriba es abajo, lo que es dentro es fuera)
direct-send implica un
envio
sin esperar respuesta o una respuesta inmediata.
request-response implica un
envio
y sà espera una
respuesta
y por lo tanto el emisor normalmente
cambia al estado de esperar esa respuesta.
En request-response el json de respuesta deberÃa incluir los campos
"result"
y
"data"
Para lectura fácil de humanos y yunos.
"result" es un integer con el retorno estandar de C
0 ok
<0 error
En "data" los datos json que se quieran.
subscribe-publish ya se sabe.
SuscrÃbete
a un evento, y cuando dicho evento ocurra
se te informará.
Con filtros para que matchear los eventos a tu gusto
Define tu mundo con los roles y el flujo de mensajes de Yuneta.
Investiga y descubre el flujo de datos de tu negocio e impleméntalo con yunos.
Lo podrás visualizar y controlar.
Llegarás a conocer profundamente tu mundo.
Tendrás control total de tu actividad.
Cuando las
"comunicaciones entre aplicaciones",
tienen más peso que las
propias aplicaciones,
el
modelo tiene que cambiar.
Los datos importantes?
Ahora es más importante el
intercambio de esos datos,
la
polÃtica de intercambios,
la
filosofÃa de los intercambios,
el
diseño de los intercambios.
Cambio de modelo.
Ya no existe eso de
jefe, director, subdirector, encargado, operario...
ahora es
agente de reino,
observador,
dibujante...
y los yunos y sus mensajes.
Cambio de modelo.
Empresa, organización, o lo que seas:
conoces los roles y el flujo de información en tu empresa?
Pues deberÃas.
Disecciona tu empresa o negocio y descubre
los roles necesarios,
quien los ostenta,
y los servicios que se intercambian entre ellos.
Cuando hayas
diseccionado tu negocio
y lo hayas
representado con Yuneta,
tendrás
control,
conocimiento.
Podrás
mejorarlo
y
optimizarlo.
Lo que es arriba es abajo, y lo que es dentro es fuera.
Yunos?
GObjs?
es la misma cosa pero en diferente nivel.
Diferencia entre GObjs y Yunos a nivel funcional?
a los
GObjs los tiene que conocer el desarrollador,
a los
Yunos los tiene que conocer el cliente.
Quieres saber algo más del GObj?
Internamente tiene una tabla de
atributos estructurados
y un
autómata o FSM (Finite State Machine)
Los atributos están definidos con estandar ASN1
y son accesibles por SNMP
Y ahora quieres conocer un secreto?
La @config de un yuno es un fiel reflejo de los
atributos
de todos sus
GObj internos.
Otro secreto?
Un autómata se mueve por
eventos
Los
mensajes entre yunos
contienen el nombre del
evento
y sus
propiedades
Ejemplo de mensaje entre yunos.
~ { "iev_dst_yuno": "Ph2e", "iev_dst_role": "h2email", "iev_dst_srv": "persist", "iev_event": "EV_REMOVE_IEVENT", "iev_src_yuno": "Pems", "iev_src_role": "emailsender", "iev_src_srv": "router", "iev_kw": { "store": "*", "room": "*", "shelf": "*", "owner": 0, "reference": "5-055A4B97D-0A6EE8E1-0000000040043B54-0000C5FD" } }
Cerrando un circulo:
Consulta
las tablas de atributos
de los
GObj
para conocer la
@config
de un
yuno
Cerrando otro circulo:
Consulta el
autómata
de los
GObj públicos
para conocer el
interface o API
de un
yuno
Yuneta es un framework cercano a la
máquina
y al
sistema operativo
porque está escrito en C,
pero es también de
desarrollo rápido
y
moderno
Es
Json inside
Yuneta es un framework para mentes
sin memoria,
olvidadizas,
cada dÃa más torpes,
como la del autor de Yuneta.
Memoria
por
lógica estructurada.
Yuneta es un framework de naturaleza asÃncrona, construido sobre las librerias de gobj-ecosistema
gobj-ecosistema es un conjunto de cuatro librerias estáticas:
Los componentes de Yuneta son:
- libreria c-core.
- yuno yuneta Agent .
- yuno yuneta CLI.
Todos ellos se compilan con CMake.
Otro proyectos auxiliares son:
- Yunos Template. Una utilidad en Python con plantillas de yunos.
- js-core. Versión Javascript de Yuneta para correr en navegadores.
Entiendo el uso de librerÃas dinámicas cuando habÃa escasez de memoria.
Pero ahora, sobrando memoria, usa librerÃas estáticas.
Con las librerÃas estáticas:
adiós a los problemas de incompatibilidad con las versiones de las librerias usadas.
Table of Contents | t |
---|---|
Exposé | ESC |
Full screen slides | e |
Presenter View | p |
Source Files | s |
Slide Numbers | n |
Toggle screen blanking | b |
Show/hide slide context | c |
Notes | 2 |
Help | h |