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 represen
te? 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 s
e 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 s
iempre 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 preocu
pe 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 experienci
a 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 h
acerlo en
paralelo, si generalmente es al revés, la cola es para ser
ializarlos
(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 n
ivel 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 mant
endrí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 exi
ste"... ;-)
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 n
o. Puede que
algunos objetos ya estén acá o que realmente estén allá. E
n 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.goog
le.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 hash
ing 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 dis
co. 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úsq
ueda 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 p
ara 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 <[email protected]>
Que rápido. Me parece que pasó menos de una semana.
Unas preguntas:
1. ¿Cómo publicas los objetos que reciben mensaj
es remotos
para ser
usados por las máquinas remotas? ¿Existe un serv
icio 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 mensaj
e 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 so
n siempre
serializados o
también se puede enviar un proxy de ellos (por e
jemplo 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 pr
otocolo 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 o
tra máquina?
6. ¿Cómo implementarías map-reduce con AjTalk? S
uponiendo 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 <[email protected]>
> 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 qu
e 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
<[email protected]>:
> > 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
<[email protected]>
> >>
> >> Che, si es esto a lo que Mariano se
referia, no
nos
> olvidemos de
> >> GemStone que hace no se, 25 años qu
e 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
<[email protected]>:
> >> > 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
> [email protected]
> >> > To unsubscribe from this group, send
email to
> >> > clubSmalltalk
[email protected]
> >> >
> >> > http://www.clubSmalltalk.org
> >>
> >> --
> >> To post to this group, send email to
> [email protected]
> >> To unsubscribe from this group, send
email to
> >> [email protected]
> >>
> >> http://www.clubSmalltalk.org
> >
> > --
> > To post to this group, send email to
> [email protected]
> > To unsubscribe from this group, send email
to
> > [email protected]
> >
> > http://www.clubSmalltalk.org
>
> --
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to
clubSmalltalk
> [email protected]
>
> http://www.clubSmalltalk.org
>
>
>
> --
> To post to this group, send email to
[email protected]
> To unsubscribe from this group, send email to
clubSmalltalk
> [email protected]
>
> http://www.clubSmalltalk.org
--
Simplex Veri Sigillum
--
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
clubSmalltalk
[email protected]
http://www.clubSmalltalk.org
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to clubSmalltalk
[email protected]
http://www.clubSmalltalk.org
--
Simplex Veri Sigillum
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
