Universidad de Colima

Transcripción

1 Universidad de Colima MAESTRÍA EN CIENCIAS: ÁREA TELEMÁTICA APLICACIÓN CLIENTE/SERVIDOR DE 2 NIVELES UTILIZANDO DCOM/COM PARA GESTIONAR, REMOTA Y LOCALMENTE, TABLAS.DBF UBICADAS EN UNA LAN OPERANDO CON LOS SISTEMAS OPERATIVOS WINDOWS 9X Y NETWARE TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS, ÁREA TELEMÁTICA PRESENTA MIGUEL ÁNGEL MIRANDA GUERRERO ASESOR M. en C. PEDRO DAMIÁN REYES COLIMA, COLIMA. NOVIEMBRE DE 2002

2 UNIVERSIDAD DE COLIMA OFICIO NO. 757/02 FACULTAD DE TELEMATICA C. MIGUEL ÁNGEL MIRANDA GUERRERO P R E S E N T E Informo a usted que ha sido aprobado como tema de titulación para obtener el título de Maestro en Ciencias área: Telemática, lo solicitado por usted bajo el título APLICACIÓN CLIENTE / SERVIDOR DE 2 NIVELES UTILIZANDO DCOM/COM PARA GESTIONAR, REMOTA Y LOCALMENTE, TABLAS. DBF UBICADAS EN UNA LAN OPERANDO CON LOS SISTEMAS OPERATIVOS WINDOWS 9X Y NETWARE 4.11 Desarrollado bajo los siguientes puntos: Índice Introducción Capítulo I Marco Teórico Capítulo II Aspectos Técnicos de DCOM Capítulo III Archivos Tipo DBF Capítulo IV Planteamiento del Problema y Desarrollo de la Solución Capítulo V Resultados. Conclusiones Sugerencias Anexos Glosario Bibliografía Al mismo tiempo informo a usted que han sido designado como asesor de titulación: MC. PEDRO DAMIÁN REYES En cada uno de los ejemplares de titulación que presente para examen, deberá aparecer en primer termino copia del presente oficio. Copia: expediente del egresado Archivo Av. Universidad 333, Colima, Colima, México, C.P Telefax 01 (312) , , Ext

3 DEDICATORIAS A mi esposa Ángeles, mis hijos Miguel Ángel y Saúl Orlando.- Por el tiempo que no estuve con ellos por dedicarlo al estudio de la maestría. A mis maestros. - Por su esfuerzo y dedicación no siempre comprendido. A la Universidad. - Por la posibilidad que brinda a quienes desean superarse. ii

4 ÍNDICE INTRODUCCIÓN...1 I.- MARCO TEÓRICO...5 II.- ASPECTOS TÉCNICOS DE DCOM III.-ARCHIVOS TIPO.DBF IV.-PLANTEAMIENTO DEL PROBLEMA Y DESARROLLO DE LA SOLUCIÓN 43 V.- RESULTADOS Y CONCLUSIONES...66 SUGERENCIAS ANEXO A...71 ANEXO B ANEXO C ANEXO D ANEXO E ANEXO F GLOSARIO BIBLIOGRAFÍA iii

5 Tabla de figuras No. Fig Descripció n Página 1.1 Arquitectura Mainframe o Centralizada. 1.2 Esquema de un servidor de archivos Diseño de la arquitectura Cliente/Servidor de 2 niveles. 1.4 Esquema de aplicaciones distribuidas Enlaces entre aplicaciones Cliente/Servidor con RPC Esquema de la arquitectura Cliente/Servidor utilizando COM Esquema de la arquitectura DCOM Componentes COM en diferentes procesos DCOM: componentes COM en diferentes equipos Independencia de la localización Distribución paralela de componentes Distribución de un componente critico Administración consolidada del tiempo de vida Conexiones de red previas en CAPDAM Esquema de la solución propuesta Contenido del proyecto de la aplicación servidor Clase principal de la aplicación servidor Cuadro de dialogo que permite exponer una clase al público Opciones para generar la aplicación EXE o.dll Especificar si el servidor creado será de una o varias instancias. 53 iv

6 4.8 Configurar DCOM: opción " propiedades predeterminadas" Configurar la seguridad de DCOM Instrucción para registrar el modulo servidor Contenido del proyecto Cliente.pjx Formulario forml de la aplicación cliente Formulario ftira de la aplicación cliente Formulario para el login Utileria para configurar DCOM Indicar en que equipo se ejecuta el servidor. 63 No. tabla Tablas Descripción 1 Primera parte de la cabecera de una Tabla.DBF 31 2 Identificador del tipo de Tabla 31 3 Segunda parte de la cabecera de una tabla.dbf 34 Página v

7 Resumen: Se llevó a cabo una investigación aplicada, mediante el diseño y desarrollo de una aplicación Cliente/Servidor de 2 niveles, empleando la tecnología DCOM y el lenguaje Visual Fox Pro ver 6.0 para gestionar datos en archivos tipo.dbf localizados en un servidor bajo el sistema operativo Netware 4.11 de Novell. Las terminales clientes utilizan los sistemas operativos Windows 9.x. y están enlazadas en una LAN (red de área local) utilizando Ethernet. Se logró un menor tiempo promedio de respuesta respecto al tiempo requerido por un proceso remoto de arquitectura servidor de archivos, así como gestión concurrente, desde estaciones conectadas a la red empleando la aplicación desarrollada con la tecnología COM/DCOM, de los archivos ubicados en el servidor Netware 4.11 por un número de usuarios mayor al máximo permitido por la correspondiente licencia de Novell. Abstract: An applied aplication was performed, thru the design and development of a Middle tier Client/Server application, using DCOM technology and Visual Fox Pro version 6 language in order to process data contained in.dbf tables located in a file server running under Netware 4.11 by Novell. The client workstations run under the Windows 9.x operating system and are connected in an Ethernet LAN. A lower processing mean time was obtained in comparation to the required time using remote processing under a filer server architecture, as well as the concurrent procesing, by connected workstation to the net, of files located in the Netwar 4.11 serve r by a larger number of users than alloewed by the Novell licenced. vi

8 INTRODUCCIÓN Las condiciones económicas en las que se encuentra nuestro país, y que, según declaraciones de las autoridades hacendarias, se prolongará como resultado de las condiciones prevalecientes en los mercados internacionales, conlleva a las empresas públicas o privadas, particularmente a la pequeña o micro empresa, a reducir o cancelar los presupuestos disponibles para actualizar su infraestructura informática. Debido a las dificultades económicas imperantes, es común la necesidad de encontrar una solución de bajo costo que, coexistiendo con los procedimientos y equipos existentes, permita a la empresa enfrentar con éxito los problemas derivados del crecimiento en el volumen de datos a procesar o la mejora en la calidad o expansión de los servicios ofrecidos a sus clientes o usuarios. La Comisión de Agua Potable, Drenaje y Alcantarillado de Manzanillo, (CAPDAM), no escapa a la crisis referida y carece de los recursos financieros necesarios para la adquisición de equipo de cómputo o sistemas actuales, por lo que se ve forzada a operar con una infraestructura basada en equipos personales con procesadores que van del 386 al Pentium II, los cuales funcionan empleando los sistemas operativos MS-DOS, Win9x y Netware 4.11 en el servidor de archivos de la red local a la que están conectados. Los datos se almacenan en archivos tipo.dbf con índices IDX que son gestionados desde programas elaborados en CLIPPER. Una tecnología que permite la construcción de aplicaciones y sistemas bajo la arquitectura Cliente/Servidor, a partir de componentes producidos por diversos proveedores, es la arquitectura de software por componentes de Microsoft denominada COM (Modelo de Objetos Componentes), la cual permite la comunicación entre objetos ubicados en la misma computadora (Williams, 1996). La evolución de COM es DCOM, la cual extiende la comunicación entre objetos ubicados en diferentes computadoras (las cuales pueden estar ubicadas en una LAN, una WAN o incluso Internet), permitiendo distribuir las aplicaciones de la manera que tenga más 1

9 sentido para el usuario. Diseñar aplicaciones para ser distribuidas le da una gran flexibilidad al administrador del sistema, ya que, además de ser más fáciles de escalar, permite distribuir la carga de procesamiento al ejecutarse algunos módulos en equipos de bajo use (Microsoft Corporation, 1996). La industria de cómputo enfocada a Internet ha empezado a orientarse a dos campos tecnológicos (o plataformas de desarrollo); uno centrado alrededor de COMIDCOM/COM+, Internet Explorer y las capacidades de ActiveX de Microsoft, y el otro campo basado en las soluciones proporcionadas por CORBA, Netscape y Java. Ambas partes argumentan acerca de los meritos relativos a sus enfoques, pero actualmente no se tiene un claro ganador. Afortunadamente, ambos campos están trabajando en mecanismos que permiten la interacción entre ambas bases tecnológicas. Por lo tanto, se tiene soporte en CORBA para COM/DCOM/COM+ y Microsoft ha incorporado Java en su estrategia para Internet. Sin embargo, el trabajo para la interconexión entre ambos campos competitivos aun no esta completa. Existe una gran cantidad de aplicaciones basadas en las PC que toman ventaja de la tecnología COM y DCOM de Microsoft (por ejemplo Excell, Word, Power Point, etc.). COM+ es mas reciente que COM, fue anunciado el 23 de Septiembre de 1997 y embarcado con Windows 2000 (llamado también Windows NT versión 5.0). COM+ puede considerarse como la siguiente versión de COM (Williams, 1996). Debido a que la CAPDAM tiene sus recursos informáticos actualmente basados en la plataforma Microsoft y disponen de equipos con Windows 95 y Windows 98 (estos con modem interno y procesador P11), los cuales tienen disponible sin costo adicional la tecnología COM/DCOM, se empleara este enfoque para desarrollar la solución al problema propuesto. Además, se puede emplear Visual Fox Pro versión 6 para construir la solución Cliente/Servidor en esta plataforma, dado que es un recurso con el que se cuenta. 2

10 La tecnología Cliente/Servidor ha demostrado ser la más eficiente en los sistemas administrativos de alto desempeño, brindando: velocidad, integridad, seguridad y versatilidad (Microsoft Corporation, 1997; Hostmann 1997). Siendo estas las hipótesis sobre las que descanso el desarrollo de esta investigación. El presente trabajo aplica la metodología de la investigación aplicada y también de la investigación documental. Durante el desarrollo fue patente la escasez de información respecto a la arquitectura COM/DCOM tanto en el idioma español como en ingles, lo cual se puede palpar en la falta de referencias bibliográficas al respecto en las bibliotecas y librerías de nuestra Universidad y el Estado, por lo que fue necesario recurrir a una intensiva búsqueda de documentación en Internet, presentando hache una síntesis que podrá facilitar la incursión en este campo de mas interesados en este tema. La utilización de la arquitectura COM/DCOM para el desarrollo de componentes reutilizables y el empleo de la tecnología Cliente/Servidor para el desarrollo de aplicaciones en redes (ya sean LAN, WAN o Internet) empleadas para resolver el problema aquí planteado es la punta de lanza en la utilización de nuevas tecnologías. El trabajo esta organizado de la siguiente manera: el capítulos I presenta el marco teórico en el cual se encuadra y comprende la arquitectura Cliente/Servidor; en el capitulo II se revisan los principales aspectos técnicos de la tecnología COM/DCOM; en el capitulo III se detalla la estructura de los archivos tipo DBF; en el capitulo IV se plantea el problema, análisis, diseño y desarrollo de la solución; finalmente, se plasman las conclusiones y sugerencias. Con este proyecto se obtiene un prototipo que incorpora las nuevas tecnologías y herramientas de información (COM/DCOM/COM+) en el desarrollo de aplicaciones distribuidas para aplicarse a técnicas de acceso a bases de datos, búsquedas y recuperación de la información. Lo cual puede potenciar el use de estas para el desarrollo de aplicaciones para el procesamiento de Bases de Datos con una mayor eficiencia de desarrollo de software que puede ser reutilizado por cualquier aplicación que requiera su servicio y, con esto, redundar en una reducción de tiempos y costos de 3

11 producción, lo cual puede beneficiar enormemente tanto al sector empresarial como a nuestra Universidad. Se considera que el lector tiene conocimientos básicos de los conceptos de Redes LAN, WAN e Internet; conoce el modelo OSI y maneja con fluidez el lenguaje Visual Fox Pro versión 6, la teoría de Bases de Datos y los sistemas operativos Windows 95 y Windows 98, además de estar familiarizado con la programación de Objetos (POO.) 4

12 CAPÍTULO I MARCO TEÓRICO Es importante conocer que y como evolucionaron los conceptos básicos sobre los que se desarrollo el presente trabajo, estos son: Arquitectura Cliente/Servidor. Arquitectura de software de 2 niveles (Middletier o Two Tier). Ambiente de Cómputo Distribuido (Distributed Computing Enviroment o DCE) Interface para Programación de Aplicaciones (Application Programming Interface o API). Llamada a Procedimientos Remotos (Remote Procedure Call o RPC). COM/DCOM/COM+ : el Modelo de Objetos Componentes (Component Object Model o COM), Modelo de Objetos Componentes Distribuido (Distributed Component Object Model o DCOM) y Modelo de Objetos Componentes Mejorado ( COM+). A continuación se presenta un resumen para cada uno de los anteriores conceptos. La fuente fue tomada de The Software Engineering Institute (SEI), el cual es un centro federal para la investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos y operado por la Universidad Carnegie Mellon ( body.html ). 1.- Arquitectura de Software Cliente/Servidor (Darleen,2000). El termino Cliente/Servidor se utilizo por primera vez en los 1980's en referencia a computadoras personales (PC's) en una red. El modelo actual Cliente/Servidor empezó a ganar aceptación a finales de los 1980's. La arquitectura de software Cliente/Servidor es una infraestructura modular versátil, basada en mensajes, que esta dirigida a incrementar la usabilidad, flexibilidad, interoperatibidad y escalabilidad en comparación con la arquitectura Mainframe que funciona de manera centralizada y compartiendo el tiempo de cómputo ("time sharing computing"). 5

13 Un Cliente está definido como un solicitante de servicios y un Servidor esta definido como el proveedor de servicios. Una máquina puede ser, a la vez, cliente y servidor, dependiendo de la configuración del software. Son ejemplos de la arquitectura Cliente/Servidor: Arquitectura de software de 2 niveles (two tier o Middletier), arquitectura de software de 3 niveles (threee tier), arquitectura empresarial Distribuida/Colaborativa. Se tienen otros tipos de arquitectura, que no son Cliente/Servidor, estos son: a).-arquitectura Mainframe Con la arquitectura de software Mainframe, toda la inteligencia está en la computadora central que funciona como Servidor (ver fig. 1.1). Los usuarios interactúan con el Servidor a través de una terminal que captura lo tecleado y envía esa información al Servidor. La arquitectura de software Mainframe no esta atada a una plataforma de hardware. La interacción del usuario puede hacerse usando estaciones PC's y UNIX. Una limitación del software de arquitectura Mainframe es que no soportan fácilmente interfaces gráficas para el usuario o accesar múltiples bases de datos desde lugares dispersos geográficamente. En los últimos anos, los Mainframes han encontrado un nuevo use como servidores en una arquitectura distribuida Cliente/Servidor. Fig. 1.1 Arquitectura Mainframe o Centralizada. 6

14 b).- Arquitectura de Archivo Compartido (File Sharing Arquitecture) Las redes de PC's se basaron en la Arquitectura de Archivo Compartido, donde el Servidor descarga archivos desde las localidades compartidas al ambiente de escritorio. La arquitectura de Archivo Compartido es funcional si el use concurrente es bajo. En los 1990's, el cómputo en las redes de área local cambió debido a que la capacidad para compartir archivos fue comprometida a medida que el número de usuarios en línea creció (puede satisfacer cerca de 12 usuarios simultáneamente) y las interfaces gráficas para usuarios (GUI's) se volvieron populares (haciendo que el desplegado en las pantallas de terminales y mainframes pareciera obsoleto). El sistema operativo Netware versión 4.11 de Novell opera bajo este principio cuando se instala como servidor de archivos. En la figura 1.2 se ilustra esta arquitectura. 2.- Arquitectura de software de 2 Niveles o Middletier (Bray,2001). Esta arquitectura se desarrolló en los 1980's a partir del diseño de la arquitectura de Servidor de Archivos. La arquitectura de 2 niveles intenta incrementar la usabilidad al soportar interfaces amigables basadas en formatos, incrementa la escalabilidad al acomodar hasta 100 usuarios (la arquitectura de servidor de archivos solamente acomoda una docena de usuarios) y mejora la flexibilidad al permitir compartir los datos, usualmente dentro de un 7

15 ambiente homogéneo. La arquitectura de 2 niveles requiere de una mínima intervención del operador y se utiliza con frecuencia en sistemas de procesamiento que gestionan información que no sea compleja y tampoco crítica en el tiempo. La arquitectura de 2 niveles consiste de tres componentes distribuidos en 2 capas: Cliente (solicitante de servicios) y Servidor (proveedor de servicios). Los tres componentes son: Interface del Sistema para el usuario.- tales como sesión, captura de texto, diálogo y desplegado de los servicios de administración. Administración del Procesamiento.- ejemplos de esto es desarrollo, monitoreo y recursos para servicios de procesos. Administración de Base de Datos.- servicios de datos y archivos. El diseño de 2 niveles provee la interface del sistema para el usuario exclusivamente al cliente. Este ubica la administración de la base de dates en el servidor y divide la administración del procesamiento entre el cliente y el servidor, creando 2 capas como se muestra en la figura 1.3: En general, el cliente de la interface del sistema para el usuario invoca servicios desde el servidor de administración de bases de datos. En muchos diseños de 2 niveles, la mayor parte de la porción de procesamiento de la aplicación está en el ambiente del Cliente. El 8

16 servidor de administración de bases de datos usualmente proporciona la parte del procesamiento relativo al acceso a datos. (a menudo implementado en procedimientos almacenados). Los clientes se comunican con el servidor a través de instrucciones SQL o una interface de llamada de nivel (en el programa implementado no se usan instrucciones SQL). Nótese que la conectividad entre niveles puede cambiarse dinámicamente dependiendo de los requerimientos del usuario de datos y servicios. Comparándola con la arquitectura de servidor de archivos (que también soporta sistemas distribuidos), la arquitectura de 2 niveles mejora la flexibilidad y escalabilidad al alojar los 2 niveles sobre la red de computadoras. Los 2 niveles aumentan la usabilidad (comparado con la arquitectura de Servidor de Archivos) debido a que facilita proporcionar una interface de usuario del sistema adecuada. Es posible que un servidor funcione como cliente para un servidor diferente -en una arquitectura jerárquica Cliente/Servidor-. Esto es conocido como diseño encadenado de arquitectura de 2 niveles. La arquitectura de 2 niveles trabaja bien en ambientes relativamente homogéneos con reglas de negocios que no cambien con frecuencia y que los grupos de trabajo se considere sean menores a 100 usuarios. 3.- Ambiente de Cómputo Distribuido o DCE (Vondrak, 2001). Desarrollado y soportado por la Open System Foundation (OSF), el Ambiente de Cómputo Distribuido (DCE) es un ambiente integrado distribuido que incorpora tecnología de la industria. La DCE es un conjunto de servicios integrados de sistemas que proporcionan un ambiente distribuido interoperable y flexible cuyo principal propósito es resolver problemas de interoperabilidad en ambientes heterogéneos de redes. La OSF proporciona una referencia para la implementación (código fuente) en la cual se basan todos los productos DCE. La DCE son servicios portables y flexibles -la implementación de la referencia es independiente tanto de las redes como de los sistemas operativos y proporciona una arquitectura en la cual las nuevas tecnologías puedes ser incluidas, lo cual facilita las futuras mejoras. El intento de la DCE es que la implementación de la referencia incluirá tecnología madura y probada que pueda ser utilizada en partes- o como una infraestructura integrada completa. 9

17 La infraestructura DCE soporta la construcción e integración de aplicaciones Cliente/Servidor a la vez que procura ocultar la complejidad inherente al procesamiento distribuido al usuario. La OSF DCE intenta formar una plataforma de software comprensible sobre la cual las distribuciones distribuidas puedan construirse, ejecutarse y darles mantenimiento. En la figura 1.4 se muestra la arquitectura DCE Fig. 1.4 Esquema de aplicaciones distribuidas. Los servicios DCE están organizados en dos categorías: Servicios Distribuidos Fundamentales que proporcionan herramientas para el desarrollador de software para crear los servicios para el usuario final necesarias para el cómputo distribuido. Estos incluyen: RPC o Llamadas a Procesos Remotos (Remote Procedure Call), las cuales proporcionan portabilidad, independencia de la red y aplicaciones distribuidas seguras. Servicios de Directorio, los cuales proporcionan total soporte al protocolo X.500 y un modelo simple para nombrar que permite a los programadores identificar y accesar los recursos distribuidos más fácilmente. 10

18 Servicios de tiempo, los cuales proporcionan a la red los servicios de autenticación, autorización y administración de cuentas de usuarios para mantener la integridad, privacidad y autenticidad para los sistemas distribuidos. Servicios de Seguridad, los cuales proporcionan un modelo de programación simple y portable para construir aplicaciones concurrentes. Los Servicios para compartir datos proporcionan a los usuarios finales las capacidades construidas sobre los servicios fundamentales distribuidos. Estos servicios no requieren programación de parte de los usuarios finales y facilitan un mejor use de la información. Estos servicios incluyen: Sistema de Archivos Distribuido, el cual interopera con el sistema de archivos de la red para proporcionar un acceso al sistema de archivos de alto desempeño, escalable y seguro. Soporte no dependiente de discos, el cual permite a estaciones de trabajo de bajo costo usar los discos de los servidores, posiblemente reduciendo la necesidad o costos de discos locales y proporcionando un desempeño mejorado que reduce la sobrecarga en la red. La DCE soporta los estándares de la International Open System Interconnect (OSI), los cuales son críticos para la interconectividad global. También implementa los estándares ISO tales como CCITT X.500, Remote Operations Service Element (ROSE), Association Control Service Element (ACSE) y los servicios de sesión y presentación ISO. La DCE también soporta estándares de Internet tales como los protocolos de transporte y red de TCP/IP, así como el Domain Name System (DNS) y Network Time Protocol proporcionados por Internet. La DCE puede ser utilizada por vendedores de sistemas, desarrolladores de software y usuarios finales. Puede ser utilizada en cualquier hardware de red y software de la capa Trasporte, incluyendo TCP/IP, OSI y X.25. La DCE esta escrita en C estándar y utiliza servicios estándar de interfaces de sistemas operativos, tales como POSIX y referencias X/Open. Esto hace que DCE sea portable a una amplia variedad de plataformas. DCE permitela extensión de redes a un gran número de nodos, proporcionando un ambiente capaz de soportar redes de númerosas computadoras de 11

19 bajo costo (tales como equipos PC's o Macintosh), lo cual es importante si se desea el procesamiento distribuido y el empleo de equipos de bajo perfil. Debido a que DCE es proporcionado en su forma fuente, este puede ser rastreado para aplicaciones específicas si así se desea. DCE trabaja internamente con el modelo Cliente/Servidor y esta perfectamente adaptado para el desarrollo de aplicaciones que son estructuradas de acuerdo a este modelo. La mayor parte de los servicios DCE están especialmente optimizados para estructurar los sistemas de cómputo distribuido en una "celda" (un conjunto de nodos/plataformas) que es administrado junto con una autoridad. Para DCE, la comunicación entre "celdas" esta optimizada y relativamente segura y transparente. La comunicación entre "celdas", sin embargo, requiere más procesamiento especializado y más complejidad que su contraparte entre celdas, además de un mayor grado de experiencia en programación. Cuando se usan los servicios de hilos (trheads) proporcionados por DCE, los programadores de aplicaciones deberán estar concientes de la sincronización de hilos y datos compartidos a través de la red. En tanto que diferentes hilos son mutuamente asíncronos hasta un número estático definido en la inicialización, un hilo individual es tratado sincrónicamente. La complejidad de la programación de hilos deberá considerarse si se van a utilizar estos servicios. A principios de 1992, la OSF liberó el código fuente para DCE 1.0. Aproximadamente 12 vendedores han transferido esta versión a sus sistemas y tuvieron los productos DCE 1.0 disponibles a partir de Enero de La mayor parte de estos productos fueron estuches para el desarrollo que no fueron robustos y no contenían el conjunto total de características DCE todas carecieron de los servicios de archivos distribuidos), y fueron adecuadas principalmente para plataformas UNIX. DCE 1.2.1, liberado en Marzo de 1996, proporciono las siguientes características: Soporte para la definición de inteface de lenguaje (Interface Definition languague o IDL) para C++ para incluir características tales como herencia y referencia a objetos como soporte para aplicaciones orientadas a objetos. Estas características 12

20 soportaron la adopción de cualquier modelo de objetos o jerarquía de clases, proporcionando por lo tanto a los programadores con una flexibilidad adicional. Características para proporcionar la coexistencia con otros ambientes de aplicación. Mejoras sobre DCE 1.1 incluyendo realce para alcanzar una mayor confiabilidad y mejor desempeño. Se consideran otros enfoques para soportar objetos además del descrito para DCE 1.2, estos son: Instalar un producto basado en CORBA sobre DCE para proporcionar soporte adicional para tecnología de objetos distribuidos y una amplia gama de servicios de interface estandarizados. Integrar redes COM/DCOM dentro de la infraestructura DCE. 4.- Interface para Programación de Aplicaciones o API (Bray, 2000). La Interface para Programación de Aplicaciones (Application Programming Interface o API), es una vieja tecnología que facilita el intercambio de mensajes o datos entre dos o más aplicaciones diferentes de software. API es la interface virtual entre dos funciones de software de red, tales como procesadores de palabra y hojas de cálculo. Esta tecnología se ha expandido desde simples llamadas a subrutinas hasta incluir características que proporcionan interoperatividad y modificabilidad de sistemas para soportar los requerimientos para compartir datos entre múltiples aplicaciones. Una API es el software que se usa para soportar la integración a nivel del sistema para múltiples paquetes de productos comerciales o nuevos productos desarrollados para aplicaciones existentes o nuevas. Las API's también son un tipo de arquitectura de dos niveles (Middleware) que posibilita el compartir datos a través diferentes plataformas; esta es una característica importante cuando se desarrolla o actualizan sistemas distribuidos nuevos o ya existentes. Esta tecnología es una forma de alcanzar el objetivo de los sistemas abiertos y estándares: la consistencia total entre plataformas. 13

21 API es un conjunto de reglas para escribir llamadas a funciones o subrutinas que accesen funciones en una librería. Los programas que usan estas reglas o funciones en sus llamadas API se pueden comunicar con cualquier otro que use API, sin importar las especificaciones de esos otros. API trabaja con un amplio espectro de diálogos de aplicaciones (es decir: esquemas de comunicación entre programas) para facilitar el intercambio de información. Los cuales incluyen: acceso a bases de datos, Cliente/Servidor, punto a punto, tiempo real y procesamiento de transacciones. API combina la recuperación de errores, traducción de datos, seguridad, colas (queuing) y designación con una interface fácil de aprender que comprende comandos/acciones simples pero poderosas. Para invocar una API, un programa llama a una función tipo SEND (enviar), especificando como parámetros el nombre del destino, apuntadores (pointers) a los datos y regresar opciones de confirmación. La API toma los datos y efectúa el trabajo de todas las comunicaciones de manera transparente para la aplicación. Hay cuatro tipos de API's que habilitan el compartir datos entre diferentes aplicaciones de software sobre plataformas distribuidas o únicas. Remote Procedure Calls (RPCs) Standard Query Language (SQL) Transferencia de Archivos Entrega de Mensajes (message delivery) Al usar RPC, los programas se comunican mediante procedimientos (o tareas) que actúan sobre buffers de datos compartidos. SQL es un lenguaje para acceso a datos que permite compartir los datos entre aplicaciones mediante el acceso a una base de datos común. Los estándares actúales que aplican API incluyen el ANSI estándar SQL API. La Transferencia de Archivos permite el compartir datos mediante el envió archivos formateados entre aplicaciones. 14

22 Entrega de Mensajes proporciona el compartir datos mediante la comunicación directa entre programas por medio de pequeños mensajes formateados entre aplicaciones estrecha o fuertemente acopladas. Las API's pueden ser desarrolladas para todas las plataformas de cómputo y sistemas operativos o adquirirse para la mayoría de las plataformas y sistemas operativos. Los cuatro tipos de API's pueden ser usadas tanto en aplicaciones multiplataformas o homogéneas. Sin embargo debido a la complejidad adicional requerida para compartir datos a través de múltiples plataformas, Las API's RPC, SQL o Transferencia de Datos son preferiblemente utilizadas para facilitar la comunicación entre diferentes aplicaciones sobre sistemas de plataformas homogéneas. Estas API's comunican datos en diferentes formatos (es decir: buffers de datos compartidos, estructuras de bases de datos y constructores de archivos). Cada formato de datos requiere comandos de red y parámetros diferentes para comunicar los datos adecuadamente y pueden causar diferentes tipos de errores, por lo que cada aplicación debe proporcionar comunicaciones entre programas robustas. Una API para Entrega de Mensajes ofrece un pequeño subconjunto de comandos, parámetros de red y condiciones de red debido a que estas API tratan solo con una clase de formato (mensaje). Debido a su reducida complejidad, las API para Entrega de Mensajes son una mejor opción cuando las aplicaciones requieren compartir datos a través de múltiples plataformas. 15

23 5.- Llamada a Procedimientos Remotos o RPC Esta es una infraestructura Cliente/Servidor que ha incrementado la interoperabilidad, portabilidad y flexibilidad de una aplicación, al permitir a esta que este distribuida sobre múltiples plataformas heterogéneas. Reduce la complejidad del desarrollo de aplicaciones que se expanden a múltiples sistemas operativos y protocolos de red al aislar el desarrollo de la aplicación de los detalles de los diversos sistemas operativos e interfaces de red - las llamadas de funciones son la interfaz de los programadores cuando utilizan RPC. El concepto de RPC ha sido discutido en la literatura desde 1976, apareciendo su completa implementación a fines de 1970 y principio de los 1980s. Para poder accesar la porción remota de una aplicación Servidor, las llamadas especiales de funciones, RPC, están imbuidas dentro de la porción Cliente de un programa de aplicación Cliente/Servidor. Debido a que están imbuidas, RPC no esta aislado como una capa discreta de 2 niveles (middleware). Cuando el programa Cliente es compilado, el compilador crea un enlace (stub) para la porción Cliente u otro enlace (stub) para la porción Servidor de la aplicación. Estos enlaces son invocados cuando la aplicación requiere una función remota y típicamente soporta llamadas asíncronas entre Clientes y Servidores. Estas relaciones se muestran en la figura

24 Al usar RPC, la complejidad involucrada en el desarrollo de procesamiento distribuido se reduce a conservar igual la semántica de una llamada remota estén o no colocados el Cliente y el Servidor en el mismo sistema. Sin embargo, RPC incrementa el involucramiento del desarrollador de una aplicación con la complejidad de la naturaleza maestro-esclavo del mecanismo Cliente/Servidor. RPC incrementa la flexibilidad de una arquitectura al permitir a un componente Cliente de una aplicación, emplear una llamada a función para accesar el Servidor en un sistema remoto. RPC permite al componente remoto ser accesado sin conocimiento de la dirección de la red o cualquier otra información de bajo nivel. La mayor parte de RPC's usan un protocolo síncrono, petición-respuesta (algunas veces referido como "llama/espera") que involucra el bloqueo del Cliente hasta que el Servidor complementa la solicitud. Implementaciones asíncronas ("llama/espera") están disponibles pero actualmente son la excepción. RPC esta implementado típicamente en una de 2 formas: dentro de un producto propietario por un programador utilizando una herramienta propia para crear enlaces RPC para aplicaciones Cliente/Servidor RPC es apropiado para aplicaciones Cliente/Servidor en los cuales el cliente puede enviar una petición y esperar por la respuesta del Servidor antes de continuar su propio procesamiento Otras tecnologías que permiten la distribución de procesos a través de múltiples procesadores y plataformas son: Object Request Brokers (ORB) Distributed Computing Enviroment (DCE) COM/DCOM Arquitectura de Software de 3 niveles (Tree Tier Software Arquitecture) 17

25 6.- COM/DCOM/COM+ (Mueller J.P, 2000, pp 5-22; Williams,1996) El Modelo de Objetos Componentes (COM) es una arquitectura de software por componentes que permite construir aplicaciones y sistemas a partir de componentes proporcionados por diferentes proveedores de software. COM proporciona la arquitectura subyacente que forma las bases para servicios de software de alto nivel, como los proporcionados por OLE. Estos servicios proporcionan diversas funcionalidades al usuario, sin embargo, comparten un requerimiento fundamental de un mecanismo que permita a los componentes binarios de software, proporcionados por diferentes vendedores, la conexión y comunicación entre sí de una manera bien definida. Este mecanismo esta proporcionado por COM, una arquitectura de software por componentes que: Define un estándar binario para la interoperabilidad de componentes. s independiente del lenguaje de programación utilizado. Se proporciona en múltiples plataformas (Microsoft Windows, Windows NT/2000, Apple Macintosh, Unix). Permite la evolución robusta de aplicaciones y sistemas basados en componentes. Es extensible. Adicionalmente, COM proporciona mecanismos para lo siguiente: Comunicación entre componentes, aun a través de procesos y fronteras de red. Administración de memoria compartida entre componentes. Reporte de Errores y Estado. Carga dinámica de componentes. La historia de COM inicia a finales de 1989 y principios de 1990 cuando aparece por primera vez DDE (Dynamic Data Exchange), cuyo propósito era crear un macro lenguaje común para aplicaciones que permitiera a 2 documentos compartir los mismos datos. Los programas con capacidad DDE pueden intercambiar información al tiempo de ejecución, intercambiando texto, imágenes e incluso algunos comandos simples. En 1991, se creó OLE (Object Linking and Embedding) que permitió el control tanto de la aplicación como de los datos de la aplicación. OLE versión 1 formó parte de Windows 3.x y rápidamente fue sobrepasado por los requerimientos de los usuarios, entre sus mayores 18

26 problemas estaba la gran cantidad de memoria que necesitaba y baja velocidad de procesamiento. En 1995 se liberó OLE versión 2, llamada COM, el cual proporciona un mecanismo de propósito general para la integración de componentes en las plataformas de Windows. En Diciembre de 1995, OLE evoluciona en ActiveX, que es otro término para una específica clase de tecnología por componentes que se basaba en COM, entre otras cosas. En la figura 1.6 se muestra un ejemplo de COM Aún cuando en la primera versión de COM se incluían algunas nociones de componentes distribuidos, el soporte más completo para la distribución de objetos a escala empresarial, fué disponible en 1996 con DCOM, el cual esta basado en la OSF (Open Software Foundation), DCE (Distributed Computing Enviroment), el protocolo de red RPC (Remote Procedure Call). DCOM permite a las aplicaciones comunicarse a través de la red en formas que los usuarios de DDE, OLE y COM desearon. Las ligas que crea DCOM son, razonablemente seguras y permanentes. Si se remueve el componente del lado del Servidor, el cliente no lo encontrará por más que lo intente. Esto significa que tanto el Cliente como el Servidor deberán existir al mismo tiempo y tener una conexión entre si. En la figura 1.7 se ilustra DCOM. 19

27 La arquitectura DCOM (Distributed Component Object Model) es una extensión de COM que permite la comunicación entre objetos situados en diferentes máquinas a través de distintos tipos de redes (LAN, WAN e incluso Internet). Al ser DCOM una evolución natural de COM es posible utilizar todas aquellas aplicaciones, componentes, herramientas y conocimiento previos para trabajar ahora en un entorno distribuido. DCOM pretende solucionar los problemas más comunes que surgen en un entorno de trabajo distribuido: Fiabilidad ante posibles fallos en la red. Fiabilidad ante posibles fallos en el hardware. Eficiencia en términos de carga de la red. Posibilidad de trabajar con maquinas de diferentes prestaciones situadas en distintas áreas geográficas. Posibilidad de instalación tanto en grupos de trabajo pequeños como grandes. COM+ es la más reciente de las versiones de COM, fue anunciado el 23 de Septiembre de 1997 y embarcado con Windows 2000 (Windows NT 5.0). 20

28 CAPÍTULO II ASPECTOS TÉCNICOS DE DCOM En este capítulo se resume el contenido del artículo "DCOM a Technical Overview" (Microsoft Corporation, 1996), en el cual se detallan las características técnicas de la arquitectura de software DCOM (Distributed Component Object Model), la cual permite la comunicación directa entre componentes de software ubicados en diferentes computadoras en una red (local, amplia o Internet) de manera confiable, segura y eficiente. Con DCOM, la aplicación puede distribuirse a la ubicación que tenga más sentido para el usuario y el administrador de sistemas. 2.1 Introducción Las necesidades de interoperabilidad que presentan los actuales sistemas de información han motivado el desarrollo de estándares que normalizan la comunicación y el traspaso de objetos entre aplicaciones. La tecnología OLE (Object Linking and Embedding) de Microsoft representó un primer paso en esta línea de acción. Con este sistema se proporcionan herramientas como el portapapeles, la vinculación e incrustación de objetos y su almacenamiento estructurado, además de interfaces que posibilitan su inclusión y reutilización en aplicaciones diversas. OLE es sustentado por la arquitectura COM (Component Object Model), que le suministra los mecanismos de coordinación y comunicación entre componentes. Dado que COM se desarrolló en un primer momento para su utilización en un sistema aislado, Microsoft extendió el estándar para que pudiera ser utilizado en entornos distribuidos, con lo que dio lugar a la especificación DCOM (Distributed Component Object Model). 2.2 Arquitectura DCOM En los sistemas operativos en los cuales los procesos están aislados unos de otros. Un cliente que necesite comunicarse con un componente de otro proceso no puede realizar una llamada directa, sino que tiene que hacer use de algún tipo de comunicación entre procesos proporcionada por el sistema operativo. COM/DCOM permite establecer esta 21

29 comunicación de una manera completamente transparente interceptando la llamada del cliente y dirigiéndola a un componente en otro proceso (fig.2.1). Cuando cliente y componente residen en diferentes máquinas (fig. 2.2), DCOM simplemente sustituye la comunicación entre procesos por un protocolo de red, de modo que ninguno de los dos advierte este cambio. COM proporciona servicios orientados a objetos a clientes y componentes, y utiliza DCE RPC (Remote Procedure Call) y varios sistemas de seguridad (Security Providers) para generar paquetes de red. DCE RPC, del que DCOM toma el concepto de GUID (Globally Unique Identifier), define un estándar para la conversión de parámetros y estructuras de datos almacenadas en memoria para formar paquetes de red. Su formato de representación de datos NDR (Network Data Representation) es independiente de la plataforma. Fig 2.2 DCOM: componentes COM en diferentes equipos. 22

30 DCOM proporciona un tipo de comunicación Cliente/Servidor. Para solicitar un servicio, el cliente invoca un método implementado en un objeto remoto, que actúa como servidor en dicho modelo. Este servicio se encapsula como un objeto, y su interfaz se describe en un lenguaje específico, IDL (Interface Definition Language), manteniéndose oculta al cliente la implementación real del objeto. DCOM tiene la posibilidad de que un objeto tenga múltiples interfaces. DCOM emplea comunicaciones de tipo RPC para llevar a cabo las relaciones entre cliente y servidor. En el protocolo RPC para invocar a una función, el cliente hace una llamada al stub del cliente. El stub empaqueta los parámetros en un mensaje de petición y se lo pasa al protocolo de comunicación para que lo lleve al servidor. Aquí, el protocolo de comunicación entrega el mensaje al stub del servidor, que desempaqueta los datos y llama a la función requerida. En DCOM, al stub (ver RPC en capítulo I) del cliente se le conoce como proxy y al del servidor como stub. DCOM puede asociar varias interfaces a una misma clase. El código de DCOM pasa por un compilador de DL para generar el código del stub/proxy y la cabecera de la interfaz que usarán tanto el servidor como el cliente. En DCOM, cada interfaz lleva asociada un GUID o identificador único global, llamado interface ID (IID). Del mismo modo, a cada clase se le asigna un único identificador Class ID (CLSID). Por otro lado, cada interfaz COM debe heredar propiedades de la interfaz Iunknown, que consta de un método llamado Querylnterface() para navegar entre diferentes interfaces del mismo objeto, y otros dos métodos AddRef() y Release() para contar las referencias. Así, un objeto COM lleva cuenta de sus clientes, y puede descargarse a sí mismo cuando no se le necesita. Después de compilar y antes de ser ejecutado, DCOM requiere un proceso de registro para el servidor. La asociación entre el CLSID y la localización del ejecutable se guarda en el registro de Windows. Además, como la interfaz del proxy/stub es también un objeto COM, necesita ser registrada de la misma manera. 23

31 2.2.2 Capa Intermedia. Arquitectura de Proceso Remoto Esta capa contiene la infraestructura necesaria para ofrecer al cliente y al servidor la ilusión de encontrarse en el mismo espacio de direcciones. DCOM emplea el registro de Windows para registrar los objetos servidores. En cuanto a la creación de objetos, DCOM crea un stub después de llamar a Createlnstance(). Para enviar datos a través de distintos espacios de direcciones se emplea un proceso denominado marshaling. Este proceso empaqueta los parámetros de la llamada y devuelve un valor en el servidor en un formato de transmisión estándar, como una RPC normal. La operación contraria se conoce como unmarshaling, y convierte los datos entrantes del formato estándar al propio del espacio de memoria destino. DCOM también proporciona un mecanismo para hacer este proceso según la definición del usuario. Este procedimiento, denominado custom marshaling, puede emplearse para soportar infraestructuras de comunicación específicas de la aplicación Capa Inferior: Arquitectura del Protocolo de Comunicación Esta capa especifica el protocolo para soportar la comunicación entre clientes y servidores. El protocolo empleado en DCOM se basa principalmente en la especificación OSF DCE RPC con algunas extensiones, como ya se ha comentado en capítulos anteriores de este documento. 2.3 Independencia de localización Al implementar una aplicación distribuida real sobre una red pueden aparecer una serie de restricciones al diseño: Algunos componentes sólo pueden ser ejecutados en algunas máquinas o en determinadas localizaciones. 24

32 Los componentes que interactúan más a menudo deberían estar situados "más cerca". Muchos componentes pequeños incrementan la flexibilidad del diseñó, pero generan mayor tráfico en la red. Pocos componentes grandes reducen el tráfico en la red pero también la flexibilidad del diseño. Con DCOM es fácil evitar estas restricciones, ya que oculta la localización de los componentes, y la forma en la que el cliente se conecta a ellos y realiza una llamada a sus funciones es siempre la misma. DCOM no sólo no requiere cambios en los programas fuente, sino que tampoco es necesario recompilarlos, porque la reconfiguración cambia la forma en que los componentes se conectan entre ellos. Esto simplifica en gran medida la tarea de distribuir los diferentes componentes de la aplicación con el fin de optimizar el rendimiento. En la figura 2.3 se muestra como un mismo componente puede situarse en la máquina del cliente cuando existe suficiente capacidad en la red o en el servidor cuando el cliente accede a la aplicación a través de un enlace lento. Fig. 2.3 Independencia de la localización 2.4 Facilidad de crecimiento (scalability) Un factor crítico de las aplicaciones distribuidas es su capacidad de adaptarse al aumento del número de usuarios, volumen de datos o funcionalidades requeridas. La aplicación 25

33 debería ser pequeña y rápida cuando la demanda es baja, pero también ser capaz de de atender una demanda creciente manteniendo un rendimiento y una fiabilidad aceptables. DCOM proporciona algunos elementos que facilitan la capacidad de crecimiento de las aplicaciones Multiproceso simétrico. DCOM aprovecha la capacidad de proceso de Windows NT. En aquellas aplicaciones que utilizan un modelo de hebras libres (free-threads), DCOM usa un banco de hebras (thread pool) para las peticiones que llegan al sistema. En máquinas con varios procesadores, este banco de hebras se optimiza en función del número de procesadores disponibles: demasiadas hebras suponen cambios de contexto frecuentes, mientras que pocas hebras pueden desaprovechar la capacidad de algunos procesadores que quedarían inactivos. DCOM libera al diseñador de los detalles del manejo de hebras, consiguiendo un rendimiento que sólo podría obtener programando todo el proceso manualmente Desarrollo flexible. En ocasiones no es posible atender a una demanda creciente ni siquiera aumentando la velocidad que proporciona una máquina multiprocesador. La independencia de la localización de DCOM facilita la labor de distribuir componentes entre diversas máquinas, ofreciendo un modo más sencillo y barato de aumentar la capacidad de las aplicaciones. La redistribución es más sencilla cuando los componentes son "sin estado" (stateless) o no comparten su estado con otros componentes, ya que en este caso es posible ejecutar varias copias en diferentes máquinas. La demanda puede ser distribuida de forma uniforme entre todas las máquinas o de acuerdo a criterios como capacidad y carga (fig. 2.4). Cambiar la forma en la que los clientes se conectan a los componentes y éstos últimos entre si es fácil con DCOM, porque permite, sin necesidad de añadir código o recompilar, la redistribución dinámica de los componentes. Sólo es necesario actualizar el registro, archivo del sistema, o base de datos en la cual se almacena la situación de cada componente en un momento determinado. 26

34 Figura 2.4. Distribución paralela de componentes. Muchas aplicaciones reales tienen uno o mas componentes críticos (bottleneck components) que son utilizados en la mayor parte de las operaciones. Pueden ser, por ejemplo, componentes de bases de datos a los que hay que acceder en serie de modo FCFS (first come-first served). No es posible duplicar este tipo de componentes, ya que su finalidad es precisamente establecer un punto único de sincronización para todos los usuarios de la aplicación. Con el objetivo de mejorar el rendimiento de una aplicación distribuida estos componentes críticos deberían ejecutarse en un servidor dedicado de gran potencia y altas prestaciones. De nuevo DCOM ayuda a aislar estos componentes críticos en las fases iniciales del proceso de diseño, colocando inicialmente todos ellos en una misma máquina para más tarde situar los componentes críticos en máquinas dedicadas. Los componentes críticos suelen formar parte de una cadena de procesos, por ejemplo, órdenes de compra o venta en un sistema de venta electrónico: los pedidos deben ser procesados conforme se van recibiendo y en ese orden (FCFS). Una posible solución sería dividir el trabajo en componentes más pequeños y ejecutar cada uno de ellos en una máquina diferente (fig. 2.5). El efecto sería similar al que se consigue con la técnica del pipelining en los microprocesadores modernos: cuando llega la primera petición es procesada por el primer componente (que podría ser, por ejemplo, una comprobación de la corrección semántica de la orden) y en caso de que sea válida pasa 27

35 al siguiente (para realizar, por ejemplo, una actualización de la base de datos). Tan pronto como el primer componente mande al segundo la petición, quedará libre para procesar nuevas entradas y de esta forma tendremos dos máquinas trabajando en paralelo entre dos peticiones diferentes, a la vez que garantizamos que éstas son procesadas en el orden adecuado. Con DCOM es posible aplicar esta misma técnica cuando trabajamos en una sola máquina, ya que podemos ejecutar varios componentes en diferentes hebras o en diferentes procesos, facilitando además el crecimiento de nuestra aplicación mediante la distribución de las hebras en una máquina multiproceso o de los procesos en diferentes máquinas. 2.5 Control de la conexión Las conexiones a través de la red son más delicadas que las conexiones dentro de una máquina, por esta razón es necesario, que los componentes de una aplicación distribuida sean avisados cuando un cliente deja de estar activo o cuando se produce un fallo en la red o en el hardware. DCOM controla las conexiones entre componentes que están dedicados a un solo cliente así como las de aquellos que están compartidos por varios clientes. Cuando un cliente establece una conexión con un cliente el contador de referencias se incrementa en una unidad, decrementandose cuando el componente libera la conexión. En caso de que el contador sea cero el componente puede liberar la memoria que ocupa. 28

36 DCOM utiliza un protocolo de ping en el cual el cliente envía de forma periódica un mensaje para comprobar que los componentes permanecen activos (fig. 2.6). Si transcurren más de tres periodos sin que el componente reciba estos mensajes DCOM considera rota la conexión y procederá a decrementar el contador de referencias, liberando el componente si el contador llega a cero. Desde el punto de vista del componente, el proceso es el mismo independientemente de que sea el cliente el que se desconecte por sí mismo o de que se produzca un fallo en la red o en la máquina cliente. Todo este mecanismo de liberación de memoria por parte de componentes no utilizados es transparente a las aplicaciones clientes. 1.6 Ancho de banda y retardo Aunque en teoría DCOM oculta el hecho de que en las aplicaciones distribuidas los componentes se ejecutan en diferentes máquinas, en la práctica es necesario considerar las limitaciones de una conexión a través de una red: Ancho de banda: el tamaño de los parámetros en una llamada a una función afecta directamente al tiempo necesario para completar esa llamada. Retardo: La distancia física y el número de elementos de la red, tales como routers o enlaces, introducen un retardo que puede llegar a ser significativo. En el caso de una red 29

37 global como Internet los retardos pueden ser del orden de segundos. DCOM consigue superar estas limitaciones minimizando cuando sea posible el número de saltos en la red para evitar retardos. El protocolo de transporte más usado por DCOM es el protocolo no orientado a conexión UDP, lo que permite una mayor optimización mezclando paquetes de asentimiento con datos y mensajes ping. Incluso en el caso de que DCOM emplee protocolos orientados a conexión se consigue una significativa mejora con respecto a protocolos desarrollados específicamente para cada aplicación. 2.7 Seguridad Al utilizar una red de comunicaciones para distribuir una aplicación no sólo nos encontramos con limitaciones físicas, ancho de banda y retardo, sino también con problemas de seguridad entre clientes y componentes. Al ser las funciones accesibles físicamente por cualquiera con acceso a la red, es necesario establecer restricciones en un nivel superior. DCOM implementa su propio sistema de seguridad con el fin de evitar que cada aplicación se vea obligada a desarrollar el suyo de manera independiente. Una plataforma distribuida como DCOM debe facilitar un entorno seguro que permita distinguir entre clientes y grupos de clientes de modo que el sistema o la aplicación pueda conocer quién intenta acceder a determinados servicios de un componente. DCOM utiliza el sistema de seguridad de Windows NT que consiste en una serie de security providers basados e métodos tradicionales tales como dominios o claves públicas en sistemas no centralizados. Una de las partes fundamentales de este sistema de seguridad es el directorio de usuarios que almacena la información necesaria para comprobar las credenciales de éstos. DCOM proporciona seguridad a las aplicaciones distribuidas sin necesidad de incluir en el cliente o en el componente elementos de codificación o diseño específicos. Al igual que ocurría con la localización de los componentes DCOM también oculta sus necesidades de seguridad. El mismo código ejecutable en un entorno centralizado, con 30

38 una sola máquina, donde la seguridad no plantea ningún problema puede ser utilizado en un entorno distribuido de manera segura. El diseñador simplemente tiene que fijar los requisitos de seguridad de cada componente, indicando que usuarios tienen derecho de acceso a sus servicios. En el que caso de que el diseñador se desentienda de los aspectos de seguridad, DCOM proporciona un mecanismo de seguridad por defecto bastante eficiente Seguridad en Internet Existen dos problemas de seguridad fundamentales a la hora de utilizar aplicaciónes diseñadas para trabajar en Internet. El número de usuarios puede ser varios ordenes de magnitud superior al existente en una compañía. Los usuarios finales desearían poder usar la misma slave o password para todas las aplicaciones que utilizan, aunque sean distribuidas por diferentes compañías. Sin embargo, la aplicación o el sistema de seguridad del proveedor de los servicios puede no tener capacidad para almacenar las slaves privadas de todos los posibles usuarios. Las aplicaciones distribuidas que utilizan la arquitectura DCOM pueden aprovechar los sistemas de seguridad que ésta proporciona sin necesidad de introducir ningún cambio en dichas aplicaciones, incluso en las más sensibles a los problemas de seguridad. DCOM hace use de los sistemas de seguridad (security providers) que proporciona el entorno Windows NT: Protocolo de autentificación NTLM, empleado por la versión 4.0 y anteriores de Windows NT. Protocolo de autentificación Kerberos Versión 5, que sustituye a NTLM para el acceso a recursos dentro o entre dominios de Windows NT. Protocolo de autentificación distribuido DPA (Distributed Password Autenticación), empleado por algunas de las principales organizaciones de Internet, como CompuServe o Microsoft Network. Servicios de seguridad por canales seguros, que implementan los protocolos SSL/PCT en Windows NT 4.0. Sistema de seguridad que utiliza DCE como entidad expendedora de claves sobre Windows NT. 31

39 Todos estos sistemas de seguridad utilizan protocolos estándar de Internet y tienen diferentes ventajas e inconvenientes. Los protocolos NTLM y Kerberos son protocolos de clave privada, son extremadamente eficientes y seguros en entornos centralizados o en dominios basados en servidores Windows NT. Existen versiones comerciales de NTLM para la mayor parte de los entornos UNIX. Con el sistema de directorios de Windows NT 4.0, dominios controlados por varios servidores de claves pueden tener un buen comportamiento hasta aproximadamente usuarios. Con el sistema ampliado de directorios de Windows NT 5.0 un solo servidor de claves en un dominio Windows NT puede llegar a administrar hasta un millón de usuarios. Combinando varios servidores de claves en el árbol de directorios de Windows NT 5.0, el número de usuarios en un sólo dominio es prácticamente ilimitado. El sistema Kerberos sobre Windows NT 5.0 proporciona elementos de seguridad más avanzados como controlar qué pueden hacer los componentes mientras autentifica a los clientes, además de requerir menos recursos que NTLM. Microsoft planea incluir en el futuro sistemas de seguridad basados en claves públicas para Windows NT, que permitirá descentralizar el control de la seguridad para cualquier aplicación de Windows NT, incluyendo aquellas basadas en DCOM. La autentificación mediante claves públicas es menos eficiente que usando claves privadas, pero no requiere almacenar las credenciales privadas de los clientes. 2.8 Rendimiento y prestaciones Como hemos visto hasta ahora la arquitectura DCOM ofrece herramientas que proporcionan flexibilidad tanto para la integración de componentes COM ya desarrollados, como para la utilización de diferentes lenguajes de programación, además de permitir el crecimiento de las aplicaciónes. Sin embargo, podemos preguntarnos cómo afectan estas características al rendimiento de la arquitectura. En COM/DCOM el cliente nunca tiene acceso a la implementación del objeto servidor, lo que se consigue, en la mayor parte de los casos, sin tener que utilizar componentes intermedios. Esta transparencia de acceso se obtiene 32

40 mediante un mecanismo de comunicación entre componentes a través de llamadas a función mediante punteros. La única sobrecarga que introduce este método frente a los utilizados en otros lenguajes de programación es la búsqueda de la dirección de función en las tablas virtuales (vtables). 33

41 CAPÍTULO III ARCHIVOS TIPO.DBF Desde su nacimiento con dbase de Ashton-Tate en los 1980's, la utilización de los archivos de datos tipo DBF han sido utilizados extensamente, posibilitando una gran cantidad de aplicaciones desarrolladas para la micro, pequeña y mediana industria que contaban con equipos PC compatibles. Las aplicaciones para gestionar este tipo de archivos son varias, empezando con la familia de productos dbase, Fox y Clipper en la plataforma de MS-DOS, hasta las diferentes versiones de Visual Objects y Visual Fox Pro en la plataforma Windows. Actualmente, la literatura relativa a bases de datos les da la denominación de Tablas, misma que se empleará en el presente trabajo (Kroenke,1996,pp 13-25), La importancia de este tipo de archivos o tablas, esta patentizada por los servicios de compatibilidad que ofrecen los nuevos productos manejadores de bases de datos (DBMS) y gestores de Información geográfica (GIS) para manejar, importar o convertirlos a los nuevos tipos de tablas. Este tipo de tablas esta compuesto por dos partes claramente diferenciables: La cabecera y los registros de datos (Martínez,1999) La cabecera de la tabla DBF De la misma forma que las tablas DBF se componen de cabecera y registros de datos, la cabecera también se compone de dos partes:. a).- Primera parte de la cabecera. La primera parte tiene 32 bytes de longitud. La estructura tiene la forma que se detalla en la Tabla 1 que se muestra a continuación: No. Byte Descripción/Contenido I Identificador del tipo de la tabla 2-4 Fecha de la última modificación 5-8 Número de registros de la tabla 34

42 9-10 Donde inician los registros de datos Longitud del registro Sin uso 29 Indica si tiene componentes de indizado 30 Indica el número de página de la tabla Sin uso Tabla 1. Primera parte de la cabecera de una tabla DBF Donde: El identificador del tipo de archivo (byte 1), puede ser (Bazian, 2000,pag 135): Valor Descripción 0x02 FoxBaseOx30 FoxPro, FoxBASE+, dbaseiii PLUS, dbase IV (sin memo) 0x30 Visual Fox Pro 0x43 Archivo de tabla SQL de dbase IV sin memo 0x63 Archivo de sistema SQL de dbase IV sin memo 0x83 FoxBASE+, dbase III PLUS (con memo) Ox8B dbase IV (con memo) OxCB Archivo de tabla ASQL de dbase IV con memo OxF5 FoxPro 2.x (o anterior) (con memo) OxFB FoxBASE Tabla 2.- Identificador del tipo de Tabla. - Si se tiene un campo memo definido en el primer byte aparecerá F5h. - Si no contiene ningún campo memo será 03h. Si el valor contenido en este primer byte es distinto, se considera que el archivo no es una tabla DBF. La última fecha de modificación (byte 2-4), se guardará en hexadecimal ocupando los bytes2, 3 y 4 correspondiente al ano, mes y día, respectivamente. El número de registros (byte 5-8), de la base de datos incluye el número de los registros de la tabla. Los bytes utilizados - del 5 al 8 - están dispuestos en orden inverso de tal 35

43 manera que el byte menos significativo es el primero de la izquierda. Por ejemplo: 0B 2A 01 00, corresponde al número 00/01 /2A/0B en hexadecimal. Puede ser que si se usa la función RECCOUNT() para contar el número de registros que contiene el archivo, el número que nos de no coincida con este número exacto y es que esta instrucción contabiliza también aquellos registros marcados para ser borrados. Sólo cuando se haya realizado el correspondiente borrado físico (PACK) el resultado de la función RECCOUNT() será correcto. La dirección donde comienza (byte 9-10), el primer registro de datos ocupan los bytes 9 y 10. Al igual que el anterior, los bytes están en orden inverso siendo 42(byte 9) 1B(byte 10) igual a la dirección 1 B42 en hexadecimal. A partir de la dirección indicada por dichos bytes comenzara los registros de datos. *La longitud de un registro (byte 11-12), es la suma de las longitudes de cada uno de los campos. Este ocupa 2 bytes. *Flag de componente de indexación(índices) nos indicará la presencia de un componente de índice estructural (CDX). Si por alguna causa el archivo de índices es borrado por medio de un comando DOS como por ejemplo DEL o ERASE, se recibirá el siguiente mensaje: STRUCTURAL CDX FILE NOT FOUND El número de página ( byte 30), con el que ha sido creado el DBF. El número total de valores de códigos de página que puede soportar son 19, sin embargo los valores más comunes que este byte contiene son los señalados en la tabla siguiente Los bytes sobrantes, que no son usados, suelen rellenarse con el carácter 0 o nulo. 3.2).-Segunda parte de la cabecera. La segunda parte de la cabecera depende del número de campos del que se componga el registro. Por cada una de los campos utiliza 32 bytes organizados e la siguiente manera: 36

44 Valor del Byte 30 Descripción / Contenido 00 No tiene código de página. Este valor lo tienen las tablas creadas con FoxPro hasta la versión DBF creada desde DOS. Código de página IBF creada desde DOS Internacional. Código de página BF creada desde Windows. Código de página 1252 No. De Byte Descripción /Autocontenido 1-11 Nombre del Campo 12 Tipo del Campo Dirección donde comienza el campo desde el principio del registro Sin use Longitud del campo (campos no numéricos) 17 Longitud del campo (campos numéricos) 18 Campos decimates (campos numéricos) Sin use Tabla 3 Segunda parte de la cabecera de una tabla.dbf El nombre del campo en FoxPro está limitado a 10 caracteres, el último carácter (el más a la derecha) debe ser nulo (0). Si el no mbre del campo es inferior a 10 caracteres, el primer carácter de la derecha será 0 o nulo. Pueden existir, en principio, 5 tipos de campos definidos en el byte 12 con un carácter ASCII de la siguiente forma: Valores de Tipos de Campos Tipo Carácter ASCII Valor Decimal Valor Hexadecimal Character (Carácter) C Date (fecha) D Logical (lógico) L 76 4C Memo M 77 4D Numeric (Numérico) N 78 4E 37

45 Flota (coma flotante) F General G La dirección donde comienza el campo (bytes 13 y 14) nos indica la posición de comienzo del campo relativo al principio del registro. La longitud de los campos depende del tipo de dato que vayamos a definir. Para los campos de caracteres utiliza los bytes 17 y 18 para insertar el tamaño, eso sí, en formato invertido. Para los campos tipo Fecha, Memo, General y Lógico solo necesita el primer byte para definir sus tamaños: 8 para el campo Fecha. 10 para el campo Memo. 10 para el campo General. 1 para el campo Lógico. Por último, para los campos numéricos el primer byte especifica el total de número de dígitos, y el segundo el número de posiciones decimales. Los bytes restantes no son utilizados, y su valor suele ser rellenado a nulo (0). FoxPro no es capaz de controlar el número de definiciones de campos que se han realizado en la cabecera. Hay tres formas/maneras de determinar cuando hemos leído todos los campos: 1.- La suma de todos los tamaños. El último campo ha sido leído cuando el total es igual a la longitud contada en la cabecera menos 1 para el flag de borrado. 2.- Buscar el carácter 0Dh (13 decimal) como el primer carácter después de de la definición de un campo. Esto separa la cabecera del principio de los datos. Tendremos que tener en cuenta el 38

46 byte extra cuando determinemos la longitud de una cabecera del DBF. 3.- Por último, contar el total de bytes y comparar con el valor del comienzo de los datos del archivo contenidos en los bytes 9 y 10 de la primera parte de la cabecera Datos de la Tabla. Los datos comienzan inmediatamente después del byte de terminación de la cabecera. El primer byte de cada registro está en la bandera de borrado. Si la bandera de borrado contiene 20h, el registro es activo. Si por el contrario su valor es 2Ah, significa que ese registro ha sido marcado para ser borrado. El siguiente byte es el primer byte del primer campo. No existen separaciones entre los campos, no es necesario. La sección de definición del registro de cada campo ya especifica la longitud y la posición. Los campos de tipo carácter son fáciles de leer. Cada byte, es añadido de izquierda a derecha, añadiendo un carácter. Determinar el contenido de un campo, es solo cuestión de convertir el valor hexadecimal en su correspondiente valor ASCII. Los campos de tipo fecha también son fáciles de interpretar. Cada campo ocupa 8 bytes. Los cuatro primeros son los relativos al año, los dos siguientes al mes y los dos últimos al día. Los bytes son dígitos ASCII del 30 al 39 hex que se corresponden con el 0 al 9 decimal. Al 1 de Enero de 1995 le corresponderían los siguientes valores: A A A A M M D D Formato Valor Hex Valor Dec. Los campos de tipo lógico usan los caracteres ASCII F y T, que traducidos a valores hexadecimales se corresponden con el 46h para el valor lógico falso(f) y 54h para el 39

47 valor verdadero(t). Los campos memo, como comentábamos antes, usan 10 bytes en cada registro. Si el campo resulta estar vacío, este se rellena con el carácter 20h (espacios en blanco). Si el campo memo no está vacío, los caracteres ASCII definen su posición (en bloques de 64 bytes) en el archivo.fpt. Por ejemplo, si tenemos los 10 bytes con los siguientes valores: (Valores hex.) traducido a decimal 15 Los datos del campo memo comienzan después del décimo quinto bloque de 64 bytes del archivo FPT. Los campos numéricos en FoxPro son interpretados como números ASCII individuales. Define el número de dígitos por la estructura de la base de datos. Supongamos que definimos un campo numérico de seis caracteres con tres decimales. El número 22,324 estaría de la siguiente manera:, C Hex. 22,3 2 4 Dec. La coma decimal corresponde con el valor hexadecimal 2Ch. Si el número no ocupase las seis posiciones se toman los siguientes criterios: - Si el espacio es por la izquierda se rellenará con un espacio en blanco (20h). - Si el espacio no utilizado es por la derecha se pondrá un cero (30h). Después del último registro, FoxPro añade un carácter de final de archivo (lah). Este byte se crea cuando se determina la longitud del archivo DBF. Tener en cuenta que es diferente al carácter de final de cabecera (0Dh) Interfaces para control de archivos tipo DBF 40

48 Tan importante como los archivos de datos lo son los archivos de índices. Estos permiten el rápido acceso y búsqueda de la información conforme a las necesidades de la aplicación. Debido a la diversidad de proveedores de productos para la gestión de archivos del tipo DBF, se tienen diferentes manejadores (drivers) con los cuales se pueden accesar y manipular las bases de datos. RDD es la abreviación para Replaceable Database Driver, cuyo objeto es dar acceso a la base de datos, archivos tipo memo y el formato de archivos de índices para diversos productos de software para el manejo de bases de datos (Data Base Manager System o DBMS), lo cual se logra mediante el enlace (linking) el RDD adecuado para la aplicación. Entre los más populares están (Computer Associates,1992): Manejador para archivos tipo DBF e índices compatibles con FoxPro. Este manejador (driver) es compatible. con FoxPro, como tal, conecta con el subsistema de administración de la base de datos a un bajo nivel. Su empleo permite las siguientes características: Compatibilidad con el formato de archivos de FoxPro. Manejo de índices compactos (tipo.idx), los cuales almacenan los datos Have en un formato comprimido, lo que resulta en una reducción sustancial del tamaño del archivo de índices. Manejo de índices compuestos (tipo.cdx). Este es un archivo de índices que contiene múltiples índices (llamados tags), los cuales están disponibles para la aplicación usando únicamente un manejador de archivos ale handle) y que se actualizan automáticamente a medida que Gambian los registros de datos (records) Índices condicionales. En estos la condición puede ser cualquier expresión, incluyendo 41

49 una función definida por el usuario. A medida que se actualizan los registros de datos, solo aquellos que cumplen con la condición establecida son agregados o actualizados en el índice Manejador para archivos tipo.dbf e índices compatibles con dbase IV. Este manejador proporciona compatibilidad, incluyendo acceso, a archivos de formato.dbf,.mdx y.dbt, así como esquemas para la protección de archivos y registros de datos, permitiendo el acceso compartido entre programas CA-Clipper y dbase IV Manejador para archivos tipo DBF e índices compatibles con dbase III PLUS. Este manejador permite crear, accesar y actualizar archivos de índices.ndx compatibles con dbase III y dbase III PLUS Manejador para archivos tipo.dbf e índices compatibles con Clipper. Los índices con formato de archivo tipo.ntx, son los que de manera predeterminada utiliza el lenguaje Clipper. Para mayor detalle, se recomienda la consulta del apéndice contenido en el Manual del Programador contenida en la "Documentación de Visual FoxPro" incluida con el Lenguaje Visual FoxPro versión 6. 42

50 CAPÍTULO IV PLANTEAMIENTO DEL PROBLEMA Y DESARROLLO DE LA SOLUCIÓN Conocer el problema, las condiciones, limitaciones y recursos existentes o disponible son requisito indispensable para plantear la propuesta de solución mas adecuada. Por lo anterior, se presentan dichas circunstancias, así como el análisis y la síntesis, plasmada en los programas desarrollados Problemática existente. La CAPDAM necesitaba mejorar el servicio de recepción de pagos en 3 localidades donde tiene instaladas cajas (sucursales de CAPDAM en las cuales se puede recibir el pago de los servicios que proporciona el organismo) ubicadas fuera del edificio de sus oficinas centrales. La figura 4.1 muestra el esquema de la red Ethernet con una arquitectura Servidor de Archivos, bajo el sistema operativo Netware Las estaciones Cliente deben enviar el requerimiento al Servidor de Archivos y esperar a que este les envíe todos los registros (records) para que sean procesados por la aplicación ubicada en ellas. 43

51 El tiempo promedio necesario para que el operador recibiera en pantalla el total del adeudo del usuario de los servicios de CAPDAM era de 2.5 minutos, dándose el caso de usuarios que, al acudir a pagan hasta 8 recibos, les implicaba un tiempo superior a 15 minutos para realizar el proceso, lo cual generaba quejas al respecto. Los datos del sistema comercial (con el cual se lleva el control de los cargos, abonos y servicios a los usuarios de CAPDAM), están almacenados en tablas tipo DBF y son gestionados con programas realizados con el lenguaje CLIPPER versión 5.2 y empleando índices IDX. Las Tablas para Cargos (todo cargo que aplica CAPDAM a los usuarios) y la de Abonos (todo abono a cada cargo que realiza el usuario) contienen más de 2.5 millones de registros cada una y se tienen más de 32,000 usuarios registrados, por lo que la base de datos contiene más de 5 millones de registros, de los cuales se seleccionarán los del usuario que se presenta a pagar. El acceso a los datos se realiza tanto local (dentro de la LAN) como remotamente (mediante la conexión vía módem) mediante CONNECT versión 1.1 de Novell, el cual estaba instalado en el Servidor de Archivos. Esto implica dividir la capacidad del procesador entre procesos de comunicación y de servidor de archivos Consideraciones y limitaciones para la elaboración del proyecto. Debido a la falta de recursos económicos y a la dinámica existente en CAPDAM, se detectaron las siguientes limitaciones: La solución debía implementarse sin disponer de recursos económicos para adquirir software o hardware, esto es, sólo con los recursos informáticos existentes y sin el tiempo o recursos humanos para rediseñar todo el sistema y aplicar otro tipo de soluciones (por ejemplo migrar la información a MySQL y utilizar PHP para una aplicación Cliente/Servidor de 3 niveles). La operación de los módulos no relacionados con la recepción de pagos y elaborados con el lenguaje CLIPPER versión 5.2 deberá continuar sin interrupción, debido a que en las 44

52 oficinas centrales se utilizan equipos PC con procesador 386 sin disco duro, con sistema operativo MS-DOS y enlace a NET WARE Para la capacitación a operadores, se debe considerar que su grado máximo de estudios es primaria, y es personal sindicalizado. Los recursos existentes y aprovechables para el proyecto se describen a continuación: 12 computadoras Compaq con procesador AMD 400 Mhz, Windows 98, módem interno de 56Kb y tarjeta de red a 10 Mb (ubicada en las oficinas centrales). 2 computadoras Acer con procesador Pentium a 100 Mhz, Windows 95 (ubicadas en las sucursales de Santiago y Cárcamo) 1 computadora Acer con procesador 486 a 100 Mhz, Windows 95 (ubicada en a sucursal Salahua). 4 computadoras Acer con procesador 386, MS-DOS y sin disco duro (ubicadas en caja de las oficinas centrales) 1 módem Hayes extern a 9600 bps (ubicado en el servidor de oficinas centrales). 1 módem Smart Módem a 14,000 bps (ubicado en la sucursal de Salahua). 3 miniprinter Epson TM-375 U seriales y 2 Epson TM-270 (ubicadas en cajas). Computadora Compaq con procesador Pill a 750 Mhz, Netware 4.11 y tarjeta de red a 10 Mb (ubicado como servidor de archivos en las oficinas centrales). Visual Fox Pro versión 6 en Español. 45

53 4.2.- Análisis de la problemática. La tecnología Cliente/Servidor ha demostrado ser la más eficiente en los sistemas administrativos de alto desempeño, brindando: velocidad, integridad, seguridad y versatilidad (versatilidad (Microsoft Corporation, 1997; Hostmann 1997). Debido a que la CAPDAM tiene sus recursos informáticos actualmente basados en la plataforma Novell y Microsoft y disponen de equipos con Windows 95 y Windows 98 (estos con módem interno y procesador Pentium II), los cuales tienen disponible sin costo adicional la tecnología COM/DCOM, se empleará este enfoque para desarrollar la solución al problema propuesto. Además, se puede emplear Visual Fox Pro versión 6 para construir el Cliente y el Servidor en esta plataforma, dado que es un recurso con el que se cuenta. Dadas las características de la problemática planteada y los recursos existentes, es adecuada una solución Cliente/Servidor de 2 niveles (Middletier), colocando el módulo Cliente en el equipo del cajero y el módulo Servidor en una computadora que este conectada a la red local en la oficina centra y que tenga acceso la base de datos ubicada en el servidor de archivos operando con Netware La figura 4.2 ilustra la disposición de la solución propuesta. En esta, el módulo Cliente se encargará de la interface del sistema y el procesamiento relativo a la impresión y certificación del pago principalmente (un nivel o capa) y, por el otro lado, la aplicación Servidor (el segundo nivel o capa) llevará a cabo la gestión de la base de datos, localizando al usuario de CAPDAM, calculando el saldo y enviando éstos datos al módulo Cliente. El mecanismo utilizado para la comunicación entre niveles (capas) es DCOM, el cual pasa datos en ambas direcciones entre la aplicación o módulo Cliente interfaz y la aplicación del lado del Servidor. 46

54 Fig. 4.2 Esquema de la solución propuesta. Como se observa, se tendrá una red operando concurrentemente bajo las arquitecturas "Servidor de Archivos" para los equipos en oficinas centrales y "Cliente/Servidor de 2 niveles" para la operación de las cajas remotas Diseño del Módulo Servidor. El propósito consiste en crear un programa genérico que utilicen los cajeros (Clientes) para poblar las tablas de la aplicación del lado del Servidor (en este caso, tablas tipo DBF con archivos índice.idx). El primer paso consiste en diseñar la solución a este propósito como si se estuviera 47

55 usando Visual FoxPro versión 6 en una aplicación de un solo nivel (Menhaen,2000, pp ). En este caso, el diseño consiste en crear una sola clase con propiedades que corresponda con los campos de la tabla de transacciones de los pagos recibidos. Un método abrirá las tablas, otro buscara los datos en las tablas de usuarios, cargos y convenios; otro método guardara los datos del pago en la tabla correspondiente Las Tablas. Se necesitan principalmente 4 tablas de la base de datos conformada por tablas tipo DBF existentes para llevar a cabo el proceso de las cajas. Estas corresponden a los datos de: Usuarios, Cargos, Convenios y Pagos. En el anexo F se detalla la estructura de éstas tablas. La tabla de Usuarios, denominada CA_TOMAS, contiene los datos que identifican al usuario de los servicios de CAPDAM. La tabla de Cargos, denominada CARGOS, contiene los datos que identifican cada uno de los cargos que se le aplica a cada usuario por los servicios recibidos de CAPDAM. La tabla de Convenios, denominada CONVENIOS, contiene los datos correspondientes a cada convenio que se ha celebrado con los usuarios de CAPDAM que solicitaron facilidades para cubrir sus adeudos. La tabla en que se almacenan los pagos recibidos durante el día se almacenan en la tabla denominada ABONAR, identificando que usuario lo realiza, importe y las condiciones del mismo El código. El módulo Servidor esta contenido en una aplicación en el proyecto denominado Tstclase.pjx, la cual consta de un programa progrl.prg y una clase pública nominada frmusu, almacenada en la librería de clases llamada clasesmam.vcx, en la que se llevará a cabo toda la inteligencia de la aplicación Servidor (ver fig.4.3). 48

56 Fig. 4.3 Contenido del Proyecto de la aplicación Servidor. En el Anexo A se muestra el código de la clase frmusu tal como se obtuvo del Examinador de Clases (Class Browser). El código anterior se percibe en pantalla como se ilustra en la figura 4.4, en la cual se puede apreciar con claridad los objetos cuadro de texto (textbox)que reciben como valor el resultado del procesamiento de las tablas y que serán utilizados por la aplicación Cliente. Los métodos (procedimientos) implementados en esta clase son: Abretabla.- Inicializa las tablas a utilizar, así como sus índices. 49

57 Fig. 4.4 Clase principal de la aplicación Servidor. Buscar.- Recibe de la aplicación Cliente el número de cuenta para efectuar la búsqueda de los datos en las tablas necesarias. grabap.- Graba el pago en la tabla correspondiente, recibe el importe y tipo desde la aplicación Cliente. Leetira.- Asigna los valores de los campos de la tabla de pagos para dejarlos disponibles a la aplicación Cliente. tira.- Localiza en la tabla de Pagos los movimientos registrados en una fecha determinada. 50

58 unomas.- Brinca al siguiente registro. Para indicar que la clase creada es del tipo Público o Privado, se deberá seguir el siguiente proceso: Entrar a la modificación de la clase. Desplegar el cuadro de dialogo Información de clase, (seleccionar en la barra superior: clase: Información de clase ), como se muestra en la figura 4.5. Fig Cuadro de dialogo que permite exponer una clase al publico. Marcar el cuadro de verificación OLE público(ole public). Cerrar el cuadro de diálogo. Guardar la clase. 51

59 Creación del Servidor DCOM. El servidor se puede crear de uno de 2 tipos:.dll o EXE. La diferencia está en si el servidor va ejecutarse como servidor en proceso (inproc) o fuera de proceso (OutProc). Un servidor en proceso es aquél que se ejecuta dentro del mismo espacio de memoria que la aplicación que lo llama y esta implementado como una.dll Un servidor fuera de proceso se ejecuta en su propio espacio de memoria y se implementa como un archivo.exe. En este caso, la aplicación se generó como.exe por dos razones: Si el Servidor se cae, el programa aún estará protegido. Debido a que el.exe está en su propio espacio de memoria, no puede corromper la memoria de otras aplicaciónes. Un.EXE se puede ejecutar de manera remota, lo cual no puede hacerse con un.dll. 52

60 La figura siguiente muestra la pantalla respectiva. Fig Opciones para generar la aplicación como.exe o.dll Después de generar el.exe y registrar el servidor por primera vez, se tiene que especificar si el servidor es de una o varias instancias. Se tienen 3 opciones: Multiuso (multiple instancing).- Varios Clientes pueden utilizar una sola instancia en ejecución del Servidor. Uso único (Single instancing).- Cada Cliente tiene su propia copia del Servidor. No se puede crear (Not creatable).- El Servidor sólo puede emplearse dentro de Visual FoxPro. 53

61 En la figura siguiente se muestra la pantalla respectiva. Fig Especificar si el Servidor creado será de una o varias instancias Registro del Servidor DCOM en la computadora destinada. Cuando se genera el.exe, el proceso de construir el servidor genera los GUIDs y registra el servidor en el Registro de Windows del equipo utilizado para el desarrollo. Para transferir esta aplicación.exe al equipo que será utilizado como Servidor, se deberá seguir el procedimiento siguiente: 1. Instalar el protocolo TCP/IP (ver anexo B para mayor detalle) 2. Instalación de DCOM. Descargar DCOM de la página en Internet de Microsoft, según el sistema operativo del equipo asignado, siguiendo las instrucciones en pantalla: 54

62 Para Windows 95.- http ://microsoft.com/com/dcom/dcom95/download.asp Para Windows Instalar tanto la aplicación DCOM (dcom98.exe o dcom95.exe) como la utilería para configurar DCOM (dcm95cfg.exe). 3. Configurar la computadora para ejecutar aplicaciones DCOM. En la opción Inicio (Start) de Windows, seleccionar Ejecutar (Run) y teclear Dcomcnfg, aparecerá en pantalla el cuadro de diá logo de la utilería para configurar DCOM. En la pestafta Default Properties, seleccionar Enable Distributed COM on this computer, ponga la opción None en Default Authentication Level y active la opción Impersonate en Default Impersonation Level (ver la figura 4.8). Fig. 4.8 Configurar DCOM: opción propiedades predeterminadas. 55

63 En la pestaña Default Security, seleccionar Enable remote connecction, la figura siguiente ilustra este proceso. Fig. 4.9 Configurar la seguridad de DCOM. 4. Registrar el módulo servidor, denominado tstclase.exe Copiar a un directorio en el equipo que fungirá como servidor los archivos (por ejemplo: c:\capdam\vfp\prgs\servidor): tstclase.exe tstclase.vbr tstclase.tlb Verificar que en el directorio c: Iwindowslsystem se encuentren los archivos siguientes: Vfp6r.dl1 Vfp6renu.dll 56

64 Vfp6resn.dll Vfprun.exe Vfp6t.dll Vfp6t.dll Cfpodbc.dll En la opción Inicio (Start), seleccionar Ejecutar (Run) e indicar la ubicación de la aplicación Servidor usando la opción Explorar. Se agrega la instrucción /regserver con to que se instruye al programa para que se registre en el Registro de Windows. Fig Instrucción para registrar el módulo Servidor Con lo cual, Microsoft asigna un CLSID (Identifcador de clase o GUID o Identificador global único) que identifica a esta clase mediante un número único en el Registro de Windows Diseño del Modulo Cliente. El propósito de la aplicación Cliente es utilizar el objeto DCOM Servidor generado, para tomar de este los valores correspondientes al saldo que debe pagar el usuario de CAPDAM y enviar la información a grabar en la base de datos. 57

65 Un objeto DCOM se utiliza de manera similar a cualquier otro objeto. Se utiliza la instrucción CreateObject() para obtener una referencia al objeto, para lo cual es indispensable conocer el nombre de la clase que se instanciará. Una vez obtenido lo anterior, se utilizará el objeto como si estuviera trabajando con una clase local a la aplicación (Menahen,2000, pp ). La aplicación Cliente está contenida en el proyecto denominado Cliente.pjx. Esta conformada por un programa principal (llamado progrl.prg), desde el cual se crea la instancia la clase del servidor, se ejecuta el formulario login.scx para validar el acceso al use de la aplicación y, si es aceptada la clave proporcionada, ejecutará el menú menul.mnu que da acceso a las acciones básicas del cajero: Recepción de Pagos.- Contenida en formulario forml.scx, lleva a cabo la gestión de los pagos que realicen los usuarios de CAPDAM, la certificación de recibos y grabado en la base de datos. Lo anterior mediante la gestión de los métodos abretablas, busca y grabs contenidos en la clase tstclase.frmusu ubicada en la aplicación Servidor. Listado de pagos del día.- Contenido en el formulario ftira.scx, realiza el listado de todo: los pagos recibidos en el día, indicando el total de ingresos, para lo cual se utiliza los, métodos leetira y tira contenidos en la clase tstclase.frmusu ubicada en la aplicación Servidor. 58

66 La figura 4.11 muestra el proyecto como se aprecia desde Visual FoxPro El Código. Se muestran los formularios generados en esta aplicación: form l.scx, ftira.scx y login.scx. El código para generar cada una de estas se lista en el apéndice C. El formulario form]. scx (fig. 4.12) lleva a cabo la gestión de los pagos. 59

67 Fig Formulario form1 de la aplicación cliente. El propósito de los componentes es: Text1 a Text16.- En Text1 se indica el número de cuenta del usuario de CAPDAM, el cual se transmite a la aplicación remota (mediante DCOM). Una vez localizado, los importes correspondientes a los conceptos de adeudo son recibidos desde el módulo Servidor y desplegados en pantalla. Botón Buscar.- Se envía la instrucción para que la aplicación Servidor reciba el parámetro con el número de cuenta y busque los datos del usuario de CAPDAM. Check Box Convenio. - Indica si el usuario tiene un convenio vigente registrado. Grupo de Opciones.- Indicar si el pago que se recibe se aplicará a facturación o Convenios. Se habilita solo si el usuario tiene convenios vigentes registrados. Botón Grabar Pago.- Se activa cuando el importe del pago es mayor o igual al mínimo exigible conforme a la legislación vigente (la suma de recargos y gastos de cobranza). Se invoca el método grabap para grabar en la base de datos el pago y se ejecutan 60

68 los procedimientos para imprimir el ticket en la miniprinter en modo journal (queda copia en el rollo de auditoría). Botón Validar Recibo.- Se activa una vez realizados los procesos anteriores, permite ejecutar el procedimiento para imprimir con la miniprinter en modo de validación (Slip). Para suspender el proceso de pago, se deberá dar click en el campo de texto Text1 antes de activar el botón de pago. En la figura 4.13 se ilustra el formulario ftira.scx, el cual se activará mediante el menú principal para emitir el resumen de los pagos recibidos en el día. Fig Formulario ftira 61

69 Al activar el botón Imprimir Tira, se ejecutan los procedimientos para imprimir el resumen en la miniprinter en modo journal (queda copia en el rollo de auditoria). El formulario login.scx tiene el propósito de ofrecer un primer nivel de seguridad, negando el acceso a las opciónes del módulo Cliente que gestionan los pagos. La figura 4.14 muestra este formulario. Fig Formulario para el login. El fin que tiene cada objeto en este formulario se describe a continuación: txtusername.- Recibe la slave del cajero, no es sensible a mayúsculas o minúsculas. txtpassword.- Recibe el código asociado a la clave, si es sensible a mayúsculas o minúsculas. Enmascara los caracteres recibidos para hacerlos invisible a terceros. Botón Aceptar.- Al activarse, efectúa la búsqueda de los datos proporcionados en el archivo login.dbf, regresando el correspondiente mensaje y permitiendo o no el acceso al resto del módulo. 62

70 Botón Cancelar.- Suspende el proceso y cierra aplicación Instalación de la aplicación Visual FoxPro ofrece una utilería que facilita generar la aplicación para su instalación en cualquier equipo (opción Herramientas->Instalación). El procedimiento para efectuar la instalación se describe a continuación: 1. Instalar TCP/IP (ver anexo B). 2. Instalar el enlace telefónico (ver anexo D). 3. Instalar DCOM (ver el punto inciso 2 de este capítulo). 4. Configurar la computadora para ejecutar aplicaciones DCOM (ver el punto inciso 3 de este capítulo). 5. Registrar la aplicación Servidor DCOM (ver el punto inciso 4 de este capítulo). 6. Configurar el direccionamiento a la aplicación Servidor. Debido a que el servidor quedó registrado en el mismo equipo que se ejecutará la aplicación cliente (paso anterior), se deberá redireccionar para que el cliente busque al servidor en el equipo remoto, para esto, ejecutar la utilería dcomcnfg, como se ilustra en la figura 4_15. Fig Utilería para configurar DCOM 63

71 Tras lo cual aparecerá el cuadro de dialogo de esta utilería. Seleccionar la aplicación servidor y dar click en el cuadro de propiedades, a continuación seleccionar la pestaña correspondiente a location, y activar el cuadro Run aplicattion on the following computer e indicar la IP correspondiente (ver cuadro 4.16). Fig Indicar en que equipo se ejecuta el servidor. Es importante verificar que se deshabilita la opción Run aplication on this computer, inclusive, se puede borrar el ejecutable tstclase.exe de la computadora en la cual reside la aplicación cliente, una vez efectuado lo anterior. 7. Instalar la aplicación Cliente en la computadora de las cajas. Para esto, bastará ejecutar los discos o aplicación obtenida con la utilería de Visual 64

72 FoxPro para generarla. 4.5 Ejecución de la aplicación Cliente/Servidor. Para que este disponible la aplicación Cliente/Servidor, es necesario ejecutar el procedimiento siguiente: En el equipo donde se insta1ó la aplicación servidor. Tener al servidor de acceso telefónico a redes activo y a la espera (ver anexo D). Abrir una sesión al servidor Netware 4.11 con una clave que proporcione los atributos necesarios. Tener la aplicación servidor activa, lo cual se logra instalando en el mismo equipo la aplicación servidor y ejecutarla En el equipo remoto a utilizar por el cajero. Efectuar la llamada telefónica para el enlace con la computadora que hospeda la aplicación servidor. Ejecutar la aplicación cliente. Una vez establecido el enlace, la aplicación podrá procesar los pagos o consultas que se indiquen. 4.6 Capacitación a Cajeros(as). Con el propósito de que la cajera comparara la aplicación desarrollada utilizando DCOM y Visual FoxPro con la que tenían en use (desarrollada bajo arquitectura servidor de archivos y con el lenguaje Clipper 5.2), se instaló una segunda computadora cerca una de la otra y se genero un directorio de pruebas para 65

73 consultar y almacenar los movimientos durante la capacitación. Con lo anterior, el instructor operó paralelamente la aplicación cliente y comparaba, conjuntamente con la cajera, las similitudes o diferencias entre ambas aplicaciones. Con esto, se hizo palpable la diferencia en facilidad de use y tiempo de respuesta entre la antigua aplicación y la nueva, motivando con esto la aceptación por parte de la cajera hacia el nuevo sistema. Logrado lo anterior, se pidió a la cajera que utilizara el nuevo programa y lo operara completamente (tomando su lugar el instructor ante el equipo con la aplicación antigua) y lograr con esto se familiarizará rápidamente. Al tercer día, la cajera estaba capacitada para la operación del sistema nuevo. Sin embargo, se les permitió una semana para pruebas. Para medir el tiempo de respuesta entre una y otra aplicación, se tomaba el tiempo necesario para que se desplegara en pantalla el saldo a pagar por el usuario de CAPDAM a partir del instante en que se oprimía la tecla ENTER para alimentar el número de cuenta y el instante en que se desplegaba en pantalla los datos correspondientes. 66

74 CAPÍTULO V RESULTADOS Y CONCLUSIONES RESULTADOS Para que la aplicación CLIENTE tenga acceso a las tablas tipo.dbf que conforman la base de datos ubicada en el Servidor de Archivos bajo Netware 4.11, es requisito indispensable que en la PC en la cual se tiene el objeto SERVIDOR esté abierta una sesión con acceso a Netware, que el usuario registrado tenga los derechos necesarios para gestionar los archivos en el directorio correspondiente y que se deje abierta la clase SERVIDOR (lo cual se logra ejecutando la misma aplicación CLIENTE o un objeto que abra un hilo hacia la clase base del SERVIDOR). El operador de la aplicación CLIENTE no requiere de una clase de acceso a Netware, ya que empleara la sesión abierta en el equipo donde reside la aplicación SERVIDOR a la que esta dirigido. Los archivos tipo.dbf son gestionados, de manera concurrente, desde las computadoras ubicadas en oficinas centrales con aplicaciones desarrolladas en lenguaje CLIPPER (para sistema operativo MS-DOS) y desde cajas remotas con las aplicaciones CLIENTE y SERVIDOR (para sistema operativo Windows 9x). El tiempo promedio, requerido por la aplicación desarrollada para mostrar el estado de cuenta en las PC remotas, depende de la velocidad a la que se enlacen los módems utilizados (se emplearon líneas telefónicas conmutadas no dedicadas). Se obtuvieron los siguientes: Velocidad del enlace de módems Tiempo Promedio 9600 baudios 48 segundos 33,000 baudios 22 segundos 67

75 La aplicación desarrollada cumplió con las espectativas de velocidad, integridad, seguridad y versatilidad esperadas para una aplicación basada en la arquitectura Cliente/Servidor de 2 niveles. Se encuestó a las personas que acudieron a pagar a las cajas remotas y el 90% manifestó satisfacción por la mejora en la calidad del servicio recibido. Las aplicaciones existentes creadas bajo, la arquitectura de Archivo Compartido para sistemas operativos MS-DOS y NETWARE 4.11 operan concurrentemente y sin problema con la desarrollada bajo la arquitectura Cliente/Servidor para los sistemas operativos Windows 9x y Netware. Debido a que se emplearon solo recursos existentes, la inversión total fue menor a cualquier otra que hubiere requerido adquisición de hardware o software. La sesión de Netware 4.11 que se abre desde la PC que alojara a la(s) aplicación(es) puede(n) ser utilizada(s) por más de una aplicación cliente (ubicadas en diferentes computadoras), lo que resulta en que una sola sesión a Netware puede ser empleada por más de 1 usuario de manera simultánea. CONCLUSIONES El utilizar la tecnología COM/DCOM efectivamente proporciona lo siguiente: Versatilidad.- La aplicación servidor se puede desplegar o distribuir en equipos de bajo costo que están subutilizados por el operador, evitando así el desembolso en la adquisición de computadoras más potentes para funcionar come, servidores. 68

76 Integridad.- Permite la gestión conjunta de aplicaciones desarrolladas en diferentes lenguajes bajo el entorno Windows de Microsoft y operar concurrentemente con aplicaciones desarrollada par la plataforma Novell. Bajo costo.- Esta disponible en forma gratuita para operar en la plataforma Windows 9x. Velocidad.- La aplicación Cliente/Servidor de 2 niveles es hasta un 375% más rápida que la utilizada anteriormente bajo la arquitectura "Servidor de Archivos" y utilizando el mismo hardware. Seguridad.- El contenido de las tablas contenidas en el servidor con Netware no es visible al operador remoto de la aplicación cliente fuera de la aplicación misma, esto es, no pueden desplegar o accesar las tablas o datos ubicados en el servidor de archivos con programas o utilerías diferentes a la diseñada para operar con DCOM, incluso, no requiere tener habilitado el protocolo IPX/SPX con el que opera el servidor Netware y los equipos instalados en la red local. Facilidad de actualización- Las actividades necesarias para actualizar, corregir o mejorar las aplicaciones cliente o servidor se simplifican notablemente. Facilidad de uso.- Es notable como se acelera la aceptación del nuevo sistema por parte del operador de la aplicación, debido al use de un ambiente grafico (a diferencia de aplicaciones en modo texto típicas de la arquitectura "servidor de Archivos", como es el caso de la aplicación previa). Por lo anterior, la utilización de la arquitectura Cliente/Servidor de 2 niveles (o middletier) empleando la tecnología COM/DCOM es una excelente opción para la micro o pequeña empresa que requiera mejorar el tiempo de respuesta en la gestión de sus bases de datos y no dispone de los recursos económicos para adquirir hardware o software que 69

77 empleen otras tecnologías o arquitecturas. Por otro lado, es indispensable tener en cuenta los siguientes resultados observados: La comunicación entre cliente y servidor, cuando se emplea la tecnología DCOM, requiere del protocolo TCP/IP cuando se utilizan equipos con Windows 9x como sistema operativo. La sesión de Netware 4.11 que se abre desde la PC que alojará a la(s) aplicación(es) puede(n) ser utilizada(s) por mas de una aplicación cliente (ubicadas en diferentes computadoras), lo que resulta en que una Bola sesión a Netware puede ser empleada por más de 1 usuario de manera simultánea. 70

78 SUGERENCIAS Si bien el proyecto presentó una solución adecuada al problema existente, se recomienda que se realice el escalamiento a arquitecturas y tecnologías mejores cuando estén disponibles los recursos necesarios (tiempo, recursos económicos, materiales y humanos). Por ejemplo, emigrar del empleo de archivos tipo.dbf e índices tipo IDX a manejadores de bases de datos actuales (SQL Server, MySQL, Oracle, etc.) los cuales mejorarán el tiempo de respuesta, considerando el tamaño de los archivos en use o utilizar COM+ (disponible para Windows 2000 y XP) y aplicaciones Cliente /Servidor de 3 o más niveles. En el renglón de seguridad, se recomienda la utilización del sistema operativo Windows NT/2000 para establecer el servicio de acceso remoto (lo que permitirá efectuar el enlace telefónico de más de una PC remota a un solo equipo que opere como servidor de acceso remoto, en lugar de una PC para cada enlace telefónico cuando se emplea Windows 98), lo cual, además, permite aprovechar el esquema de seguridad inherente a NT/2000. Para emplear otras tecnologías (ODBC 3, Java), se recomienda pasar los índices del tipo IDX a índices del tipo CDX, los cuales si están implementados en los manejadores (drivers) disponibles actualmente bajo la plataforma Windows de Microsoft. 71

79 Anexo A 72

80 Listado del código correspondiente a la clase frmusu, la cual es el núcleo de la aplicación Servidor.... *-- Class: fr mus u (c:\capdam\vfp\progs\servidor\clasesmam.vcx) *-- ParentClass: form *-- BaseClass: form *-- Marca de hora: 04/18/02 10:12:05 AM * DEFINE CLASS frmusu AS form OLEPUBLIC DataSession = 2 Top= 1 Left = 47 Height = 334 Width = 456 DoCreate =.T. Caption = "Form2" Name = "frmusu" 73

81 ADD OBJECT cclave AS textbox WITH ; ControlSource =, ; Height = 25, ; Left = 12,; ReadOnly =.T., ; Top = 12, ; Width = 85, ; Name = "cclave" ADD OBJECT cnombre AS textbox WITH ; ControlSource =, ; Height = 25, ; Left = 108, ; ReadOnly =.T., ; Top = 12, ; Width = 240, ; Name = "cnombre" ADD OBJECT cdirecc AS textbox WITH ; ControlSource =, ; Height = 25, ; 74

82 Left = 108,; ReadOnly =.T., ; Top = 48, ; Width = 240, ; Name = "Cdirecc" ADD OBJECT cagua AS textbox WITH ; Format = ["'999,999,999.99"'], ; Height = 25, ; Left = 12, ; Top = 84, ; Width = 85, ; Name = "cagua" ADD OBJECT calcan AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 108, ; Width = 85, ; Name = "calcan" 75

83 ADD OBJECT civa AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 132,; Width = 85, ; Name = "clva" ADD OBJECT cotros AS textbox WITH ; Height = 25, ; Left= 12, ; Top = 192, ; Width = 85, ; Name = "cotros" ADD OBJECT crecar AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 216, ; Width = 85, ; Name = "crecar" 76

84 ADD OBJECT cgtos AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 240, ; Width = 85, ; Name = "cgtos" ADD OBJECT checkl AS checkbox WITH ; Top = 48,; Left = 12,; Height = 25, ; Width = 84, ; Caption = "encontro", ; Value = 0, ; Name = "Check l" ADD OBJECT check2 AS checkbox WITH ; Top = 216, ; Left = 108, ; Height = 25, ; 77

85 Width = 84, ; Caption = "Convenio", ; Name = "Check2" ADD OBJECT cconvenio AS textbox WITH ; Height = 25, ; Left = 108,; Top = 252, ; Width = 84, ; Name = "cconvenio" ADD OBJECT canticipo AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 276, ; Width = 85, ; Name = "canticipo" 78

86 ADD OBJECT cabonar AS textbox WITH ; Height = 25, ; Left = 12, ; Top = 300, ; Width = 85, ; Narre = "cabonar" ADD OBJECT cpoblac AS textbox WITH ; Height = 25, ; Left = 108, ; ReadOnly =.T., ; Top = 84, ; Width = 157, ; Name = "cpoblac" ADD OBJECT crfc AS textbox WITH ; Height = 25, ; Left = 108, ; ReadOnly =.T.,; Top = 120, ; 79

87 Width =121, ; Name = "crfc" ADD OBJECT tcuenta AS textbox WITH ; Height = 25, ; Left = 360, ; Top = 144, ; Width = 73, ; Name = "tcuenta" ADD OBJECT timporte AS textbox WITH ; Height = 25, ; Left = 360, ; Top = 180, ; Width = 73, ; Name = "timporte" ADD OBJECT tconv AS textbox WITH ; Height = 25, ; Left = 360, ; 80

88 Top = 216, ; Width = 49, ; Name = "tconv" ADD OBJECT csan AS textbox WITH ; Height = 25, ; Left= 12, ; Top = 168, ; Width = 85, ; Name = "csan" *-- abre un archivo PROCEDURE abretabla select 5 use f:\pruebas\abonar index f:\pruebas\abonar.idx,f:\pruebas\tabonar.idx shared select 4 use f:\pruebas\anticipo index f:\pruebas\anticipo.idx shared select 3 use f:\pruebas\convenio index f:\pruebas\convenio.idx shared select 2 *use c:\capdam\hoy\cargos index c:\capdam\hoy\cargos.idx shared *use f:\sicous\cargos index f:\sicous\cargos.idx shared use f:\pruebas\cargos index f:\pruebas\cargos.idx shared 81

89 select 1 *use c:\capdam\hoy\ca tomas index c:\capdam\hoy\ca tomas.idx shared *use f:\sicous\ca tomas index f:\sicous\ca tomas.idx shared use f:\pruebas\ca tomas index f:\pruebas\ca tomas.idx shared ENDPROC *-- para pasar al siguiente registro PROCEDURE unomas Parameter dfechn,ncaja skip 1 if eof() or. dfecha!=abonar.abo fecha.or. ncaja!=abonar.abo caja return.f. else return.t. endif ENDPROC 82

90 *-- Localiza el usuario cuya clave esta en nbusca PROCEDURE buscar lparameter ncuenta *Dimension acargos(100,2) local nagua,nalca,notro,niva *wait windows nowait "entrando a clase" this. Check 1. value=.t. select 1 seek(ncuenta) if eof() messagebox("no se localizó al usuario:"+str(ncuenta,7)) WAIT WINDOW `No se localizo al usuario: '+str(ncuenta,7) + WONTOP( ) this. Check l.value=. f. this.cclave.value="" this.cnombre.value="" this.cdirecc.value="" return endif nanti=0 nabo=0 select 5 seek(str(ncuenta,7)) do while eof() and. abonar.abo_cvecta=ncuenta nabo=nabo+abonar.abo_import 83

91 skip enddo nanti=0 select 4 seek(str(ncuenta,7)) do while eof() and. anticipo.ant cvecta=ncuenta nanti=nanti+anticipo.ant agua+anticipo.ant dren+; anticipo.ant iva skip enddo lconve=.f. 1Gastos=.f. nconvlmporte=0 this.cclave.value=ca_tomas.tom_cvecta this.cnombre.value=ca_tomas.tom_nombre this.cdirecc.value=ca_tomas.tom_direcc this.cpoblac.value=ca_tomas.tom_poblac this.crfc.value=ca_tomas.tom_rfc this. Check1.value=.t. if ca_tomas.tom_estnot=3 lconve=.t. endif 84

92 if (ca_tomas.tom_estnot=l or. ca_tomas.tom_estnot=2) and. ca_tomas.tom_fecnot!=ctod(" / / ") lgastos=.t. endif if 1Conve select 3 seek(ncuenta) if eof() nconvlmporte=con cosmen endif endif select 2 seek str(ncuenta,7) WAIT WINDOW `Usuario: '+str(ncuenta,7) + "localizado en:"+str(recnoo,8)+ WONTOP( ) if eof() messagebox("no se localizaron cargos a:"+str(qcta,7)) WAIT WINDOW No se localizo cargos al usuario: '+str(ncuenta,7) + WONTOP( ) endif nagua=0 niva=0 nalca=0 nsan=0 notro=0 85

93 nreca=0 ngtos=o do while eof() and cargos. car cvecta=ncuenta saldo=cargos.car cargo-cargos.car abonos-cargos.car ajuste-cargos. car_descue WAIT WINDOW' valor saldo: '+str(saldo,7,2) + " rec:"+str(recno(),7) if saldo>0 and. cargos. car conv nreca=nreca+cargos.car recarg if cargos. car cvecon!=l0 and. cargos.car_cvecon!=58 and. ; cargos.car cvecon!=4 and. cargos.car cvecon!=26 and. cargos.car cvecon!=61 ngtos=ngtos+saldo endif acargos [cargos. c arcvecon,2]=acargos(cargos.car cvecon,2)+saldo do case case cargos.car cvecon=l nagua=nagua+saldo case cargos.car cvecon=2 nalca=nalca+saldo case cargos.car_cvecon=l0 niva=niva+saldo case cargos. car cvecon=65 nsan=nsan+saldo otherwise notro=notro+saldo 86

94 endcase endif skip enddo this.cagua.value=nagua this.calcan.value=nalca this.csan.value=nsan this.cotros.value=notro this.clva.value = niva this.crecar.value =nreca if 1Gastos this. cgtos.value=round(ngtos*0.08,2) else this.cgtos.value=0 endif this.check2.value=lconve this.cconvenio.value=nconvlmporte this.canticipo.value=nanti this.cabonar.value=nabo acargos(3,2)=nreca acargos(4,2)=round(ngtos*0.08,2) select 1 return ENDPROC 87

95 *-- regostra pago PROCEDURE grabap lparameter ncuenta,npago,ncaja,coper,lconv,dfecha,chora select 5 append blank rlock() replace abo_cvecta with ncuenta, abo_import with npago,abo caja with ; ncaja,abo login with coper,abo conven with lconv,abo_fecha ; with dfecha, abo hora with chora unlock ENDPROC *-- Tira de auditoria PROCEDURE tira Parameter dfecha,ncaja select 5 set order to 2 seek dtos(dfecha)+str(ncaja,2) if found().and. eof() si=.t. else si=.f. 88

96 endif return si ENDPROC PROCEDURE leetira this.tcuenta.value=abonar.abo cvecta this.tlmporte.value=abonar.abo import this. tconv.value=abonar.abo conven ENDPROC PROCEDURE Init Public int nbusca messagebox("activando Init") this.abretabla ENDPROC PROCEDURE Load nbusca=0 messagebox("activando Init") set deleted on this.abretabla ENDPROC 89

97 ENDDEFINE * *-- EndDefine: frmusu... 90

98 Anexo B 91

99 Procedimiento para instalar el protocolo TCP/IP en equipos PC con sistema operativo WIN9x Se puede instalar el protocolo TCP/IP para operar en una red local (LAN) o para enlaces remotos vía un módem. A continuación se describe el procedimiento para cada uno de los casos. A. Protocolo TCP/IP para una tarjeta de red local (LAN) o adaptador de enlace telefónico. Una vez que ya se instaló correctamente la tarjeta de red (NIC) que se va a utilizar o el adaptador de enlace telefónico, se deberán seguir los siguientes pasos: Seleccionar la opción Red (Networkt) dentro del Panel de Control (Inicio- >Configuración->Panel de Control) Dar doble click con el botón izquierdo para ejecutar la utileria que permitirá agregar el protocolo 92

100 Seleccionar Agregar 93

101 Seleccionar Protocolo y Agregar Seleccionar Microsoft, TCP/IP y Aceptar Seleccionar Dirección IP, activar la opción Especificar una dirección IP y capturar la dirección que se asignará al equipo (en el ejemplo: con la máscara ) y Aceptar. 94

102 Reinicializar el equipo 95

103 Anexo C 96

104 Listado del código correspondiente a los métodos contenidos en la aplicación Cliente. A).-Formulario form1.scx A-1) Método load: public o, Qpago,nQcta,Qpoblac,Qrfc dimension anqdebe(100,2) set decimal to 2 A-2) Método Init: Qpago=0.00 thisform.label11. visible=.f. thisform. Text15.visible=.f. thisform. Option group1. visible=. f. thisform. command2. visible=.f. thisform. command3. visible=.f. Qv4=0 Qv6=0 Qv7=0 Qv8=0 Qv9=0 Qv10=0 Qv11 =0 97

105 Qv12=0 Qv13=0 Qv14=0 Qv16=0 A-3) Caja de texto Text1: Click thisform. Text1. value= thisform. Text2. value="" thisform. Text3. value="" thisform. Text5. value="" thisform. Text4. value=0 thisform. Text6. value=0 thisform. Text7 value=0 thisform. Text8. value=0 th isform. Text9. value=0 thisform. Text10. value=0 thisform. Text1l. value=0 thisform. Textl2. value=0 thisform. Text13. value=0 thisform. Text16. value=0 thisform. checkl. value=.f. Qv4=0 Qv6=0 98

106 Qv7=0 Qv8=0 Qv9=0 Qv10=0 Qv11=0 Qv12=0 Qv13=0 Qv16=0 Qpoblac="" Qrfc="'f thisform.label11. visible=.f. thisform. Text15. visible=.f. thisform. Text15. value=0. 00 thisform. Option group1. visible=.f. thisformh.command2. visible=.f. thisformh.command3. visible=.f. thisform. Option groupl.option1. value=0 thisform.optiongroupl. option2. value=0 A-4) Botón Buscar (Commandl:Click) nqcta=0 * messagebox("entro a botton ") nqcta=val(thisform text1. value) o.buscar(nqcta) 99

107 if. not. ( o. Check1. value) messagebox("no se localizó la cuenta( cliente) ") return endif thisform. Text2. value=o. cnombre. value thisform. Text3. value=o. cdirecc. value thisform. Text5. value=o. cclave. value thisform. Text4. value=o. cagua. value thisform. Text6. value=o. calcan. Value thisform. Text7. value=o. cotros. value thisform. Text8. value=o. clva. value thisform.text9.value - -o.crecar.value thisform.text10.value=o.cgtos.value thisform. Text11. value=o. ccon ven io. Value thisform. Text13. value=o. cabonar. Value thisform. Text14. value=o. canticipo. value thisform. Text16. value=o.csan. value Qpoblac=o.cPoblac. value Qrfc=o. crfc. value thisform. Check1. value=o. check2. value thisform. Texti2 value. cagua. value+o. calcan. value+o. csan. value+o. cotros. value+; o. clva. value+o. crecar. value+o. cgtos. value+; o.ccon venio. value-(o. cabonar. value+o. canticipo. value) Qpago=

108 thisform.label11. visible=. t. thisform. Text15. visible=. t. thisform.text15.setfocus A-5) Botón Grabar Pago (Command2:Click) private ngcuenta,ngpago,ngcaja,cgoper,lgconv,dgfecha,cghora * si es facturacion if thisform.optiongroup1.option1.value=.t. cquepaga="facturacion" igconv=.f. else cquepaga= "Convenio " igconv=. t. endif if thisform.text] 5.value<=0 messagebox("no se puede registrar sin pago ) return endif set console off set printer to name "TMj" set printer font "Times ",11 set printer on? 'Comision de Agua Potable, Drenaje y'? 'Alcantarillado de Manzanillo, Col.'? ' Palacio Municipal s/n, Piso 3' 101

109 ?? space(5),' Recepcion de pago a:'+cquepaga?? 'Fecha:,date(),' Hora: ;time() dgfecha=date() cghora=substr(time(),1,5)?? 'Cuenta:,trans(nQcta, " ") set printer font "Times ",8?? substr(thisform.text2.value,1,40)? substr(thisform.text3.value,1,40)? Qpoblac? Qrfc *? substr(thisform.text2.value,1,40)? set printer font "Times ",10?? "== Cargos actuales =="? 'Agua 'AT 1, trans (thisform. Text4. value, 999, ) AT 20? Alcantarillado 'AT 1, trans(thisform.text6.value, "999,999.99") at 20?'Saneamiento 'AT 1, trans(thisform.textl6.value, "999,999.99") at 20? 'Otros' AT 1, trans(thisform. Text7. value, "999, ") at 20? 'IVA 'AT 1, trans(thisform.text8.value, "999,999.99') at 20? 'Recargos 'AT 1, trans(thisform.text9.value, "999,999.99") at

110 ? 'Gastos 'AT 1,trans(thisform.TextlO.value, "999,999.99") at 20? replicate("-",36)? 'Adeudo Total' AT l,trans(thisform.textl0.value+; thisform.text4.value+; thisform. Text6. value+thisform. Text16. value+; thisform. Text7. value+; thisform. Text8. value+; thisform. Text9. value, "999,999.99') AT 20? set printer font "Times ",12, "B"?'Su Pago: $,trans(thisform. Textl5. value, "999,999.99") set printer font "Times",11,""N"? *WAIT WINDOW "Entra cuser: "+cuser+" Id: "+str(nqidcaja,2) TIMEOUT 5.5? 'Operador: ;cuser,' Caja: ;str(nqidcaja,2)?? "El agua es vida.. cuidala!! " set printer off set printer to set console on thisform.command3. visible=. t. thisform. command3. enabled=.t. thisform.command2.enabled=.f. ngcuenta=n Qcta 103

111 ngpago=thisform. Text15. value ngcaja=nqidcaja cgoper=cuser o.grabap(ngcuenta,ngpago,ngcaja,cgoper,lgconv,dgfecha,cghora) * messagebox("grabado el pago ") A-6) Botón Validar Pago (command2:click) set console off set printer to name "TMs" set printer font "Times ",10 set printer on? 'Operador: ',cuser,' Caja:,str(nQidCaja,2)??"Cuenta: ",trans(nqcta," ")," Pago: ",trans(thisform.text] 5.value, "999, ")??"Fecha: ",dateo," Hora: ",time()? for i=1 to 13? next?? 'Operador:,cUser,' Caja:,str(nQidCaja,2)??"Cuenta:",trans(nQcta," ")," Pago: 104

112 ",trans(thisform.textl5.value, "999,999.99")? "Fecha: ",date()," Hora: ',time()? set printer off set printer to set console on set printer to name "TMs" thisform. command3. enabled=. F B) Formulario ftira.scx B-1) Botón imprimir Tira (Command1:Click) local Qfecha,ncta,npag Qfecha=date() * WAIT WINDOW "Regresa con:"+len(atira) TIMEOUT 1.5 * set console off * set printer to name "TMj" * set printer font "Times", 11 * set printer on? 'Comision de Agua Potable, Drenaje y'?'alcantarillado de Manzanillo, Col.'? ' Palacio Municipal s/n, Piso 3'?? Relación de pagos del día:',qfecha? 105

113 restore from c:\windows\id.mem additive ncaj a=nqidcaj a? "Caja:",nCaja?? 'Fecha Imp:',date(),' Hora:',time()? set printer font "Times",8? replicate("-",36)? 'Cuenta Importe Conv.'? replicate("-",36) * llamar a la función Tot- 0 Que=o.tira(Qfecha,nCaja) 106

114 do while Que o.leetira() ncta=o.tcuenta.value npag=o.timporte.value? str(ncta,7),trans(npag,"99,999,999.99")," ",o.tconv.value Tot=Tot+o.timporte.value que=o.unomas(qfecha,ncaja) enddo? replicate("-",36)? "Total "+trans(tot,"99,999,999.99")??'operador: ',cuser,' Caja:',str(nQidCaja,2)?? "El agua es vida..cuidala!!" set printer off set printer to set console on 107

115 C) Formulario login.scx C-1) Método load THIS.Autocenter = T. THIS.BorderStyle = 2 && Fixed Dialog C-2) Método unload RETURN THIS.cUser C-3) Botón comando Aceptar (cmdok:click) LOCATE FOR UPPER(login.userid) = UPPER(ALLTRIM(THISFORM.txtUserName.Value)) IF FOUNDO AND ALLTRIM(password) == ALLTRIM(THISFORM.txtPassword.Value) THISFORM.cUser = ALLTRIM(login.userid) THISFORM.Release *WAIT WINDOW "Si entra" TIMEOUT 1.5 ELSE #DEFINE MISMATCH LOC "El nombre de usuario o la contraseña no son correctos. Vuelva a intentarlo." 108

116 WAIT WINDOW MISMATCH LOC TIMEOUT 1.5 THISFORM.txtUserName.Value = "" THIS FORM. txtpassword. Value = "" THIS FORM.txtUserName. S etfocus END IF C-4) Botón Cancelar (cmdcancela:click) THISFORM.cUser = "" THISFORM.Release D) Programa Principal de la aplicación Progrl.prg public o,cuser SET TALK OFF SET ECHO OFF SET DELETE ON SET DATE DMY SET STATUS BAR OFF SET BELL OFF SET MESSAGE TO SET SAFETY OFF SET EXACT OFF SET MULTILOCKS ON CLEAR MACROS && limpiamos el archivo de macros de VFP ON KEY LABEL ESC * && desactivamos la tecla Escape 109

117 * Guardamos todas las posibles barras de herramientas de VFP y también * si están visibles o no. Si ocurre lo primero las ocultamos Dimension abarras[11,2] abarras[1, 1 ]="Controles de formularios" abarras[2,1 ]="Controles de informes" abarras[3,1 ]="Distribución" abarras[4, 1 ]="Estándar" abarras[5,1]="diseñador de bases de datos" abarras[6,1 ]="Diseñador de consultas" abarras[7,1 ]="Diseñador de formularios" abarras[8,1 ]="Diseñador de informes" abarras[9,1 ]="Diseñador de vistas" abarras[1 0, 1 ]="Paleta de colores" abarras[1 1,1 ]="Vista preliminar" FOR i=1 to ALEN(aBarras,1) abarras[i,2]=wvisible(abarras[i, l ]) IF abarras[i,2] HIDE WINDOW (abarras[i,l]) ENDIF NEXT restore from c:\windows\id.mem additive o=createobject("tstclase.frmusu") 110

118 do form login to cuser if len(cuser)!=0 WAIT WINDOW "Si Entra con cuser:"+cuser+" Caja:"+str(nQidCaja,2) TIMEOUT 1.5 * ncaja=nqidcaja do menú1.mpr read events else * WAIT WINDOW "No Entra con cuser:"+cuser+" len:"+str(len(cuser)) TIMEOUT 1.5 WAIT WINDOW "No esta autorizado a usar el Sistema: "+cuser TIMEOUT 5.5 CLOSE ALL RELEASE ALL EXTENDED CLEAR CLEAR ALL quit endif * Cerramos todo y limpiamos la memoria CLOSE ALL RELEASE ALL EXTENDED CLEAR CLEAR ALL 111

119 Anexo D 112

120 Configurar un enlace telefónico a una red, utilizando el sistema operativo Windows 9x de Microsoft. Se deberá tener instalado el módulo para Acceso telefónico, para verificarlo, dar un doble click con el botón izquierdo al icono Mi PC, en caso de no aparecer la carpeta con ese nombre, instalarlo siguiendo el procedimiento siguiente: a) Procedimiento para instalar los programas para enlace telefónico en Windows 9x Dar click en Inicio. Seleccionar la opción Configuración. Activar la opción Panel de control. Dar doble click Agregar o quitar programas Dar clic en la opción Instalación de Windows. Seleccionar el módulo de comunicaciones ( ver figura) 113

121 Activar el botón Detalles (ver figura siguiente). 114

122 Activar las casillas de selección correspondientes a Acceso telefónico a redes y Marcador de teléfono Dar click en el botón Aceptar. b) Instalar un enlace telefónico a redes. Activar Mi PC y seleccionar la carpeta Enlace telefónico a redes. (ver figura siguiente) 115

123 Al abrir la carpeta anterior, seleccionar Realizar conexión nueva y proporcionar los datos que se solicitan: Nombre de la conexión, teléfono, etc. 116

124 Anexo E 117

125 Instalación de un servidor para enlace telefónico en Windows 98, segunda edición. Se necesita tener instalados el módulo Servidor de acceso telefónico a redes (seguir los pasos indicados en el anexo C inciso a para activar la instalación de comunicaciones como se ilustra en la figura siguiente. Teniendo instalado lo anterior, seguir los siguientes pasos: Abrir Mi PC. Dar un doble click sobre la carpeta Acceso telefónico a redes. Seleccionar la opción Conexiones. Seleccionar Servidor de acceso telefónico a redes. Activar el servidor telefónico (ver figura siguiente). 118

126 119