Ensamblados (Analysis Services)
Microsoft SQL Server 2005 Analysis Services (SSAS) proporciona gran cantidad de funciones intrínsecas que se pueden utilizar con los lenguajes MDX (Expresiones multidimensionales) y DMX (Extensiones de minería de datos), diseñados para realizar multitud de tareas, desde el cálculo estadístico estándar hasta recorridos de miembros de una jerarquía. No obstante, al igual que con cualquier otro producto complejo, existe siempre la necesidad de ampliar la funcionalidad.
Por lo tanto, Analysis Services permite agregar ensamblados a una instancia o base de datos de Analysis Services. Los ensamblados permiten crear funciones externas definidas por el usuario mediante cualquier lenguaje CLR (Common Language Runtime), como por ejemplo Microsoft Visual Basic .NET o Microsoft Visual C#. También puede utilizar lenguajes de automatización COM (Modelo de objetos componentes), como Microsoft Visual Basic o Microsoft Visual C++.
Los ensamblados le permiten ampliar la funcionalidad empresarial de MDX y DMX. Cree la funcionalidad que desee en una biblioteca, como por ejemplo una biblioteca de vínculos dinámicos (DLL), y agregue la biblioteca como ensamblado a una instancia de Analysis Services o a una base de datos de Analysis Services. Los métodos públicos de la biblioteca se ofrecerán como funciones definidas por el usuario a procedimientos, cálculos, acciones, aplicaciones cliente y expresiones de MDX y DMX.
Llamar a funciones definidas por el usuario
La llamada a una función definida por el usuario en un ensamblado se realiza de la misma forma que la llamada a una función intrínseca, salvo que se deba utilizar un nombre completo. Por ejemplo, una función definida por el usuario que devuelva un tipo esperado por MDX se incluye en una consulta MDX, como se muestra en el siguiente ejemplo:
Select MyAssembly.MyClass.MyStoredProcedure(a, b, c) on 0 from Sales
También se puede llamar a las funciones definidas por el usuario mediante la palabra clave CALL. Debe utilizar la palabra clave CALL con funciones definidas por el usuario que devuelvan conjuntos de registros o valores nulos, y no podrá utilizarla si la función definida por el usuario depende de un objeto del contexto de la secuencia de comandos o instrucción MDX o DMX, como el modelo de minería de datos o el cubo actual. Un uso común de una función llamada fuera de una consulta MDX o DMX es utilizar el modelo de objetos AMO para realizar funciones administrativas. Si, por ejemplo, desea utilizar la función MyVoidProcedure(a, b, c) en una instrucción MDX, se utilizaría la siguiente sintaxis:
Call MyAssembly.MyClass.MyVoidProcedure(a, b, c)
Los ensamblados simplifican el desarrollo de la base de datos al permitir que se desarrolle una sola vez el código común y se almacene en una ubicación única. Los programadores de software cliente pueden crear bibliotecas de funciones para Analysis Services y distribuirlas por sus aplicaciones.
Los ensamblados y las funciones definidas por el usuario pueden duplicar los nombres de función de la biblioteca de funciones de Analysis Services o de otros ensamblados. Siempre que se llame a la función definida por el usuario con su nombre completo, Analysis Services utilizará el procedimiento correcto. Por razones de seguridad y para eliminar la posibilidad de llamar a un nombre duplicado de una biblioteca de clases diferente, Analysis Services requiere que se utilicen sólo nombres completos para procedimientos almacenados.
Para llamar a una función definida por el usuario desde un ensamblado CLR, la función definida por el usuario estará precedida por el nombre de ensamblado, el nombre de clase completo y el nombre de procedimiento, como se muestra a continuación:
AssemblyName.FullClassName.ProcedureName(Argument1, Argument2, ...)
Por razones de compatibilidad con versiones anteriores de Analysis Services, se acepta también la siguiente sintaxis:
AssemblyName!FullClassName!ProcedureName(Argument1, Argument2, ...)
Si una biblioteca COM admite varias interfaces, también se puede utilizar el Id. de interfaz para resolver el nombre de procedimiento, como se muestra a continuación:
AssemblyName!InterfaceID!ProcedureName(Argument1, Argument2, ...)
Seguridad
La seguridad de los ensamblados depende del modelo de seguridad de .NET Framework, que es un modelo de seguridad de acceso mediante códigos. .NET Framework admite un mecanismo de seguridad de acceso mediante códigos que presupone que el tiempo de ejecución puede alojar código de plena confianza y código parcialmente de confianza. Los recursos protegidos por la seguridad de acceso mediante códigos de .NET Framework se suelen empaquetar mediante código administrado que solicita el permiso correspondiente antes de permitir el acceso al recurso. La solicitud de permiso sólo se satisface si todos los que llaman (en el nivel de ensamblado) de la pila de llamadas tienen el permiso correspondiente para el recurso.
En el caso de los ensamblados, el permiso de ejecución se pasa con la propiedad PermissionSet del objeto Assembly. Los permisos que recibe el código administrado vienen determinados por la directiva de seguridad activa. Existen tres niveles de directiva activos en un entorno que no tenga alojado Analysis Services: empresa, equipo y usuario. La lista real de permisos que el código recibe queda determinada por la intersección de los permisos obtenidos por estos tres niveles.
Analysis Services proporciona un nivel de directiva de seguridad de nivel de host a la biblioteca CLR mientras lo aloja; esta directiva es un nivel de directiva adicional por debajo de los tres niveles de directiva que siempre están activos. Esta directiva se establece para cada dominio de aplicación creado por Analysis Services.
La directiva de nivel de host de Analysis Services es una combinación de la directiva fija de Analysis Services para ensamblados de sistema y de la directiva especificada por el usuario para ensamblados de usuario. La parte especificada por el usuario de la directiva de host de Analysis Services depende del propietario de ensamblado que especifique uno de los tres depósitos de permisos para cada ensamblado:
| Configuración de permisos | Descripción |
|---|---|
Safe |
Proporciona permiso de cálculo interno. Este depósito de permisos no asigna permisos para el acceso a los recursos protegidos en .NET Framework. Se trata del depósito de permisos predeterminado para un ensamblado si no se especifica ninguno con la propiedad PermissionSet. |
ExternalAccess |
Proporciona el mismo acceso que la configuración Safe, con la posibilidad adicional de permitir el acceso a los recursos externos del sistema. Este depósito de permisos no ofrece garantías de seguridad (aunque se puede proteger este escenario), pero ofrece garantías de confiabilidad. |
Unsafe |
Sin restricciones. No se pueden ofrecer garantías de seguridad ni confiabilidad al código administrado que se ejecute en este conjunto de permisos. Otorga cualquier permiso al código que se ejecute en este nivel de confianza, incluso un permiso personalizado incluido por el administrador. |
Si CLR es alojado por Analysis Services, la comprobación de permisos basada en el recorrido de la pila se detiene en el límite con el código de Analysis Services nativo. Cualquier código administrado en los ensamblados de Analysis Services queda siempre en una de las tres categorías de permiso descritas anteriormente.
Las rutinas de ensamblado COM (o no administradas) no admiten el modelo de seguridad de CLR.
Suplantación
Siempre que exista código administrado que tenga acceso a cualquier recurso externo a Analysis Services, Analysis Services sigue las reglas asociadas a la configuración de la propiedad ImpersonationMode del ensamblado para asegurar que el acceso se produce en un contexto de seguridad de Windows adecuado. Dado que los ensamblados que utilizan la configuración de permisos Safe no tienen acceso a los recursos externos a Analysis Services, estas reglas sólo se aplican a ensamblados que utilicen la configuración de permisos ExternalAccess y Unsafe.
- Si el contexto de ejecución actual corresponde al inicio de sesión autenticado de Windows y es el mismo contexto del autor de la llamada original (es decir, EXECUTE AS no se encuentra en el medio), Analysis Services suplantará el inicio de sesión autenticado de Windows para tener acceso al recurso.
- Si hay un EXECUTE AS intermedio que ha cambiado el contexto del llamador original, se producirá un error al intentar obtener acceso al recurso externo.
La propiedad ImpersonationMode se puede establecer en ImpersonateCurrentUser o ImpersonateAnonymous. La configuración predeterminada, ImpersonateCurrentUser, ejecuta un ensamblado en la cuenta de inicio de sesión en red del usuario actual. Si se utiliza la configuración ImpersonateAnonymous, el contexto de ejecución corresponderá a la cuenta de usuario de inicio de sesión en Windows IUSER_servername del servidor. Se trata de la cuenta de invitado para Internet, que tiene privilegios limitados en el servidor. Un ensamblado que se ejecute en este contexto sólo podrá tener acceso a recursos limitados del servidor local.
Dominios de aplicación
Analysis Services no ofrece dominios de aplicación directamente. Dado que un conjunto de ensamblados se ejecuta en el mismo dominio de aplicación, los dominios de aplicación podrán descubrirse entre ellos en el tiempo de ejecución mediante el espacio de nombres System.Reflection de .NET Framework o de alguna otra forma, y podrán realizar en ellos llamadas enlazadas en tiempo de ejecución. Tales llamadas estarán sujetas a las comprobaciones de permiso utilizadas por la seguridad basada en autorizaciones de Analysis Services.
No debe confiarse en la búsqueda de ensamblados en el mismo dominio de aplicación, porque la implementación define el límite del dominio de aplicación y los ensamblados que van en cada dominio.
Vea también
Conceptos
Configurar la seguridad para procedimientos almacenados (Analysis Services)
Trabajar con procedimientos almacenados (Analysis Services)