Publicado originalmente en FoxTalk.
Traducción de Jorge Espinosa.
En la primera parte de esta serie hemos revisado COM y MTS y nos hemos introducido en los servicios de COM+ en Windows 2000.También le he mostrado como crear una nueva aplicación COM+ e instalar el componente en el servidor. Ahora, en la parte 2, le mostraré cómo hacer que el cliente use el componente en el servidor, la seguridad y el manejo de errores.
¿El cliente siempre tiene razón?
En el articulo anterior, le he mostrado cómo instalar su aplicación en el servidor. Pero esto, no sirve de mucho si usted no puede usar el componente desde el cliente. Lo bueno es, que Windows 2000 hace que esto sea muy fácil. Yendo un poco hacia atrás, al componente que hemos creado e instalado, le damos un vistazo al código:
DEFINE CLASS Math AS SESSION OLEPUBLIC
FUNCTION Multiply(tnNum1, tnNum2)
LOCAL lnResult, loMtx, loContext
*Creamos una referencia al Objeto MTS
loMtx=CREATEOBJECT("MTXAS.APPSERVER.1")
*Creamos la ref. al Contexto
loContext=loMtx.GetObjectContext()
lnResult=tnNum1*tnNum2
*Si hay alguna transacción abierta hacemos el Commit y avisamos al MTS
*que terminamos de usar el objeto.
loContext.SetComplete()
RETURN lnResult
ENDFUNC
ENDDEFINE
He llamado a este el más tonto de los componentes COM. Todo lo que hace es multiplicar dos números. Sin embargo, manteniendo este simple código de ejemplo, nos permite concentrarnos en los aspectos COM+ del mismo.
Ahora, necesitamos hacer la instalación en el cliente. Volvamos a
Component Services Manager. Expanda el árbol debajo de
COM+ Applications y seleccione MyFirstCOMApp. Esta es la aplicación que hemos creado e instalado en el artículo anterior. Ahora, clic derecho sobre MyFirstCOMApp y seleccionar
Export. El asistente de
COM Application Export aparecerá (Figura 1). En primera instancia le solicitará el path completo y el nombre del archivo para su aplicación. Ingrese C:\COMApps\MyFirstCOMAppProxy. Luego asegúrese de haber seleccionado
"Application Proxy-Install on other machines to enable access to this machine". (La otra opción,
"Server Application", es utilizada cuando quiere instalar el componente en otro servidor). clic en Next para finalizar.
El asistente creará dos archivos MyFirstCOMAppProxy.MSI.CAB y MyFirstCOMAppProxy.MSI. Estos archivos pueden ser copiados e instalados en la computadora cliente. Estos archivos NO contienen el componente. Usted no necesita de él en el cliente. Estos archivos contienen información acerca de los métodos públicos y propiedades que expone el componente y punteros hacia el servidor que lo aloja de modo que Windows pueda encontrarlo e instanciarlo.
Nuevamente, usted nunca instala el componente en el cliente. En su lugar instala un proxy. Su aplicación "piensa" que el componente esta alojado y corriendo localmente, pero no es así. Tome nota de esto. Un componente instalado sobre un servidor de aplicaciones nunca corre en el cliente. Por alguna razón, este es un concepto difícil de entender para algunas personas.
Usted instancia el componente servidor exactamente de la misma forma que lo hace localmente. Pruebe esto en su ventana de comandos:
ox = CREATEOBJECT("MyCom.Math")
? ox.Multiply(3, 4) && devolvera 12
ox = NULL
¿Porque ésto funciona?. VFP hace un llamado a Windows, solicitando instanciar el componente. Windows toma información del componente desde la Registry y encuentra que el componente se aloja en un servidor de aplicaciones. Windows entonces instancia el proxy del componente y hace una llamada al servidor para instanciar el componente. VFP no sabe que esta "hablando" con el proxy; "piensa" que lo hace directamente con el componente. Cuando usted llama al método Multiply, el proxy envía el llamado al Server vía DCOM y el resultado es pasado al proxy, quien a su vez se lo pasa a VFP.
¿Se siente inseguro?
Ahora que el componente está instalado en el servidor y el proxy en el cliente, permítame mostrarle cuan fácilmente podemos permitir o prohibir accesos a los componentes.
COM+ utiliza seguridad basada en roles. Un rol es un tipo de usuario. Por ejemplo, en un banco podría tener cajeros, gerentes, oficiales de cuenta, personal de servicios de clientes, etc. Cada una de esas personas cumple un rol. Si quiere prohibir a los cajeros hacer préstamos, en COM+ podría setear seguridad sobre el componente "PRESTAMO" para prohibir esto. Lo bueno es que esto es una opción de configuración que se puede cambiar utilizando el
Component Service Manager.
Los roles están basados en los usuarios y grupos de Windows, así el primer paso en setear el esquema de seguridad es establecer los grupos de seguridad de Windows. Puede ser confuso para entender donde encajan los roles en las jerarquías de grupos y usuarios. Los archivos de ayuda COM+ dicen que : " Los Roles son categorías de usuarios que han sido definidos para la aplicación con el propósito de determinar los permisos de acceso para los recursos de la aplicación. El desarrollador asigna los roles (como categorías de usuarios simbólicas) para la aplicación". Esto se asemeja a un grupo de usuarios de Windows, tome esto con cuidado, piense en el rol como un grupo de usuarios para una aplicación específica.
Ahora volviendo sobre nuestro ejemplo del banco, tenemos cuatro grupos: cajeros, gerentes, oficiales de cuenta y servicios al cliente. Avanzamos y creamos estos en el servidor utilizando el
User Manager de Windows NT o la herramienta
Computer Management de Windows 2000. Ingrese el primer grupo de usuario y luego los otros tres.
Una vez que estos grupos han sido creados volvemos sobre MyFirstCOMApp en
Component Services Manager. clic sobre roles, clic derecho y seleccione
New Role. Ingrese el primer rol, cajero, y clic OK (figura 2). No es necesario nombrar los roles igual a los grupos de usuarios de Windows pero esto hace que la administración sea mucho mas fácil. Ahora cree los tres roles restantes gerente, oficial de cuenta y servicios al cliente.
Luego necesitamos identificar los usuarios en cada rol. Expanda el árbol debajo de cajero. Verá una carpeta llamada
Users. clic sobre esa carpeta, clic derecho y seleccione
New User. Ubique en la lista de grupos y usuarios de Windows y seleccione el grupo de usuarios
Cajero, clic sobre
Add. Lo mismo para gerentes y servicios al cliente. clic en Ok. Podrá ver cada uno de los grupos de seguridad de Windows agregados en el rol cajero en Components Services (figura 3).
Cuando un usuario es agregado al sistema este debe ser agregado a su correspondiente grupo de Windows que automáticamente lo agregará dentro de su rol correspondiente. Entonces tenemos identificados los roles, pero aún no le hemos indicado a
Components Services sobre el uso de seguridad. clic sobre MyFirstCOMApp, clic derecho y seleccionamos
Properties, allí seleccionamos la solapa
Security. Habilitamos la opción
"Enforce access checks for this application" y clic en Ok (figura 4). Ignore la otra opción por ahora que será tratada en breve.
Ahora clic derecho sobre
MyComm.math y seleccione
Properties, luego la solapa
Security. Usted verá que está habilitada la opción
"Enforce component level access checks". También verá la lista de seguridad para los roles. Simplemente seleccione el rol que tendrá acceso a este componente (figura 5).
Usted puede desplegar y asignar el acceso de seguridad a la interfaz o método en el nivel que usted desee. Esto le permite a usted tener un mismo componente con varias interfaces, cada una conteniendo diferentes niveles de seguridad. Si un usuario no tiene el permiso apropiado para el uso del componente, se mostrará un mensaje de error indicando que el componente no puede ser instanciado.
Ahora retomemos al cuadro de diálogo de
Aplication Security (figura 4), allí hay algunas opciones adicionales que necesitamos discutir. La primera es el nivel de seguridad. Esta controla cuando COM+ valida la seguridad de usuario. Con la primera opción,
"Perform access checks only at the process level", el chequeo del rol no será hecho a nivel de componente, interfaz o método. En la segunda opción,
"Perform access checks at the process and component level", la seguridad es chequeada cuando se produce una llamada al componente. Casi siempre se debería utilizar la segunda opción.
No obstante, la primera opción es útil cuando usted ya tiene validado al usuario.
El siguiente seteo es
"Authentication level for calls". Éste tiene seis opciones descriptas en la tabla 1.
Viendo a través de la lista cada opción toma progresivamente mas seguridad, note que el mayor nivel de seguridad está en validar el usuario. La opción por defecto es Packet.
Tabla 1. Niveles de autenticación
| Nivel | Descripción |
|---|
| None | Sin autenticación. |
| Connect | Chequea la seguridad sólo cuando el cliente se conecta al componente. |
| Call | Chequea la seguridad al comienzo de cada llamada. |
| Packet | Chequea la seguridad y valida que todos los datos fueron recibidos. |
| Packet Integrity | Chequea la seguridad y valida que ningún dato fue modificado en tránsito. |
| Packet Privacy | Chequea la seguridad y encripta el paquete. |
Finalmente tenemos
"Impresonation level". Este es el seteo de niveles de autoridad que los componentes tienen con otros procesos. Estos son cuatro niveles diferentes como describe la tabla 2. Por defecto es Impersonate.
Tabla 2. Niveles de Impersonamiento
| Nivel | Descripción |
|---|
| Anonymous | El segundo proceso no sabe nada acerca del cliente. |
| Identify | El segundo proceso puede identificar quién es el cliente. |
| Impersonate | El segundo proceso puede impersonar al cliente, pero sólo por procesos en el mismo servidor. |
| Delegate | El segundo proceso puede impersonar al cliente en todas las instancias. |
Bien, hemos discutido sobre seguridad declarativa basada en roles, la cual es definida y manejada en tiempo de ejecución. También puede usar la seguridad programática. Esto le permite expandir su código basado en los niveles de acceso del usuario. Por ejemplo, un oficial de cuentas solo podría estar autorizado a prestar $50.000. Después que el gerente hace la aprobación para autorizar el préstamo.
Do case
Case IsCallerInrole("Loan Officer")
lnMaxLoanAmt = 50000
Case IsCallerInRole("Manager")
LnMaxLoanAmt = 100000
OTherWise
LnMaxLoanAmt = 10000000000000
EndCase
Utilizar ambos, seguridad basada en roles combinado con seguridad programática, puede soportar cualquier esquema de seguridad que usted necesite.
Manejo de errores
Una de las preguntas que con mas frecuencia de ve en los foros es,
"Como mostrar un error de vuelta al usuario?". Si usted piensa sobre esto la respuesta no parece fácil. Usted NO puede mostrar un cuadro de diálogo con el error de su componente. Este está corriendo en una computadora distinta de la que contiene la interfaz de usuario. VFP posee la función COMRETURNERROR(), para enviar el mensaje de error de vuelta al cliente. COMRETURNERROR() usa dos parámetros. El primero es el nombre del módulo donde ocurre el error. El segundo es el mensaje que muestra al usuario. Veámoslo en el código.
Define Class ErrorExample as SESSION OLEPUBLIC
Procedure Error(tnError, tcMetodo, tnLine)
Local lcMensaje
LcMensaje = "Este es mi mensaje de error")
COMRETURNERROR(tcMethod, lcMensaje)
EndProc
Function CauseError
Error 15
Return "Esto nunca debería ser mostrado"
EndFunc
Enddefine
Ahora compile el código en una DLL e instancie lo siguiente.
Ox = CREATEOBJECT("MyError.ErrorExample")
? ox.CauseError()
Usted debe esperar
"Esto nunca debería ser mostrado" para mostrar en el escritorio de VFP. Sin embargo, aparece un cuadro de dialogo con el mensaje de error.
>Puede retornar cualquier información que quiera en el parámetro del mensaje. Podría querer mejorar el método de error al capturar información adicional utilizando la función AERROR( ) o escribiendo información en el log de errores. Esta es una advertencia:
El método de error no se disparará si el error ocurre en el método Init.
Conclusión
Hemos cubierto instalación, seguridad y manejo de errores. En la próxima oportunidad discutiremos transacciones y veremos como COM+ y VFP 7 permite incluir datos de VFP en las transacciones, algo que no se podía hacer con MTS y VFP 6.
 | Craig Berntson es Microsoft Certified Solution Developer y fue nombrado cuatro veces Microsoft Most Valuable Profesional. Disertante de varias conferencias de FoxPro en todo EEUU y eventos de Microsoft en Salt Lake. Es Presidente del Salt Lake City Fox Users Group y actualmente ingeniero de software senior para 3m Health Information Systems. |
Jorge A. Espinosa, Buenos Aires (Capital Federal), Argentina, es Analista Programador y MCP. Dedicado al desarrollo de sistemas desktop desde el año 1987; siempre en el entorno xBase y en Visual Fox Pro desde la version 3.0. Hoy Gerente de Sistemas en Droguería Saporiti SACIFIA.
