Parábola del Actor: el Acto termina

En el post anterior (Parábola del Actor y el Objeto) se planteó la idea de procesos ligeros e inmortales en memoria. Pero esta situación no es realista, estos procesos deben terminar algún día. La solución es simple: el proceso no se vuelve a llamar a sí mismo; el garbage colector se encarga del resto.
Por ejemplo estos dos mensajes terminan el proceso:

vendeDor(PrecioArticulo, CompradorActual, VentasLogradas) ->
 receive
  {despedido, Jefe } ->
   Jefe ! {enCurso, self(), CompradorActual },
   adios;
  {jubilado, Jefe } ->
   Jefe ! {enCurso, self(), CompradorActual },
   graciasADios
 end. 

La siguiente pregunta es:
¿Qué sucede si hay una actualización del módulo "vendedor"? ¿Se detiene todo para poderlo online?


Lo mejor sería reemplazar el código "in-runtime" (en caliente), finalizando las operaciones pendientes usando el código antiguo y atendiendo las nuevas con el más reciente. (En Erlang existe y es un tema avanzado, se llama "release handling".)




Estos dos conceptos implican una entidad superior que lo controla todo. Obviamente se trata de un principio de diseño llamado árbol de supervisión compuesto por trabajadores y supervisores.




Espero con esto haber despertado un poco de interes en esta tecnología.



Viene de: Parábola del actor y del objeto.


Relacionados:
Erlang: Programación funcional y concurrente.
Mapeo de actores a objetos.

Parábola del Actor y el Objeto

La idea de hacer este embrollo surge del artículo de Angel "Java" López Look, ma! No database!, pero es toda mi responsabilidad.

Supongamos que nos devolvimos en el tiempo en una pequeña tienda que vende un solo producto.

Hay un “desconta-dor” (viejo mañoso y malhumorado) que calcula el descuento de cada venta, agrega el valor al recibo y le pone un sello. A continuación el “vende-dor” envía el recibo al “autoriza-dor” por otro sello, y por último, este le envía una copia a el “bodegista-dor”. Así, el “bodegista-dor” descuenta la cantidad de artículos vendidos (y pone un sello) y los entrega (otro sello)... etc.

Supongamos que cada uno de estos señores “-dor” tiene twitter (o un mensajero) y emite sus acciones como alienado (una por vez). Supongamos también que hay un fan de los “-dor” llamado “conta-dor”, encargado de fiscalizar el dinero y los artículos vendidos, y que no pierde un mensaje.

Supongamos también que al “vende-dor” no le cae bien el “bodegista-dor” y husmea su canal llevando la cuenta de las ventas efectivamente entregadas (la comisión depende de ello). Y como la desconfianza es algo contagioso, el  “autoriza-dor” hace lo mismo.
Agreguemos varios “vende-dor” (para hacer esto ameno) con su propia identificación (id) y hagamos que sigan la rutina del primero.

Si esto fuera orientado a objetos, cada “compra-dor” creará sus propios “-dor” usando la taxonomía de la tienda (siendo él mismo un “-dor”). Estos clones de los “-dor” existirán mientras sean necesarios (ocupando un lugar en la memoria de la tienda) y serán desechados luego de registrar sus actos; excepto el “conta-dor” que existe sólo los jueves y se encarga de analizar todos los registros de la semana (la tarde completa) y luego entrega su informe para dejar de existir.

Antes de continuar, la notación Erlang para hablar de Actores:
    ->             Inicio de rutina (entonces).
    {}             Tupla
    []             Lista
    atom        Etiqueta (empieza en minúsculas.)
    Var          Variable (empieza en mayúsculas.)
    !               Send()
    self()   Devuelve mi identificador (algo parecido a un número).

Cualquiera entiende este mensaje:

  { quiero, YO, "Videojuego", "Nientiendo" }

Enviar mensaje a Papá:

  Papa ! { quiero, self(), "Videojuego", "Nientiendo" }

Donde “Papá” es un identificador de proceso (Pid).

El padre, que tiene varios hijos y no sabe cual de ellos manda el mensaje, responde con un mensaje genérico:

  Hijo ! { noHayDinero }

Uniendo ambos mensajes, el mailbox de Papá será:

receive
  { quiero, Hijo, Articulo, Marca } ->
     Hijo ! { noHayDinero }
end.

El resultado de self() se asigna a la variable Hijo mediante Pattern Matching. En Artículo queda "Videojuego" y en Marca queda "Nientiendo".


Volviendo a la tienda, el mensaje entre uno de los "vendedor" y el "descontador" será:

descontador ! { descontar, self(), Cantidad, Valor }

El descontador captura el Pid del vendedor en la variable Vendedor, hace un proceso y le devuelve otro mensaje:

receive
  {descontar, Vendedor, Cantidad, Valor } ->
      ValorConDescuento = Valor * (1 - PorcentajeDescuento),
      Vendedor ! {descuento, Cantidad, ValorConDescuento }
end.

También debe notificar al "contador" y seguir existiendo, razón por la cual se llama a sí mismo manteniendo su estado interno (el porcentaje de descuento para el artículo). El "descontador" sería:

descontaDor(PorcentajeDescuento) ->
  receive
     {descontar, Vendedor, Cantidad, Valor } ->
        ValorConDescuento = Valor * (1 - PorcentajeDescuento),
        Vendedor ! {descuento, Cantidad, ValorConDescuento },
        contador ! {descuento, Cantidad, ValorConDescuento },
        descontaDor(PorcentajeDescuento)
  end.

%% Vendedor es una variable, al igual que Cantidad, Valor y ValorConDescuento.
%% "contador" y "descuento" son etiquetas

Los "vendedor" también se comunican con el "autorizador" y el "bodegizador". Una idea simple del código para este actor:

vendeDor(PrecioArticulo, CompradorActual, VentasLogradas) ->
  receive
    {iniciarVenta, Comprador, Cantidad } ->
       %% Se omite la lógica para atender un comprador a la vez
       Valor = Cantidad * PrecioArticulo,
       descontador ! {descontar, self(), Cantidad, Valor},
       vendeDor(PrecioArticulo, Comprador, VentasLogradas);
    {descuento, Cantidad, Valor } ->
       autorizador ! {autorizar, Cantidad, Valor},
       vendeDor(PrecioArticulo, CompradorActual, VentasLogradas);
    {finVenta, _, _ } ->
       CompradorActual ! {retirarMercancia },
       vendeDor(PrecioArticulo, _, VentasLogradas + 1)
 end.
%%Donde “_” significa no importa o variable vacía.

El mensaje “iniciarVenta” llega de un “comprador” y el mensaje “finVenta” del “bodegador”.

Para “lanzar” estos procesos (algo como un constructor), se usa spawn (desovar), así:

   Pid_descontador = spawn(descontaDor, [0.01]).
   Pid_vendedor = spawn(vendeDor, [20.50, _, 0]).

Y como “descontador” solo hay uno, lo registramos con una identidad única (lo mismo con  autorizador, bodegador y contador):

   register(descontador, Pid_descontador).
   ...
   register(contador, Pid_contador).

Por esta razón, tanto el “vendedor” como el "descontador" no necesitaron los Pids para enviarles mensajes.

Luego de esta maraton, quedan de ejercicio mental los demás actores. La idea general, es que estos actores existen siempre en memoria, atendiendo y enviando mensajes sin necesidad de ser instanciados y destruidos cada vez, y ocupando muy poco espacio en memoria. Son concurrentes, asincrónicos e independientes, pues no comparten información de estado.

Volviendo al artículo de Angel que originó todo esto: ¿para qué la Base de Datos? Y me respondo, tal vez como un histórico, como un almacén de comprobantes (recibos y sellos de la tienda).


Para quién quiera explorar el origen (o entender de verdad): Erlang.

Sigue con: El acto termina.

Relacionados:
Erlang: Programación funcional y concurrente.
Mapeo de actores a objetos.

Erlang: Mapping Objects Classes to Actors Model

You can "map" an object class to actor. Lets see a simple example:

public class myClass

{

   private string myProperty;

   public myClass(string argInit) {

      myProperty = argInit;

   }

   public myMethod(string arg1, int arg2) {

      //do something

      myProperty = arg1 + arg2.toString();

   }

}

The actor (process with Erlang) is:

myClass(myProperty) ->

   receive

      {myMethod, Arg1, Arg2 } ->

         myClass(Arg1 ++ Arg2)

   end.

And it's "constructor" is the spawn of process:

spawn( myClass, [argInit ]).

Thus, an object's method (OOP) is an actor's message. Like UML sequence diagrams.

Erlang y OOP

Mi primera experiencia de programación fue con Erlang, un lenguaje de programación orientado a la concurrencia (Concurrency Oriented Programming) y cuyo énfasis es la confiabilidad. Se trata de un lenguaje funcional.
El modelo de memoria está basado en "tail-call optimization" de unidades con estado llamadas "procesos". Estos procesos no guardan información de estado compartida, comunicándose únicamente mediante mensajes. Si un proceso es modificado y algo falla, se restituye a su estado previo (parecido a la destrucción y vuelta a crear del objeto, pero en memoria.)
Estas características permiten actualizaciones en caliente de la aplicación, cosa que no se ve en los ambientes OOP.

Sin entrar a realizar una introducción al lenguaje; existe una cierta correspondencia entre los modelos Erlang y OOP. Por ejemplo, una clase con propiedades y métodos:

public class myClass

{

   private string myProperty;

   public myClass(string argInit) {

      myProperty = argInit;

   }

   public myMethod(string arg1, int arg2) {

      //do something

      myProperty = arg1 + arg2.toString();

   }

}

En un proceso en Erlang:

myClass(myProperty) ->

   receive

      {myMethod, Arg1, Arg2 } ->

         myClass(Arg1 ++ Arg2)

   end.

Cuyo constructor queda implícito en el desove (spawn) del proceso:

spawn( myClass, [argInit ]).

Asi que un método de un objeto (OOP) es un mensaje en Erlang, tal como se describe en los diagramas de secuencia UML.

YUI 3: Modelo-Vista-Controlador (MVC) con JavaScript

Este ejemplo de "hello world" sale de http://cakebaker.42dh.com/2007/03/17/mvc-with-javascript/ Lo que hice fue actualizarlo para YUI 3.

--- HTML ---

<a id="bubbleUserEvent" href="javascript:void(0);">
   notify user action to controller 
</a>
<div id="feedBackMessages"> </div>

--- JavaScript ---

 YUI().use('event', function (Y) {
  var model = {
   getText: function () {
    return 'hello world';
   }
  };
  var view = {
   showMessage: function (message) {
    Y.Node.one('#feedBackMessages').set('innerHTML', message);
   }
  };
  var controller = {
   sayHelloWorld: function () {
    view.showMessage(model.getText());
   }
  };
  //Add event handler to view's control
  Y.on('click', controller.sayHelloWorld, '#bubbleUserEvent');
});

Capas de Software

Sostengo que el concepto de "tres capas"(three-tier) o "n capas" (n-tier) de Software es más una metodología que una arquitectura. 

Para explicar la premisa anterior, me baso en el mismo simil arquitectónico que la origina. Veamos:

Un albañil, con la experiencia acumulada y si conoce lo esencial, puede llegar a construir una casa: muros, cimientos, ventanas, tuberías, conductos... etc. No sería una casa "mal hecha" porque no se cae, tiene habitaciones donde poner las camas, electricidad, agua, corredores y todo lo demás.
En el caso del Software es igual: tiene un GUI, una capa de negocio (que puede estar alojada en el servidor) y una DB para la persistencia. Con esto funciona.

Ahora bien, en mi concepto, el acto arquitectónico es un acto deliberado de creación sobre el espacio que busca incluir lo estético y lo estructural. Esto con el fin de obtener un espacio vital agradable y armónico.

Conocemos viviendas con corredores estrechos, cuartos oscuros, columnas mal dispuestas, escaleras potencialmente letales, baños que miran a la puerta de la calle... etc. Todas ellas habitadas y funcionando. Tienen techo, dos o tres pisos y pagan impuestos. Pasa igual con edificios completos y con conjuntos residenciales. Y todos ellos cumplen con ciertos mínimos que nos sirven para identificarlos como viviendas. Mínimos como: acceso a la calle, algunos servicios domiciliarios, techo y cerramiento. Esta situación es idéntica en el ámbito del Software.

Una casa (edificio o conjunto) diseñada por un arquitecto (bueno) tendrá los mismos elementos y funcionará como un todo armónico, facilitando la vida de los habitantes, de la comunidad y de los proveedores de servicios.


En conclusión, Larman dice que se trata de un patrón arquitectónico, pero en este contexto (y abusando del simil) la separación en capas sería más bien un patrón urbanístico.

Obtener un registro al azar desde un archivo Access(.mdb)

//Iniciar el generador pseudo-aleatorio
Int32 iPreSeed = Convert.ToInt32(DateTime.Now.Ticks % Int32.MaxValue);
Random fixRand = new Random((new Random(iPreSeed)).Next());

//Establecer la cadena de conexión
String ConnectionString = "Provider=Microsoft.Jet.OleDb.4.0;Data Source=" +
Server.MapPath("~/App_Data/test.mdb") + ";";

//Crear el objeto que conecta a la DB en Access
OleDbConnection _Connection = new OleDbConnection(ConnectionString);

try
{
//Abrir la conexión. Suena algo oscuro pero tiene que ver con la
//cantidad de usuarios concurrentes que pueden acceder a la DB.
//Es un bien preciado que no debe malgastarse.
_Connection.Open();

//Comando SQL a ejecutar. Solo obtiene los IDs de la tabla.
//Nota: Esta no es una práctica recomendable. Se usa para 
//          ejemplificar. Ver más abajo como usar un Store Procedure.
OleDbCommand _Command = new OleDbCommand("SELECT TestID FROM Test", _Connection);

//Ejecutar el comando SQL
OleDbDataAdapter myAdapt = new OleDbDataAdapter(_Command);

//Obtener el resultado del SQL en un objeto Tabla
DataTable myDataTable = new DataTable();
myAdapt.Fill(myDataTable);

//Obtener un ID al azar de la Tabla
int iRndTestID = fixRand.Next(0, myDataTable.Rows.Count -1);
string testRndID = myDataTable.Rows[iRndTestID][0].ToString();

//Nueva consulta SQL para obtener el registro elegido al azar.
//Usa un Store Procedure en lugar de un SQL.
_Command = new OleDbCommand("[TestByID]", _Connection);
_Command.CommandType = CommandType.StoredProcedure;
_Command.Parameters.AddWithValue("@testID", testRndID);

myAdapt = new OleDbDataAdapter(_Command);

myDataTable = new DataTable();
myAdapt.Fill(myDataTable);
}
catch (Exception Err){}
finally
{
//No olvidar cerrar la conexión.
_Connection.Close();
}

//Store procedure TestByID usado en el paso anterior
--------------[TestByID] Query--------------------

SELECT TestID
FROM Test
WHERE TestID = @testID

---------------------------------------------------

//CONCLUSIONES
//Se recomienda usar Store Procedures (SP) en lugar de sentencias
//SQL debido a que permite cambiar el programa o la base de datos
//sin muchos contratiempos. Si el programa conoce la estructura de la
//base de datos quedará ligado a ella. Esto se conoce como
//acoplamiento y debe ser reducido lo más posible. Al usar SPs se
//cumple con mantener el acoplamiento bajo.