Objetos Distribuidos

On 10/13/2010 07:52 PM, Mariano Martinez Peck wrote:
> Sipi :)  Acá están los slides por si alguien está interesado:
> http://www.slideshare.net/esug/swapping-esug2010

ah! pero eso es trivial... no, verso eh! ja, para nada, mientras miraba
tu charla en la ESUG pensaba "este flaco es un capo, HIZO todo eso!"

che, para mi que tu tesis no va a estar terminada hasta que implementes
esto para SqueakNOS y saquemos el file system de abajo, que decís? :)

   saludos,
   gera

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Ah, para clarificar.

>> Che, si es esto

esto = "tener proxies y mandar mensajes remotos a objetos sin perder
la identidad del objeto", por ejemplo...

>> a lo que Mariano se referia, no nos olvidemos de
>> GemStone que hace no se, 25 años que esta con su base de objetos
>> (esencialmente se puede ver como una imagen compartida entre N otras
>> imagenes, con transacciones).  Si eso

eso = "resolver el problema de distribucion de mensajes a objetos
distribuidos de manera razonablemente general, como por ejemplo lo
hace GemStone"...

>> es lo que aca se describio como
>> "trivial", desde ya que de ninguna manera es trivial ese problema.
>> Trivial podra ser una primera aproximacion a la serializacion, pero
>> literalmente "objetos distribuidos" asi como en GemStone, ni ahi.

Andres.

2010/10/11 Angel Java Lopez <[hidden email]>:
> Hola gente!
>
> Ah! Yo, por lo menos, nunca mencione GemStone (que alguien bueno de Sugar
> (Smalltalk Users Group de Argentina) me comento en los noventa, el bueno de
> Leandro Caniglia, recuerdo su implementacion en Luchetti, que recuerde).
>
> Lo que me gustaria (tengo codigo, pero no tengo test, asi que nada de
> publicado ahora), es:
>
> anObject msg: par1 ....
>
> y anObject sea un proxy local, que deriva a un objeto residente en otra
> maquina ese mensaje. El programador puede haberlo creado local (como para
> probar su algoritmo en una sola maquina) o puede haberlo creado en otro nodo
> de una red. En los casos de uso que tengo en mente, el programador sabe que
> hay un costo en eso, asi que no esta conversando con esos objetos a cada
> milisegundo. Es mas: te doy una tarea, despues, llegado el caso, en algun
> momento, por otro canal, recibire una respuesta.
>
> Tambien quiero implementar:
>
> anObject msg: par1 ...
>
> y que anObject por abajo, derive el mensaje a uno, a todos, o a algunos de
> otros objetos, remotos o locales.
>
> Y algo ortogonal a todo eso, que tengo implementando, pero tendria que
> unirlo con lo de remoting:
>
> anObject msg: par1 ...
>
> que anObject reciba el mensaje, y lo atienda en su propio thread. Recibe el
> mensaje, lo coloca en una cola en memoria, y lo atiende en su propio thread,
> cuando este disponible. El objeto que envie el mensaje sigue su camino. Esto
> permite implementar algoritmos en paralelo, sin el tema "te envio algo, y te
> espero a que termines para seguir yo".
>
> Interesante el paper que enviaste, lo conocia, pero no lo recordaba. Ya lo
> mando a twitter.
>
> No entendi si "si es esto a lo que Mariano se referia", y "Si eso es lo que
> aca", digo, no entendi "si esto" en la primera frase se refiere a lo mismo a
> lo que se refiere "si eso", en la segunda.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
> 2010/10/11 Andres Valloud <[hidden email]>
>>
>> Che, si es esto a lo que Mariano se referia, no nos olvidemos de
>> GemStone que hace no se, 25 años que esta con su base de objetos
>> (esencialmente se puede ver como una imagen compartida entre N otras
>> imagenes, con transacciones).  Si eso es lo que aca se describio como
>> "trivial", desde ya que de ninguna manera es trivial ese problema.
>> Trivial podra ser una primera aproximacion a la serializacion, pero
>> literalmente "objetos distribuidos" asi como en GemStone, ni ahi.
>>
>> Ah, hablando de esto, hace poco encontre este articulo que me parecio
>> interesante.
>>
>> http://www.rgoarchitects.com/Files/fallacies.pdf
>>
>> 2010/10/11 Angel Java Lopez <[hidden email]>:
>> > Hola gente!
>> >
>> > Interesante la discusion del Thread "Blog", pero tambien algo se fue por
>> > las
>> > ramas... Cambio de titulo en este mensaje.
>> >
>> > Estuve agregando objetos distribuidos a mi pet project [1], quedo algo
>> > asi:
>> >
>> > http://pastie.org/1213856
>> >
>> > Tengan encuenta que no tengo libreria de clases de base, asi que tengo
>> > que
>> > comenzar desde nil subclass:... ';-)
>> >
>> > Puedo:
>> >
>> > - Levantar un servidor (tecnologia Remoting .NET), en nodo A.
>> > - Levantar un cliente remoto a ese servidor, en nodo B.
>> > - Definir una clase en nodo B.
>> > - Exportar su definicion de B a nodo A.
>> > - Ejecutar desde nodo B algo en nodo A.
>> > - Evaluar en nodo A y devolver el objeto serializado (contemplando
>> > grafos
>> > con ciclos, repeticion de objetos, etc..) a B.
>> >
>> > Me falta evaluar en nodo A y que el resultado quede en A, viajando a B
>> > una
>> > especie de proxy, de tal manera que invocando a ese objeto en B, se
>> > ejecute
>> > el mensaje en nodo A.
>> >
>> > Mi idea es que si B devuelve un objeto a A, ese resultado viaja
>> > completo.
>> > Sino, definiria algo como
>> >
>> > ^host asProxy: result.
>> >
>> > Tendria que escribir post, pero por ahora, tengo esto para mostrar.
>> >
>> > [1] http://code.google.com/p/ajtalk
>> >
>> > Nos leemos!
>> >
>> > Angel "Java" Lopez
>> > http://www.ajlopez.com
>> > http://twitter.com/ajlopez
>> >
>> >
>> >
>> > --
>> > To post to this group, send email to [hidden email]
>> > To unsubscribe from this group, send email to
>> > [hidden email]
>> >
>> > http://www.clubSmalltalk.org
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Que rápido. Me parece que pasó menos de una semana.

Unas preguntas:

1. ¿Cómo publicas los objetos que reciben mensajes remotos para ser
usados por las máquinas remotas? ¿Existe un servicio básico que indica
cuáles son etos objetos y los mensajes que están dispuestos a recibir?
2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue un mensaje
a un objeto cuando aún está ejecutando el mensaje anterior?
3. Cuando declaras una clase en M1 y la exportas a M2, ¿recompilas la
clase en M2 o simplemente envías el objeto compilado?
4. Los objetos que son pasados como parámetro son siempre serializados o
también se puede enviar un proxy de ellos (por ejemplo podría ser "ob
asProxy") de modo que automáticamente se cree un proxy de ese objeto en
M2 apuntando al objeto en M1. En EJB eso se puede hacer aunque es una
mala práctica, porque luego es natural que el protocolo de comunicación
se vuelva "chatty".
5. ¿Porqué quieres los objetos que no se han usado se serialicen?
¿Quedan vivos los resultados que se enviaron a otra máquina?
6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que tengo un
arreglo de proxies en M0 donde cada elemento del arreglo tiene un proxy
a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada petición se
hace de manera asíncrona (cuando la respuesta se recibe se ejecuta un
bloque). ¿Consideras eso implementable?

Tengo entendido que en Squeak existe un ambiente distribuido de objetos
llamado Croquet. Y bueno en Open Cobalt, que al parecer es un mundo
virtual construido sobre Croquet, se puede hacer mundos 3D sobre los que
se puede ejecutar aplicaciones Windows y compartirlas con otros
usuarios...

http://en.wikipedia.org/wiki/Open_Cobalt

Según recuerdo la gran idea de Croquet es que en vez de enviar los
objetos para ejecutar de manera remota, se puede enviar "la computación"
para ejecutarla localmente y de esa manera obtener un mejor desempeño.

Saludos,
Guillermo.

On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote:
> Hola gente!
>
> Ya tengo objetos distribuidos en mi pet project AjTalk:
>
> http://pastie.org/1213856
>
> Puedo comunicar N maquinas, cada una puede ser cliente o servidora de
> otra maquina.
> Puedo declarar una clase en maquina M1, y exportarla a M2.
> Puedo ejecutar texto definido en M1, en la maquina M2.
> Puedo evaluar texto definido en M1, en la maquina M2, y serializar
> (como copia) el resultado calculado en M2, para que viaje y se
> reifique en M1.
> Puedo evaluar texto definido en M1, en la maquina M2, y pedirle que
> devuelva el proxy que apunta a ese objeto que queda en M2.
> Usando el proxy en M1, como un objeto mas, puedo enviar mensajes al
> objeto remoto que todavia reside en M2.
>
> Hay que mejorar puntos, pero la "base esta" ;-)
>
> Proximos pasos: investigar la idea de "objeto intermedio" de Mariano,
> implementarlo, implementar que los objetos que no se usan desde un
> tiempo se serializen, implementar transacciones de objetos como la
> describi en otro thread... pero tengo que ver en que orden, que
> tiempo.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/11 Andres Valloud <[hidden email]>
>         Ah, para clarificar.
>
>         >> Che, si es esto
>
>         esto = "tener proxies y mandar mensajes remotos a objetos sin
>         perder
>         la identidad del objeto", por ejemplo...
>
>         >> a lo que Mariano se referia, no nos olvidemos de
>         >> GemStone que hace no se, 25 años que esta con su base de
>         objetos
>         >> (esencialmente se puede ver como una imagen compartida
>         entre N otras
>         >> imagenes, con transacciones).  Si eso
>
>
>         eso = "resolver el problema de distribucion de mensajes a
>         objetos
>         distribuidos de manera razonablemente general, como por
>         ejemplo lo
>         hace GemStone"...
>
>         >> es lo que aca se describio como
>         >> "trivial", desde ya que de ninguna manera es trivial ese
>         problema.
>         >> Trivial podra ser una primera aproximacion a la
>         serializacion, pero
>         >> literalmente "objetos distribuidos" asi como en GemStone,
>         ni ahi.
>
>
>         Andres.
>
>
>
>         2010/10/11 Angel Java Lopez <[hidden email]>:
>         > Hola gente!
>         >
>         > Ah! Yo, por lo menos, nunca mencione GemStone (que alguien
>         bueno de Sugar
>         > (Smalltalk Users Group de Argentina) me comento en los
>         noventa, el bueno de
>         > Leandro Caniglia, recuerdo su implementacion en Luchetti,
>         que recuerde).
>         >
>         > Lo que me gustaria (tengo codigo, pero no tengo test, asi
>         que nada de
>         > publicado ahora), es:
>         >
>         > anObject msg: par1 ....
>         >
>         > y anObject sea un proxy local, que deriva a un objeto
>         residente en otra
>         > maquina ese mensaje. El programador puede haberlo creado
>         local (como para
>         > probar su algoritmo en una sola maquina) o puede haberlo
>         creado en otro nodo
>         > de una red. En los casos de uso que tengo en mente, el
>         programador sabe que
>         > hay un costo en eso, asi que no esta conversando con esos
>         objetos a cada
>         > milisegundo. Es mas: te doy una tarea, despues, llegado el
>         caso, en algun
>         > momento, por otro canal, recibire una respuesta.
>         >
>         > Tambien quiero implementar:
>         >
>         > anObject msg: par1 ...
>         >
>         > y que anObject por abajo, derive el mensaje a uno, a todos,
>         o a algunos de
>         > otros objetos, remotos o locales.
>         >
>         > Y algo ortogonal a todo eso, que tengo implementando, pero
>         tendria que
>         > unirlo con lo de remoting:
>         >
>         > anObject msg: par1 ...
>         >
>         > que anObject reciba el mensaje, y lo atienda en su propio
>         thread. Recibe el
>         > mensaje, lo coloca en una cola en memoria, y lo atiende en
>         su propio thread,
>         > cuando este disponible. El objeto que envie el mensaje sigue
>         su camino. Esto
>         > permite implementar algoritmos en paralelo, sin el tema "te
>         envio algo, y te
>         > espero a que termines para seguir yo".
>         >
>         > Interesante el paper que enviaste, lo conocia, pero no lo
>         recordaba. Ya lo
>         > mando a twitter.
>         >
>         > No entendi si "si es esto a lo que Mariano se referia", y
>         "Si eso es lo que
>         > aca", digo, no entendi "si esto" en la primera frase se
>         refiere a lo mismo a
>         > lo que se refiere "si eso", en la segunda.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         > 2010/10/11 Andres Valloud <[hidden email]>
>         >>
>         >> Che, si es esto a lo que Mariano se referia, no nos
>         olvidemos de
>         >> GemStone que hace no se, 25 años que esta con su base de
>         objetos
>         >> (esencialmente se puede ver como una imagen compartida
>         entre N otras
>         >> imagenes, con transacciones).  Si eso es lo que aca se
>         describio como
>         >> "trivial", desde ya que de ninguna manera es trivial ese
>         problema.
>         >> Trivial podra ser una primera aproximacion a la
>         serializacion, pero
>         >> literalmente "objetos distribuidos" asi como en GemStone,
>         ni ahi.
>         >>
>         >> Ah, hablando de esto, hace poco encontre este articulo que
>         me parecio
>         >> interesante.
>         >>
>         >> http://www.rgoarchitects.com/Files/fallacies.pdf
>         >>
>         >> 2010/10/11 Angel Java Lopez <[hidden email]>:
>         >> > Hola gente!
>         >> >
>         >> > Interesante la discusion del Thread "Blog", pero tambien
>         algo se fue por
>         >> > las
>         >> > ramas... Cambio de titulo en este mensaje.
>         >> >
>         >> > Estuve agregando objetos distribuidos a mi pet project
>         [1], quedo algo
>         >> > asi:
>         >> >
>         >> > http://pastie.org/1213856
>         >> >
>         >> > Tengan encuenta que no tengo libreria de clases de base,
>         asi que tengo
>         >> > que
>         >> > comenzar desde nil subclass:... ';-)
>         >> >
>         >> > Puedo:
>         >> >
>         >> > - Levantar un servidor (tecnologia Remoting .NET), en
>         nodo A.
>         >> > - Levantar un cliente remoto a ese servidor, en nodo B.
>         >> > - Definir una clase en nodo B.
>         >> > - Exportar su definicion de B a nodo A.
>         >> > - Ejecutar desde nodo B algo en nodo A.
>         >> > - Evaluar en nodo A y devolver el objeto serializado
>         (contemplando
>         >> > grafos
>         >> > con ciclos, repeticion de objetos, etc..) a B.
>         >> >
>         >> > Me falta evaluar en nodo A y que el resultado quede en A,
>         viajando a B
>         >> > una
>         >> > especie de proxy, de tal manera que invocando a ese
>         objeto en B, se
>         >> > ejecute
>         >> > el mensaje en nodo A.
>         >> >
>         >> > Mi idea es que si B devuelve un objeto a A, ese resultado
>         viaja
>         >> > completo.
>         >> > Sino, definiria algo como
>         >> >
>         >> > ^host asProxy: result.
>         >> >
>         >> > Tendria que escribir post, pero por ahora, tengo esto
>         para mostrar.
>         >> >
>         >> > [1] http://code.google.com/p/ajtalk
>         >> >
>         >> > Nos leemos!
>         >> >
>         >> > Angel "Java" Lopez
>         >> > http://www.ajlopez.com
>         >> > http://twitter.com/ajlopez
>         >> >
>         >> >
>         >> >
>         >> > --
>         >> > To post to this group, send email to
>         [hidden email]
>         >> > To unsubscribe from this group, send email to
>         >> > [hidden email]
>         >> >
>         >> > http://www.clubSmalltalk.org
>         >>
>         >> --
>         >> To post to this group, send email to
>         [hidden email]
>         >> To unsubscribe from this group, send email to
>         >> [hidden email]
>         >>
>         >> http://www.clubSmalltalk.org
>         >
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to
>         > [hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>

> --

> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--

Simplex Veri Sigillum

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

>
> rectRemoto := host evaluate: 'rectEnM2 asRemote'.
>
> queda en la variable local rectRemoto un proxy al objeto Rectangle
> rectEnM2 que quedo en M2.

Qué fácil de usar.

Sería aún más fácil si hubiera un Publisher tal que:

publisher := Publisher new.
publisher publish: anObject.

Dejara ese objeto publicado, la lo cual bastaría con que:

Publisher>>publish: anObject
       host evaluate: anObject + ' asRemote'


¿Cómo convierto <<anObject>> en un símbolo que lo represente? Se me
olvidó...

> Cualquier mensaje
>
> rectRemoto width: 10.
>
> se envia a M2 y se EJECUTA en M2.
>
> Si hago desde M1:
>
> rectCopia := host evaluate: 'rectEnM2'.
>
> viaja serializado el rectangulo y queda una copia en M1, que se invoca
> en M1 y asi.
>
> Guillermo, vamos a tus preguntas:
> 1. Los publico evaluando algo en M2 y aplicando el mensaje que tienen
> todos los Object (ver el pastie que envie
> http://pastie.org/1213856
> como se define el mensaje asRemote);

AsRemote es una primitiva en tu sistema...

> Entonces, si desde M2 a M1 quiero enviar un resultado serializado,
> implemente devuelvo
>
> result
>
> Si quiero enviar el objeto resultado pero como "objeto clavado en M2",
> devuelvo
>
> result asRemote

Pero el objeto fue definido íntegramente en M1, ¿no?

Porque no creo que sea muy agradable que el código de M1 se comporte
diferente dependiendo del código que ejecuta en M2.

En otras palabras, defino todo mi código en M1, y desde ahí mando
objetos a ejecutar a todas las máquinas que quiera, pero siempre la
definición que vale es la que está en M1.

De modo que el result asRemote lo programé en M1 para que el objeto se
quede en M2... (preferiría que el programador no se preocupe de esa
cosas, tal como pasa con los EJBs).

>
> Es decision del programar si lo hace de una forma u otra.
>
> 2. Si llega un mensaje a un objeto cuando esta procesando otro, es lo
> mismo que hago cuando estoy en local, con objetos locales y
> "threads" (no tengo un full Process class implementado todavia): si
> dos "threads" acceden al mismo objeto, es cuestion del programador no
> hacer nada o poner algun lockeo.

En los EJBs está prohibido el lockeo, porque la experiencia dice que un
programador en la "enterprise" no sabe usar locks, y si sabe, luego
llega otro programador de la "enterprise" y se pisa lo que hizo el
primero... ;-)

En otras palabras es el contenedor EJB (un objeto que funciona como
registro de qué EJBs hay y cuáles están ejecutando) el que se encarga de
coordinar ya no los lockeos, sino que las transacciones, es un nivel más
alto de abstracción.

>  Volviendo entonces al caso distribuido. Cuando desde M1 invoco a
> rectRemoto en M2, se ejecuta en M2, de la misma forma: si en M2 hay
> varios accediendo a ese objeto (que es local en M2, y remoto en M1),
> es lo mismo que pasa en cualquier Smalltalk, creo: es cuestion de
> programar si quiero contemplar ese caso o no.

En Lisp se resuelve haciendo que los objetos sean inmutables. Da la
casualidad de que en el caso de los stateless session beans, también.

>
> Como quiero tener cada vez mas proceso distribuido, y en paralelo
> (distribuido o no), he agregado a AjTalk el concepto de "agente" (lo
> podria haber llamado actor, por ahora quedo asi).

No está mal el nombre.

> Por ejemplo:
>
> Object agent: #MyAgent
>
> Es como una clase, pero cuando crea objetos, los crea normales, con un
> cambio: se cambio el proceso de enviarle un mensaje. Cuando:
>
> myAgent := MyAgent new.
> myAgent haceAlgoCuandoPuedas: usandoEsteArreglo
>
> cuando envio ese mensaje, lo coloco en una cola. El agente va
> procesando en paralelo mensajes de esa cola.

¡¡¡En paralelo!!! Que rara la idea de usar una cola para hacerlo en
paralelo, si generalmente es al revés, la cola es para serializarlos (en
el sentido de terminar uno para empezar el otro).

>  Tranquilamente combinar distribuido y agentes. Desde M1 con host
> apuntando a M2, puedo hacer:
>
> myRemoteAgent := host evaluate: 'MyAgente new asRemote'
>

En Smalltalk un objeto inmutable es aquel que no tiene métodos
mutadores. De modo que como es casi imposible saber si un método va a
mutar un objeto o no, creo que la única solución sería a nivel de la VM
detectar el cambio y si el objeto va a cambiar, entonces generar una
copia...

Si la copia es por thread (o por Process) entonces se mantendría una
vista consistente del mundo en ese thread.

> 3. En el pastie que envie, esta el codigo de como hago la exportacion.
> Es
>
> host export: ClaseEnM1
>
> Lo que hago es enviar el string que define a la clase, y se ejecuta en
> M2. Si esa clase deriva de otra que NO esta en M2, es responsabilidad
> del programador (todavia, estoy pensando alternativas), haber hecho
> antes:
>
> host export: ClaseEnM1 superclass

Pero es fácil. Si se cae el compilador, que tenga un hook que diga
askFor: clase que no encuentra... al nodo que contiene todas las clases
(o bien al nodo que hizo la petición).

>
> No hay forma de saber (todavia) si en M2 YA esta esa clase o no.

Si se cae la ejecución con un error que dice "clase no existe"... ;-)

>
> 4. Los parametros que paso al objeto remoto, son serializados (saca
> una copia que se reifica del otro lado). Si desde M1 hago
>
> objetoRemotoEnM2 haceDunga: obj1 yMasDunga: obj2
>
> tanto obj1 como obj2 se serializan. Si quisiera que no viajaran,
> deberia poner (tengo que testear, no tengo un caso ahora):
>
> objetoRemotoEnM2 haceDunga: obj1 asRemote yMasDunga: obj2 asRemote
>

Claro, pero preferiría que cada objeto decida si viaja o no. Puede que
algunos objetos ya estén acá o que realmente estén allá. En EJBs se usa
el concepto de JNDI para saber dónde están los objetos.

JNDI es básicamente un servicio como DNS que dice www.google.com es
182.123.45.67, pero en este caso le dices el nombre del EJB y te dice en
qué máquina está.

> 5. Queria seguir los pasos sugeridos por Mariano. Por explorar ese
> tema. Podria usarse, como presenta Mariano en su charla, para cuando
> hay poca memoria.

Buena idea y bastante general.

>  Otra que se me ocurre, es para implementar todo un dominio de objetos
> en memoria, de forma transaparente. Por temas de limite de memoria,
> necesitaria no tener todos al mismo tiempo en memoria. Los cambios a
> los objetos en memoria, podria ir serializandolos, a un archivo de
> cambios binario.

Prefiero una BD o algo maś simple: jdbm, un tabala de hashing en disco.

> Tengo algunas ideas de implementacion, pero implica usar el objeto
> intermedio que comento Mariano. Yo veo a ese objeto intermedio como
> una celda en lo que era un Object Table. Quisiera ponerle ahi lo
> minimo, y como explique en otro email, que esa "celda"/Objeto
> intermedio apunte al real, o a un decorador del real (para poner mas
> conducta como la que sugeria Mariano, pero no toda en la celda, objeto
> intermedio).

Supongo que basta con poner la llave del hashmap para que lo encuentre
en el disco.

>
> Pero aclaro: esto de serializar lo no usado, es ortogonal a lo de
> distribuido.

Claro. Yo partiría al revés: Todo es no usado. Todo al disco. De esa
manera te aseguras que si tienes una implementación rápida como jdbm (10
ms por consulta) con eso basta.

Obviamente siempre hay cosas que uno quiere mantener en memoria, la
clase String por ejmplo, o el mecanismo que va a buscar al jdbm. Además
por cada operación remota no quieres hacer más de una búsqueda en jdbm,
debes tener eso en consideración.

Ahora bien, yo hablo de apicaicones de negocios que siempre van a la bd
y por ende 10 ms no es nada, es sólo ejecutar otro SQL.

Pero en un compilador eso sería desastroso.

>  Era para local, un experimento para seguir las ideas de Mariano y su
> equipo (pregunto, enlace del equipo? blog? otras publicaciones?)
>
> 6. No vi en detalle MapReduce, solo algo hace dos anios, jugando con
> MPI (Message Passing Interface), en un cluster. Pero apenas para hacer
> una demo y calcular algo. Si lo hiciera con AjTalk... hmmm... a ver
> seria algo como:
>
> myLocalAgent := MyLocalAgent new. "recibira los resultados"
>
> "y por cada hostN, haria"
>
> hostN export: MyWorkerClass.
>
> myRemoteWorker := hostN evaluate: 'MyWorkerClass new'.
> myRemoteWorker process: thisDataPartN sendingResultTo: myLocalAgent
> asRemote "para que no vaya serializado y el local agent siga aca, en
> M0, digamos"

Sí, se ve simple. Habría que tener unas cuantas máquinas para probarlo,
algunas que se caen, un protocolo que defina cuanto se espera a una
máquina que se demora (yo no esperaría nada, mandaría las consultas que
no han llegado a las máquinas que se van desocupando). Eso es fácil de
hacer.

Lo único que no me gusta es C#. ¿Porqué no usar Java?

>
> Se entendio? Cualquier cosa, me preguntan.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/17 Guillermo Schwarz <[hidden email]>
>         Que rápido. Me parece que pasó menos de una semana.
>
>         Unas preguntas:
>
>         1. ¿Cómo publicas los objetos que reciben mensajes remotos
>         para ser
>         usados por las máquinas remotas? ¿Existe un servicio básico
>         que indica
>         cuáles son etos objetos y los mensajes que están dispuestos a
>         recibir?
>         2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue
>         un mensaje
>         a un objeto cuando aún está ejecutando el mensaje anterior?
>         3. Cuando declaras una clase en M1 y la exportas a M2,
>         ¿recompilas la
>         clase en M2 o simplemente envías el objeto compilado?
>         4. Los objetos que son pasados como parámetro son siempre
>         serializados o
>         también se puede enviar un proxy de ellos (por ejemplo podría
>         ser "ob
>         asProxy") de modo que automáticamente se cree un proxy de ese
>         objeto en
>         M2 apuntando al objeto en M1. En EJB eso se puede hacer aunque
>         es una
>         mala práctica, porque luego es natural que el protocolo de
>         comunicación
>         se vuelva "chatty".
>         5. ¿Porqué quieres los objetos que no se han usado se
>         serialicen?
>         ¿Quedan vivos los resultados que se enviaron a otra máquina?
>         6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que
>         tengo un
>         arreglo de proxies en M0 donde cada elemento del arreglo tiene
>         un proxy
>         a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada
>         petición se
>         hace de manera asíncrona (cuando la respuesta se recibe se
>         ejecuta un
>         bloque). ¿Consideras eso implementable?
>
>         Tengo entendido que en Squeak existe un ambiente distribuido
>         de objetos
>         llamado Croquet. Y bueno en Open Cobalt, que al parecer es un
>         mundo
>         virtual construido sobre Croquet, se puede hacer mundos 3D
>         sobre los que
>         se puede ejecutar aplicaciones Windows y compartirlas con
>         otros
>         usuarios...
>
>         http://en.wikipedia.org/wiki/Open_Cobalt
>
>         Según recuerdo la gran idea de Croquet es que en vez de enviar
>         los
>         objetos para ejecutar de manera remota, se puede enviar "la
>         computación"
>         para ejecutarla localmente y de esa manera obtener un mejor
>         desempeño.
>
>         Saludos,
>         Guillermo.
>
>
>         On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote:
>         > Hola gente!
>         >
>         > Ya tengo objetos distribuidos en mi pet project AjTalk:
>         >
>         > http://pastie.org/1213856
>         >
>         > Puedo comunicar N maquinas, cada una puede ser cliente o
>         servidora de
>         > otra maquina.
>         > Puedo declarar una clase en maquina M1, y exportarla a M2.
>         > Puedo ejecutar texto definido en M1, en la maquina M2.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         serializar
>         > (como copia) el resultado calculado en M2, para que viaje y
>         se
>         > reifique en M1.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         pedirle que
>         > devuelva el proxy que apunta a ese objeto que queda en M2.
>         > Usando el proxy en M1, como un objeto mas, puedo enviar
>         mensajes al
>         > objeto remoto que todavia reside en M2.
>         >
>         > Hay que mejorar puntos, pero la "base esta" ;-)
>         >
>         > Proximos pasos: investigar la idea de "objeto intermedio" de
>         Mariano,
>         > implementarlo, implementar que los objetos que no se usan
>         desde un
>         > tiempo se serializen, implementar transacciones de objetos
>         como la
>         > describi en otro thread... pero tengo que ver en que orden,
>         que
>         > tiempo.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         >
>         > 2010/10/11 Andres Valloud <[hidden email]>
>         >         Ah, para clarificar.
>         >
>         >         >> Che, si es esto
>         >
>         >         esto = "tener proxies y mandar mensajes remotos a
>         objetos sin
>         >         perder
>         >         la identidad del objeto", por ejemplo...
>         >
>         >         >> a lo que Mariano se referia, no nos olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso
>         >
>         >
>         >         eso = "resolver el problema de distribucion de
>         mensajes a
>         >         objetos
>         >         distribuidos de manera razonablemente general, como
>         por
>         >         ejemplo lo
>         >         hace GemStone"...
>         >
>         >         >> es lo que aca se describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >
>         >
>         >         Andres.
>         >
>         >
>         >
>         >         2010/10/11 Angel Java Lopez <[hidden email]>:
>         >         > Hola gente!
>         >         >
>         >         > Ah! Yo, por lo menos, nunca mencione GemStone (que
>         alguien
>         >         bueno de Sugar
>         >         > (Smalltalk Users Group de Argentina) me comento en
>         los
>         >         noventa, el bueno de
>         >         > Leandro Caniglia, recuerdo su implementacion en
>         Luchetti,
>         >         que recuerde).
>         >         >
>         >         > Lo que me gustaria (tengo codigo, pero no tengo
>         test, asi
>         >         que nada de
>         >         > publicado ahora), es:
>         >         >
>         >         > anObject msg: par1 ....
>         >         >
>         >         > y anObject sea un proxy local, que deriva a un
>         objeto
>         >         residente en otra
>         >         > maquina ese mensaje. El programador puede haberlo
>         creado
>         >         local (como para
>         >         > probar su algoritmo en una sola maquina) o puede
>         haberlo
>         >         creado en otro nodo
>         >         > de una red. En los casos de uso que tengo en
>         mente, el
>         >         programador sabe que
>         >         > hay un costo en eso, asi que no esta conversando
>         con esos
>         >         objetos a cada
>         >         > milisegundo. Es mas: te doy una tarea, despues,
>         llegado el
>         >         caso, en algun
>         >         > momento, por otro canal, recibire una respuesta.
>         >         >
>         >         > Tambien quiero implementar:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > y que anObject por abajo, derive el mensaje a uno,
>         a todos,
>         >         o a algunos de
>         >         > otros objetos, remotos o locales.
>         >         >
>         >         > Y algo ortogonal a todo eso, que tengo
>         implementando, pero
>         >         tendria que
>         >         > unirlo con lo de remoting:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > que anObject reciba el mensaje, y lo atienda en su
>         propio
>         >         thread. Recibe el
>         >         > mensaje, lo coloca en una cola en memoria, y lo
>         atiende en
>         >         su propio thread,
>         >         > cuando este disponible. El objeto que envie el
>         mensaje sigue
>         >         su camino. Esto
>         >         > permite implementar algoritmos en paralelo, sin el
>         tema "te
>         >         envio algo, y te
>         >         > espero a que termines para seguir yo".
>         >         >
>         >         > Interesante el paper que enviaste, lo conocia,
>         pero no lo
>         >         recordaba. Ya lo
>         >         > mando a twitter.
>         >         >
>         >         > No entendi si "si es esto a lo que Mariano se
>         referia", y
>         >         "Si eso es lo que
>         >         > aca", digo, no entendi "si esto" en la primera
>         frase se
>         >         refiere a lo mismo a
>         >         > lo que se refiere "si eso", en la segunda.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/11 Andres Valloud
>         <[hidden email]>
>         >         >>
>         >         >> Che, si es esto a lo que Mariano se referia, no
>         nos
>         >         olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso es lo que
>         aca se
>         >         describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >         >>
>         >         >> Ah, hablando de esto, hace poco encontre este
>         articulo que
>         >         me parecio
>         >         >> interesante.
>         >         >>
>         >         >> http://www.rgoarchitects.com/Files/fallacies.pdf
>         >         >>
>         >         >> 2010/10/11 Angel Java Lopez
>         <[hidden email]>:
>         >         >> > Hola gente!
>         >         >> >
>         >         >> > Interesante la discusion del Thread "Blog",
>         pero tambien
>         >         algo se fue por
>         >         >> > las
>         >         >> > ramas... Cambio de titulo en este mensaje.
>         >         >> >
>         >         >> > Estuve agregando objetos distribuidos a mi pet
>         project
>         >         [1], quedo algo
>         >         >> > asi:
>         >         >> >
>         >         >> > http://pastie.org/1213856
>         >         >> >
>         >         >> > Tengan encuenta que no tengo libreria de clases
>         de base,
>         >         asi que tengo
>         >         >> > que
>         >         >> > comenzar desde nil subclass:... ';-)
>         >         >> >
>         >         >> > Puedo:
>         >         >> >
>         >         >> > - Levantar un servidor (tecnologia
>         Remoting .NET), en
>         >         nodo A.
>         >         >> > - Levantar un cliente remoto a ese servidor, en
>         nodo B.
>         >         >> > - Definir una clase en nodo B.
>         >         >> > - Exportar su definicion de B a nodo A.
>         >         >> > - Ejecutar desde nodo B algo en nodo A.
>         >         >> > - Evaluar en nodo A y devolver el objeto
>         serializado
>         >         (contemplando
>         >         >> > grafos
>         >         >> > con ciclos, repeticion de objetos, etc..) a B.
>         >         >> >
>         >         >> > Me falta evaluar en nodo A y que el resultado
>         quede en A,
>         >         viajando a B
>         >         >> > una
>         >         >> > especie de proxy, de tal manera que invocando a
>         ese
>         >         objeto en B, se
>         >         >> > ejecute
>         >         >> > el mensaje en nodo A.
>         >         >> >
>         >         >> > Mi idea es que si B devuelve un objeto a A, ese
>         resultado
>         >         viaja
>         >         >> > completo.
>         >         >> > Sino, definiria algo como
>         >         >> >
>         >         >> > ^host asProxy: result.
>         >         >> >
>         >         >> > Tendria que escribir post, pero por ahora,
>         tengo esto
>         >         para mostrar.
>         >         >> >
>         >         >> > [1] http://code.google.com/p/ajtalk
>         >         >> >
>         >         >> > Nos leemos!
>         >         >> >
>         >         >> > Angel "Java" Lopez
>         >         >> > http://www.ajlopez.com
>         >         >> > http://twitter.com/ajlopez
>         >         >> >
>         >         >> >
>         >         >> >
>         >         >> > --
>         >         >> > To post to this group, send email to
>         >         [hidden email]
>         >         >> > To unsubscribe from this group, send email to
>         >         >> > [hidden email]
>         >         >> >
>         >         >> > http://www.clubSmalltalk.org
>         >         >>
>         >         >> --
>         >         >> To post to this group, send email to
>         >         [hidden email]
>         >         >> To unsubscribe from this group, send email to
>         >         >> [hidden email]
>         >         >>
>         >         >> http://www.clubSmalltalk.org
>         >         >
>         >         > --
>         >         > To post to this group, send email to
>         >         [hidden email]
>         >         > To unsubscribe from this group, send email to
>         >         > [hidden email]
>         >         >
>         >         > http://www.clubSmalltalk.org
>         >
>         >         --
>         >         To post to this group, send email to
>         >         [hidden email]
>         >         To unsubscribe from this group, send email to
>         clubSmalltalk
>         >         +[hidden email]
>         >
>         >         http://www.clubSmalltalk.org
>         >
>         >
>         >
>
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to clubSmalltalk
>         > +[hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>
>         Simplex Veri Sigillum
>
>         --
>
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>

> --

> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Una pregunta, ¿porqué crees que es diferente una llamada a una primitiva en Smalltalk que una llamada a "objetos nativos" an AjTalk?

Bonito nombre AjTalk, un poco autoreferente, pero está bien ;-)

Saludos,

Guillermo.

2010/10/19 Angel Java Lopez <[hidden email]>

Hola gente!

Guillermo, interesante.... A ver:

No necesite publicar todavia un objeto por nombre. Si fuera necesario, lo pondria en los globales de, digamo, el nodo M2, y desde M1 pondria:

myRemetoObject := hostM1 evaluate: 'PublishedObject asRemote'.

asRemote como primitiva: Hmmm.. no, no es precisamente una primitiva. A ver, en AjTalk, tengo bytecodes. Y tengo llamadas a objetos nativos de .NET. Si ven el pastie que envie, el asRemote es una llamada a objeto nativo. No tengo cosas como primitiva 24, o algo asi. Los bytecodes no se pueden invocar directamente. Y todo extension (tener "nuevas primitivas") viene en realidad de llamar a tipos y objetos nativos. Por ejemplo, si quisiera implementar una libreria de clases de acceso a base de datos, las escribiria llamando en sus metodos, a tipos y clases del namespace System.Data en .NET (si lo tendria que reimplementar en Java, lo mismo, pero usando tipos y objetos de java.sql y relacionados).

definicion del objeto en M2 segun clase en M1: si, el objeto del ejemplo que puse en el mail, se define en M1. Pero no habria problema en usar un objeto de M2 que estuviera definido en M2, y no en M1. Solo es cuestion de que el programador sepa que quiere hacer.

objetos inmutables: estoy experimentando con eso, en AjLisp, y AjSharpure (con estructuras trees, listas que cuando se modifican, en realidad producen un nuevo objeto, y el original queda igual) un Clojure reimplementado en .NET. No necesite todavia eso en AjTalk.

en paralelo: ciertamente, tener una cola en el agente, permite sacarse de encima el tema de multithreading sobre un objeto. Donde esta el paralelismo? En el consumidor del agente. El objeto que envia un mensaje al agente, puede "seguir su camino". Es programar tipo "tell, don't ask".

"Tell, don't ask" se refiere a decirle a un objeto "haz esto" y él verá y resolverá cómo usando polimorfismo. La estrategia "ask" sería por el contrario preguntarle al objeto de qué tipo es y en qué estado está y leugo decirle exactamente lo que debe hacer.

Cada parte de un algoritmo le pasa trabajo a otro, pero sigue luego en lo suyo. Por ejemplo, en AjSharp y otros, tengo algoritmos geneticos donde cada parte hace lo suyo, y produce trabajo para otros. Por ejemplo, un mutador produce mutantes, y los pasa a otro agente. Un seleccionador colecciona individuos, y selecciona los que mejor evaluacion obtuviero. Y asi. La idea es implementar ese caso  de uso, en algun momento, en AjTalk. Y si tengo distribuidos, puedo tener poblaciones de individuos evolucionando, en distintas maquinas. De vez en cuando, los mejores individuos pasan a otras maquinas. Cada parte/agente no es paralela: es serial, atiende un mensaje por vez. Pero el conjunto es paralelo. Recuerdo ahora un mensaje (no recuerdo de quien, disculpen, Richarte era?) mostrando presentacion con Smalltalk multicore. Mi impresion es que multicore tiene un tope: quiero pensar mas en multi-machine.

100% de acuerdo. Lo que dicen los fanáticos de la ley de Moore es que como las CPUs se estancaron el año 2005 y la ley de Moore sigue aplicando, entonces las CPUs tendrán el doble de cores cada 18 meses (o cada 12 o 24). Hasta el momento se está dando, pero supongo que el año 2030 cuando tengamos 1024 cores podremos estar seguros. Yo tampoco creo mucho en esto, me produce desconfianza porque lo mismo pasó con Solaris que iba a ser mucho más rápido que Sun OS porque el kernel iba a funcionar de manera paralela en muchas CPUs al mismo tiempo, y en la práctica al usarlo uno se daba cuenta que era mucho más lento. En general si tienes un sistema distribuido te conviene que la BD esté en una máquina, los EJBs en otra y la parte web en otra. Incluso te conviene que la parte estática de la parte web esté en otra, y eso es hoy en día un negocio, porque hay empresas que proporcionan ese servicio. ¿Debe funcionar no te parece?

Respecto de cortar el paralelismo en el agente usando colas, estoy de acuerdo, es una implemntación simple que te permite tener un control en caso de que el programador no sea muy vivo. Pero ahora supongamos que el programador lo único que hace es hacer una operación en la BD y no deja nada en memoria. En ese caso puedes asumir que los "agentes" son inmutables y simplemente dejar que operen en paralelo (es lo que hace el ejb container con los ejbs). La base de datos por su parte resuelve todo con transacciones, ya que no serviería de mucho que un thread vea que sacó dinero y nunca nadie más vea que ese dinero fue retirado, no sé si se entiende, se requiere que haya algo de objetos compartidos en la BD, pero se hace una distinción clara entre los objetos inmutables y los objetos mutables y compartidos. 

viaje de los objetos: me parece mas claro que el programador sepa que quiere que viaje o no. Es para evitar el "location transparency". Quiero que el programador sepa que esta haciendo viajar un objeto o no, y decida el. Solo que le pongo como default: se serializa.

Yo asumo que el programador no sabe, porque en general le importa solo resolver el problema de negocio, lo de ejecutar de manera distribuida es un problema de ingeneiría que es ortogonal al problema de negocio. Al menos por eso a J2EE le ha ido tan bien.

con el tema de exportar o no una clase: si al nodo M2 remoto, envio un objeto, y ese objeto es de una clase que NO esta definida en M2, me parece costoso actuar por exception, volver a M1, y decirle que tiene que enviar la clase que falta.

En XP dicen primero pruébalo y si es muy lento, entonces cámbialo. En ingeniría tendemos a planificar que todo sea muy rápido, pero si todo etá super optimizado, se vuelve lento. Sólo hay que optmizar lo que probadamente es muy lento.

 

El camino que voy a seguir es exportar explicitamente desde M1, preguntando primero si ya estaba definida en M2. Ademas, no siempre M2 conoce a M1. M1 conoce a M2, pero no necesariamente hay una forma desde M2 de pedirle cosas a M1.

No entiendo cóm podría ser esto así como dices. Me parece un hoyo de seguridad que no se conozcan de antemano, o al menos, que se puedan presentar y erstablecer una relación de confianza.

Por que .NET en vez de Java? Hmmm... deberia contestar con un post, parece un tema alejado de esta lista, no quiero que me tiren de la oreja! ;-)

De paso: creo que tengo resuelto el tema de objetos transaccionales: comenzar una transaccion, cambiar slots (variables de instancia/clase), y si hay rollback, volver esos slots a lo original, y si hay dos transacciones tocando el mismo slot, una triunfa y otra da error. Pero sera tema, supongo, de programacion de fin de semana, por ahora.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/10/18 Guillermo Schwarz <[hidden email]>

>
> rectRemoto := host evaluate: 'rectEnM2 asRemote'.
>
> queda en la variable local rectRemoto un proxy al objeto Rectangle
> rectEnM2 que quedo en M2.

Qué fácil de usar.

Sería aún más fácil si hubiera un Publisher tal que:

publisher := Publisher new.
publisher publish: anObject.

Dejara ese objeto publicado, la lo cual bastaría con que:

Publisher>>publish: anObject
       host evaluate: anObject + ' asRemote'


¿Cómo convierto <<anObject>> en un símbolo que lo represente? Se me
olvidó...

> Cualquier mensaje
>
> rectRemoto width: 10.
>
> se envia a M2 y se EJECUTA en M2.
>
> Si hago desde M1:
>
> rectCopia := host evaluate: 'rectEnM2'.
>
> viaja serializado el rectangulo y queda una copia en M1, que se invoca
> en M1 y asi.
>
> Guillermo, vamos a tus preguntas:
> 1. Los publico evaluando algo en M2 y aplicando el mensaje que tienen
> todos los Object (ver el pastie que envie
> http://pastie.org/1213856
> como se define el mensaje asRemote);

AsRemote es una primitiva en tu sistema...

> Entonces, si desde M2 a M1 quiero enviar un resultado serializado,
> implemente devuelvo
>
> result
>
> Si quiero enviar el objeto resultado pero como "objeto clavado en M2",
> devuelvo
>
> result asRemote

Pero el objeto fue definido íntegramente en M1, ¿no?

Porque no creo que sea muy agradable que el código de M1 se comporte
diferente dependiendo del código que ejecuta en M2.

En otras palabras, defino todo mi código en M1, y desde ahí mando
objetos a ejecutar a todas las máquinas que quiera, pero siempre la
definición que vale es la que está en M1.

De modo que el result asRemote lo programé en M1 para que el objeto se
quede en M2... (preferiría que el programador no se preocupe de esa
cosas, tal como pasa con los EJBs).

>
> Es decision del programar si lo hace de una forma u otra.
>
> 2. Si llega un mensaje a un objeto cuando esta procesando otro, es lo
> mismo que hago cuando estoy en local, con objetos locales y
> "threads" (no tengo un full Process class implementado todavia): si
> dos "threads" acceden al mismo objeto, es cuestion del programador no
> hacer nada o poner algun lockeo.

En los EJBs está prohibido el lockeo, porque la experiencia dice que un
programador en la "enterprise" no sabe usar locks, y si sabe, luego
llega otro programador de la "enterprise" y se pisa lo que hizo el
primero... ;-)

En otras palabras es el contenedor EJB (un objeto que funciona como
registro de qué EJBs hay y cuáles están ejecutando) el que se encarga de
coordinar ya no los lockeos, sino que las transacciones, es un nivel más
alto de abstracción.

>  Volviendo entonces al caso distribuido. Cuando desde M1 invoco a
> rectRemoto en M2, se ejecuta en M2, de la misma forma: si en M2 hay
> varios accediendo a ese objeto (que es local en M2, y remoto en M1),
> es lo mismo que pasa en cualquier Smalltalk, creo: es cuestion de
> programar si quiero contemplar ese caso o no.

En Lisp se resuelve haciendo que los objetos sean inmutables. Da la
casualidad de que en el caso de los stateless session beans, también.

>
> Como quiero tener cada vez mas proceso distribuido, y en paralelo
> (distribuido o no), he agregado a AjTalk el concepto de "agente" (lo
> podria haber llamado actor, por ahora quedo asi).

No está mal el nombre.

> Por ejemplo:
>
> Object agent: #MyAgent
>
> Es como una clase, pero cuando crea objetos, los crea normales, con un
> cambio: se cambio el proceso de enviarle un mensaje. Cuando:
>
> myAgent := MyAgent new.
> myAgent haceAlgoCuandoPuedas: usandoEsteArreglo
>
> cuando envio ese mensaje, lo coloco en una cola. El agente va
> procesando en paralelo mensajes de esa cola.

¡¡¡En paralelo!!! Que rara la idea de usar una cola para hacerlo en
paralelo, si generalmente es al revés, la cola es para serializarlos (en
el sentido de terminar uno para empezar el otro).

>  Tranquilamente combinar distribuido y agentes. Desde M1 con host
> apuntando a M2, puedo hacer:
>
> myRemoteAgent := host evaluate: 'MyAgente new asRemote'
>

En Smalltalk un objeto inmutable es aquel que no tiene métodos
mutadores. De modo que como es casi imposible saber si un método va a
mutar un objeto o no, creo que la única solución sería a nivel de la VM
detectar el cambio y si el objeto va a cambiar, entonces generar una
copia...

Si la copia es por thread (o por Process) entonces se mantendría una
vista consistente del mundo en ese thread.

> 3. En el pastie que envie, esta el codigo de como hago la exportacion.
> Es
>
> host export: ClaseEnM1
>
> Lo que hago es enviar el string que define a la clase, y se ejecuta en
> M2. Si esa clase deriva de otra que NO esta en M2, es responsabilidad
> del programador (todavia, estoy pensando alternativas), haber hecho
> antes:
>
> host export: ClaseEnM1 superclass

Pero es fácil. Si se cae el compilador, que tenga un hook que diga
askFor: clase que no encuentra... al nodo que contiene todas las clases
(o bien al nodo que hizo la petición).

>
> No hay forma de saber (todavia) si en M2 YA esta esa clase o no.

Si se cae la ejecución con un error que dice "clase no existe"... ;-)

>
> 4. Los parametros que paso al objeto remoto, son serializados (saca
> una copia que se reifica del otro lado). Si desde M1 hago
>
> objetoRemotoEnM2 haceDunga: obj1 yMasDunga: obj2
>
> tanto obj1 como obj2 se serializan. Si quisiera que no viajaran,
> deberia poner (tengo que testear, no tengo un caso ahora):
>
> objetoRemotoEnM2 haceDunga: obj1 asRemote yMasDunga: obj2 asRemote
>

Claro, pero preferiría que cada objeto decida si viaja o no. Puede que
algunos objetos ya estén acá o que realmente estén allá. En EJBs se usa
el concepto de JNDI para saber dónde están los objetos.

JNDI es básicamente un servicio como DNS que dice www.google.com es
182.123.45.67, pero en este caso le dices el nombre del EJB y te dice en
qué máquina está.

> 5. Queria seguir los pasos sugeridos por Mariano. Por explorar ese
> tema. Podria usarse, como presenta Mariano en su charla, para cuando
> hay poca memoria.

Buena idea y bastante general.

>  Otra que se me ocurre, es para implementar todo un dominio de objetos
> en memoria, de forma transaparente. Por temas de limite de memoria,
> necesitaria no tener todos al mismo tiempo en memoria. Los cambios a
> los objetos en memoria, podria ir serializandolos, a un archivo de
> cambios binario.

Prefiero una BD o algo maś simple: jdbm, un tabala de hashing en disco.

> Tengo algunas ideas de implementacion, pero implica usar el objeto
> intermedio que comento Mariano. Yo veo a ese objeto intermedio como
> una celda en lo que era un Object Table. Quisiera ponerle ahi lo
> minimo, y como explique en otro email, que esa "celda"/Objeto
> intermedio apunte al real, o a un decorador del real (para poner mas
> conducta como la que sugeria Mariano, pero no toda en la celda, objeto
> intermedio).

Supongo que basta con poner la llave del hashmap para que lo encuentre
en el disco.

>
> Pero aclaro: esto de serializar lo no usado, es ortogonal a lo de
> distribuido.

Claro. Yo partiría al revés: Todo es no usado. Todo al disco. De esa
manera te aseguras que si tienes una implementación rápida como jdbm (10
ms por consulta) con eso basta.

Obviamente siempre hay cosas que uno quiere mantener en memoria, la
clase String por ejmplo, o el mecanismo que va a buscar al jdbm. Además
por cada operación remota no quieres hacer más de una búsqueda en jdbm,
debes tener eso en consideración.

Ahora bien, yo hablo de apicaicones de negocios que siempre van a la bd
y por ende 10 ms no es nada, es sólo ejecutar otro SQL.

Pero en un compilador eso sería desastroso.

>  Era para local, un experimento para seguir las ideas de Mariano y su
> equipo (pregunto, enlace del equipo? blog? otras publicaciones?)
>
> 6. No vi en detalle MapReduce, solo algo hace dos anios, jugando con
> MPI (Message Passing Interface), en un cluster. Pero apenas para hacer
> una demo y calcular algo. Si lo hiciera con AjTalk... hmmm... a ver
> seria algo como:
>
> myLocalAgent := MyLocalAgent new. "recibira los resultados"
>
> "y por cada hostN, haria"
>
> hostN export: MyWorkerClass.
>
> myRemoteWorker := hostN evaluate: 'MyWorkerClass new'.
> myRemoteWorker process: thisDataPartN sendingResultTo: myLocalAgent
> asRemote "para que no vaya serializado y el local agent siga aca, en
> M0, digamos"

Sí, se ve simple. Habría que tener unas cuantas máquinas para probarlo,
algunas que se caen, un protocolo que defina cuanto se espera a una
máquina que se demora (yo no esperaría nada, mandaría las consultas que
no han llegado a las máquinas que se van desocupando). Eso es fácil de
hacer.

Lo único que no me gusta es C#. ¿Porqué no usar Java?

>
> Se entendio? Cualquier cosa, me preguntan.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/17 Guillermo Schwarz <[hidden email]>
>         Que rápido. Me parece que pasó menos de una semana.
>
>         Unas preguntas:
>
>         1. ¿Cómo publicas los objetos que reciben mensajes remotos
>         para ser
>         usados por las máquinas remotas? ¿Existe un servicio básico
>         que indica
>         cuáles son etos objetos y los mensajes que están dispuestos a
>         recibir?
>         2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue
>         un mensaje
>         a un objeto cuando aún está ejecutando el mensaje anterior?
>         3. Cuando declaras una clase en M1 y la exportas a M2,
>         ¿recompilas la
>         clase en M2 o simplemente envías el objeto compilado?
>         4. Los objetos que son pasados como parámetro son siempre
>         serializados o
>         también se puede enviar un proxy de ellos (por ejemplo podría
>         ser "ob
>         asProxy") de modo que automáticamente se cree un proxy de ese
>         objeto en
>         M2 apuntando al objeto en M1. En EJB eso se puede hacer aunque
>         es una
>         mala práctica, porque luego es natural que el protocolo de
>         comunicación
>         se vuelva "chatty".
>         5. ¿Porqué quieres los objetos que no se han usado se
>         serialicen?
>         ¿Quedan vivos los resultados que se enviaron a otra máquina?
>         6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que
>         tengo un
>         arreglo de proxies en M0 donde cada elemento del arreglo tiene
>         un proxy
>         a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada
>         petición se
>         hace de manera asíncrona (cuando la respuesta se recibe se
>         ejecuta un
>         bloque). ¿Consideras eso implementable?
>
>         Tengo entendido que en Squeak existe un ambiente distribuido
>         de objetos
>         llamado Croquet. Y bueno en Open Cobalt, que al parecer es un
>         mundo
>         virtual construido sobre Croquet, se puede hacer mundos 3D
>         sobre los que
>         se puede ejecutar aplicaciones Windows y compartirlas con
>         otros
>         usuarios...
>
>         http://en.wikipedia.org/wiki/Open_Cobalt
>
>         Según recuerdo la gran idea de Croquet es que en vez de enviar
>         los
>         objetos para ejecutar de manera remota, se puede enviar "la
>         computación"
>         para ejecutarla localmente y de esa manera obtener un mejor
>         desempeño.
>
>         Saludos,
>         Guillermo.
>
>
>         On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote:
>         > Hola gente!
>         >
>         > Ya tengo objetos distribuidos en mi pet project AjTalk:
>         >
>         > http://pastie.org/1213856
>         >
>         > Puedo comunicar N maquinas, cada una puede ser cliente o
>         servidora de
>         > otra maquina.
>         > Puedo declarar una clase en maquina M1, y exportarla a M2.
>         > Puedo ejecutar texto definido en M1, en la maquina M2.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         serializar
>         > (como copia) el resultado calculado en M2, para que viaje y
>         se
>         > reifique en M1.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         pedirle que
>         > devuelva el proxy que apunta a ese objeto que queda en M2.
>         > Usando el proxy en M1, como un objeto mas, puedo enviar
>         mensajes al
>         > objeto remoto que todavia reside en M2.
>         >
>         > Hay que mejorar puntos, pero la "base esta" ;-)
>         >
>         > Proximos pasos: investigar la idea de "objeto intermedio" de
>         Mariano,
>         > implementarlo, implementar que los objetos que no se usan
>         desde un
>         > tiempo se serializen, implementar transacciones de objetos
>         como la
>         > describi en otro thread... pero tengo que ver en que orden,
>         que
>         > tiempo.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         >
>         > 2010/10/11 Andres Valloud <[hidden email]>
>         >         Ah, para clarificar.
>         >
>         >         >> Che, si es esto
>         >
>         >         esto = "tener proxies y mandar mensajes remotos a
>         objetos sin
>         >         perder
>         >         la identidad del objeto", por ejemplo...
>         >
>         >         >> a lo que Mariano se referia, no nos olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso
>         >
>         >
>         >         eso = "resolver el problema de distribucion de
>         mensajes a
>         >         objetos
>         >         distribuidos de manera razonablemente general, como
>         por
>         >         ejemplo lo
>         >         hace GemStone"...
>         >
>         >         >> es lo que aca se describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >
>         >
>         >         Andres.
>         >
>         >
>         >
>         >         2010/10/11 Angel Java Lopez <[hidden email]>:
>         >         > Hola gente!
>         >         >
>         >         > Ah! Yo, por lo menos, nunca mencione GemStone (que
>         alguien
>         >         bueno de Sugar
>         >         > (Smalltalk Users Group de Argentina) me comento en
>         los
>         >         noventa, el bueno de
>         >         > Leandro Caniglia, recuerdo su implementacion en
>         Luchetti,
>         >         que recuerde).
>         >         >
>         >         > Lo que me gustaria (tengo codigo, pero no tengo
>         test, asi
>         >         que nada de
>         >         > publicado ahora), es:
>         >         >
>         >         > anObject msg: par1 ....
>         >         >
>         >         > y anObject sea un proxy local, que deriva a un
>         objeto
>         >         residente en otra
>         >         > maquina ese mensaje. El programador puede haberlo
>         creado
>         >         local (como para
>         >         > probar su algoritmo en una sola maquina) o puede
>         haberlo
>         >         creado en otro nodo
>         >         > de una red. En los casos de uso que tengo en
>         mente, el
>         >         programador sabe que
>         >         > hay un costo en eso, asi que no esta conversando
>         con esos
>         >         objetos a cada
>         >         > milisegundo. Es mas: te doy una tarea, despues,
>         llegado el
>         >         caso, en algun
>         >         > momento, por otro canal, recibire una respuesta.
>         >         >
>         >         > Tambien quiero implementar:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > y que anObject por abajo, derive el mensaje a uno,
>         a todos,
>         >         o a algunos de
>         >         > otros objetos, remotos o locales.
>         >         >
>         >         > Y algo ortogonal a todo eso, que tengo
>         implementando, pero
>         >         tendria que
>         >         > unirlo con lo de remoting:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > que anObject reciba el mensaje, y lo atienda en su
>         propio
>         >         thread. Recibe el
>         >         > mensaje, lo coloca en una cola en memoria, y lo
>         atiende en
>         >         su propio thread,
>         >         > cuando este disponible. El objeto que envie el
>         mensaje sigue
>         >         su camino. Esto
>         >         > permite implementar algoritmos en paralelo, sin el
>         tema "te
>         >         envio algo, y te
>         >         > espero a que termines para seguir yo".
>         >         >
>         >         > Interesante el paper que enviaste, lo conocia,
>         pero no lo
>         >         recordaba. Ya lo
>         >         > mando a twitter.
>         >         >
>         >         > No entendi si "si es esto a lo que Mariano se
>         referia", y
>         >         "Si eso es lo que
>         >         > aca", digo, no entendi "si esto" en la primera
>         frase se
>         >         refiere a lo mismo a
>         >         > lo que se refiere "si eso", en la segunda.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/11 Andres Valloud
>         <[hidden email]>
>         >         >>
>         >         >> Che, si es esto a lo que Mariano se referia, no
>         nos
>         >         olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso es lo que
>         aca se
>         >         describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >         >>
>         >         >> Ah, hablando de esto, hace poco encontre este
>         articulo que
>         >         me parecio
>         >         >> interesante.
>         >         >>
>         >         >> http://www.rgoarchitects.com/Files/fallacies.pdf
>         >         >>
>         >         >> 2010/10/11 Angel Java Lopez
>         <[hidden email]>:
>         >         >> > Hola gente!
>         >         >> >
>         >         >> > Interesante la discusion del Thread "Blog",
>         pero tambien
>         >         algo se fue por
>         >         >> > las
>         >         >> > ramas... Cambio de titulo en este mensaje.
>         >         >> >
>         >         >> > Estuve agregando objetos distribuidos a mi pet
>         project
>         >         [1], quedo algo
>         >         >> > asi:
>         >         >> >
>         >         >> > http://pastie.org/1213856
>         >         >> >
>         >         >> > Tengan encuenta que no tengo libreria de clases
>         de base,
>         >         asi que tengo
>         >         >> > que
>         >         >> > comenzar desde nil subclass:... ';-)
>         >         >> >
>         >         >> > Puedo:
>         >         >> >
>         >         >> > - Levantar un servidor (tecnologia
>         Remoting .NET), en
>         >         nodo A.
>         >         >> > - Levantar un cliente remoto a ese servidor, en
>         nodo B.
>         >         >> > - Definir una clase en nodo B.
>         >         >> > - Exportar su definicion de B a nodo A.
>         >         >> > - Ejecutar desde nodo B algo en nodo A.
>         >         >> > - Evaluar en nodo A y devolver el objeto
>         serializado
>         >         (contemplando
>         >         >> > grafos
>         >         >> > con ciclos, repeticion de objetos, etc..) a B.
>         >         >> >
>         >         >> > Me falta evaluar en nodo A y que el resultado
>         quede en A,
>         >         viajando a B
>         >         >> > una
>         >         >> > especie de proxy, de tal manera que invocando a
>         ese
>         >         objeto en B, se
>         >         >> > ejecute
>         >         >> > el mensaje en nodo A.
>         >         >> >
>         >         >> > Mi idea es que si B devuelve un objeto a A, ese
>         resultado
>         >         viaja
>         >         >> > completo.
>         >         >> > Sino, definiria algo como
>         >         >> >
>         >         >> > ^host asProxy: result.
>         >         >> >
>         >         >> > Tendria que escribir post, pero por ahora,
>         tengo esto
>         >         para mostrar.
>         >         >> >
>         >         >> > [1] http://code.google.com/p/ajtalk
>         >         >> >
>         >         >> > Nos leemos!
>         >         >> >
>         >         >> > Angel "Java" Lopez
>         >         >> > http://www.ajlopez.com
>         >         >> > http://twitter.com/ajlopez
>         >         >> >
>         >         >> >
>         >         >> >
>         >         >> > --
>         >         >> > To post to this group, send email to
>         >         [hidden email]
>         >         >> > To unsubscribe from this group, send email to
>         >         >> > [hidden email]
>         >         >> >
>         >         >> > http://www.clubSmalltalk.org
>         >         >>
>         >         >> --
>         >         >> To post to this group, send email to
>         >         [hidden email]
>         >         >> To unsubscribe from this group, send email to
>         >         >> [hidden email]
>         >         >>
>         >         >> http://www.clubSmalltalk.org
>         >         >
>         >         > --
>         >         > To post to this group, send email to
>         >         [hidden email]
>         >         > To unsubscribe from this group, send email to
>         >         > [hidden email]
>         >         >
>         >         > http://www.clubSmalltalk.org
>         >
>         >         --
>         >         To post to this group, send email to
>         >         [hidden email]
>         >         To unsubscribe from this group, send email to
>         clubSmalltalk
>         >         +[hidden email]
>         >
>         >         http://www.clubSmalltalk.org
>         >
>         >
>         >
>
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to clubSmalltalk
>         > +[hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>
>         Simplex Veri Sigillum
>
>         --
>
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>

> --

> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--

Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Hola gente!

Por lo que vi, las primitivas se identifican por numero.

En algunos Smalltalk no se podian extender, en otros si, pero habia que ponerse de acuerdo en el nro. de primitiva que iba ha poner.

Por lo que vi, no se si en todos los Smalltalk, un metodo puede tener una primitiva, y solo si la primitiva falla (o no se, no esta, lo que sea), se ejecuta el codigo que le sigue.

Corrijanme en cualquiera de esos puntos.

Un objeto nativo puede ser cualquier cosa, no hay que darle un numero. Un programador que ponga en un metodo una llamada a

@System.IO.File exists: 'myFile.txt'

no tiene que declarar la primitiva, por nro, ni nada. Uso lo que esta en la class library "de abajo".

Y tanto Java como .NET, tienen la capacidad de cargar, en demanda, nuevos tipos.

Con lo que cualquier programador puede aprovechar una libreria. Por ejemplo, maese Gregoris podria aprovechar una libreria sobre OpenGL, probada en diferentes ambitos, posiblemente que mas estabilidad, ejemplos mas claros, y soporte, que acceder directamente a la API original.

Eso es lo que veo de diferencia. En el siglo pasado, escribia un mini interprete, con primitivas extensibles (el programador podria agregar que era la primitiva digamos 117). Pero desde que hay librerias de clases, no veo la necesidad de ir por ese camino.

Como siempre, todo esto es <MensajeSubliminalParaElBuenoDeValloud>usen una class library y VM existente para armar un Smalltalk</MensajeSubliminalParaElBuenoDeValloud> ;-);-)

Ah, la autoreferencia es para no luchar por un nombre, no tener colision de nombres con otro proyecto existente. Aun asi, debo tener alguna colision, en el AjLogo con otro proyecto... snif ... ;-) ;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/10/19 Guillermo Schwarz <[hidden email]>

Una pregunta, ¿porqué crees que es diferente una llamada a una primitiva en Smalltalk que una llamada a "objetos nativos" an AjTalk?

Bonito nombre AjTalk, un poco autoreferente, pero está bien ;-)

Saludos,

Guillermo.

2010/10/19 Angel Java Lopez <[hidden email]>

Hola gente!

Guillermo, interesante.... A ver:

No necesite publicar todavia un objeto por nombre. Si fuera necesario, lo pondria en los globales de, digamo, el nodo M2, y desde M1 pondria:

myRemetoObject := hostM1 evaluate: 'PublishedObject asRemote'.

asRemote como primitiva: Hmmm.. no, no es precisamente una primitiva. A ver, en AjTalk, tengo bytecodes. Y tengo llamadas a objetos nativos de .NET. Si ven el pastie que envie, el asRemote es una llamada a objeto nativo. No tengo cosas como primitiva 24, o algo asi. Los bytecodes no se pueden invocar directamente. Y todo extension (tener "nuevas primitivas") viene en realidad de llamar a tipos y objetos nativos. Por ejemplo, si quisiera implementar una libreria de clases de acceso a base de datos, las escribiria llamando en sus metodos, a tipos y clases del namespace System.Data en .NET (si lo tendria que reimplementar en Java, lo mismo, pero usando tipos y objetos de java.sql y relacionados).

definicion del objeto en M2 segun clase en M1: si, el objeto del ejemplo que puse en el mail, se define en M1. Pero no habria problema en usar un objeto de M2 que estuviera definido en M2, y no en M1. Solo es cuestion de que el programador sepa que quiere hacer.

objetos inmutables: estoy experimentando con eso, en AjLisp, y AjSharpure (con estructuras trees, listas que cuando se modifican, en realidad producen un nuevo objeto, y el original queda igual) un Clojure reimplementado en .NET. No necesite todavia eso en AjTalk.

en paralelo: ciertamente, tener una cola en el agente, permite sacarse de encima el tema de multithreading sobre un objeto. Donde esta el paralelismo? En el consumidor del agente. El objeto que envia un mensaje al agente, puede "seguir su camino". Es programar tipo "tell, don't ask".

"Tell, don't ask" se refiere a decirle a un objeto "haz esto" y él verá y resolverá cómo usando polimorfismo. La estrategia "ask" sería por el contrario preguntarle al objeto de qué tipo es y en qué estado está y leugo decirle exactamente lo que debe hacer.

Cada parte de un algoritmo le pasa trabajo a otro, pero sigue luego en lo suyo. Por ejemplo, en AjSharp y otros, tengo algoritmos geneticos donde cada parte hace lo suyo, y produce trabajo para otros. Por ejemplo, un mutador produce mutantes, y los pasa a otro agente. Un seleccionador colecciona individuos, y selecciona los que mejor evaluacion obtuviero. Y asi. La idea es implementar ese caso  de uso, en algun momento, en AjTalk. Y si tengo distribuidos, puedo tener poblaciones de individuos evolucionando, en distintas maquinas. De vez en cuando, los mejores individuos pasan a otras maquinas. Cada parte/agente no es paralela: es serial, atiende un mensaje por vez. Pero el conjunto es paralelo. Recuerdo ahora un mensaje (no recuerdo de quien, disculpen, Richarte era?) mostrando presentacion con Smalltalk multicore. Mi impresion es que multicore tiene un tope: quiero pensar mas en multi-machine.

100% de acuerdo. Lo que dicen los fanáticos de la ley de Moore es que como las CPUs se estancaron el año 2005 y la ley de Moore sigue aplicando, entonces las CPUs tendrán el doble de cores cada 18 meses (o cada 12 o 24). Hasta el momento se está dando, pero supongo que el año 2030 cuando tengamos 1024 cores podremos estar seguros. Yo tampoco creo mucho en esto, me produce desconfianza porque lo mismo pasó con Solaris que iba a ser mucho más rápido que Sun OS porque el kernel iba a funcionar de manera paralela en muchas CPUs al mismo tiempo, y en la práctica al usarlo uno se daba cuenta que era mucho más lento. En general si tienes un sistema distribuido te conviene que la BD esté en una máquina, los EJBs en otra y la parte web en otra. Incluso te conviene que la parte estática de la parte web esté en otra, y eso es hoy en día un negocio, porque hay empresas que proporcionan ese servicio. ¿Debe funcionar no te parece?

Respecto de cortar el paralelismo en el agente usando colas, estoy de acuerdo, es una implemntación simple que te permite tener un control en caso de que el programador no sea muy vivo. Pero ahora supongamos que el programador lo único que hace es hacer una operación en la BD y no deja nada en memoria. En ese caso puedes asumir que los "agentes" son inmutables y simplemente dejar que operen en paralelo (es lo que hace el ejb container con los ejbs). La base de datos por su parte resuelve todo con transacciones, ya que no serviería de mucho que un thread vea que sacó dinero y nunca nadie más vea que ese dinero fue retirado, no sé si se entiende, se requiere que haya algo de objetos compartidos en la BD, pero se hace una distinción clara entre los objetos inmutables y los objetos mutables y compartidos. 

viaje de los objetos: me parece mas claro que el programador sepa que quiere que viaje o no. Es para evitar el "location transparency". Quiero que el programador sepa que esta haciendo viajar un objeto o no, y decida el. Solo que le pongo como default: se serializa.

Yo asumo que el programador no sabe, porque en general le importa solo resolver el problema de negocio, lo de ejecutar de manera distribuida es un problema de ingeneiría que es ortogonal al problema de negocio. Al menos por eso a J2EE le ha ido tan bien.

con el tema de exportar o no una clase: si al nodo M2 remoto, envio un objeto, y ese objeto es de una clase que NO esta definida en M2, me parece costoso actuar por exception, volver a M1, y decirle que tiene que enviar la clase que falta.

En XP dicen primero pruébalo y si es muy lento, entonces cámbialo. En ingeniría tendemos a planificar que todo sea muy rápido, pero si todo etá super optimizado, se vuelve lento. Sólo hay que optmizar lo que probadamente es muy lento.

 

El camino que voy a seguir es exportar explicitamente desde M1, preguntando primero si ya estaba definida en M2. Ademas, no siempre M2 conoce a M1. M1 conoce a M2, pero no necesariamente hay una forma desde M2 de pedirle cosas a M1.

No entiendo cóm podría ser esto así como dices. Me parece un hoyo de seguridad que no se conozcan de antemano, o al menos, que se puedan presentar y erstablecer una relación de confianza.

Por que .NET en vez de Java? Hmmm... deberia contestar con un post, parece un tema alejado de esta lista, no quiero que me tiren de la oreja! ;-)

De paso: creo que tengo resuelto el tema de objetos transaccionales: comenzar una transaccion, cambiar slots (variables de instancia/clase), y si hay rollback, volver esos slots a lo original, y si hay dos transacciones tocando el mismo slot, una triunfa y otra da error. Pero sera tema, supongo, de programacion de fin de semana, por ahora.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2010/10/18 Guillermo Schwarz <[hidden email]>

>
> rectRemoto := host evaluate: 'rectEnM2 asRemote'.
>
> queda en la variable local rectRemoto un proxy al objeto Rectangle
> rectEnM2 que quedo en M2.

Qué fácil de usar.

Sería aún más fácil si hubiera un Publisher tal que:

publisher := Publisher new.
publisher publish: anObject.

Dejara ese objeto publicado, la lo cual bastaría con que:

Publisher>>publish: anObject
       host evaluate: anObject + ' asRemote'


¿Cómo convierto <<anObject>> en un símbolo que lo represente? Se me
olvidó...

> Cualquier mensaje
>
> rectRemoto width: 10.
>
> se envia a M2 y se EJECUTA en M2.
>
> Si hago desde M1:
>
> rectCopia := host evaluate: 'rectEnM2'.
>
> viaja serializado el rectangulo y queda una copia en M1, que se invoca
> en M1 y asi.
>
> Guillermo, vamos a tus preguntas:
> 1. Los publico evaluando algo en M2 y aplicando el mensaje que tienen
> todos los Object (ver el pastie que envie
> http://pastie.org/1213856
> como se define el mensaje asRemote);

AsRemote es una primitiva en tu sistema...

> Entonces, si desde M2 a M1 quiero enviar un resultado serializado,
> implemente devuelvo
>
> result
>
> Si quiero enviar el objeto resultado pero como "objeto clavado en M2",
> devuelvo
>
> result asRemote

Pero el objeto fue definido íntegramente en M1, ¿no?

Porque no creo que sea muy agradable que el código de M1 se comporte
diferente dependiendo del código que ejecuta en M2.

En otras palabras, defino todo mi código en M1, y desde ahí mando
objetos a ejecutar a todas las máquinas que quiera, pero siempre la
definición que vale es la que está en M1.

De modo que el result asRemote lo programé en M1 para que el objeto se
quede en M2... (preferiría que el programador no se preocupe de esa
cosas, tal como pasa con los EJBs).

>
> Es decision del programar si lo hace de una forma u otra.
>
> 2. Si llega un mensaje a un objeto cuando esta procesando otro, es lo
> mismo que hago cuando estoy en local, con objetos locales y
> "threads" (no tengo un full Process class implementado todavia): si
> dos "threads" acceden al mismo objeto, es cuestion del programador no
> hacer nada o poner algun lockeo.

En los EJBs está prohibido el lockeo, porque la experiencia dice que un
programador en la "enterprise" no sabe usar locks, y si sabe, luego
llega otro programador de la "enterprise" y se pisa lo que hizo el
primero... ;-)

En otras palabras es el contenedor EJB (un objeto que funciona como
registro de qué EJBs hay y cuáles están ejecutando) el que se encarga de
coordinar ya no los lockeos, sino que las transacciones, es un nivel más
alto de abstracción.

>  Volviendo entonces al caso distribuido. Cuando desde M1 invoco a
> rectRemoto en M2, se ejecuta en M2, de la misma forma: si en M2 hay
> varios accediendo a ese objeto (que es local en M2, y remoto en M1),
> es lo mismo que pasa en cualquier Smalltalk, creo: es cuestion de
> programar si quiero contemplar ese caso o no.

En Lisp se resuelve haciendo que los objetos sean inmutables. Da la
casualidad de que en el caso de los stateless session beans, también.

>
> Como quiero tener cada vez mas proceso distribuido, y en paralelo
> (distribuido o no), he agregado a AjTalk el concepto de "agente" (lo
> podria haber llamado actor, por ahora quedo asi).

No está mal el nombre.

> Por ejemplo:
>
> Object agent: #MyAgent
>
> Es como una clase, pero cuando crea objetos, los crea normales, con un
> cambio: se cambio el proceso de enviarle un mensaje. Cuando:
>
> myAgent := MyAgent new.
> myAgent haceAlgoCuandoPuedas: usandoEsteArreglo
>
> cuando envio ese mensaje, lo coloco en una cola. El agente va
> procesando en paralelo mensajes de esa cola.

¡¡¡En paralelo!!! Que rara la idea de usar una cola para hacerlo en
paralelo, si generalmente es al revés, la cola es para serializarlos (en
el sentido de terminar uno para empezar el otro).

>  Tranquilamente combinar distribuido y agentes. Desde M1 con host
> apuntando a M2, puedo hacer:
>
> myRemoteAgent := host evaluate: 'MyAgente new asRemote'
>

En Smalltalk un objeto inmutable es aquel que no tiene métodos
mutadores. De modo que como es casi imposible saber si un método va a
mutar un objeto o no, creo que la única solución sería a nivel de la VM
detectar el cambio y si el objeto va a cambiar, entonces generar una
copia...

Si la copia es por thread (o por Process) entonces se mantendría una
vista consistente del mundo en ese thread.

> 3. En el pastie que envie, esta el codigo de como hago la exportacion.
> Es
>
> host export: ClaseEnM1
>
> Lo que hago es enviar el string que define a la clase, y se ejecuta en
> M2. Si esa clase deriva de otra que NO esta en M2, es responsabilidad
> del programador (todavia, estoy pensando alternativas), haber hecho
> antes:
>
> host export: ClaseEnM1 superclass

Pero es fácil. Si se cae el compilador, que tenga un hook que diga
askFor: clase que no encuentra... al nodo que contiene todas las clases
(o bien al nodo que hizo la petición).

>
> No hay forma de saber (todavia) si en M2 YA esta esa clase o no.

Si se cae la ejecución con un error que dice "clase no existe"... ;-)

>
> 4. Los parametros que paso al objeto remoto, son serializados (saca
> una copia que se reifica del otro lado). Si desde M1 hago
>
> objetoRemotoEnM2 haceDunga: obj1 yMasDunga: obj2
>
> tanto obj1 como obj2 se serializan. Si quisiera que no viajaran,
> deberia poner (tengo que testear, no tengo un caso ahora):
>
> objetoRemotoEnM2 haceDunga: obj1 asRemote yMasDunga: obj2 asRemote
>

Claro, pero preferiría que cada objeto decida si viaja o no. Puede que
algunos objetos ya estén acá o que realmente estén allá. En EJBs se usa
el concepto de JNDI para saber dónde están los objetos.

JNDI es básicamente un servicio como DNS que dice www.google.com es
182.123.45.67, pero en este caso le dices el nombre del EJB y te dice en
qué máquina está.

> 5. Queria seguir los pasos sugeridos por Mariano. Por explorar ese
> tema. Podria usarse, como presenta Mariano en su charla, para cuando
> hay poca memoria.

Buena idea y bastante general.

>  Otra que se me ocurre, es para implementar todo un dominio de objetos
> en memoria, de forma transaparente. Por temas de limite de memoria,
> necesitaria no tener todos al mismo tiempo en memoria. Los cambios a
> los objetos en memoria, podria ir serializandolos, a un archivo de
> cambios binario.

Prefiero una BD o algo maś simple: jdbm, un tabala de hashing en disco.

> Tengo algunas ideas de implementacion, pero implica usar el objeto
> intermedio que comento Mariano. Yo veo a ese objeto intermedio como
> una celda en lo que era un Object Table. Quisiera ponerle ahi lo
> minimo, y como explique en otro email, que esa "celda"/Objeto
> intermedio apunte al real, o a un decorador del real (para poner mas
> conducta como la que sugeria Mariano, pero no toda en la celda, objeto
> intermedio).

Supongo que basta con poner la llave del hashmap para que lo encuentre
en el disco.

>
> Pero aclaro: esto de serializar lo no usado, es ortogonal a lo de
> distribuido.

Claro. Yo partiría al revés: Todo es no usado. Todo al disco. De esa
manera te aseguras que si tienes una implementación rápida como jdbm (10
ms por consulta) con eso basta.

Obviamente siempre hay cosas que uno quiere mantener en memoria, la
clase String por ejmplo, o el mecanismo que va a buscar al jdbm. Además
por cada operación remota no quieres hacer más de una búsqueda en jdbm,
debes tener eso en consideración.

Ahora bien, yo hablo de apicaicones de negocios que siempre van a la bd
y por ende 10 ms no es nada, es sólo ejecutar otro SQL.

Pero en un compilador eso sería desastroso.

>  Era para local, un experimento para seguir las ideas de Mariano y su
> equipo (pregunto, enlace del equipo? blog? otras publicaciones?)
>
> 6. No vi en detalle MapReduce, solo algo hace dos anios, jugando con
> MPI (Message Passing Interface), en un cluster. Pero apenas para hacer
> una demo y calcular algo. Si lo hiciera con AjTalk... hmmm... a ver
> seria algo como:
>
> myLocalAgent := MyLocalAgent new. "recibira los resultados"
>
> "y por cada hostN, haria"
>
> hostN export: MyWorkerClass.
>
> myRemoteWorker := hostN evaluate: 'MyWorkerClass new'.
> myRemoteWorker process: thisDataPartN sendingResultTo: myLocalAgent
> asRemote "para que no vaya serializado y el local agent siga aca, en
> M0, digamos"

Sí, se ve simple. Habría que tener unas cuantas máquinas para probarlo,
algunas que se caen, un protocolo que defina cuanto se espera a una
máquina que se demora (yo no esperaría nada, mandaría las consultas que
no han llegado a las máquinas que se van desocupando). Eso es fácil de
hacer.

Lo único que no me gusta es C#. ¿Porqué no usar Java?

>
> Se entendio? Cualquier cosa, me preguntan.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2010/10/17 Guillermo Schwarz <[hidden email]>
>         Que rápido. Me parece que pasó menos de una semana.
>
>         Unas preguntas:
>
>         1. ¿Cómo publicas los objetos que reciben mensajes remotos
>         para ser
>         usados por las máquinas remotas? ¿Existe un servicio básico
>         que indica
>         cuáles son etos objetos y los mensajes que están dispuestos a
>         recibir?
>         2. ¿Usas colas de mensajes? ¿Cómo haces en caso de que llegue
>         un mensaje
>         a un objeto cuando aún está ejecutando el mensaje anterior?
>         3. Cuando declaras una clase en M1 y la exportas a M2,
>         ¿recompilas la
>         clase en M2 o simplemente envías el objeto compilado?
>         4. Los objetos que son pasados como parámetro son siempre
>         serializados o
>         también se puede enviar un proxy de ellos (por ejemplo podría
>         ser "ob
>         asProxy") de modo que automáticamente se cree un proxy de ese
>         objeto en
>         M2 apuntando al objeto en M1. En EJB eso se puede hacer aunque
>         es una
>         mala práctica, porque luego es natural que el protocolo de
>         comunicación
>         se vuelva "chatty".
>         5. ¿Porqué quieres los objetos que no se han usado se
>         serialicen?
>         ¿Quedan vivos los resultados que se enviaron a otra máquina?
>         6. ¿Cómo implementarías map-reduce con AjTalk? Suponiendo que
>         tengo un
>         arreglo de proxies en M0 donde cada elemento del arreglo tiene
>         un proxy
>         a M1, M2, ... M10 (supogamos que son 10 máquinas) y que cada
>         petición se
>         hace de manera asíncrona (cuando la respuesta se recibe se
>         ejecuta un
>         bloque). ¿Consideras eso implementable?
>
>         Tengo entendido que en Squeak existe un ambiente distribuido
>         de objetos
>         llamado Croquet. Y bueno en Open Cobalt, que al parecer es un
>         mundo
>         virtual construido sobre Croquet, se puede hacer mundos 3D
>         sobre los que
>         se puede ejecutar aplicaciones Windows y compartirlas con
>         otros
>         usuarios...
>
>         http://en.wikipedia.org/wiki/Open_Cobalt
>
>         Según recuerdo la gran idea de Croquet es que en vez de enviar
>         los
>         objetos para ejecutar de manera remota, se puede enviar "la
>         computación"
>         para ejecutarla localmente y de esa manera obtener un mejor
>         desempeño.
>
>         Saludos,
>         Guillermo.
>
>
>         On Sun, 2010-10-17 at 17:44 -0300, Angel Java Lopez wrote:
>         > Hola gente!
>         >
>         > Ya tengo objetos distribuidos en mi pet project AjTalk:
>         >
>         > http://pastie.org/1213856
>         >
>         > Puedo comunicar N maquinas, cada una puede ser cliente o
>         servidora de
>         > otra maquina.
>         > Puedo declarar una clase en maquina M1, y exportarla a M2.
>         > Puedo ejecutar texto definido en M1, en la maquina M2.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         serializar
>         > (como copia) el resultado calculado en M2, para que viaje y
>         se
>         > reifique en M1.
>         > Puedo evaluar texto definido en M1, en la maquina M2, y
>         pedirle que
>         > devuelva el proxy que apunta a ese objeto que queda en M2.
>         > Usando el proxy en M1, como un objeto mas, puedo enviar
>         mensajes al
>         > objeto remoto que todavia reside en M2.
>         >
>         > Hay que mejorar puntos, pero la "base esta" ;-)
>         >
>         > Proximos pasos: investigar la idea de "objeto intermedio" de
>         Mariano,
>         > implementarlo, implementar que los objetos que no se usan
>         desde un
>         > tiempo se serializen, implementar transacciones de objetos
>         como la
>         > describi en otro thread... pero tengo que ver en que orden,
>         que
>         > tiempo.
>         >
>         > Nos leemos!
>         >
>         > Angel "Java" Lopez
>         > http://www.ajlopez.com
>         > http://twitter.com/ajlopez
>         >
>         >
>         > 2010/10/11 Andres Valloud <[hidden email]>
>         >         Ah, para clarificar.
>         >
>         >         >> Che, si es esto
>         >
>         >         esto = "tener proxies y mandar mensajes remotos a
>         objetos sin
>         >         perder
>         >         la identidad del objeto", por ejemplo...
>         >
>         >         >> a lo que Mariano se referia, no nos olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso
>         >
>         >
>         >         eso = "resolver el problema de distribucion de
>         mensajes a
>         >         objetos
>         >         distribuidos de manera razonablemente general, como
>         por
>         >         ejemplo lo
>         >         hace GemStone"...
>         >
>         >         >> es lo que aca se describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >
>         >
>         >         Andres.
>         >
>         >
>         >
>         >         2010/10/11 Angel Java Lopez <[hidden email]>:
>         >         > Hola gente!
>         >         >
>         >         > Ah! Yo, por lo menos, nunca mencione GemStone (que
>         alguien
>         >         bueno de Sugar
>         >         > (Smalltalk Users Group de Argentina) me comento en
>         los
>         >         noventa, el bueno de
>         >         > Leandro Caniglia, recuerdo su implementacion en
>         Luchetti,
>         >         que recuerde).
>         >         >
>         >         > Lo que me gustaria (tengo codigo, pero no tengo
>         test, asi
>         >         que nada de
>         >         > publicado ahora), es:
>         >         >
>         >         > anObject msg: par1 ....
>         >         >
>         >         > y anObject sea un proxy local, que deriva a un
>         objeto
>         >         residente en otra
>         >         > maquina ese mensaje. El programador puede haberlo
>         creado
>         >         local (como para
>         >         > probar su algoritmo en una sola maquina) o puede
>         haberlo
>         >         creado en otro nodo
>         >         > de una red. En los casos de uso que tengo en
>         mente, el
>         >         programador sabe que
>         >         > hay un costo en eso, asi que no esta conversando
>         con esos
>         >         objetos a cada
>         >         > milisegundo. Es mas: te doy una tarea, despues,
>         llegado el
>         >         caso, en algun
>         >         > momento, por otro canal, recibire una respuesta.
>         >         >
>         >         > Tambien quiero implementar:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > y que anObject por abajo, derive el mensaje a uno,
>         a todos,
>         >         o a algunos de
>         >         > otros objetos, remotos o locales.
>         >         >
>         >         > Y algo ortogonal a todo eso, que tengo
>         implementando, pero
>         >         tendria que
>         >         > unirlo con lo de remoting:
>         >         >
>         >         > anObject msg: par1 ...
>         >         >
>         >         > que anObject reciba el mensaje, y lo atienda en su
>         propio
>         >         thread. Recibe el
>         >         > mensaje, lo coloca en una cola en memoria, y lo
>         atiende en
>         >         su propio thread,
>         >         > cuando este disponible. El objeto que envie el
>         mensaje sigue
>         >         su camino. Esto
>         >         > permite implementar algoritmos en paralelo, sin el
>         tema "te
>         >         envio algo, y te
>         >         > espero a que termines para seguir yo".
>         >         >
>         >         > Interesante el paper que enviaste, lo conocia,
>         pero no lo
>         >         recordaba. Ya lo
>         >         > mando a twitter.
>         >         >
>         >         > No entendi si "si es esto a lo que Mariano se
>         referia", y
>         >         "Si eso es lo que
>         >         > aca", digo, no entendi "si esto" en la primera
>         frase se
>         >         refiere a lo mismo a
>         >         > lo que se refiere "si eso", en la segunda.
>         >         >
>         >         > Nos leemos!
>         >         >
>         >         > Angel "Java" Lopez
>         >         > http://www.ajlopez.com
>         >         > http://twitter.com/ajlopez
>         >         >
>         >         > 2010/10/11 Andres Valloud
>         <[hidden email]>
>         >         >>
>         >         >> Che, si es esto a lo que Mariano se referia, no
>         nos
>         >         olvidemos de
>         >         >> GemStone que hace no se, 25 años que esta con su
>         base de
>         >         objetos
>         >         >> (esencialmente se puede ver como una imagen
>         compartida
>         >         entre N otras
>         >         >> imagenes, con transacciones).  Si eso es lo que
>         aca se
>         >         describio como
>         >         >> "trivial", desde ya que de ninguna manera es
>         trivial ese
>         >         problema.
>         >         >> Trivial podra ser una primera aproximacion a la
>         >         serializacion, pero
>         >         >> literalmente "objetos distribuidos" asi como en
>         GemStone,
>         >         ni ahi.
>         >         >>
>         >         >> Ah, hablando de esto, hace poco encontre este
>         articulo que
>         >         me parecio
>         >         >> interesante.
>         >         >>
>         >         >> http://www.rgoarchitects.com/Files/fallacies.pdf
>         >         >>
>         >         >> 2010/10/11 Angel Java Lopez
>         <[hidden email]>:
>         >         >> > Hola gente!
>         >         >> >
>         >         >> > Interesante la discusion del Thread "Blog",
>         pero tambien
>         >         algo se fue por
>         >         >> > las
>         >         >> > ramas... Cambio de titulo en este mensaje.
>         >         >> >
>         >         >> > Estuve agregando objetos distribuidos a mi pet
>         project
>         >         [1], quedo algo
>         >         >> > asi:
>         >         >> >
>         >         >> > http://pastie.org/1213856
>         >         >> >
>         >         >> > Tengan encuenta que no tengo libreria de clases
>         de base,
>         >         asi que tengo
>         >         >> > que
>         >         >> > comenzar desde nil subclass:... ';-)
>         >         >> >
>         >         >> > Puedo:
>         >         >> >
>         >         >> > - Levantar un servidor (tecnologia
>         Remoting .NET), en
>         >         nodo A.
>         >         >> > - Levantar un cliente remoto a ese servidor, en
>         nodo B.
>         >         >> > - Definir una clase en nodo B.
>         >         >> > - Exportar su definicion de B a nodo A.
>         >         >> > - Ejecutar desde nodo B algo en nodo A.
>         >         >> > - Evaluar en nodo A y devolver el objeto
>         serializado
>         >         (contemplando
>         >         >> > grafos
>         >         >> > con ciclos, repeticion de objetos, etc..) a B.
>         >         >> >
>         >         >> > Me falta evaluar en nodo A y que el resultado
>         quede en A,
>         >         viajando a B
>         >         >> > una
>         >         >> > especie de proxy, de tal manera que invocando a
>         ese
>         >         objeto en B, se
>         >         >> > ejecute
>         >         >> > el mensaje en nodo A.
>         >         >> >
>         >         >> > Mi idea es que si B devuelve un objeto a A, ese
>         resultado
>         >         viaja
>         >         >> > completo.
>         >         >> > Sino, definiria algo como
>         >         >> >
>         >         >> > ^host asProxy: result.
>         >         >> >
>         >         >> > Tendria que escribir post, pero por ahora,
>         tengo esto
>         >         para mostrar.
>         >         >> >
>         >         >> > [1] http://code.google.com/p/ajtalk
>         >         >> >
>         >         >> > Nos leemos!
>         >         >> >
>         >         >> > Angel "Java" Lopez
>         >         >> > http://www.ajlopez.com
>         >         >> > http://twitter.com/ajlopez
>         >         >> >
>         >         >> >
>         >         >> >
>         >         >> > --
>         >         >> > To post to this group, send email to
>         >         [hidden email]
>         >         >> > To unsubscribe from this group, send email to
>         >         >> > [hidden email]
>         >         >> >
>         >         >> > http://www.clubSmalltalk.org
>         >         >>
>         >         >> --
>         >         >> To post to this group, send email to
>         >         [hidden email]
>         >         >> To unsubscribe from this group, send email to
>         >         >> [hidden email]
>         >         >>
>         >         >> http://www.clubSmalltalk.org
>         >         >
>         >         > --
>         >         > To post to this group, send email to
>         >         [hidden email]
>         >         > To unsubscribe from this group, send email to
>         >         > [hidden email]
>         >         >
>         >         > http://www.clubSmalltalk.org
>         >
>         >         --
>         >         To post to this group, send email to
>         >         [hidden email]
>         >         To unsubscribe from this group, send email to
>         clubSmalltalk
>         >         +[hidden email]
>         >
>         >         http://www.clubSmalltalk.org
>         >
>         >
>         >
>
>         > --
>         > To post to this group, send email to
>         [hidden email]
>         > To unsubscribe from this group, send email to clubSmalltalk
>         > +[hidden email]
>         >
>         > http://www.clubSmalltalk.org
>
>         --
>
>         Simplex Veri Sigillum
>
>         --
>
>         To post to this group, send email to
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>

> --

> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--

Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org