ayuda con explotar esta idea.

[javier calderon]

jejejeje.... mira estoy aun metido con LDAP, (fase de documentacion) hasta
que vea la matrix segun mi problematica veré si me sirve o no (cosas de
tiempo) y luego veria lo de .Net  y web XML  servicie que mencionaste...

jejje como ya me meti en papa con el LDAP, me costaria dejarlo de lado ahora
en la mitad... en fin cuando vea la luz, espero esta semana, envio señales y
mis nuevas propuestas para asi pulirlas o deshecharlas

Gracias

2006/5/24, Rodrigo Fuentealba <darkprox en gmail.com>:
>
> javier calderon wrote:
> > tu idea me parece atractiva e interesante, pero tengo los siguentes
> > problemas..
> Problemas en la integración siempre habrá...
> > la bd que se encuentra en sqlserver y una de las que esta en postgres,
> > no se encontrarian localmente, es decir, el sistema relacionado con el
> > foro y la aplicacion de venta & compra de productos en una primera
> > instancia estaran alojadas en un hosting, mientras las otras dos en
> > distintos servidores.
> Pues, ¿cuál será la idea de no unificar productos? Es más fácil pero
> toma más tiempo. En este caso comienzan los paneles de control... :S
> > el otro problema en base a tu idea, es que el sistema que posee bd
> > sqlserver es luvit y al tratarse de un sistema "E-Learning Sofware"
> > nunca me daran acceso tal que pueda ingresar a las tablas del sistema
> > y ver los privilegios de los usuarios
> Dile al jefe que dije yo que es un disparate tener 4 sistemas con bases
> de datos distintas. Aquí en mi empresa tenemos únicamente tres:
> PostgreSQL, LDAP (que no es base de datos propiamente tal) y MySQL.
> Migramos todas las autenticaciones a LDAP y de ahi cuando nos validamos
> hacemos todo en PostgreSQL. MySQL es para jugar un rato con los
> contenidos de la página, pero se va a ir.
> >
> > Y mi amigo se me acaba de ocurrir otra situacion conflictiva, y se
> > trata de que pasaria si se les ocurre hacer otro sistema , con otra bd
> > y con otro modo de programacion, ¿entonces deberia manejar 6
> > instancias de conexion ? y asi suscesivamente.
> Yep, eso pasaría con un middleware también en todo caso.
> >
> > lo que actualmente estaba pensando es una posible solucion mediante
> > LDAP, aún manejo  informacion de forma teorica, pero estoy trabajando
> > en ello... ahora si alguien o tu mismo sabe algo al respecto seria
> > bienvenida su opinon tal cual como la que acabas de dar Roman
> LDAP es altamente recomendado... pero tampoco podrás autenticarte de
> varias partes si tienes un hosting entremedio... Creo que tu solución va
> por lo que en .NET se le llama XML Web Service, y no te autenticas
> contra la BD sino contra servicio web... y se va haciendo más complejo.
> >
> > Gracias
> >
> >
> > El día 24/05/06, *Roman Jesus Astorga Guzman*
> > <roman_astorga en hotmail.com <mailto:roman_astorga en hotmail.com>> escribió:
> >
> >     Voy a tirar algunas líneas, a ver si te sirve de algo
> >
> OK, dibujemos de nuevo entonces:
>
> 1.- SQL Server local
> 2.- PostgreSQL local
> 3.- MySQL remoto
> 4.- PostgreSQL remoto
>
> Para autenticar usuarios, te recomiendo que uses el SQL Server local o
> el PostgreSQL local, con un servicio web XML o algo así (mira cómo
> trabaja el .NET Passport). Para eso necesitas IP fija: tienes IP fija
> ahí donde estás?
>
> Vas a necesitar desarrollar una aplicación de autenticación que consulte
> a la BD y después de recibida la respuesta (ejem, ejem, por ejemplo con
> ajax), inicies la sesión con los datos del usuario en el sistema que
> está usando.
>
> Problemas con los que te vas a encontrar:
>
> 1.- Redundancia de información: Los perfiles no siempre serán los mismos
> en todas partes, por lo que tu aplicación deberá pasar al resto de las
> aplicaciones también lo que se llama perfiles en común.
>
> 2.- Inaccesibilidad: si no tienes IP fija o si se cae el servidor local,
> cooperaste con el remoto, todos tienen que sincronizarse.
>
> Te va a quedar riiiiiiiiiiiiiiiico :D pero podrías ir por ahí.
>
> ;) Atte. Yo q:-)
>
> --
> Rodrigo Fuentealba
>



-- 
Javier Calderón.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.inf.utfsm.cl/pipermail/php/attachments/20060525/944bdd16/attachment.html