MIIS (continuación)
Retomando el tema de MIIS, seguiremos haciendo referencia al diagrama que publicamos en el post de la primera parte.
Cuando miramos cada “Agente de Administración” (MA) y los Perfiles de Ejecución (RP’s) asociados a él, no nos damos cuenta, al principio, de que es aquí donde reside la mayor parte del trabajo de planeación y diseño de una solución de integración de Servicios de Directorios con MIIS.
Las decisiones más importantes a la hora de construir estos componentes se derivan del trabajo previo que se haya realizado entre los responsables a cada lado de la solución. En mi experiencia, es raro que una misma persona sea la responsable de (y hasta cierto punto el experto en) 2 o más Servicios de Directorios. Por lo general es necesario que haya un alto grado de cooperación para exhibir los objetos y sus propiedades involucrados en cada Servicio de Directorios, de tal forma que se puedan establecer los puntos de correspondencia de la información o los mecanismo necesarios para que esto se de.
Un ejemplo simple sería así de sencillo: en el Servicio de Directorios (A) el objeto que representa a cada usuario se llama “User” y en el Servicio de Directorios (B) este objeto o uno equivalente se llama “People”. Luego, a mayor detalle, el objeto “User” posee 5 datos importantes, entre muchos otros que quizá no nos interesen para los propósitos de negocio de esta integración, “First Name”, “last Name” “Job Role”, “Department” y “UserName”, mientras que el objeto “People” posee 6 Datos importantes, igualmente entre otros tantos que no son de utilidad para nuestros propósitos, “Name”, “Family Name”, “Full Name”, “Position”, “Area” y “LogonName”.
Hasta aquí no parece difícil ver como se resolvería esto, pero claro lo he simplificado para mostrar el proceso (dijimos que sería un ejemplo simple, ¿cierto?).
El experto en el Servicio de Directorios (A) aporta la información correspondiente a sus objetos y propiedades y junto con la información proporcionada por el experto en el Servicio de Directorios (B) deciden que hay un mapeo directo entre mucho de sus datos, mientras que otros, como el “Full Name” del objeto “People” se pueden “calcular al vuelo” o inferir a partir de otros datos también presentes.
Ambos han tomado en cuenta los datos importantes para cada Servicio de Directorios, y también deciden qué hacer con el resto de los datos, de manera que cuando importen la información hacia MIIS puedan filtrar los datos que no son necesarios, y cuando exporten la información ya integrada se respeten los datos mínimos necesarios e importantes de cada uno. Incluso pueden haber decidido si existe un Servicio de Directorios que se considere Autoritario en la solución, esto es que la información en él sea la que se considera más completa, más actualizada o simplemente más confiable y por consiguiente los cambios en otros Servicios de Directorios son desechados a la hora de consolidar la información y solo los cambios hechos en él son propagados hacia el resto.
Ahora si vemos la importancia de este proceso, ¿cierto?, pero aun nos falta entender donde y como se dan los procesos de mapeo e integración de la información. . . . .
Aquí es donde entra en acción el “Espacio de Conector” o Connector Space (CS en nuestro diagrama). Este es un espacio de trabajo para contener los datos en tránsito entre las Fuentes de Datos y MIIS. Es el resultado inicial de la creación de un Agente de Administración y representa el repositorio local de los datos de un Servicio de Directorios dentro de MIIS. Típicamente este espacio contiene una copia de los datos provenientes de una Fuente de Datos en su versión simplificada, ya que solo contiene los datos que se han considerado importantes para la integración. Adicionalmente este espacio es un punto interino para la información que aun no ha sido propagada hacia la fuente de datos después de un proceso de integración.
Finalmente el día de mañana completaré el análisis de los componentes de MIIS al hablarles de la Metaverse! Mañana nos vemos!!
