Universidad de Colima

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Universidad de Colima"

Transcripción

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

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

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

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

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

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

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

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

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

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

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

12 CAPÍTULO I MARCO TEÓRICO Es importante conocer que y como evolucionaron los conceptos básicos sobre los que se desarrollo el presente trabajo, estos son: Arquitectura Cliente/Servidor. Arquitectura de software de 2 niveles (Middletier o Two Tier). Ambiente de Cómputo Distribuido (Distributed Computing Enviroment o DCE) Interface para Programación de Aplicaciones (Application Programming Interface o API). Llamada a Procedimientos Remotos (Remote Procedure Call o RPC). COM/DCOM/COM+ : el Modelo de Objetos Componentes (Component Object Model o COM), Modelo de Objetos Componentes Distribuido (Distributed Component Object Model o DCOM) y Modelo de Objetos Componentes Mejorado ( COM+). A continuación se presenta un resumen para cada uno de los anteriores conceptos. La fuente fue tomada de The Software Engineering Institute (SEI), el cual es un centro federal para la investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos y operado por la Universidad Carnegie Mellon (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

79 Anexo A 72

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

98 Anexo B 91

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

100 Seleccionar Agregar 93

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

102 Reinicializar el equipo 95

103 Anexo C 96

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

119 Anexo D 112

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

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

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

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

124 Anexo E 117

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

126 119

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

Tema 2: EL MODELO CLIENTE/SERVIDOR Tema 2: EL MODELO CLIENTE/SERVIDOR E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Definición de sistemas cliente/servidor (1) Clientes y servidores: entidades lógicas

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

Justificación Cliente/Servidor. Arquitectura Cliente/Servidor. Nuevas Tareas del Dpto. de Sistemas de Información

Justificación Cliente/Servidor. Arquitectura Cliente/Servidor. Nuevas Tareas del Dpto. de Sistemas de Información Tema IV Arquitectura liente/servidor Justificación liente/servidor AVANE TENOLÓGIO EXIGENIAS DE LA EMPRESA ENTORNO GENERAL ANTES Rigidez. No redistribución. Vinculación al sistema. Solapamiento, duplicación

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

1.264 Tema 16. Middleware heredado

1.264 Tema 16. Middleware heredado 1.264 Tema 16 Middleware heredado Qué es el middleware heredado? Cliente (interf. de usuario, aplic. local) Cliente (interf. de usuario, aplic. local) Cómo conectamos clientes y servidores? Middleware

Más detalles

Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS Sistemas Distribuidos

Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS Sistemas Distribuidos Tema 1: INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Introducción a la Computación Distribuida Sistema distribuido: conjunto

Más detalles

Capítulo 1. Componentes de CORBA.

Capítulo 1. Componentes de CORBA. Capítulo 1. Componentes de CORBA. La OMA (Object Management Architecture) define en alto nivel de abstracción las reglas necesarias para la distribución de la computación orientada a objetos (OO) en entornos

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

Notas. Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos. Resumen 2. CORBA. 1. Introducción

Notas. Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos. Resumen 2. CORBA. 1. Introducción Notas Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos Resumen Debido al auge que se ha venido dando últimamente en el uso de las redes, se ha incrementado el crecimiento de los entornos

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

Introducción a Windows 2000 Server

Introducción a Windows 2000 Server Introducción a Windows 2000 Server Contenido Descripción general 1 Administración de los recursos utilizando el servicio de Directorio Activo 2 Administración de una red 3 Mejora del soporte de red y comunicaciones

Más detalles

C/S:CLIENTE/SERVIDOR

C/S:CLIENTE/SERVIDOR C/S:CLIENTE/SERVIDOR ALEJANDRO DOMÍNGUEZ Curso impartido en la Universidad Autónoma de Ciudad del Carmen, Campeche 15/10/1998 PRINCIPIA INFORMATICA 1 Temario La computación C/S Qué es C/S? Tipos de C/S

Más detalles

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores. GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

Curso: Base de Datos Distribuidas. Unidad 1: Fundamentos de Sistemas de Base de Datos Distribuidas. M. en C. José Mario Martínez Castro

Curso: Base de Datos Distribuidas. Unidad 1: Fundamentos de Sistemas de Base de Datos Distribuidas. M. en C. José Mario Martínez Castro Curso: Base de Datos Distribuidas Unidad 1: Fundamentos de Sistemas de Base de Datos Distribuidas M. en C. José Mario Martínez Castro Chilpancingo, Gro., Febrero del 2007-1 - C O N T E N I D O 1. Fundamentos

Más detalles

DIPLOMADO EN SEGURIDAD INFORMATICA

DIPLOMADO EN SEGURIDAD INFORMATICA DIPLOMADO EN SEGURIDAD INFORMATICA Modulo 9: Soporte Computacional Clase 9_1:Instalación y configuración de redes Director Programa: César Torres A Profesor : Claudio Hormazábal Ocampo Contenidos del Módulo.

Más detalles

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa.

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa. Glosario de términos Ancho de Banda El ancho de banda es la máxima cantidad de datos que pueden pasar por un camino de comunicación en un momento dado, normalmente medido en segundos. Cuanto mayor sea

Más detalles

Desarrollo Informático del SIGOB

Desarrollo Informático del SIGOB Desarrollo Informático del SIGOB Los soportes informáticos del Sistema de Información y Gestión para la Gobernabilidad (SIGOB) utilizan productos de tecnología avanzada, que permite la rápida incorporación

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

Desarrollo de Aplicaciones N-Tier. Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009

Desarrollo de Aplicaciones N-Tier. Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009 Desarrollo de Aplicaciones N-Tier Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009 Ambiente Mainframe La primera forma de automatización de negocios tomó la forma de una gran computadora central, llamada

Más detalles

CAPITULO III. TECNOLOGÍA SNMP

CAPITULO III. TECNOLOGÍA SNMP CAPITULO III. TECNOLOGÍA SNMP En este capitulo haremos una presentación sobre la estructura básica del protocolo de monitoreo SNMP. El objetivo de este protocolo es poder realizar un monitoreo del estado

Más detalles

Solución IP Office de Avaya

Solución IP Office de Avaya Solución IP Office de Avaya La solución completa para las necesidades de su empresa Redes convergentes de voz y datos Gestión de relaciones con los clientes Comunicación unificada Con el soporte de: Laboratorios

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 1: Introducción: 1.1 Introducción: Qué es un sistema operativo?. 1.2 Conceptos clave de un sistema operativo. 1.3 El sistema operativo como administrador

Más detalles

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Instituto Tecnológico Superior de los Ríos Ing. en Sistemas Computacionales 30 de enero de 2012 Bases de Datos Distribuidas:Arquitectura Cliente/Servidor

Más detalles

Operación Microsoft Windows XP

Operación Microsoft Windows XP Entornos de red Concepto de red En el nivel más elemental, una red consiste en dos equipos conectados entre sí mediante un cable de forma tal que puedan compartir datos. Todas las redes, no importa lo

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Desarrollo de Aplicaciones N-Tier. Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009/15

Desarrollo de Aplicaciones N-Tier. Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009/15 Desarrollo de Aplicaciones N-Tier Lic. Guillermo Cherencio. Versión 1.0 Febrero 2009/15 Ambiente Mainframe La primera forma de automatización de negocios tomó la forma de una gran computadora central,

Más detalles

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos.

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos. Contenidos Sistemas operativos Tema 3: Estructura del sistema operativo Componentes típicos del SO Servicios del SO Llamadas al sistema Programas del sistema El núcleo o kernel Modelos de diseño del SO

Más detalles

La utilización de las diferentes aplicaciones o servicios de Internet se lleva a cabo respondiendo al llamado modelo cliente-servidor.

La utilización de las diferentes aplicaciones o servicios de Internet se lleva a cabo respondiendo al llamado modelo cliente-servidor. Procesamiento del lado del servidor La Programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante la interpretación de un script en el

Más detalles

Virtualización de Escritorios NComputing

Virtualización de Escritorios NComputing Virtualización de Escritorios NComputing Resumen Introducción Tendencia de los mercados informáticos INFORME EJECUTIVO Todos estamos acostumbrados al modelo de las PCs, que permiten a cada usuario tener

Más detalles

UNIVERSIDAD ESTATAL DE MILAGRO

UNIVERSIDAD ESTATAL DE MILAGRO UNIVERSIDAD ESTATAL DE MILAGRO TRABAJO DE INVESTIGACION DE BASE DE DATOS TEMA: SISTEMAS DISTRIBUIDOS NOMBRE: ANGEL SAUL NOBOA BARRENO PROFESOR: ING. RICHARD RAMIREZ CURSO: 6 To SEMESTRE C SISTEMAS DISTRIBUIDOS

Más detalles

Capítulo 5. Sistemas operativos. Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática)

Capítulo 5. Sistemas operativos. Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática) Capítulo 5 Sistemas operativos Autor: Santiago Felici Fundamentos de Telemática (Ingeniería Telemática) 1 Sistemas operativos Definición de Sistema Operativo Partes de un Sistema Operativo Servicios proporcionados:

Más detalles

Unicenter Remote Control Versión 6.0

Unicenter Remote Control Versión 6.0 D A T A S H E E T Unicenter Remote Control Versión 6.0 Unicenter Remote Control es una aplicación altamente fiable y segura para controlar y dar soporte a sistemas Windows remotos. Puede mejorar significativamente

Más detalles

unidad redes de computadoras

unidad redes de computadoras unidad 4 redes de computadoras contenidos Compartir recursos Modelo cliente/servidor Tecnologías de la Información y la Comunicación 67 Acerca de esta unidad Una red es un conjunto de computadoras dos

Más detalles

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A.

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. VERSIÓN 4.0 a2 Herramienta Administrativa Configurable e-mail a2softway@cantv.net

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red. Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor;

Más detalles

servicios. El API es definido al nivel de código fuente y proporciona el nivel de

servicios. El API es definido al nivel de código fuente y proporciona el nivel de GLOSARIO API Application Program -ming- Interface Es la interfaz por la cual una aplicación accede al sistema operativo u a otros servicios. El API es definido al nivel de código fuente y proporciona el

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Visualización y modelado de elementos geográficos en dispositivos móviles. Capítulo 5: Aplicaciones cliente

Visualización y modelado de elementos geográficos en dispositivos móviles. Capítulo 5: Aplicaciones cliente Capítulo 5: Aplicaciones cliente 46 5.1 La aplicación cliente en la Pocket PC La aplicación desarrollada para el cliente en un dispositivo móvil como corresponde a la Pocket PC necesita una capa muy delgada

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Agradecimientos: por su contribución a la realización de estas transparencias: Jesus Villamor Lugo y Simon

Más detalles

Microsoft. Febrero de 2006

Microsoft. Febrero de 2006 Microsoft Febrero de 2006 Tabla de contenido Información general de Microsoft Office InfoPath 2007...1 Incorpore eficacia a sus formularios comerciales...1 Amplíe el alcance de sus formularios comerciales...2

Más detalles

Tipos de comunicación La comunicación puede ser:

Tipos de comunicación La comunicación puede ser: Unidad 3. Procesos concurrentes 3.3 Semáforos (informática) Un semáforo es una variable especial (o tipo abstracto de datos) que constituye el método clásico para restringir o permitir el acceso a recursos

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2004-2005 Índice Introducción Tipos de servidores Ventajas Separación de funciones Modelos

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Utilidades de la base de datos

Utilidades de la base de datos Utilidades de la base de datos Desde esta opcion del menú de Access, podemos realizar las siguientes operaciones: Convertir Base de datos Compactar y reparar base de datos Administrador de tablas vinculadas

Más detalles

Configuración del acceso a Internet en una red

Configuración del acceso a Internet en una red Configuración del acceso a Internet en una red Contenido Descripción general 1 Opciones para conectar una red a Internet 2 Configuración del acceso a Internet utilizando un router 12 Configuración del

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

Más detalles

Práctica 5.1. Proyectos Access y SQL Server

Práctica 5.1. Proyectos Access y SQL Server Práctica 5.1. Proyectos Access y SQL Server 5.1.1. Introducción Desde la aparición de Microsoft Access 2000 es posible crear proyectos de Access. Los proyectos de Access ofrecen a los usuarios y programadores

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

MS_10747 Administering System Center 2012 Configuration Manager

MS_10747 Administering System Center 2012 Configuration Manager Administering System Center 2012 Configuration Manager www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso describe cómo

Más detalles

Hoja de datos: Virtualización de puntos finales Symantec Endpoint Virtualization Suite Optimización dinámica del espacio de trabajo

Hoja de datos: Virtualización de puntos finales Symantec Endpoint Virtualization Suite Optimización dinámica del espacio de trabajo Hoja de datos: Virtualización de puntos finales Optimización dinámica del espacio de trabajo Descripción general es una solución flexible y efectiva que se centra en la productividad del usuario, independientemente

Más detalles

Descripción General de Softengine Pinakes

Descripción General de Softengine Pinakes Descripción General de Softengine Pinakes Características de Softengine Pinakes. Pinakes es un sistema modular altamente configurable que tiene las siguientes características: Es amigable con el usuario.

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

INFRAESTRUCTURA TECNOLÓGICA Y SISTEMAS DE APOYO DEL EDN

INFRAESTRUCTURA TECNOLÓGICA Y SISTEMAS DE APOYO DEL EDN INFRAESTRUCTURA TECNOLÓGICA Y SISTEMAS DE APOYO DEL EDN Introducción La conectividad a Internet se ha convertido durante los últimos años en algo común en casi todas las empresas de Europa, incluyendo

Más detalles

Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada.

Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada. Tema 47. Las herramientas ofimáticas. Integración con sistemas de información estructurada. Esquema Introducción... 2 Historia... 2 Suites... 2 Herramientas ofimáticas... 3 Tipos de programas ofimáticos:...

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

Tema 2: EL MODELO CLIENTE/SERVIDOR Tema 2: EL MODELO CLIENTE/SERVIDOR E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Definición de sistemas cliente/servidor (1) En la arquitectura cliente/servidor: Los

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

Más detalles

Concepto de Procesamiento Distribuido y Centralizado

Concepto de Procesamiento Distribuido y Centralizado Concepto de Procesamiento Distribuido y Centralizado Procesamiento Centralizado: En la década de los años 50 s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

El servidor Web. Arquitectura y funcionamiento

El servidor Web. Arquitectura y funcionamiento El servidor Web. Arquitectura y funcionamiento ÍNDICE INTRODUCCIÓN Qué es un servidor? Y un servidor Web? FUNCIONAMIENTO DE UN SERVIDOR WEB Arquitectura Tipos de servidores Web Servidores basados en procesos

Más detalles

(Advanced Communications Function / Virtual Telecomunications Access Method) Función avanzada de comunicaciones/método virtual a telecomunicaciones

(Advanced Communications Function / Virtual Telecomunications Access Method) Función avanzada de comunicaciones/método virtual a telecomunicaciones Las arquitectura de red como la ISO, OSI, IBM SNA, DEC DNA, TCP/IP, estan diseñadas para mostrar la vista lógica de las comunicaciones de red independientes de la implementación física. El modelo OSI describe

Más detalles

Definición arquitectura cliente servidor

Definición arquitectura cliente servidor www.monografias.com Definición arquitectura cliente servidor 1. Introducción 2. Elementos principales 3. En resumen 4. Algunos antecedentes, Por qué fue creado? 5. Evolución de la arquitectura cliente

Más detalles

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 Módulo 1. Fundamentos de Computadores Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 1 CONTENIDO Tema 1. Introducción

Más detalles

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace 5. Internet 5.1. Qué es Internet? Internet es una red mundial de equipos que se comunican usando un lenguaje común. Es similar al sistema telefónico internacional: nadie posee ni controla todo el sistema,

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Capítulo 6: Instrumentación: Diseño del Sistema de H2O

Capítulo 6: Instrumentación: Diseño del Sistema de H2O Capítulo 6: Instrumentación: Diseño del Sistema de H2O Digital Media Server El video en demanda a través del web aún está restringido a las grandes empresas que pueden pagar por contar por un servicio

Más detalles

Capítulo 5. Implementación y Tecnologías Utilizadas

Capítulo 5. Implementación y Tecnologías Utilizadas Capítulo 5. Implementación y Tecnologías Utilizadas Cada vez más, se está utilizando Flash para desarrollar aplicaciones basadas en Web, pues permite la construcción de ambientes con mayor interacción.

Más detalles

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web 2 SERVIDOR En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los usuarios.

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY)

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIA Y TECNOLOGIA MAESTRIA CIENCIA DE LA COMPUTACION MENCION REDES DE COMPUTADORAS INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA

Más detalles

GENERALIDADES DE LA COMUNICACIÓN DE DATOS

GENERALIDADES DE LA COMUNICACIÓN DE DATOS Comunicaciones I Capítulo 1 GENERALIDADES DE LA COMUNICACIÓN DE DATOS 1 El Sistema de Comunicación Sistema de comunicación: Lleva a cabo el intercambio de información entre dos entes ubicados en los extremos

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

Más detalles

CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO.

CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO. CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO. Competencias a desarrollar: Conocer la importancia de la estandarización en redes de datos. Identificar los estándares. Saber los tipos de

Más detalles

Indice 1. Introducción a la computación en nube (cloud computing)

Indice 1. Introducción a la computación en nube (cloud computing) Tema 9. Centros de datos: computación en nube y organización física Indice 1. Introducción a la computación en nube (cloud computing) 2. Virtualización de recursos: consolidación de servidores 3. Arquitectura

Más detalles

UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ

UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ El programa base fundamental de todos los programas de sistema, es el Sistema Operativo, que controla todos los recursos de la computadora y proporciona

Más detalles

Aplicaciones Distribuidas. Informática III

Aplicaciones Distribuidas. Informática III Aplicaciones Distribuidas Informática III Temario Elementos arquitecturales Arquitecturas tradicionales Arquitecturas Cliente/Servidor Arquitecturas distribuidas Elementos Arquitecturales Componentes de

Más detalles

CAPÍTULO 3 VISUAL BASIC

CAPÍTULO 3 VISUAL BASIC CAPÍTULO 3 VISUAL BASIC 3.1 Visual Basic Microsoft Visual Basic es la actual y mejor representación del viejo lenguaje BASIC, le proporciona un sistema completo para el desarrollo de aplicaciones para

Más detalles

Estrategia de cluster: Alta disponibilidad y capacidad de escalación con hardware estándar en la industria.

Estrategia de cluster: Alta disponibilidad y capacidad de escalación con hardware estándar en la industria. Windows NT Sistema operativo de servidor Server Estrategia de cluster: Alta disponibilidad y capacidad de escalación con hardware estándar en la industria. Bajado desde www.softdownload.com.ar Resumen

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI.

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI. 3.1 Modelo de referencia OSI. Durante las últimas dos décadas ha habido un enorme crecimiento en la cantidad y tamaño de las redes. Muchas de ellas sin embargo, se desarrollaron utilizando implementaciones

Más detalles

XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS. La Habana, Cuba, 26 al 30 de octubre de 1998

XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS. La Habana, Cuba, 26 al 30 de octubre de 1998 XXVI REUNION DE SISTEMATIZACION DE BANCOS CENTRALES AMERICANOS E IBERICOS La Habana, Cuba, 26 al 30 de octubre de 1998 CONTENIDO PROYECTO DE SISTEMA INFORMATIVO PARA EL BANCO CENTRAL DE CUBA Autor: Ing.

Más detalles

AcuServer Servidor de Archivos Remoto de Alto Rendimiento

AcuServer Servidor de Archivos Remoto de Alto Rendimiento AcuServer Servidor de Archivos Remoto de Alto Rendimiento RESUMEN EJECUTIVO AcuServer es una tecnología de servidor de datos remoto que ofrece un seguro e inmediato acceso a datos indexados, relativos

Más detalles

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES SISTEMAS DISTRIBUIDOS DE REDES 5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES Programación remota: Introducción y generalidades INTRODUCCIÓN Debido a la dificultad de la arquitectura actual

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles