Tesis - Dirección General de Servicios Telemáticos

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 4.11.
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
UNIVERSIDAD DE COLIMA
OFICIO NO. 757/02
FACULTAD DE TELEMATICA
C. MIGUEL ÁNGEL MIRANDA GUERRERO
PRESENTE
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. 28040
Telefax 01 (312) 316 10 75, 316 10 00, Ext. 37801
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
ÍNDICE
INTRODUCCIÓ N ...................................................................................................................1
I.- MARCO TEÓRICO ............................................................................................................5
II.- ASPECTOS TÉCNICOS DE DCOM ............................................................................. 21
III.-ARCHIVOS TIPO.DBF .................................................................................................. 34
IV. -PLANTEAMIENTO DEL PROBLEMA Y DESARROLLO DE LA SOLUCIÓN
43
V.- RESULTADOS Y CONCLUSIONES ..............................................................................66
SUGERENCIAS ..................................................................................................................... 70
ANEXO A ................................................................................................................................71
ANEXO B ................................................................................................................................ 93
ANEXO C ............................................................................................................................... 98
ANEXO D ............................................................................................................................. 117
ANEXO E .............................................................................................................................. 121
ANEXO F .............................................................................................................................. 124
GLOSARIO ..........................................................................................................................127
BIBLIOGRAFÍA .................................................................................................................. 129
iii
Tabla de figuras
No. Fig
De s c r i p c i ó n
Página
1.1
Arquitectura Mainframe o Centralizada.
1.2
Esquema de un servidor de archivos.
1.3
Diseño de la arquitectura Cliente/Servidor de 2 niveles.
1.4
Esquema de aplicaciones distribuidas.
10
1.5
Enlaces entre aplicaciones Cliente/Servidor con RPC
16
1.6
Esquema de la arquitectura Cliente/Servidor utilizando COM.
19
1.7
Esquema de la arquitectura DCOM.
20
2.1
Componentes COM en diferentes procesos.
22
2.2
DCOM: componentes COM en diferentes equipos.
22
2.3
Independencia de la localización.
25
2.4
Distribución paralela de componentes.
27
2.5
Distribución de un componente critico.
28
2.6
Administración consolidada del tiempo de vida.
29
4.1
Conexiones de red previas en CAPDAM.
43
4.2
Esquema de la solución propuesta.
47
4.3
Contenido del proyecto de la aplicación servidor
49
4.4
Clase principal de la aplicación servidor.
50
4.5
Cuadro de dialogo que permite exponer una clase al público.
51
4.6
Opciones para generar la aplicación EXE o .DLL
52
4.7
Especificar si el servidor creado será de una o varias instancias.
53
7
iv
4.8
Configurar DCOM: opción " propiedades predeterminadas".
55
4.9
Configurar la seguridad de DCOM.
55
4.10
Instrucción para registrar el modulo servidor.
57
4.11
Contenido del proyecto Cliente.pjx.
58
4.12
Formulario forml de la aplicación cliente.
59
4.13
Formulario ftira de la aplicación cliente.
60
4.14
Formulario para el login.
61
4.15
Utileria para configurar DCOM.
62
4.16
Indicar en que equipo se ejecuta el servidor.
63
Tablas
Descripción
No.
tabla
Página
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
v
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
INTRODUCCIÓN
Las cond iciones 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
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
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
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
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 (http://www.sei.cmu.edu/str/descriptions/dce
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
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
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
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
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
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
• 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
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 1993. 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
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
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
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
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 1.5.
16
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
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
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
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
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 compone ntes. 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
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
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 desempaque ta 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
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.
2.2.3 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
•
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
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 aplicacio nes.
2.4.1 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.
2.4.2 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
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
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
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
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
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.
2.7.1 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
aplicacio nes 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
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 versione s 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
100.000 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
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
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).
3.1.- 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
9-10
Donde inician los registros de datos
11-12
Longitud del registro
13-28
Sin uso
29
Indica si tiene componentes de indizado
30
Indica el número de página de la tabla
31-32
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
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
Valor del Byte
Descripción / Contenido
30
“00”
No tiene código de página. Este valor lo tienen las tablas creadas con FoxPro hasta la versión 2.5
“01 ”
DBF creada desde DOS. Código de página 437
“02”
IBF creada desde DOS Internacional. Código de página 850
“03”
19 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
13-14
Dirección donde comienza el campo desde el principio del registro
15-16
Sin use
17-18
Longitud del campo (campos no numéricos)
17
Longitud del campo (campos numéricos)
18
Campos decimates (campos numéricos)
19-32
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
Valor Hexadecimal
Decimal
Character (Carácter)
C
67
43
Date (fecha)
Logical (lógico)
Memo
Numeric (Numérico)
D
L
M
N
68
76
77
78
44
4C
4D
4E
37
Flota (coma flotante)
F
70
46
General
G
71
47
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
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.
3.3.-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:
AAAAMMDD
---------Formato
31 39 39 35 30 31 30 31
--------Valor Hex.
19950101
--------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
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:
20 20 20 20 20 20 20 20 31 35 (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:,
32 32 2C 33 32 34 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).
3.4.-Interfaces para control de archivos tipo DBF
40
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):
3.4.1.- 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
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.
3.4.2.- 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.
3.4.3.- 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.
3.4.4.- 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
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.
4.1.- 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 4.11. 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
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.
4.1.1.- 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 e l 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
oficinas centrales se utilizan equipos PC con procesador 386 sin disco duro, con
sistema operativo MS-DOS y enlace a NET WARE 4.11.
• 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
4.2.- Análisis de la problemática.
La tecno logí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 4.11.
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
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.
4.3.- 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
usando Visual FoxPro versión 6 en una aplicación de un solo nivel (Menhaen,2000, pp
724-746). 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.
4.3.1.- 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 aplic a 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 lo s pagos recibidos
durante el día se almacenan en la tabla denominada ABONAR, identificando que usuario
lo realiza, importe y las condiciones del mismo.
4.3.2.- 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
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
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
•
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. 4.5.- 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
4.3.3.- 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
La figura siguiente muestra la pantalla respectiva.
Fig. 4.6.-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
En la figura siguiente se muestra la pantalla respectiva.
Fig. 4.7.- Especificar si el Servidor creado será de una o varias instancias.
4.3.4.- 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
• Para Windows 95 .- http ://microsoft.com/com/dcom/dcom95/download.asp
•
Para Windows 98.- http://www.microsotft.com/com/dcom98/download.asp
• 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
• 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
• 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. 4.10.- 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.
4.4.- 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
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. 676-723).
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
La figura 4.11 muestra el proyecto como se aprecia desde Visual FoxPro.
4.4.1.- 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
Fig. 4.12 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
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. 4.13 Formulario ftira
61
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,
negand o el acceso a las opciónes del módulo Cliente que gestionan los pagos. La
figura 4.14 muestra este formulario.
Fig. 4.14 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
•
Botón Cancelar.- Suspende el proceso y cierra aplicación.
4.4.2.- 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 4.3.4 inciso 2 de este capítulo).
4. Configurar la computadora para ejecutar aplicaciones DCOM (ver el punto 4.3.4
inciso 3 de este capítulo).
5. Registrar la aplicación Servidor DCOM (ver el punto 4.3.4 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. 4.15 Utilería para configurar DCOM
63
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. 4.16 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
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:
4.5.1 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.
4.5.2 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
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
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
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
ü 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 aplicacio nes 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
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
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
Anexo A
72
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
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
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
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
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
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
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
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
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
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
*-- 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
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
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 usua rio: '+str(nCuenta,7) + WONTOP( )
endif
nagua=0
niva=0
nalca=0
nsan=0
notro=0
85
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
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
*-- 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
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
ENDDEFINE
*
*- - EndDefine: frmusu
……………………………………………………………...
90
Anexo B
91
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
Seleccionar Agregar
93
• 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: 10.0.0.11 con la máscara
255.255.255.0) y Aceptar.
94
• Reinicializar el equipo
95
Anexo C
96
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
Qv12=0
Qv13=0
Qv14=0
Qv16=0
A-3) Caja de texto Text 1: 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
Qv7=0
Qv8=0
Qv9=0
Qv10=0
Q v1 1=0
Qv12=0
Qv13=0
Qv16=0
Qpoblac=""
Qrfc="'f
thisform.label 11. 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
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.Text 10.value=o.cGtos.value
thisform. Text11. value=o. cCon ven io. Value
thisform. Text 13. 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=0.00
100
thisform.label 11. visible=. t.
thisform. Text15. visible=. t.
thisform.Text 15.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
?
? space(5),' Recepcion de pago a:'+cQuePaga
?
? 'Fecha: ,date(),' Hora: ;time()
dgFecha=date()
cgHora=substr(time(),1,5)
?
? 'Cuenta: ,trans(nQcta, "9999999")
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,999.99”) 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,999.99 ") 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 20
102
? '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" , 1 1 , " " 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
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,"9999999")," Pago:
",trans(thisform.Text] 5.value, "999,999.99 ")
?
?"Fecha: ",dateO," Hora: ",time()
?
for i=1 to 13
?
next
?
? 'Operador: ,cUser,' Caja: ,str(nQidCaja,2)
?
?"Cuenta:",trans(nQcta,"9999999")," Pago:
104
",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
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
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
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
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
* 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
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
Anexo D
112
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
Ø Activar el botón Detalles (ver figura siguiente).
114
Ø 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
Ø 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
Anexo E
117
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
119
Anexo F
120
Estructura de las principales tablas utilizadas durante el proceso de
recepción y registro de pagos por los servicios de CAPDAM .
1.- Tabla denominada CA_ TOMAS.DBF, en la cual se almacenan los datos de los usuarios de
los servicios de CAPDAM, se muestran los campos utilizados para la aplicación de cajas.
2.- Tabla denominada ABONAR.DBF, en la cual se almacenan los datos del pago efectuado
por el usuario.
121
3.- Tabla denominada CARGOS.DBF, en la cual se almacenan los cargos que hace la
CAPDAM a los usuarios, se muestran los campos utilizados en la aplicación.
4.- Tabla denominada CONVENIOS.DBF, en la cual se registran lo relativos a los
convenios que hace la CAPDAM con aquellos usuarios que solicitan facilidades de pago.
Como se observa, el campo llave para las tablas es el correspondiente al número de cuenta
del usuario.
122
Glosario
Flexibilidad
La facilidad con la cual un componente o sistema puede ser modificado para su uso en
aplicaciones o ambientes diversos a aquel para el cual fue específicamente diseñado [IEEE
90].
Usabilidad
La facilidad con la cual un usuario puede aprender a operar, preparar los datos que alimentara e
interpretar las salidas o reportes de un sistema o componente [IEEE 90].
Interoperabilidad
La habilidad de dos o más sistemas o componentes para intercambiar información y usar la
información que se intercambió [IEEE 90].
Escalabilidad
La facilidad con la que un sistema o componente puede ser modificado para adecuarse al
problema.
Portabilidad
La facilidad con la que un sistema o componente puede ser transferido de un hardware o
ambiente de software a otro [IEEE 90].
Mantenible (Maintainability )
La facilidad con la que un sistema de software o componente puede ser modificado para
corregir fallas, mejorar su desempeño u otros atributos, o adaptarlo a un cambio de ambiente
[IEEE 90].
Adaptabilidad
La facilidad con la que un software satisface diferentes requisitos de sistemas y necesidades del
usuario [Evans 87].
123
Complejidad
• (Aparente) el grado al que un sistema o componente tiene un diseño o implementación que es
difícil de entender y verificar [IEEE 90].
• (Inherente) el grado de complicación de un sistema o componente de un sistema,
determinado por factores tales como el número y lo intrincado de las bifurcaciones
condicionales, el grado de anidación y el tipo de estructura de datos [Evans 87].
Stub
Un subprograma que se emplea para unir 2 aplicaciones en RPC
124
BIBLIOGRAFÍA
Bray Mik. (2001). Application Programming Interface. Carnegie Mellon University
URL: http://www.sei.cmu.edu/str/descriptions/api body.html.
Bray Mike (2001). Middleware. Carnegie Mellon University
URL: http://www.sei.cmu.edu/str/descriptions/middleware body.html.
Computer Associates. (1992). Drivers Guide, version 5.2.
Darleen Sadoski. (2000). Client/Server Software Architectures--An Overview. Carnegie
Mellon University. URL: http://www.sei.cmu.edu/str/descriptions/clientserver body.html.
Hostmann Markus & Kirtland Mary (1997, Julio), DCOM Architecture. Obtenido de la Red
Mundial el 26 de Febrero de 2002:
http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dndcom/html/msdn
dcomarch.asp
[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.
Kroenke David M. (1996), Procesamiento de bases de datos, fundamentos, diseño e
instrumentación. Prentice Hall. 5a edición, México.
Martínez Luis. (1999). La cabecera de los .DBF. FoxPress, Mayo 2001
http://www.$ress.com/revista/Num0501/May01 i.htm.
Microsoft Corporation (1996, Noviembre), DCOM Technical Overview. Obtenido de la Red
Mundial el 26 de Febrero de 2002:
httv://msdn.microsoft.com/library/default.asp?url=/library/en- us/dndcom/html/msdn
dcomtec.asp
125
Microsoft Corporation (1997, Abril), DCOM a Bussines Overview. Obtenido de la Red
Mundial el 26 de Febrero de 2002:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn
dcombiz.asp
Mueller, J.P. (2000). Visual Basic COM+ Programming Bible. IDG Books
Vondrak Cory (2001). Distributed Computing Environment. Carnegie Mellon University
URL: http://www.sei.cmu.edu/str/descriptions/dce body.html.
Vondrak Cory (1997). Remote Procedure Call. Carnegie Mellon University
URL: http://www.sei.cmu.edu/str/descriptions/rpc body.html.
Williams Sara & Kindel Charlie, Microsoft Corporation (1996, Octubre), The Component
Object Model: A Technical Overview. Obtenido de la Red Mundial el 26 de Febrero de
2002: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dndcomg/html/msdn
comppr.asp
126