[pyar] Sobre Twisted Matrix

[Angel Java Lopez]

Algo mas.... no se si tomaron en cuenta casos como:

1- Sistema Academico A da de alta estudiante, pero Moodle necesita MAS
datos que los que da el sistema A, para dar de alta el estudiante.
2- Sistema Academico A da de alta estudiante, pero por que cargar eso en A,
si Moodle ya tiene el estudiante dado de alta
3- En el caso que A de de alta estudiante, y Moodle encuentre que ya
existe, pero tiene otros (otro domicilio), que hacer?

Es decir, temas de "que es alta?" vs "esa alta en A ya estaba en B", y como
se resuelven los conflictos.

El caso 2, daria para que el sistema A tal vez tenga que acceder a B
(Moodle) para obtener datos de un estudiante YA EXISTENTE en B, pero que no
se conoce en A (es la primera vez que el estudiante aparece en el sistema
A).

Hace unos meses, en una reunion presencial de agiles buenos aires, se
planteo un software architecture kata parecido:
http://www.architecturalkatas.com/kata.html?kata=ECollege.json

ver http://www.architecturalkatas.com/


2012/8/13 Angel Java Lopez <ajlopez2000 en gmail.com>

> Hola gente!
>
> Interesante tema, Milton... Bien, apenas sabiendo Python, igual me atrevo
> a comentar algo por aca.
>
> Yo propondria:
> - Sistema A publica eventos (tipo: cambio tal dato en el Estudiante X;
> nuevo docente Y con tales datos; etc...)
> - Sistema B1 (algo a escribir) se subscribe a algunos de esos eventos (por
> ejemplo, tal vez B1 no le interesen los cambios de Asignatura, pero si le
> interesen los de Estudiantes y Docentes)
> - Sistema C1 (algo a escribir) idem..
> - Y asi Sistema D1, E1 y los que vengan
>
> El Sistema B1 (digamos que B es Moodle), al  leer los eventos (en un
> servidor dedicado para eso, corriendo siempre, o solo a la noche, etc.),
> toma los datos del evento, y los aplica al sistema B (el Moodle,
> posiblemente a su base de datos).
> Lo mismo el sistem C1, D1, E1 y los que vengan
>
> Que usar para este esquema de publicar/subscribir?
> Jeje... no se, miraria Redis, RabbitMQ, etc.
> Ver quizas
> http://stackoverflow.com/questions/115844/recommended-python-publish-subscribe-dispatch-module
>
> El esquema propuesto tiene pros y contras:
> - Contra? Puede ser mas "grande" que otras soluciones directas, como
> actualizar Moodle directamente
> - Pros? Te permite desacoplar los sistemas. El sistema A solo tiene que
> "aprender" a publicar eventos. El resto del sistema A no se toca.
> Generalmente, la publicacion de eventos se basa en sistemas que siguen
> funcionando aun cuando los B1, C1, D1... no esten en linea. Tambien A
> podria publicar eventos en una cola, si es que el "broker" de esos eventos
> (el que los recibe y se encarga de dejarlos disponibles a los sistemas
> subscriptores), no esta en algun momento accesible desde el sistema A.
> Permite incoporar a G1 (un nuevo subsistema subscriptor de eventos) en
> cualquier momento, sin tener que cambiar A, o B1, o C1, etc... Permite
> cambiar B1 cuando cambien B (por ejemplo, version de Moodle cambia, cambia
> la base, solo hay que tocar B1, lo demas sigue andando). Los temas de
> seguridad de acceso a las bases de datos de B, C, D... se delegan en B1,
> C1, D1... y nunca le pueden "hechar la culpa" al programador de A de
> arruinar algo, etc...
>
> Pero todo depende de tu contexto. Puede que lo propuesto sea lo mas
> conveniente ahora, o puede que sea lo mas conveniente a futuro, mediano
> plazo, o que me digas: no, realmente no podemos implementarlo.
>
> Tuve un caso parecido (que no se llego a implementar): un sistema A daba
> de altas, modificaciones en pozos petroleros (un pozo tiene mas de una
> perforacion, incluso hay perforaciones que no son verticales ,etc..). Habia
> distintos sistemas que debian enterarse de eso: recursos humanos,
> seguridad, SCADA con herramientas, etc....  Sin un sistema asi (pub/sub),
> uno termina en la "swivel chair solution": un tipo que se sienta, en una
> pantalla ve lo que cambio de A, da vuelta su silla rotatoria, y en otra
> pantalla carga los datos en el sistema B... ;-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
>
> 2012/8/13 Milton Labanda <1000ton.lab en gmail.com>
>
>> Muchas gracias Emiliano y disculpa la verdad que si me faltó aclarar:
>> La sincronización que quiero hacer es: Cuando se produscan  eventos CRUD
>> en el sistema Aacademico (A) (principalmente en Estudiantes, Docentes y
>> Asignaturas) se produscan las actualizaciones respectivas en los otros
>> sistemas (Moodle (B), Encuestas (C) y los que vengan)
>>
>> El 13 de agosto de 2012 08:41, Emiliano Dalla Verde Marcozzi <
>> edvm en fedoraproject.org> escribió:
>>
>> El día 13 de agosto de 2012 10:34, Milton Labanda
>>> <1000ton.lab en gmail.com> escribió:
>>> > Hola amigos, me recomendarían usar Twisted en el siguiente escenario, o
>>> > alguna otra alternativa:
>>> > En una universidad tenemos un Sistema Académico en Python (TurboGears)
>>> a
>>> > partir del cual queremos sincronizar  otros sistemas tales como:
>>> Moodle (PHP
>>> > logicamente), Un sistema de encuestas (Django) y otros que vendrán
>>> > psiblemente hechos en python o java.
>>> >
>>> >
>>> > /\/\;/-----------------------------------------------------
>>> > Milton  Labanda  [miltonlab]
>>> > Distro:        Debian GNU/Linux 6.0 Squeeze
>>> > Blog:          http://1000tonlab.wordpress.com
>>> > jabber:        miltonlab en jabber.org
>>> > "... Solamente la libertad que se somete a la Verdad conduce a la
>>> persona
>>> > humana a su  verdadero bien...".  Karol Wojtyla
>>> > (:\ Usa Software Legal, usa Software Libre /:)
>>> >
>>> >
>>>
>>> Buen día Milton,
>>> Podrías aclarar un poco más como es el tema de sincronizar los datos
>>> entre todos
>>> esos sistemas ? :-) Te pregunto esto, porque Twisted está muy bueno, me
>>> gusta
>>> mucho para escribir servidores y clientes no bloqueantes (entre otras
>>> muchas cosas),
>>> pero no entiendo muy bien como es esto de que queres sincronizar los
>>> datos ...
>>> Por ejemplo, sean tus sistemas:
>>> A, B, C, D
>>> Esperas que al agregar un dato en A, pueda ser visto en B? Quizá con
>>> 'compartir' las bases
>>> de datos entre tus apps sea suficiente ? :-)
>>> Saludos,
>>>
>>> --
>>> "Code without tests is broken by design." - Jacob Kaplan-Moss
>>> Show me the mone ... code!: https://bitbucket.org/edvm
>>> _______________________________________________
>>> pyar mailing list pyar en python.org.ar
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>>
>>
>>
>>
>> --
>> /\/\;/-----------------------------------------------------
>> Milton  Labanda  [miltonlab]
>> Distro:        Debian GNU/Linux 6.0 Squeeze
>> Blog:          http://1000tonlab.wordpress.com
>> jabber:        miltonlab en jabber.org <milotnlab en jabber.org>
>> "... Solamente la libertad que se somete a la Verdad conduce a la persona
>> humana a su  verdadero bien...".  Karol Wojtyla
>> (:\ Usa Software Legal, usa Software Libre /:)
>>
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20120813/77a7c631/attachment.html>