C Framework

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:

• GinsFSM (autómatas sencillos)
• GHelpers (utilidades)

• external-libs:

  • libuv (event loop, plataforma de Node.js)
  • jansson (json)

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.

Reino de GPSS