Bueno cada uno se acostumbra a diferentes cosas.
Squeak lo encuentro un enredo. Aparte de que acá en Chile nadie lo pesca,
que yo sepa, supongo que porque se ve muy infantil.
Alguna vez lo pude usar, pero cuando empezaron a desarrollar con Morphic me
perdí, nunca lo entendí. Luego empezaron con el conejo 3D y ahí si que no
entendí nada.
Lo de los objetos distribuidos lo hago hasta con macros de Excel (ja, es
broma ;-) Aunque no tan broma si pensamos que DCOM+ es algo parecido... Y
hay que ver que los DCOM sí que tienen reglas para el manejo de sus objetos
que muchas veces ni ellos mismos las entienden bien.
Bueno unas preguntas pensando en que lo voy a implementar en Pharo:
1. ¿Cómo creo un ServerSocket?
2. ¿Cómo creo un Socket que se conecte a ese ServerSocket?
3. ¿Cómo implemento un protocolo sobre los sockets? ¿Hay algún ejemplo en
alguna parte?
4. ¿Cóm tengo el equivalente de un ConcurrentQueue en Pharo? Esto es
necesario porque en el caso de implementar EJBs, cada EJB tiene varias
instancias, entonces cada una cuando se desocupa va saando de la cola y
ejecutando.
Entonces la idea es que cada instancia de Pharo publica sus EJBs,
básicamente ante un mensaje como listEjbs retorna la lista de clases
publicadas. Cada clase publicada se peude instanciar según el número
configurado de instancias o por cada petición creamos un nuevo EJB, eso lo
podemos dejar configurable.
Entonces cada computador remoto puede conectarse a este servidor y ver la
lista. Supongamos que el usuario lo hace interactivamente, simplemente tengo
una GUI que me lista los servidores que tengo en la red y cuando abro uno,
veo sus clases EJBs.(A todo esto todas las clases EJBs son stateless, las
otras fueron un fracaso).
Luego cada clase tiene su propio protocolo, es decir, sus métodos, me parece
la lista de métodos.Selecciono uno, ingreso los parámetros en un GUI que me
muestra el número de cajas que corresponda al número de parámetros, y luego
"send". Espero que el resultado me aparezca en la misma GUI.
Al llamar tengo que llamar un objeto local. Ese objeto local simplemente
manda el mensaje a través del socket (serializo el mensaje). Esto llega a la
cola en el servidor. Lo implementamos como una cola por EJB (cada EJB con su
número de instancias). Hay un EJB scheduler que se encarga de tomar los EJBs
que están "ready" y los pone a leer de la cola. O dicho de otra manera,
llama a alguno de EJBs que estén desocupados con el método que deserializó.
ejb perform: aMessage selector
withArguments: aMessage arguments
¿Qué ventaja tierne esto? No se queda pegado si un EJB es abusado (el resto
del EJBs peude seguir ejecutando). En Smalltalk habría que tener cuidado de
bajarle la prioridad al proceso si lleva más de 3 o 6 segundos ejecutando y
hacerle un yield por fuera. Tengo entendido que uno peude poner un proceso
de más alta prioridad a chequear esos temas.
Además no hay problemas raros como GC distribuido y cosas similares. Cuando
acaba el request la referencia se suelta.
Saludos,
Guillermo.
2010/10/8 Francisco Garau <[email protected]>
>
> El único problema es que Squeak no lo entiendo. Simplemente no puedo salir
>> de los monitos animados y los mundos con herramientas para niños.
>>
>> Saludos,
>> Guillermo.
>>
>
> Guille,
>
> Como es eso que te resulta muy complicado hacer <click-boton derecho> +
> <click - Exit World> pero te resulta trivial implementar una maquina
> virtual con objetos distribuidos?
>
> O es que no te gusta la GUI de Squeak porque sos capaz de mandarle mensajes
> a los objetos modificando la memoria con un editor hexa? Ojo, nunca lo probe
> pero no es *tan* difícil tampoco - solo tenes que conocer el formato interno
> que le da la VM a cada objeto, y listo. Bueno, también jode un poquito el
> GC. Pero también es trivial: si lo único que hace el GC es mover objetos de
> un lado para otro.
>
> En fin, si no podes usar el Squeak porque es para señoritas, no te queda
> otra que hacerlo todo de cero.
>
> Un par de semanitas te alcanza? Lo tendrás listo para la Smalltalks
> 2010? Tenes que ir; todos queremos conocer a groso de tu calibre.
>
> Nos vemos pronto.
>
> - Pancho
> Orbis non sufficit
>
>
> --
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<clubsmalltalk%[email protected]>
>
> http://www.clubSmalltalk.org
>
--
Saludos cordiales,
Guillermo Schwarz
Sun Certified Enterprise Architect
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
