tesis - Instituto Politécnico Nacional

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA
UNIDAD PROFESIONAL “ADOLFO LÓPEZ MATEOS”
“DISEÑO Y CONSTRUCCIÓN DE UN SISTEMA DE
NOTIFICACIONES PARA EL CONTROL DEL
ESTÁTUS ACADÉMICO ESTUDIANTIL”
T E S I S
QUE PARA OBTENER EL TÍTULO DE:
INGENIERO EN COMUNICACIONES Y ELECTRONICA
PRESENTAN:
CARLOS ALBERTO MANCILLA FLORES
RAMÓN RIVERA CAMACHO
ASESOR:
ING. JUANITA NANCY MONDRAGON MEDINA
MÉXICO, D.F. 2012
Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Índice general
Índice de figuras y tablas. ................................................................................................................ vi Figuras ............................................................................................................................................. vi Tablas ............................................................................................................................................ viii Lista de abreviaturas. ...................................................................................................................... ix Objetivos. ......................................................................................................................................... xii Objetivo general. ............................................................................................................................ xii Objetivos particulares. .................................................................................................................... xii Justificación ..................................................................................................................................... xii Introducción.................................................................................................................................... xiv Capítulo I. Estado de arte. ................................................................................................................ 1 Referencias .................................................................................................................................... 10 Capítulo II. Enfoque teórico. .......................................................................................................... 11 2.1. El modelo OSI. .................................................................................................................. 11 2.2. Capas del modelo OSI ....................................................................................................... 12 2.3. Perspectiva en base al modelo OSI. .................................................................................. 19 2.3.1. Interacción del usuario con la capa de aplicación. .................................................... 19 2.3.2. Capa de aplicación. El protocolo HTTP .................................................................... 21 2.3.2.1. Mensaje HTTP ...................................................................................................... 22 2.3.2.2. Métodos HTTP ...................................................................................................... 24 2.3.3. Formateo de tipos. MIME e IMT .............................................................................. 25 2.3.4. Llamada a procedimientos remotos. El protocolo RPC. ........................................... 28 2.3.5. El protocolo de transporte. TCP ................................................................................ 31 2.3.6. El protocolo de internet. ............................................................................................ 37 Índice general iii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.3.7. 2.4. Enlace de datos y medio físico. ................................................................................. 41 Comunicación en el protocolo de transporte ..................................................................... 42 2.4.1. Sockets de comunicación. ......................................................................................... 44 Referencias. ................................................................................................................................... 47 Capítulo III. Enfoque práctico. ...................................................................................................... 48 3.1. Los lenguajes de programación. ........................................................................................ 49 3.1.1. La aplicación del lado del servidor, C#. .................................................................... 50 El cuadro de trabajo .Net. ...................................................................................... 50 3.1.1.1. 3.1.2. El trabajo del lado del cliente, Java. .......................................................................... 52 3.1.3. La construcción de la base de datos, SQL. ................................................................ 54 3.1.3.1. 3.2. Acceso a base de Datos. ........................................................................................ 55 La página de hospedaje. .................................................................................................... 57 3.2.1. HTML (HyperText Markup Language) .................................................................... 57 3.2.2. IIS (Internet Information Services). .......................................................................... 58 3.3. La aplicación de actualización. ......................................................................................... 59 3.3.1. Diferencias entre las arquitecturas REST y SOA ...................................................... 60 3.3.2. Web Service REST-WCF .......................................................................................... 65 3.3.3. Serializado del mensaje. ............................................................................................ 67 3.4. La aplicación cliente. ......................................................................................................... 69 3.4.1. Arquitectura del consumidor ..................................................................................... 69 3.4.2. Proceso de consumo .................................................................................................. 72 3.4.3. Presentación de la información ................................................................................. 74 Referencias .................................................................................................................................... 79 Capítulo IV. La aplicación CEM ................................................................................................... 80 4.1. Los entornos de desarrollo ................................................................................................ 81 4.1.1. Microsoft Visual Studio ............................................................................................ 82 4.1.2. Eclipse ....................................................................................................................... 84 4.1.3. Administrador de Base de Datos, SQL Server Management Studio ......................... 85 4.2. Arquitectura de diseño. ..................................................................................................... 88 4.3. Las plataformas. ................................................................................................................ 92 Índice general iv Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.4. Los productos. ................................................................................................................... 96 4.4.1. La descarga de la aplicación. ..................................................................................... 97 4.4.2. Portal de administrador CEM. ................................................................................... 98 4.4.3. Servicio de actualización. ........................................................................................ 101 4.4.4. Aplicación cliente. ................................................................................................... 102 4.5. Costos relacionados con la aplicación CEM. .................................................................. 105 4.5.1. Costos de desarrollo de la aplicación CEM. ............................................................ 105 4.5.2. Costos de implementación de la aplicación CEM. .................................................. 108 4.5.3. Costos finales del sistema ....................................................................................... 115 4.6. Trabajo futuro relacionado con la aplicación CEM. ....................................................... 116 Referencias .................................................................................................................................. 118 Conclusiones .................................................................................................................................. 119 Apéndices ....................................................................................................................................... xvii Apéndice A. Códigos de estatus del protocolo HTTP. ................................................................. xvii Apéndice B. Manejo de sockets de red. ....................................................................................... xxii Índice general v Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Índice de figuras y tablas.
Figuras
1.1. Pantalla de trabajo de MS-DOS ........................................................................................................... 4
1.2. Diagrama esquemático de la arquitectura de la tecnología GSM ....................................................... 6
1.3. Tareas a desempeñar por parte de los componentes de la aplicación ................................................. 8
2.1. Modelo de comunicación por niveles o capas ................................................................................... 13
2.2. Comunicación por medio del modelo de referencia OSI .................................................................. 17
2.3. Trayectoria de la comunicación en el modelo OSI ........................................................................... 18
2.4. Diagrama del proceso de compilación y ensamble de un programa escrito en lenguaje de alto nivel
compilado ................................................................................................................................................. 20
2.5. Formato general de los mensajes de petición y respuesta del protocolo HTTP ................................. 22
2.6. Formato de la línea de petición en el protocolo HTTP ..................................................................... 23
2.7. Formato de la línea de estatus es un mensaje de respuesta del protocolo HTTP .............................. 24
2.8. Sentencia que indica el tipo de contenido MIME ............................................................................. 28
2.9. Diagrama de comunicación a través del protocolo RPC ................................................................... 29
2.10. Establecimiento de una conexión en el protocolo TCP por medio del proceso Three-Way
Handshake ................................................................................................................................................ 32
2.11. Proceso de transferencia de información sobre el protocolo TCP .................................................. 33
2.12. Diagrama esquemático de término de conexión TCP ..................................................................... 34
2.13. Diagrama de conexión fiable extremo a extremo en TCP .............................................................. 35
2.14. Segmento de información del protocolo TCP ................................................................................. 35
2.15. Familia de protocolos de internet .................................................................................................... 37
2.16. Paquete de información del protocolo IP ........................................................................................ 39
2.17. Registro correspondiente al campo de tipo de servicio ................................................................... 39
2.18. Propósito de los puertos del protocolo TCP .................................................................................... 42
2.19. Diagrama esquemático del apilamiento de peticiones a través de puertos TCP ............................. 43
2.20. Formato de un socket de comunicación red .................................................................................... 44
3.1. Diagrama esquemático del sistema CEM ......................................................................................... 48
3.2. Proceso de compilado bajo la tecnología .Net .................................................................................. 52
3.3. Diagrama de compilado de un programa con uso de la JVM ........................................................... 54
Índice de figuras
vi Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
3.4. Relación entre componentes de un Web-Service .............................................................................. 60
3.5. Diferencias entre las arquitecturas REST y SOA para el manejo del protocolo HTTP .................... 63
3.6. Comunicación basada en una arquitectura con estado ...................................................................... 63
3.7. Comunicación basada en una arquitectura sin estado ....................................................................... 64
3.8. Proceso de modelado de un servicio web ......................................................................................... 66
3.9. Formato de invocación de servicio web ............................................................................................ 67
3.10. Estructuras de serializado/deserializado en JSON .......................................................................... 68
3.11. Diagrama a bloques de la arquitectura del sistema Android ........................................................... 71
3.12. Tareas del consumidor de un servicio web ..................................................................................... 72
3.13. Procedimiento de consumo de un servicio web .............................................................................. 73
3.14. Prioridad de actividad del sistema operativo Android .................................................................... 75
3.15. Modelo del objeto LinearLayout ..................................................................................................... 76
3.16. Modelo del objeto TableLayout ...................................................................................................... 76
3.17. Diagrama esquemático del tratamiento de información en el sistema Android .............................. 77
4.1. Modelo completo del sistema de notificaciones CEM ...................................................................... 81
4.2. Pantalla de inicio del IDE de programación Visual Studio en su versión 2008 ................................. 83
4.3. Pantalla inicial del IDE Eclipse ........................................................................................................ 85
4.4. Pantalla demostrativa del entorno SQL Server Management Studio ................................................ 88
4.5. Arquitectura en capas de los componentes del sistema CEM ........................................................... 90
4.6. Instalación del servicio CEM ............................................................................................................ 92
4.7. Instalación de la aplicación de escritorio CEM ................................................................................. 93
4.8. Instalado de la aplicación CEM ........................................................................................................ 94
4.9. Pantalla de activación de características de Windows 7 .................................................................... 94
4.10. Pantalla de confirmación de la correcta instalación del servidor web IIS 7 .................................... 95
4.11. Proceso para crear la excepción en el firewall para la intercomunicación con el servicio web ...... 95
4.12. Instalación del portal CEM ............................................................................................................. 96
4.13. Página de descarga de la aplicación CEM ...................................................................................... 97
4.14. Pantalla de login de la aplicación de administrador CEM .............................................................. 98
4.15. Pantalla correspondiente al logueo de un usuario administrador .................................................... 99
4.16. Alta de alumno y relacionado con el tutor correspondiente ............................................................ 99
4.17. Pantalla de mensajes ..................................................................................................................... 100
4.18. Apariencia de la aplicación proveedora del servicio de actualización del sistema CEM .............. 101
4.19. Pantalla de inicio de la aplicación CEM ....................................................................................... 102
4.20. Pantalla de sincronización de mensajes generales ........................................................................ 103
4.21. Pantalla de sincronización de mensajes personales. ..................................................................... 103
Índice de figuras
vii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.22. Pantalla de visualización de calificaciones ................................................................................... 104
4.23. Pantalla de preferencias ................................................................................................................ 104
4.24. Pantalla para asociar un nuevo alumno al tutor ............................................................................ 105
4.25. Resumen de resultados para pruebas de carga para una petición de mensajes personales, grupales y
de escuela del servicio CEM .................................................................................................................. 111
4.26. Diagrama esquemático del sistema CEM después de consideraciones futuras.............................. 117
B.1. Estructura del argumento localAddr .............................................................................................. xxiii
Tablas
Tabla 2.1. Capas de modelo OSI .............................................................................................................. 13
Tabla 2.2 Valor decimal y hexadecimal de algunos de los protocolos más utilizados en el protocolo de
Internet ..................................................................................................................................................... 40
Tabla 3.1 Comparación de las arquitecturas de servicios web REST y SOA .......................................... 62
Tabla 4.1 Costo de licencias para el desarrollo del sistema CEM .......................................................... 106
Tabla 4.2 Especificaciones del equipo de pruebas .................................................................................. 110
Tabla 4.3 Comparación de rendimiento entre procesadores i3-2100 e i5-2500 ...................................... 112
Tabla 4.4 Especificaciones del servidor para implementación ............................................................... 112
Tabla 4.5 Costos de implementación del sistema CEM .......................................................................... 114
Tabla 4.6 Desglose de costos finales del sistema CEM .......................................................................... 115
Tabla A.1 Grupos de códigos informacionales del protocolo HTTP ...................................................... xvii
Índice de figuras
viii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Lista de abreviaturas.
3GPP - 3rd Generation Partnership Project, Proyecto Asociación de Tercera Generación.
ADO - ActiveX Data Objects, Objetos de Datos ActiveX.
API - Application Programming Interface, Interfaz de Programación de Aplicaciones.
ARPANET - Advanced Research Projects Agency Network, Red de la Agencia de Proyectos de
Investigación Avanzada.
ASP - Active Server Pages, Páginas Activas de Servidor.
CDMA - Code Division Multiple Access, Multiplexaje por División de Código.
CEM - Control de Estudiantes Móvil.
COM – Component Object Model, Modelado de Objetos de Componentes.
CIL - Common Intermediate Language, Lenguaje Común Intermediario.
CLR - Common Language Runtime, Entorno en Tiempo de Ejecución de Lenguaje Común.
DBMS - Database Management System, Sistema de Gestión de Bases de Datos.
DHCP - Dynamic Host Configuration Protocol - Protocolo de Configuración Dinámica de Host.
DNS - Domain Name System, Sistema de Nombres de Dominio.
DSN – Data Source Name, Nombre de Fuente de Datos.
DVM – Dalvik Virtual Machine, Máquina Vitual Dalvik.
EDGE - Enhanced Data Rates GSM of Evolution, Tasas de Datos Mejoradas para la evolución de
GSM.
FDMA - - Frequency Division Multiple Access, Acceso Múltiple por División de Frecuencia..
FORTRAN - Formula Translating System, Sistema de Traducción de Fórmula.
FTP - File Transfer Protocol, Protocolo de Transferencia de Archivos.
GPRS - General Packet Radio Service, Servicio General de Paquetes Vía Radio.
GSM - Global System for Mobile Communications, Sistema Global para las Comunicaciones Móviles.
HSPA - High-Speed Packet Access, Acceso de Paquetes de Alta Velocidad.
HTML - HyperText Markup Language, Lenguaje de Marcado de Hipertexto.
Lista de abreviaturas y términos ix Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
HTTP - Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto.
HTTPR - Reliable Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto Confiable.
HTTPS - Hyper Text Transfer Protocol Secure, Protocolo Seguro de Transferencia de Hipertexto.
IDE - Integrated Development Environment, Entorno de Desarrollo Integrado.
IIS - Internet Information Services, Servicios de Información de Internet.
IMT - Intenet Media Type, Tipo de Medio de Internet.
IP - Internet Protocol, Protocolo de Internet.
ISO - International Organization for Standardization, Organización Internacional para la
Estandarización.
JSON - JavaScript Object Notation, Notación de Objetos de JavaScript.
JSP - JavaServer Pages, Páginas de Servidor de Java.
JVM - Java Virtual Machine, Máquina Virtual de Java.
LTE - Long Term Evolution, Evolución de Término Largo.
MIME - Multipurpose Internet Mail Extensions, Extensiones Multipropósito de Correo de Internet.
MS-DOS - Microsoft Disk Operating System, Sistema Operativo de Disco de Microsoft.
NAT - Network Address Translation, Traducción de Dirección de Red.
NPC – Network Control Protocol, Protocolo de Control de Red.
ODBC - Open DataBase Connectivity, Conectividad Abierta a Base de Datos.
OLE DB - Object Linking and Embedding for Databases, Enlace e incrustación de objetos para bases
de datos.
OSI - Open System Interconnection, Modelo de Interconexión de Sistemas Abiertos.
PC - Personal Computer, Computadora Personal.
POP - Post Office Protocol, Protocolo de Oficina de CorreO.
ROA - Resource Oriented Architecture, Arquitectura Orientada a Recursos.
REST - REpresentational State Transfer, Transferencia de Estado Representacional.
RPC - Remote Procedure Call, Llamada a Procedimiento Remoto.
SDK - Software Development Kit, Kit de Desarrollo de Software.
SMTP - Simple Mail Transfer Protocol, Protocolo Simple de Transferencia de Correo.
Lista de abreviaturas y términos x Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
SOA - Service Oriented Architecture, Arquitectura Orientada a Servicios.
SOAP - Simple Object Access Protocol, Protocolo de Acceso Simple a Objetos.
SQL - Structured Query Language, Lenguaje de Consulta Estructurad.
SSL - Secure Socket Layer, Capa de Conexión Segura.
TCP - Transmission Control Protocol, Protocolo de Control de Transmisión.
TDMA - Time Division Multiple Access, Acceso Múltiple por División de Tiempo
T-SQL - Transact- Structured Query Language, Lenguaje de Consulta Estructurado Transaccional.
UDP - User Datagram Protocol, Protocolo de Datagramas de Usuario.
URI - Uniform Resource Identifier, Identificador Uniforme de Recurso.
URL - Uniform Resource Locator, Localizador de Recursos Uniforme.
URN - Uniform Resource Name, Nombre de Recurso Uniforme.
UTP - Unshielded Twisted Pair, Par Ttrenzado No Blindado.
WCF - Windows Communication Foundation.
WSDL - Web Services Description Language, Lenguaje de Descripción de Servicios Web.
XML - eXtensible Markup Language, Lenguaje de Marcado Extensible.
XML-RPC
eXtensible Markup Language- Remote Procedure Call, Lenguaje de Marcado
Extensible sobre el protocolo RPC.
Lista de abreviaturas y términos xi Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Objetivos.
Objetivo general.
•
Diseñar un sistema capaz de notificar al padre o tutor en su teléfono móvil del
estatus escolar e información relevante del alumno
Objetivos particulares.
El diseño y desarrollo de este sistema persigue los siguientes objetivos particulares:
•
Establecer el preámbulo histórico que hizo capaz el desarrollo de la aplicación de
notificaciones.
•
Presentar el enfoque teórico para el tratamiento de la comunicación de la
aplicación, lo que comprende el modelo de trabajo y las bases y protocolos
utilizados para dicha intercomunicación.
•
Mostrar las tecnologías utilizadas dentro de un ambiente real de producción y que
fueron utilizadas en la construcción del sistema de control, además de presentar un
panorama general de la aplicación en sí.
•
Describir el funcionamiento de los productos desarrollados además de los costos
típicos de implementación de dicho sistema.
Justificación
La demanda de la sociedad por mecanismos que la mantengan interconectada se ha
incrementado rápidamente en los últimos años. La aparente necesidad por estar
comunicados los unos con los otros genera métodos cada vez más complejos con el único
fin de saciar esta necesidad, ya no basta solamente con consultar la información importante
en el ordenador personal, principalmente este comportamiento puede atribuirse al ajetreado
ritmo de la vida.
Objetivo xii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Actualmente el dispositivo con el que virtualmente toda persona cuenta es el teléfono
celular, desde ya hace varias décadas ha satisfecho las necesidades de comunicación entre
las personas, así que no fue extraño cuando se mostraron por primera vez los celulares
multitareas capaces de almacenar aquella información importante del usuario y conectarse
con sus pares de manera indirecta.
La infraestructura moderna capaz de servir la demanda de usuarios y utilizando técnicas
para hacerlo de manera eficiente, influyó también en la evolución de estos mecanismos de
comunicación.
Hay cientos de miles de aplicaciones que residen en teléfonos inteligentes que van desde
aquellas enfocadas a la mera diversión hasta las que se dedican al incremento de la
productividad y de la comunicación entre los usuarios y que se comunican por la misma
infraestructura de los ordenadores convencionales.
Por lo antes explicado se decide tomar el enfoque de comunicación entre la información
relevante de un alumno como propósito principal del desarrollo de este trabajo de tesis. La
idea formal de este trabajo es el desarrollo de una aplicación capaz de poder notificar al
usuario, es decir, el padre de familia o tutor, acerca de los puntos relevantes acerca de la
escuela del alumno o incluso de este mismo.
Esta aplicación describe un sistema de notificaciones para el usuario que se actualiza ya
sea a demanda o dependiendo del tiempo configurado, con esto se intenta satisfacer la
necesidad del tutor de estar al tanto del alumno.
Objetivo xiii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Introducción.
En el siguiente trabajo se presentarán los fundamentos teóricos e históricos de la evolución
de los dispositivos, sistemas y estándares que componen una aplicación de interconexión,
además, se mostrarán las tecnologías con que puede desarrollarse una de ellas en la
actualidad para finalizar con un conjunto de herramientas y entornos para el desarrollo.
Toda esta explicación se realizará con el fin de crear un panorama para entender el
funcionamiento de una aplicación de interconexión llevada a un ámbito real.
El sistema de interconexión propuesto es la aplicación de notificaciones CEM (Control de
estudiantes móvil), a grandes rasgos, este sistema toma datos relevantes –desde lo que se
considera relevante basados en el punto de vista de un padre de familia-, los almacena de
manera permanente, publica los métodos necesarios para la consulta de la información y
finalmente los entrega a un dispositivo móvil que cuente con conexión a internet a
demanda de este último.
El presente trabajo representa el desarrollo de una aplicación de interconexión entre
sistemas a través de un servicio web. Este trabajo se encuentra dividido en cuatro capítulos
que abarcan el marco histórico de las tecnologías, así como su evolución con respecto al
tiempo, los antecedentes teóricos de estás misma tecnologías así como su tratado práctico
en un ambiente real y por último el desarrollo de la aplicación.
En el primer capítulo del presente se tomará una postura histórica de los componentes y
tecnologías de interconexión, así como su desarrollo a través de tiempo, además la
vinculación de cada uno de estos, se finalizará mostrando un pequeño preámbulo que dará
cabida al tratamiento teórico de la aplicación propuesta explicando brevemente su
funcionamiento.
El segundo capítulo comprende lo relacionado a las bases teóricas para el desarrollo de la
aplicación. La disposición de este capítulo muestra en una primera instancia el marco de
referencia que debe respetar la aplicación en cada uno de los niveles de conexión y
Introducción xiv Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
presentación al usuario, esto se hace de dos maneras: primero, explicando la referencia de
interconexión de sistemas abiertos (OSI) para cada una de las capas y segundo,
presentando el funcionamiento de la aplicación propuesta en cada uno de estos niveles, en
cada una de estas capas, estará presente la tecnología que la aplicación utiliza. En la
sección final de este capítulo se describirá el método de conexión entre aplicaciones o
procesos a través del protocolo TCP, haciendo especial hincapié en la comunicación por
medio de sockets, precursor del método de exposición y consumo de la aplicación a
desarrollar. El propósito de este capítulo es dar una perspectiva de los fundamentos
teóricos de las tecnologías y productos con los cuáles se desarrolló dicha aplicación.
Existen varias tecnologías propietarias y de uso libre en el mercado que tienen como fin el
manejo de los protocolos y lenguajes de programación que dan vida a una aplicación
desarrollada por terceros. El tercer capítulo trata específicamente de estas tecnologías. El
enfoque para este capítulo está dividido en dos ámbitos. El primero de ellos intenta
explicar la arquitectura de la aplicación, dividida en tres secciones.
•
La aplicación cliente. Encargada de obtener y presentar al usuario de ésta la
información pedida.
•
La aplicación proveedora. Cuya tarea es recolectar la información perteneciente al
usuario, corroborar su correcta transferencia y modificar a demanda del usuario.
•
La página de descarga. Muestra de una manera agradable al usuario la forma de
trabajo de la aplicación además de permitir la descarga de ésta.
El segundo propósito de este capítulo es el describir la forma de trabajo de las tecnologías
utilizadas para el desarrollo de la aplicación, a grandes rasgos, se mostrará el principio
básico de los servicios web y de su exposición así como las diferencias entre arquitecturas
de enfoque, el sistema que se encargará del mostrado y almacenaje de la información
provista, un teléfono celular inteligente con sistema operativo Android, además, el
hospedaje y básico funcionamiento de la página que permite la descarga de la aplicación,
desde el punto de vista del caso específico de la aplicación desarrollada.
Introducción xv Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
El cuarto y último capítulo se refiere a los productos utilizados para el desarrollo de la
aplicación, estos corresponden al sistema que proveerá el servicio, el que lo consumirá, los
entornos utilizados para dicho fin, incluyendo los gestores de bases de datos para el
almacenaje de la aplicación. También se mostrará la instalación de ambas aplicaciones y la
publicación de la página desde donde la aplicación puede ser accesada. También se
muestran los resultados finales de trabajo, para cada una de las secciones de la aplicación
planteada así como la comunicación entre ambos. Finalmente se hará una comparación con
otro software similar en cuanto a funcionamiento y prestaciones para terminar con lo
referente a la implementación para dicha aplicación, se mostrarán también los productos
necesarios para dicha tarea y el estimado de precio.
El tratado de este documento se considera íntegro para la implementación y entendimiento,
tanto práctico como teórico, de una aplicación cuyo fin es mantener en tanto de
información relevante al usuario por medio de notificaciones, en este caso en particular la
aplicación de control de estudiantes móvil (CEM).
Introducción xvi Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Capítulo I. Estado de arte.
Antes de iniciar con cualquier tipo de explicación con respecto al trabajo de una aplicación
de interconexión, es pertinente hacer un perfil histórico. Una pregunta fundamental que
suele hacerse es acerca de la reflexión de la historia o los antecedentes de lo tratado o en sí
mismo porque remontarse a conceptos antiguos si se pueden utilizar más modernos y
supuestamente más avanzados. Parafraseando, frecuentemente sucede que un cambio en la
tecnología deja obsoleta alguna idea que inmediatamente a continuación desaparece. Sin
embargo, otro cambio en la tecnología podría hacer que esa idea repentinamente volviera a
estar vigente [1]. Este capítulo se enfoca específicamente a este tratado la evolución de los
sistemas, conceptos y componentes que le dan vida a la aplicación a desarrollar, lo cual nos
situará dentro del ámbito actual de desarrollo.
La primera computadora conocida apareció en el año de 1941, como una máquina
experimental, era un aparato que consumía grandes cantidades de potencia y tenía un peso
de algunas toneladas también, principalmente se inventó con el afán de agilizar las
operaciones matemáticas rutinarias. Para esta época se contaba con tecnología de tubos de
vacío, éstos funcionaban como amplificadores y conmutadores, mismos que eran utilizados
para gran parte de los dispositivos de la primera mitad del siglo XX. Las válvulas
termoiónicas –como también eran nombradas- dieron cabida a la producción en masa de
televisores, radios y también a los ordenadores de primera generación.
La primera generación de computadoras, que abarca desde 1945 a 1955, carecía de
lenguajes de programación y software de control, como el sistema operativo. Eran
controladas por medio de tableros de conexión y en las últimas etapas de esta generación
por tarjetas perforadas donde se escribía el programa en lenguaje que la máquina podía leer
y realizar la rutina.
Capítulo I. Estado del arte
1 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La invención del transistor 19471 y su posterior distribución a mediados de la década de los
50s dio como resultado la segunda generación de computadoras (1965 - 1980) las cuales se
volvieron más confiables, redujeron su tamaño, además de poder tener la confianza de que
durarían lo suficiente para completar la tarea necesaria, debido al reemplazo de los tubos
de vacío por dichos componentes. Estas computadoras se alojaban en salas especialmente
acondicionadas y eran muy costosas, estas máquinas ahora son conocidas como
mainframes que solo se encontraban en agencias de gobierno, grandes corporaciones y
algunas universidades. Es en estos mainframes donde encontramos por primera vez la
noción de dos conceptos muy importantes en la actualidad, la interconexión y la
programación.
Los inicios de la intercomunicación entre computadoras se remontan a inicios de la década
de los 60s con la arquitectura punto a punto2 entre los mainframes y las terminales,
también, en estos mainframes era posible ejecutar rutinas de programación, las cuales eran
grabadas en tarjetas perforadas, mismas que eran desarrolladas en papel y luego
transcodificadas ya sea a un el primer lenguaje de alto nivel, FORTRAN o al mismo
lenguaje ensamblador, el proceso de la ejecución de los programas necesitaba una
constante intervención del hombre, insertando las tarjetas para la ejecución, si era
necesario un proceso de compilación también insertando dichas tarjetas a la máquina, etc.,
este proceso conllevaba una gran pérdida de tiempo. Es por ello que al término de esta
segunda generación, con el afán de reducir el tiempo desperdiciado se adopta el sistema de
procesamiento por lotes en la cual se tomaba una gran cantidad de trabajos que se
procesaban con equipos “baratos” que eran eficientes para la lectura y copiado de la
información pero ineficaces para los cálculos aritméticos, cuya tarea era traducir y
reescribir los trabajos en cintas magnéticas, para después insertar la cinta con todos los
trabajo para realizar los cálculos y la tarea en sí en máquinas más caras y con mayor
1
Inventado en diciembre de 1947, por John Bardeen, Walter Houser Brattain y William Bradford
Shockley, sustituyo a la válvula termoiónica. Poco después se inventó el transistor de efecto de campo, el cuál
no pudo producirse en masa sino hasta la década de los 80s. 2
Esta arquitectura de conexión se refiere a la conexión directa entre dos nodos o terminales, en los inicios no
tenía formateo de paquete así que ambos nodos tenían la responsabilidad del formateo de la información antes
del envío.
Capítulo I. Estado del arte
2 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
potencia para los cálculos, una vez terminado, el trabajo se regresaba a una máquina
pequeña para la tarea de impresión.
El desarrollo del primer circuito integrado en 19593 y su popularización a mediados de los
60s dan cabida a la tercera generación de ordenadores, con un periodo comprendido entre
1965 a 1980. En esta época se tenían principalmente dos sectores de consumo los
ordenadores más grandes y caros, orientados a cálculos complejos utilizados en la ciencia y
la ingeniería y aquellos más pequeños orientados a palabras principalmente utilizados en
bancos y compañías, esto se traducía en un gran costo de las compañías dedicadas a la
producción de estos, ya que tenían que mantener dos sectores distintos. Un intento por
resolver este problema fue el realizar series de máquinas compatibles entre sí, ya que las
máquinas compartían las arquitecturas e instrucciones con lo que se trataba de satisfacer a
todos los clientes, estas series de ordenadores eran notablemente más baratas y más
potentes con respecto a sus pares de segunda generación. También en este periodo de
tiempo encontramos el desarrollo de las redes basadas en la conmutación de paquetes,
entre ellas ARPANET, en algún punto entre 1960 y 1970, como un proyecto de
comunicación a encargo del departamento de defensa de los Estados Unidos, en esta está
inspirado el desarrollo de lo que actualmente conocemos como Internet ya que describía la
interconexión de redes a través de redes.
Con el paulatino avance de los circuitos, aumentando el nivel de integración, contando con
cada vez más transistores4, las computadores continuaban reduciendo su tamaño, para
inicios de la década de los 80s esta ventaja permitió la invención de los microordenadores,
nombrados así en dicha época, lo que se conoce hasta estos momentos como ordenador
personal (a.k.a. PC, de las siglas, Personal Computer), la diferencia en cuanto a potencia de
3
Desarrollado por el ingeniero Jack Kilby para firma Texas Instruments, era un dispositivo que integraba seis
transistores. 4
Para la década de 1980 se implementaban circuitos con un gran nivel de integración (LSI), en la actualidad
este nivel de integración se ha incrementado notablemente hasta más de un millón de transistores. La
clasificación actual de integración para circuitos integrados comprende seis categorías: Pequeño nivel de
integración (SSI) con 10 a 100 transistores, nivel medio de integración (MSI) – 101 a 1000 transistores, gran
nivel de integración (LSI) – 1 001 a 10 000 transistores, nivel de integración muy grande (VLSI) – 10 001 a
100 000 transistores, ultra grande nivel de integración (ULSI) – 100 001 a 1 000 000 de transistores y
finalmente el nivel de integración giga grande (GLSI) con más de un millón de transistores. Este crecimiento
corresponde a la ley de moore que indica que el número de transistores se duplica aproximadamente cada 18
meses.
Capítulo I. Estado del arte
3 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
un ordenador de tercera generación no era muy notable, en cambio sí lo era su precio, lo
cual los volvía asequibles para las personas, en su hogar, en lugar de solo estar confinados
a compañías y universidades.
Cuando IBM diseño la PC, necesitó un software para controlar la misma máquina provisto
por Microsoft MS-DOS, una versión con pocas modificaciones del sistema operativo DOS
de la SCP (Seattle computer products), lo que da cabida a lo que la mayoría de las personas
conoce como sistema operativo5, una pantalla típica de trabajo de este sistema operativo se
muestra en la figura 1.1.
Figura 1.1 – Pantalla de trabajo de MS-DOS.
Además, con el hecho de la creciente en el número de ordenadores, también apareció la
necesidad de interconectarlos mutuamente, a mediados de los 80s se muestra una tendencia
creciente a la ejecución de los sistemas operativos en red, cuya característica era que
además de tener las funciones básicas, adjuntar un control de interfaz de red y software
5
Se refiere al sistema operativo de un ordenador personal, aunque la primera aparición de un sistema
operativo, fue de manera simple, con programas monitores residentes dedicados a leer el programa de una
cinta magnética o tarjeta perforada y cargarlos para su ejecución. Otra aproximación al uso de un sistema
operativo es el concepto de multiprogramación y tiempo compartido, donde se cede el tiempo de CPU a otros
usuarios y programas. La primera noción de un sistema operativo formal fue concebida con el desarrollo de
1964 de MULTICS terminado años después, era un proyecto colaboración de General Electric y los
laboratorios Bell, no tuvo mucho auge pero se tomaron muchas ideas base de este sistema. Capítulo I. Estado del arte
4 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
para el inicio de sesión en otros equipos con el fin de la obtención de ficheros en la
máquina remota.
Esta comunicación fue posible debido al desarrollo del antiguo protocolo en el cuál estaba
basada la intercomunicación de la red ARPANET, NPC (Network Control Protocol) para
el año de 1982, estas bases se habían solidificado para crear el conjunto de protocolos de
internet, TCP/IP, proliferando la presencia de los proveedores de internet en esta misma
década, y antes del término de la misma volverse global.
A la par, pero en otra rama de la ingeniería se perfeccionaba un invento que data de la
época de la segunda guerra mundial, el teléfono móvil, creado por Motorola era un
dispositivo que se valía de las ondas de radio, con el fin de mantener en constante
comunicación a las tropas, las frecuencias de operación que no sobrepasaban los 60 MHz.
La invención del primer teléfono móvil –completamente portable6- se remonta al año de
1983, eran teléfonos analógicos cuya función única era el realizar llamadas de usuarios.
La segunda generación de teléfonos móviles se da a partir de 1990, ya que las
radiocomunicaciones se habían digitalizado, estos teléfonos accesaban al medio basándose
en división por tiempo o por código, TDMA y CDMA, respectivamente. El medio digital
permitía, además de la mejora en servicios ya existentes, como mayor capacidad de
usuarios y la disminución en potencia de las emisiones de radio –dando como
consecuencia dispositivos más pequeños- , la introducción de nuevos servicios como el
mensajeo instantáneo y la consulta de correos electrónicos.
Uno de los mayores ponentes en cuanto a telefonía celular es la tecnología de acceso GSM,
cuya infraestructura cuenta con varios componentes interactuando, desde las estaciones
móviles hasta los sistemas de soporte, como se muestra en la figura 1.2, ésta tecnología,
basada en multiplexaje por división de tiempo trabajaba en frecuencias de los 450 MHz en
un inicio y después en los rangos de 900 MHz y 1.87 GHz necesitando un promedio de 2
Watts para acceso, evolucionando a tecnologías como GPRS y la evolución del mismo
GSM, EDGE. Aunque este último también es considerado como una tecnología de tercera
6
Debido a que era posible realizar este tipo de comunicación antes de la invención de este, en teléfonos
dispuestos en automóviles que podían realizar llamadas entre sí.
Capítulo I. Estado del arte
5 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
generación, se posiciona en un punto intermedio entre ambas, por las tasas de transferencia
muy por debajo de sus contrapartes.
Figura 1.2 – Diagrama esquemático de la arquitectura de la tecnología GSM.
La infraestructura provista por la tecnología GSM, permitía, por medios digitales, el
intercambio de mensajes de texto, como se dijo, pero también el acceso a internet debido a
la demanda para intercambio de datos, sin embargo, también con la creciente de usuarios lo
hizo la demanda de velocidades de transferencia, dando cabida a la tercera generación de
teléfonos celulares, estos permiten alta capacidad de transmisión de datos de hasta 7 Mbps,
ofreciendo servicios de conexión completa a internet, descarga de archivos,
videoconferencia, etc.
Actualmente los teléfonos móviles cuentan con una variedad de sistemas operativos
desarrollados por distintas compañías, estos sistemas son versiones pequeñas que cuentan
con funciones de red, como los sistemas operativos en red, es posible obtener una dirección
de internet para tener conectividad por medio de un punto de acceso inalámbrico,
implementando interfaces de Wi-Fi las cuales son “propias” del usuario con el hardware o
acceso mediante la red propia del teléfono (GSM,3GPP, LTE, etc. ) para utilizar protocolos
estándar como HTTP, FTP, etc., también permiten la instalación de programas por parte
del fabricante del sistema o de terceros, por tal, la posibilidad de crear aplicaciones para
teléfonos está al alcance de cualquiera que tenga el conocimiento, estos sistemas pueden
Capítulo I. Estado del arte
6 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
ser propietarios del fabricante del mismo hardware mientras que otros lo hacen trabajando
sobre cualquier hardware.
Finalmente, la interconexión masiva de usuarios requiere técnicas especializadas para la
obtención de la información en relación con las capacidades de los servidores, es decir, aun
cuando la comunicación sea posible es necesaria la optimización con el fin de realizar
acciones tanto en el cliente como en el servidor. Protocolos especializados realizan esa
acción de manera encapsulada los cuales utilizan la comunicación prevista por protocolos
de más bajo nivel y los vuelven más confiables, por ejemplo, TCP para el método de
apertura y transferencia por medio de sockets.
La idea principal de explicar cada uno de los tópicos anteriores es con el fin de crear un
mapa mental que explique el modelo de interconexión actual, además de establecer las
bases de como este modelo se creó, en estos momentos es posible intercambiar
información desde un dispositivo hacia otro o de manera masiva, esta información también
puede ser transferida a casi cualquier dispositivo, ya sean los mismos ordenadores,
portátiles, teléfonos móviles, etc.
Cuando se realiza una nueva aplicación cuya tarea fundamental es el comunicar cualquier
cosa, esta debe estar disponible para una cantidad de medios, esta tarea se traduciría en
varias aplicaciones distintas trabajando cada una en su estándar específico, o por lo menos
es lo que se podría pensar a primera vista, la realidad es que pueden tomarse distintas
características de cada una para poder hacerlas “portables” en cada uno de los dispositivos,
este desarrollo corresponde a uno basado en capas, las cuales son –o tratan de serindependientes entre sí y que solo se preocupen por una tarea específica
independientemente de quien reciba o envíe la información.
Los modelos de referencia realizan esta labor, desarrollando una tecnología trabajando
dentro del marco de estos se intenta minimizar –o nulificar- el impacto entre capas
contiguas, así, cuando se desarrolla una aplicación que sea consumida a través de internet
podemos asegurar que mientras el dispositivo que la utiliza también trabaje en ese marco,
capas más bajas o altas pueden ser obviadas, es decir, si se desea mostrar una página
escrita en algún lenguaje para ser mostrado en un navegador de Internet, se puede obviar la
Capítulo I. Estado del arte
7 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
manera en que la información llega al destino o como es enviada7, lo concerniente será de
las capas en las que se está trabajando. Es así como las aplicaciones pueden ser modulares
y transferibles a varios dispositivos.
Así entonces, se propone el desarrollo de una aplicación de interconectividad utilizando las
tecnologías actuales para información a través de un teléfono móvil, basándonos en el
marco de referencia OSI (Véase capítulo II).
El trabajo estaría confinado a las tareas relacionadas con la capa de transporte y de niveles
superiores, entrando de manera mínima en la capa de red, debido al trabajo de estas dos
capas de manera conjunta, como se explicará más detalle en la sección 2.3.6 y pudiendo
obviar las capas más bajas.
En esta aplicación a desarrollar, el trabajo corresponderá a las tareas de presentación y
almacenaje de la información (Capa de aplicación), formateo de los mensajes enviados
hacia un dispositivo cliente (Capa de presentación) y mantenimiento, conexión y término
de la sesión de transferencia de información (Capas de sesión, transporte y red).
El diagrama básico de las tareas de cada componente de la aplicación se muestra en la
figura 1.3:
Figura 1.3 – Tareas a desempeñar por parte de los componentes de la aplicación.
7
Referente a transmisiones de bajo nivel, el formateo de la información o como esta es leída si corresponde a
la labor de la aplicación.
Capítulo I. Estado del arte
8 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La descripción de estas tareas corresponde al proceso de consumo de un servicio web,
estos servicios son ampliamente utilizados en el Internet, utilizan para el intercambio de
información protocolos y estándares abiertos, con lo que se favorece la interoperabilidad
de los sistemas, pueden ser escritos en varios lenguajes de programación, su
funcionamiento se muestra en la sección 3.1, utilizan peticiones HTTP, lo cual es un
avance al intercambio de datos de generaciones anteriores generando interfaces ad-hoc
para la comunicación, como por ejemplo el protocolo RPC, descrito en la sección 2.3.4.
Capítulo I. Estado del arte
9 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Referencias
[1]
Andrew S. Tanenbaum, Sistemas Operativos Modernos. Pearson Educación 2003.
[2]
Tom Farley, Mobile telephone history. Telektronikk 2005.
[3]
Johnny Ryan, A history of the internet and the digital future. Reaktion Books 2010.
Capítulo I. Estado del arte
10 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Capítulo II. Enfoque teórico.
En esta sección se describirá el funcionamiento de la aplicación CEM desde un punto de
vista teórico, se explicará en que capa del modelo OSI estaría el desarrollo de la misma,
además, se hará un análisis con respecto a este modelo y la utilización dentro de
aplicación.
Posterior al análisis, se elaborará la correspondiente explicación de los protocolos que son
utilizados en cada una de las tecnologías en un ambiente real, con esto se sembrarán las
bases para el siguiente capítulo.
La aplicación CEM, al igual que muchos sistemas actualmente, es una aplicación
interconectada con otras tecnologías y sistemas trabajando bajo un estándar bien definido.
Es por ello, que se rige y trabaja dentro del modelo OSI, este modelo, es una referencia
para definición de arquitecturas de sistemas abiertos creado por la ISO8 en 1984.
2.1. El modelo OSI.
El propósito del modelo de referencia OSI es proveer una base común para la coordinación
del desarrollo de estándares para sistemas de interconexión, además de permitir a los
estándares existentes ser situados en la perspectiva dentro del modelo de referencia,
permite a los sistemas abiertos estándares calificados para el intercambio de información a
través de ellos brindando la interconexión mutua.
Existen varias ventajas acerca de un modelado en capas como el del modelo OSI, algunas
de ellas se enumeran a continuación:
8
International Organization for Standarization(Organización Internacional de Normalización). Esta
organización es la más grande desarrolladora y publicadora de estándares internacionales, es una red de
institutos de normalización a nivel nacional de cada uno de los 163 miembros y que tiene su sede en Suiza Capítulo II. Enfoque teórico
11 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Cuando algún cambio es realizado en alguna de las capas la independencia entre
ellas permite que el impacto en otras capas sea el mínimo posible o nulo, si la
arquitectura no fuera de esta manera un cambio en algún componente
comprometería a los demás.
•
Los protocolos se encuentran encapsulados dentro de una sola capa y cada una de
ellas está especializada en una acción determinada, por lo que el diagnóstico y
reparación de problemas pueden ser aislados con mayor facilidad sabiendo en que
sección de la interconexión se presenta la falla.
•
Debido a que el esquema es de interconexión guarda la individualidad de cada una
de las capas, cada diseñador de componentes o tecnologías puede especializarse en
un área sin entrar en conflicto con las demás a utilizar dentro del sistema completo.
•
Establece una guía preestablecida de interoperabilidad entre varios productos de
diferentes proveedores que pueden desempeñar distintas tareas dentro de la
comunicación entre capas.
•
Los niveles tienen conocimiento de las capas adyacentes, asimismo éstas se sirven
mutuamente de las capas inferiores para seguir el flujo de la información.
2.2. Capas del modelo OSI
Este modelo se compone de 7 capas, cada una de ellas con una función específica por lo
que las tareas son separadas comunicando dos sistemas independientes e indicando la
funcionalidad de cada una de ellas, constituyendo un marco de trabajo para desarrollar
protocolos y estándares, así entonces, capas iguales pueden comunicarse con sus
homónimas entre diferentes equipos, en la figura 2.1 se muestra la intercomunicación de
las capas del modelo:
Capítulo II. Enfoque teórico
12 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 2.1 – Modelo de comunicación por niveles o capas.
Los principios que siguen las siete capas o niveles para su funcionamiento e interconexión
son los siguientes:
1. Se debe crear una capa siempre que se necesite otro nivel de abstracción.
2. Cada capa realiza una función definida.
3. La función de cada nivel se elige pensando en la definición de los protocolos
estandarizados.
4. La cantidad de niveles debe ser suficiente para no agrupar funciones distintas en
una misma capa ni lo bastante pequeña para que la arquitectura se vuelva muy
extensa.
Las siete capas del modelo OSI se enuncian en la tabla 2.1:
Nivel
7
6
5
4
3
2
1
Nombre
Aplicación
Presentación
Sesión
Transporte
Red
Enlace de datos.
Física
Tabla 2.1. Capas del modelo OSI
Capítulo II. Enfoque teórico
13 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
A continuación se procede a una breve descripción de las tareas a realizar de todos los
niveles del modelo de referencia:
1. Capa física: Es la encargada de la transmisión de bits en el canal de comunicación,
se debe considerar en el diseño el aseguramiento de una transmisión confiable, que
el envío se reciba correctamente por el receptor.
Le concierne todo lo relacionado con la descripción de la transmisión. Especifica
las características eléctricas, mecánicas, funcionales y de procedimiento de los
equipos, i.e., los volts de transmisión, la dirección de la comunicación
(unidireccional o bidireccional), método de interrupción de la comunicación, el
establecimiento de la conexión inicial, entre otros. En esta capa las unidades de
transmisión (o PDU) son los bits.
2.
Capa de enlace de datos. Es responsable de la integridad de la recepción y del
envío de la información, toma los paquetes recibidos en la capa de red y los prepara
para que se transmitan hacia el nivel físico, de igual manera, le da significado a los
bits de información recibida de la capa física y verifica si al información no
contiene errores, si están en orden o contienen alguna falla, para que si todo está
correcto los envíe a la capa de red.
Las funciones de esta capa consisten en notificar al emisor si alguna trama se recibe
en mal estado, si no se recibieron, están duplicadas o si fueron recibidas
correctamente, hace que el emisor divida los datos en tramas de datos, que los
transmita de manera secuencial y procese las tramas de acuse de recibo por parte
del receptor, es decir, lo referente al control de errores.
En este, al igual que en otros niveles más altos, se considera la regulación o control
de tráfico, es decir, que un transmisor rápido pueda saturar a un receptor que sea
más lento, por lo que implementa un espacio de almacenamiento temporal del lado
del receptor (buffer). Las direcciones físicas de los equipos se encuentran en esta
Capítulo II. Enfoque teórico
14 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
capa, éstas son utilizadas para el transporte local de las tramas, que son las unidades
de transporte (o PDU) de este nivel.
3. Capa de red. Controla el funcionamiento de la subred, se responsabiliza del
direccionamiento de los mensajes y de la conversión de las direcciones
(Direccionamiento lógico) y nombres de los equipos. En esta capa se encuentran las
funciones de enrutamiento, de control de tráfico, entre otras, que deben asegurar
que el paquete llegue a su destino aun cuando no exista una conexión física entre
ellos.
Este nivel independiza a capas superiores del medio y tipo de transmisión, ya que
se realiza un paquete estándar, con el diálogo (Payload), direcciones y demás
parámetros importantes para este fin. También se encuentra presente las topologías
o arquitecturas de red, punto que está relacionado con las funciones de
encaminamiento.
Los protocolos correspondientes a este nivel pueden ser de 2 tipos, de enrutamiento
(i.e. IP (Internet Protocol)) o enrutados (i.e. RIP (Protocolo de Información de
Enrutamiento), EIGRP (Protocolo de enrutamiento de gateway interior mejorado),
entre otros.), dependiendo de si se seleccionan las rutas o si definen el formato y el
uso del paquete, respectivamente. En este nivel las unidades de unidades de datos
(o PDU) son los paquetes.
4. Capa de transporte. También se conoce como capa de extremo a extremo, ya que
proporciona la conexión y el transporte confiable de los datos desde el origen al
destino. En esta capa se mantienen, establecen y terminan las conexiones lógicas
para la transferencia de información a través de la red, en este nivel encontramos 2
tipos de servicio, orientados a conexión y no orientados a conexión, el primero de
ellos necesita de un establecimiento de conexión, transferencia de datos y
liberación de la conexión, mientras que el restante trata los paquetes
individualmente.
Capítulo II. Enfoque teórico
15 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Dentro de la interconexión por medio de Internet hay 2 principales protocolos de
transporte, TCP y UDP, orientados a conexión y no orientados a conexión,
respectivamente. Las unidades de datos (o PDU) en este nivel son los segmentos.
Desde esta capa hasta niveles más altos se consideran capas de extremo a extremos,
mientras que las capas inferiores son niveles de protocolos.
5. Capa de sesión. Permite que 2 aplicaciones establezcan, usen y terminen la
conexión, además maneja el diálogo establecido entre los 2 equipos, como lo hace
la capa de transporte, la diferencia está en que proporciona servicios mejorados
para la comunicación entre las aplicaciones.
Sus funciones son:
•
Establecer conexiones a petición del usuario y liberar cuando la conexión
termina.
•
Control del diálogo, que puede ser simultáneo en los 2 sentidos o alternado,
en este caso, la capa de sesión también ayuda para el control de turnos.
•
Agrupamiento del flujo de datos.
•
Sincronización de la sesión.
•
Provee puntos de verificación para que en caso de fallo la sesión se reanude
desde ese punto y no desde el inicio.
6. Capa de presentación. Su objetivo es la definición del formato de la información,
a diferencia de las capas inferiores cuyo cometido es el envío de la información de
manera confiable, esta capa se ocupa de la sintaxis de la información que se
transmite.
Este nivel cumple 3 funciones principales:
•
El formateo. Representa los datos recibidos desde las capas inferiores y las
muestra según sea el caso, como cadenas de caracteres, enteros, número de
coma flotante, etc. En esta capa se realiza la conversión de las estructuras de
datos abstractas a la representación estándar de la red y viceversa, es decir,
Capítulo II. Enfoque teórico
16 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
se ocupa como traductor cuando la información enviada no corresponde al
mismo formato que la recibida.
•
El cifrado. Indica las reglas de encriptación y desencriptación de la
información.
•
La compresión. Implementa los algoritmos para reducir de tamaño un
archivo.
7. Capa de aplicación. Es el nivel más alto del modelo, es el que interactúa
directamente con las aplicaciones y servicios que están en contacto (o pueden no
estarlo) con el usuario.
En esta capa están las funciones de transferencia de archivos, así entonces, dos
sistemas con convenciones distintas para nombrar archivos o de representar la
información se valen de la capa de aplicación como traductor, la cual debe resolver
las incompatibilidades para la presentación de la información requerida. Algunos
protocolos pertenecientes a este nivel utilizados con frecuencia para el intercambio
de información son: FTP, DNS, DHCP, HTTP, NAT, POP, SMTP, entre otros.
Así entonces, podemos expandir la idea expuesta por la figura 2.1 de interconexión entre
niveles y equipos por una más precisa que se muestra en la figura 2.2:
Figura 2.2 – Comunicación por medio del modelo de referencia OSI
Capítulo II. Enfoque teórico
17 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
El proceso de transmisión de la información a través del modelo OSI se hace descendiendo
los niveles para después enviarlos desde la Capa Física al medio de trasmisión de una
manera reconocida (Que puede ser ondas electromagnéticas, ondas de luz, etc.) para
nuevamente ascender hasta el nivel de aplicación, esto es, cuando se desea transmitir el
proceso entrega los datos a la capa de aplicación que añade el encabezado del protocolo de
la capa de aplicación y se lo entrega a la capa de presentación. Este nivel los transforma y
añade encabezados para entregar el resultado a la capa de sesión y así sucesivamente hasta
alcanzar la capa física, del lado del receptor se hace el mismo proceso pero inverso,
leyendo los encabezados para que al final se presente la información al usuario, esto se
conoce como trayectoria de la comunicación que se representa en la figura 2.3.
Figura 2.3 – Trayectoria de la comunicación en el modelo OSI.
Este marco de referencia está presente en los sistemas de interconexión. El sistema
propuesto para obtener información de los alumnos, CEM, también trabaja bajo este
marco, en las siguientes páginas se explicará el funcionamiento de este sistema desde la
perspectiva del modelo OSI.
Capítulo II. Enfoque teórico
18 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.3. Perspectiva en base al modelo OSI.
Una vez ya conocido el comportamiento de cada una de las capas del modelo OSI, nos
centraremos en describir la participación de los componentes principales de cada una de las
capas dentro del sistema de notificaciones, este apartado es con el fin de conocer el
funcionamiento de cada una de las tecnologías que se utilizan en un ambiente real y que se
describirán en el capítulo siguiente.
La aplicación CEM funciona dentro de un sistema operativo basado en Windows (En el
caso específico se utiliza Windows 7) para el lado del proveedor de datos y del receptor,
que un teléfono móvil inteligente (Smartphone) con sistema operativo Android (2.1 –
Eclair, para el caso muestra). Así entonces lo primero a llevar a cabo será el análisis de
funcionamiento del lado del proveedor.
2.3.1. Interacción del usuario con la capa de aplicación.
La sección más alta del modelo OSI corresponde a la capa de aplicación, sin embargo, el
usuario común no tiene acceso a los protocolos pertenecientes a la capa de aplicación, en
lugar de ello el sistema operativo, y programas de terceros, ofrecen una serie de
aplicaciones para estar en contacto con esta capa.
El sistema operativo es el software que administra los procesos de un sistema en particular,
esto engloba tanto la administración de memoria, de almacenamiento, del sistema de
archivo así como de las aplicaciones corriendo en él, así entonces, el punto de partida será
el sistema operativo.
La aplicación proveedora está desarrollada para trabajar dentro de un núcleo de Windows,
por lo que será este quien lo administré, sin embargo la aplicación, bajo el consentimiento
del sistema operativo, será la que esté en contacto con la capa de aplicación.
Capítulo II. Enfoque teórico
19 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
El software que dará esta operatividad con la capa de aplicación es en sí el lenguaje de
programación a utilizar. Por encima de él se encuentre el IDE (Entorno de desarrollo
integrado) que es el que le da la apariencia amigable para el usuario, el programador da las
instrucciones que desea que realice el programa pero el lenguaje es el que traduce esto a la
máquina para realizar en sí la acción.
Este proceso se realiza por medio del programa desarrollado y el contacto se hace por
medio de 2 fases, la de compilado o enlazado del programa y la de ejecución del programa.
Cuando se realiza un programa en un lenguaje de alto nivel9 este debe ser traducido a
lenguaje máquina, este proceso se muestra en la figura 2.4:
Figura 2.4 – Diagrama del proceso de compilación y ensamble de un programa escrito en
lenguaje de alto nivel compilado.
En la figura anterior se muestran los procesos de traducción de un programa escrito para
ser ejecutado en un ordenador, se pueden destacar los siguientes puntos:
9
Lenguajes de programación que expresan los algoritmos de manera adecuada para la comprensión humana, a
diferencia de los lenguajes de bajo nivel que expresan las instrucciones para ser entendidas por la máquina,
algunos ejemplos de lenguajes de alto nivel son Java, C#, C++, Fortran, etc. Capítulo II. Enfoque teórico
20 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Programa fuente. Es el programa que se escribe en lenguaje de alto, este programa
es el que se traducirá a lenguaje máquina.
•
Compilador. El proceso de compilado será el que traduce el código fuente a otro
lenguaje o a lenguaje máquina, realiza análisis léxico y sintáctico y optimización de
ejecución.
•
Ensamblador. Este es el programa ya traducido a lenguaje máquina, en esta fase
no puede ejecutarse aún.
•
Enlazador. Una vez se tiene el programa objeto, el enlazador agrega las
bibliotecas necesarias y realiza su montaje, terminado esto se tendrá el producto
final que será el ejecutable, que será el que en realidad se comunique con la capa de
aplicación.
2.3.2. Capa de aplicación. El protocolo HTTP
La aplicación proveedora se comunicará con servicio web REST (Estado de transferencia
representacional) (Véase sección 3.3), por lo que el protocolo de la capa de aplicación será
HTTP que es usado ampliamente a través del internet.
Lo relacionado con el protocolo HTTP y su tratamiento es muy extenso, entonces, nos
centraremos en las características fundamentales de éste. HTTP (HyperText Transfer
Protocol, traducido como Protocolo de Transferencia De Hipertexto) es un protocolo para
la distribución de medios en sistemas de información, desde su versión 1.0 (HTTP/1.0)
ofrece un formateo de mensajes muy similar al relacionado con los tipos MIME
(Extensiones Multipropósito de Correo de Internet) (Este formateo se refiere a la capa de
presentación, se describe más a fondo en la sección 2.3.3 del presente trabajo) conteniendo
metainformación10 acerca de los datos transferidos.
Este protocolo que trabaja por medio de peticiones y respuestas, hace referencia a
estándares a identificadores, localizadores y descriptores de recursos, URI (Identificador
Uniforme de Recurso), URL (Localizador de Recursos Uniforme) y URN (Nombre de
10
Capítulo II. Enfoque teórico
21 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Recurso Uniforme), respectivamente. Cuando un cliente envía una petición al servidor lo
hace en un encapsulado que contiene el método de petición, información del cliente y del
protocolo, identificador estándar. Del lado del servidor, este responde con un mensaje
parecido que contiene los datos en sí, acompañado de la versión del protocolo, códigos de
error o éxito, metainformación de la entidad además de información acerca del formateo de
mensaje parecido al descrito en MIME.
2.3.2.1.
Mensaje HTTP
Los mensajes a través del protocolo se dividen en dos: del cliente al servidor nos
encontramos con peticiones HTTP, del servidor hacia el cliente serán respuestas HTTP. El
formato genérico del mensaje consiste en una línea inicial, campos de encabezado, una
línea de delimitación de término de encabezados y el cuerpo del mensaje.
Un mensaje de petición, basado en el formato básico de los mensajes, contiene la línea
inicial, que es la línea de petición, seguida de encabezados de alto nivel y propios de la
petición, así como el cuerpo de la petición. Del lado del servidor, en la respuesta, se tiene
el formato general de mensaje el cual contiene la estructura básica, primero la línea de
respuesta, nombrada línea de estatus, encabezados y cuerpos del mensaje. El formato de
los mensajes de petición y respuesta se muestra en la figura 2.5:
Figura 2.5 - Formato general de los mensajes de petición y respuesta del protocolo HTTP.
Capítulo II. Enfoque teórico
22 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
De la figura anterior podemos destacar los valores de línea de petición, encabezado de
petición, línea de estatus, encabezado de respuesta para los mensajes de petición y
respuesta, respectivamente, además de los campos generales de encabezado de nivel alto y
de entidad. Además de contar con un separador entre encabezados y cuerpo del mensajes,
siendo una línea en blanco tradicional.
•
Encabezado general. El encabezado general de HTTP contiene el comportamiento
general del mensaje, independientemente de ser respuesta o petición, pero que no
debe ser enviado en el encabezado de la entidad, los valores que contiene están
relacionados con el control del caché, la fecha de envío, las transformaciones, entre
otros.
•
Línea de petición. Describe el método a usar en la petición, la URI del cliente y la
versión del protocolo, todos separados por un espacio y finaliza con una línea en
blanco. Los métodos de definición se explican con más profundidad en la sección
2.3.2.2. El formato general de la línea de petición se muestra en la figura 2.6:
Figura 2.6 – Formato de la línea de petición en el protocolo HTTP.
•
Encabezado de petición. Este campo permite al cliente enviar información
adicional acerca de la petición, son modificadores de la petición.
•
Línea de estatus. Esta línea de respuesta consiste en la versión del protocolo
usado, el código de respuesta y la descripción asociada a este, separados por
espacios, el término de la línea se delimita por una línea en blanco. El código de
respuesta corresponde al estatus del servidor, estos códigos se muestran a fondo en
el apéndice A. El formato de la línea de estatus se presenta en la figura 2.7:
Capítulo II. Enfoque teórico
23 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 2.7 – Formato de la línea de estatus es un mensaje de respuesta del protocolo
HTTP
•
Encabezado de respuesta. Son la contraparte de los encabezados de petición, su
función es enviar información adicional acerca de la respuesta del servidor, la cual
no debe ser enviada en la línea de estatus, tiene valores referentes acerca del acceso
al servidor.
•
Encabezado de la entidad. Define la metainformación acerca del cuerpo del
mensaje así como de los identificadores (URI) de las peticiones.
2.3.2.2.
Métodos HTTP
Los métodos de HTTP, incluidos en la línea de petición, definen la manera en la cual se
realizará la petición al servidor, corresponden a los verbos GET, HEAD, POST, PUT,
DELETE, TRACE, CONNECT y OPTIONS.
•
GET. Este método regresa cualquier información que pueda ser identificada por el
URI de la petición, esta respuesta es guardad en caché.
•
HEAD. Este método es idéntico a GET, la diferencia radica en que al ejecutar esta
petición el servidor no regresa el cuerpo del mensaje, es decir, solo servirá el
encabezado para obtener la metainformación del recurso solicitado.
•
POST. Indica al servidor aceptar la entidad enviada en la petición como un recurso
de la URI de petición, la respuesta no es guardada en caché a menos que se le
indique explícitamente por medio del control de caché. Este método es utilizado
ampliamente cuando se quiere enviar información de formularios.
•
PUT. Indica el almacenamiento del recurso que será enviado desde la URI de
petición. Si la petición se refiere a un recurso ya existente la entidad debe ser
Capítulo II. Enfoque teórico
24 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
considerada como una modificación del mismo, en caso de existir el servidor es
capaz de crear el recurso.
•
DELETE. Indica al servidor borrar el recurso que identificara con la URI de
petición, del lado del servidor este intentará borrar el recurso y en caso de no poder
hacerlo moverlo a un lugar inaccesible, por lo que el cliente no puede garantizar la
operación de borrado aun cuando se tenga una respuesta exitosa.
•
TRACE. Este método invoca una “sesión de retroalimentación” en el servidor.
Debe reflejar el mismo mensaje de envío como respuesta acompañado de un
encabezado de éxito, este método es utilizado para sesiones de testeo y depuración.
•
CONNECT. Utilizado por proxys. Permite que dinámicamente un proxy se
convierta en un túnel. Utilizado para comunicaciones seguras a través de sockets,
SSL.
•
OPTIONS. Es te método representa una petición para obtener la información
acerca de la opciones de comunicación disponibles en la cadena petición/respuesta
de un URI específico, la respuesta de este método no es guardada en caché.
Los métodos DELETE, GET, POST y PUT son encontrados dentro del consumo de un
servicio web (web service) con arquitectura REST, el uso de esta arquitectura se explica
más a fondo en la sección 3.2 del presente trabajo, al igual que las diferencias con respecto
a otras arquitecturas.
2.3.3. Formateo de tipos. MIME e IMT
En la capa de presentación, para el sistema CEM estará definido por los tipos MIME que el
servicio será capaz de proveer. Los tipos MIME (Del inglés Multipurpose Internet Mail
Extensions, traducido como Extensiones Multipropósito de Correo de Internet)
denominados así en un inicio, fueron extensiones de intercambio de archivos. El término
fue cambiado después por IMT (Del inglés Internet Media Type, traducido como Tipo de
Capítulo II. Enfoque teórico
25 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Medio de Internet) para el intercambio de tráfico que no pertenece al correo electrónico, así
entonces, ambos términos conviven juntos pero son usados para distintos contextos.
Los tipos de medios para intercambio (Tipos MIME e IMT) son utilizados sobre internet
para un intercambio transparente de archivos, estas especificaciones son formadas por
identificadores con 2 campos el tipo de medio y el subtipo de información, además de
poder adjuntar parámetros opcionales como por ejemplo el tipo de codificación o conjunto
de caracteres permitidos (charset).
La definición de los medios consiste en lo siguiente:
a) Nombre y descripción del tipo.
b) Nombre y definiciones de los parámetros.
c) Manejo de los subtipos a través del Gateaway.
d) Consideraciones generales de tratamiento de entidades por el Gateaway.
e) Restricciones de codificación del contenido de transferencia.
El manejo de los puntos anteriores está dado por el protocolo que tiene una respuesta
específica dependiendo del tipo de medio, esto medios se pueden dividir en las siguientes
categorías:
a) Texto. Utilizando el identificador “text” es el tipo más básico de intercambio, para
llevar a cabo intercambio de información textual, no es necesario de ningún tipo de
software en especial para el desplegado, el subtipo básico corresponde al texto
plano identificado por “plain”.
b) Imágenes. Utilizan el Identificador “image” y los subtipos son principalmente los
formatos jpeg y gif, que son los más ampliamente utilizados.
c) Audio. Se determinan por el identificado “audio” y es necesario un dispositivo que
con salida de audio.
d) Video. Es necesario software con capacidad de desplegarlo, el subtipo inicial es
mpeg y es identificado por “video”.
Capítulo II. Enfoque teórico
26 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
e) Aplicaciones. El identificador asociado es “application”, son otros tipos de datos
que deben ser procesador por una aplicación, típicamente están codificados en
binario. Pueden ser utilizados para enviar datos específicos como hojas de cálculo,
documentos de Word o datos interpretados específicos.
Además de las categorías básicas descritas arriba hay dos tipos de medios compuestos o
complejos, que son:
a) Multipartes. Consistentes en varias entidades de un tipo de medio, su identificador
es “multipart” los tipos inicialmente descritos en el estándar son:
•
Mixto. Para envío de contenidos distinto, utiliza el tag “mixed”
•
Alternativo. Identificado por “alternative” y es utilizado para expresar la
misma información con varios formatos.
•
Paralelo. Para ver distintas secciones simultáneamente, identificado por
“parallel”.
•
Asimilable. Correspondientes al tipo de default, se identifica por “digest”.
b) Mensaje. Le corresponde el identificador “message” y se ocupa del envío de
mensajes encapsulados, típicamente está presente en el reenvío de mensajes de
correo electrónico.
Dentro de una aplicación corresponde al tipo de respuesta a obtener cuando se invoca a un
servicio, siempre y cuando el servidor sea capaz de responder esa petición, este atributo es
“Content-Type”, por lo que los tipos MIME o IMT también son conocidos como tipos de
contenido o “Content-Types”.
Los tipos MIME trabajan en la capa de presentación ya que esencialmente se encargan de
dar formato a los documentos adjuntos sobre un protocolo de aplicación, como puede ser
HTTP, así, durante la transacción entre un servidor web y una aplicación cliente (Puede ser
el explorador o una más especializada), lo primero en enviarse desde el servidor será el
tipo MIME del archivo para que el cliente sepa cómo mostrarlo.
Capítulo II. Enfoque teórico
27 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Dentro de una petición, el formato que se encontrará se describe en la figura 2.8.
Figura 2.8 – Sentencia que indica el tipo de contenido MIME.
A continuación se enuncian alguno de los tipos MIME más comunes:
•
audio/mpeg: Archivo de audio MPEG.
•
image/gif: Imagen con formato GIF.
•
image/jpeg: Imagen JPEG.
•
message/http: Mensaje en estándar HTTP.
•
text/html. Texto plano en HTM.
•
text/xml. Texto descriptivo en XML.
•
application/msword. Aplicación de procesamiento de texto de Microsoft
Word.
•
application/pdf. Documento de PDF
2.3.4. Llamada a procedimientos remotos. El protocolo RPC.
Lo concerniente a la capa de sesión estará presente en las llamadas a procedimientos en el
otro equipo. Principalmente, en la actualidad el modelado de servicios con mayor auge son
SOAP (Protocolo de Acceso Simple a Objetos) y REST (Transferencia de Estado
Representacional), basado a servicios (SOA) o a recursos (ROA), respectivamente. Aun
cuando ambas arquitecturas proveen la información necesaria para realizar la tarea, lo
hacen de distinta manera. (Se amplía este concepto, además de las diferencias entre ellos
en la sección 3.2.1)
Capítulo II. Enfoque teórico
28 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La arquitectura SOA, se refiere al modelo de referencia homónimo, el cual tiene como
característica principal el estar orientado a los servicios del cliente y es utilizado
ampliamente en servicios de Internet que utilizan estándares basados en esta, uno de ellos
es SOAP el cual es derivado de un protocolo de intercambio de comunicación de datos en
XML, XML-RPC.
XML-RPC es un protocolo de llamado a procedimiento remoto, se caracteriza por utilizar
XML como codificador y HTTP como transmisor de datos. Como protocolo de invocación
remota utiliza en la capa de sesión RPC para el control de diálogo y apertura y término de
sesión.
El protocolo RPC realiza un proceso de comunicación entre procesos (En inglés, el nombre
característico es inter-process communication), esto permite que un programa ejecute una
subrutina en otra máquina remota, en decir, el proceso A en la máquina A puede llamar a
un procedimiento o subrutina en la maquina B, en este momento el proceso A se suspende
y continúa su ejecución en B, la subrutina en B regresa la respuesta y el proceso sigue su
ejecución en A.
Figura 2.9 – Diagrama de comunicación a través del protocolo RPC.
Capítulo II. Enfoque teórico
29 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La figura 2.9 muestra el proceso de comunicación por medio del protocolo RPC, este
puede resumirse como sigue:
1. El cliente llama a la su propia subrutina11 (Client Stub), ésta subrutina encapsula los
argumentos necesarios para el procedimiento remoto y construye los mensajes de
red, que pueden ser uno o varios. A este empaquetado de subrutina remota y
mensaje de red se le conoce como serializado (Denominado en inglés Marshalling).
Este marshalling concierne al apareo entre equipos, puede realizarse en varias
codificaciones, como XML o JSON, es una manera muy fiable de transporte de
objetos a través de la red.
2. Los mensajes son enviados a la subrutina del lado del servidor utilizando las rutina
de red locales, propias del sistema sobre el cuál se está trabajando, pertenece a
kernel local del sistema.
3. Los mensajes son enviados por el kernel al sistema remoto (Este proceso puede ser
orientado a conexión o no orientado a conexión).
4. La subrutina de servidor (Server Stub) recibe el paquete y lo deserializa (Proceso
también conocido con unmarshalling) y posiblemente convirtiendo el mensaje
como un estándar específico para el propio sistema.
5. La subrutina del servidor ejecuta el procedimiento de manera local, pasando los
argumentos enviados por el cliente.
6. Cuando el servidor termina regresa una nueva subrutina de ejecución con el valor
resultado de la operación.
7. La subrutina del servidor vuelve a serializar la respuesta, crea los mensajes de red y
la baja hasta su propio kernel.
8. Los mensajes son enviados por una petición local de red hasta el equipo remoto,
que en este caso será el cliente.
9. El kernel cliente deserializa el mensaje y los envía a la subrutina local para ser
leídos.
10. Esta subrutina regresa los resultados del proceso a la función cliente.
11
En inglés, este término es denominado stub, que propiamente no es una subrutina sino un trozo de código
sustituto de alguna funcionalidad y que también puede funcionar en labores de testing, la principal diferencia
entre ambos términos es la aplicación, mientras que una subrutina se aplica a una funcionalidad local, un stub
es útil para sistemas distribuidos.
Capítulo II. Enfoque teórico
30 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.3.5. El protocolo de transporte. TCP
Se sabe que la actualización de los datos se hará sobre el protocolo HTTP, al igual que el
acceso a la página de descarga hospedado en un servidor de aplicaciones. El protocolo
HTTP, utiliza en su capa de transporte el protocolo TCP.
TCP (Protocolo de Control de Transmisión, en inglés Transmission Control Protocol) es un
protocolo de transporte y trabaja por encima de la capa de red. Este protocolo permite tanto
la comunicación simultánea como el demultiplexaje del tráfico entre distintas aplicaciones
que se intercomunican por este.
Este protocolo está pensado para ser un protocolo “host” a “host” (Extremo a extremo)
para intercambio fiable de paquetes y está orientado a conexión, este protocolo
proporciona mecanismos para pares de “hosts” en la red. La fiabilidad de este protocolo
está marcada por el hecho de que no supone confiabilidad de los protocolos trabajando
debajo de él.
El funcionamiento de TCP se basa en el establecimiento de circuitos lógicos seguros entre
pares de procesos que corresponden a una conexión entre ambos “hosts”. Este proceso se
lleva a cabo por medio del establecimiento de la conexión, la transferencia de los datos y el
término de la conexión, cada una de estas etapas se detalla en la sección contigua:
•
El establecimiento de la conexión se realiza con un proceso llamado Negociación
de tres pasos (Del inglés Three-Way Handshaking), este proceso se muestra en la
figura 2.10:
Capítulo II. Enfoque teórico
31 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 2.10 – Establecimiento de una conexión en el protocolo TCP por medio del
proceso Three-Way Handshake.
El proceso descrito anteriormente refleja el proceso de establecimiento. Cuando el
cliente quiere realizar una conexión envía un paquete de sincronización SYN, el
servidor revisa el paquete y si algún proceso está en escucha de esa petición el
establecimiento continúa, de otra manera el servidor enviará un paquete de
respuesta de rechazo de intento de conexión RST (Véase figura b), en caso de un
positivo el servidor responderá con un paquete de intento exitoso ACK además de
otro paquete de sincronización SYN (Fig. a). Del lado del cliente procesa las
respuestas, si recibió el paquete RST intentará nuevamente la conexión por un
número de veces predeterminadas de intentos, en caso de que haya recibido el
paquete de éxito, este responde nuevamente con un paquete de intento exitoso ACK
lo que indica que ambos están listos para el proceso de transferencia de datos.
•
En el proceso de transferencia hay 3 conceptos importantes que determinan la
confiabilidad de la comunicación, estos son el número de secuencia (Checksum),
respuestas de éxito (ACK) y el control de flujo por medio del método de ventana
deslizante o ventana (Windowing).
Capítulo II. Enfoque teórico
32 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
El método que TCP utiliza para detectar los paquetes faltantes o duplicados se basa
en el número de secuencia de dicho paquete. En cada uno de los paquetes de datos
se encuentra este número que corresponde un número de 32 bits que indica el
último paquete enviado. Cuando un paquete es recibido correctamente, se responde
con una respuesta de éxito (Acknowledgment) a la par del número de secuencia se
encontrará el número de recibido, que indica el número de secuencia del receptor, a
diferencia del primero que se refería al número de secuencia local.
Este número de recibido va de la mano con el control de flujo de datos o ventana
(Windowing), ya que TCP tiene la capacidad de variar los datos a enviar si el
cliente consiente este hecho, este proceso indica al servidor cuanta información
puede guardar el cliente internamente para que los datos enviados varíen. En la
figura 2.11 se muestra el procedimiento de transferencia de datos por medio de
TPC:
Figura 2.11 – Proceso de transferencia de información sobre el protocolo TCP.
•
El término de la conexión se realiza con un proceso parecido al del establecimiento,
este proceso se conoce como negociación de cuatro pasos (Four-Way
Handshaking). Este proceso se realiza enviando el de término de conexión FIN, por
cualquiera de las 2 partes, la otra parte accederá al paquete enviando una petición
Capítulo II. Enfoque teórico
33 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
de recepción exitosa y otro paquete de término a lo cual la primera parte accede
terminando la conexión, como se muestra en la figura 2.12:
Figura 2.12 – Diagrama esquemático de término de conexión TCP.
Este proceso de conexión de extremo a extremo se realiza utilizando un puerto de conexión
entre aplicaciones, este puerto tiene un proceso adjunto que escucha el diálogo de la
comunicación, es por ello que TCP puede brindar una conexión confiable ante un medio no
confiable como IP, como se muestra en la figura 2.13.
Capítulo II. Enfoque teórico
34 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 2.13 – Diagrama de conexión fiable extremo a extremo en TCP
Todas las opciones anteriormente mencionadas se encuentran definidas dentro del paquete
de transmisión de TCP, este paquete contiene el puerto origen, destino, tamaño de ventana,
números de secuencia y consentimiento, como se muestra en la figura 2.14 y se describen
más adelante:
Figura 2.14 – Segmento de información del protocolo TCP
Capítulo II. Enfoque teórico
35 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Puerto origen. Puerto por el que se envía la petición.
•
Puerto destino. Puerto por el cual se recibe la petición.
•
Numero de secuencia. Cuando el bit de sincronización está activo indica el byte
siguiente de secuencia de un flujo de datos, cuando el bit de sincronización no se
encuentra activo indica el primer byte del flujo.
•
Número de acuse de recibo o número de consentimiento. Contiene el siguiente
número de secuencia, el valor a pedir, solo cuando el bit de consentimiento ACK,
está activo.
•
Data offset. Indica donde inician los datos, teniendo en cuenta que una sección del
paquete es la cabecera.
•
Reservado. Son bits pensados para un uso futuro, son manejados en cero.
•
CWR
(Congestion
Window
Reduced).
Utilizado
para
indicar
el
congestionamiento de la red, solo se activa si el paquete tiene la opción de realizar
notificaciones de congestionamiento, con el bit ECE.
•
ECN (Explicit Congestion Notification). Bit que indica si es posible la
notificación de congestión de red, va aunado al bit CWR.
•
URG (Urgent). Este bit indica si el paquete contiene datos urgentes, un positivo
indicara que debe tomarse en cuenta el campo de urgente.
•
ACK (Acknowledgement). Indica el consentimiento de flujo de datos, se explicó
su funcionamiento con más detalle en esta misma sección del presente.
•
PSH (Push). Bit que indica el envío de los datos en buffer.
•
RST (Reset). Bit de término de conexión, se muestra más ampliamente su
funcionamiento en esta misma sección.
•
SYN (Synchronization). Sincronizador de números de secuencia.
•
FIN (Finish). Activado para indicar el término de la conexión, se explica su
funcionamiento en esta misma sección.
•
Tamaño de ventana. Indica el número de bytes esperados a recibir por parte del
receptor.
•
Checksum. Es la suma de comprobación de verificación de errores.
•
Indicador de urgente. Indica el último byte de los datos marcados como urgentes,
es funcional cuando el bit URG es marcado.
Capítulo II. Enfoque teórico
36 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.3.6. El protocolo de internet.
Bajo el nivel de transporte encontramos la capa de red, con el protocolo IP. La
combinación de protocolos TCP/IP son conocidos como los protocolos de Internet, debido
a que en este par se basa el internet, por encima de ellos tenemos los protocolos de
aplicación y presentación, HTTP, FTP, SMTP, que están más cerca de la interacción
usuario, todos ellos, juntos son conocidos como la familia de protocolos de internet, la
figura 2.15 muestra dicha relación:
Figura 2.15 – Familia de protocolos de internet.
Todos los protocolos de la familia de Internet, reciben los paquetes desde el protocolo IP
(Internet Protocol traducido como Protocolo de Internet), esta correspondencia se muestra
en la figura 2.15.
El protocolo de Internet fue diseñado para ser usado en sistemas interconectados en redes
de conmutación de paquetes, realiza su trabajo con la transmisión de bloques de datos, que
nombra “datagramas” desde el origen a los destinos, estas fuentes y destinos los localiza
por medio de un identificador único, la dirección IP. Así también fragmenta y reensambla
Capítulo II. Enfoque teórico
37 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
los datagramas largos cuando la transmisión solo acepta paquetes de datos pequeños.
Debido a esto el protocolo de Internet IP, es un protocolo de intercomunicación NO
orientado a conexión, de rápida entrega pero no confiable.
La operación del protocolo IP implementa dos funciones básicas, el direccionamiento
(addressing) y la fragmentación (fragmentation).
•
Direccionamiento. Para que la información alcance su destino, éste protocolo se
vale de las direcciones que lleva el encabezado que lleva el paquete, este envía
tanto la dirección de origen como la de destino, con esto puede seleccionarse el
camino a seguir, operación que se conoce como enrutamiento.
El modelo de comunicación reside en que cada host está relacionado con una puerta
de enlace (Gateway) que interconecta las redes, estos dispositivos comparten reglas
para interpretar la dirección y alcanzar el destino, además, las puertas de enlace
contienen lógica adicional para tomar decisiones de encaminamiento de los
paquetes.
Este protocolo no provee comunicación confiable, ya que no tiene conocimiento de
extremo a extremo (Host-to-host) o entre dispositivos (Hop-by-hop), tampoco tiene
control de errores, solo un encabezado de suma de comprobación (Checksum) pero
solo de cabecera, más no de datos, tampoco tiene mecanismos de retransmisión o
de control de flujo, implementa la transmisión del “mejor esfuerzo” intentando
enviar lo más rápido posible al dispositivo que debe pero no garantiza la llegada de
este.
•
Fragmentación. Este proceso se hace presente cuando el tamaño de los paquetes
de datos sobrepasa el tamaño de la unidad del canal12, esto también se indica en el
campo de banderas de fragmentación en el encabezado del datagrama IP, lo que
12
A este valor se le conoce como “Unidad máxima de transferencia”, MTU, para IP este valor TEÓRICO
máximo es de 65536 bytes (64Kbytes), sin embargo, en la práctica el dispositivo será el que determine el
tamaño máximo del datagrama en función de la tecnología utilizada, para la mayor parte de las redes este
tamaño máximo corresponde a aproximadamente unos 1500 bytes.
Capítulo II. Enfoque teórico
38 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
indica que el proceso de fragmentación se realizó y su contraparte debe
reensamblarlos.
En la figura 2.16 se detallan los campos dentro de una cabecera del protocolo IP:
Figura 2.16 – Paquete de información del protocolo IP.
•
Versión. Corresponde a la versión del protocolo IP, el valor es (0100) siempre es el
mismo, cuando se maneje IPv4.
•
IHL (IP Header Length). Longitud del encabezado de internet.
•
Tipo de servicio. Indicador de la calidad de servicio esperada, es una combinación
entre retardo, confiablidad y rendimiento, este campo es de ochos bits que se
reparten como se muestra en la figura 2.17:
Figura 2.17 – Registro correspondiente al campo de tipo de servicio.
De la figura anterior se destacan los valores.
o Retardo. 1 = Poco retardo, 0 = Retardo normal
o Rendimiento. 1 = Alto rendimiento, 0 = Rendimiento normal
o Confiabilidad. 1 = Alta confiabilidad, 0 = Confiabilidad normal
Capítulo II. Enfoque teórico
39 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Longitud. Longitud total del datagrama medido en octetos, corresponde al tamaño
de MTU máximo, en teoría son 65536 octetos, un host tiene que ser capaz de
aceptar datagramas de por lo menos 576 octetos aunque es recomendable que sean
capaces de enviar y recibir un número mayor a este.
•
Indicador. Solamente es utilizado cuando se presentan datagramas fragmentados,
sirve como auxiliar en el proceso de reensamble.
•
Banderas de control de fragmentación. Cuando se tiene un paquete fragmentado
estas banderas indican los parámetros de control.
o Bit 0. Reservado, debe ser cero.
o Bit 1. 0 = Paquete fragmentado, 1 = Paquete sin fragmentar
o Bit 2. 0 = Ultimo fragmento, 1 = Más fragmentos por recibir.
•
Posición de fragmentación. Indica, si el paquete está fragmentado, que posición
ocupa en el datagrama original.
•
Tiempo de vida. Indica el tiempo máximo que el paquete tiene permitido estar en
el sistema de internet.
•
Protocolo superior. Protocolo al que debe entregarse el datagrama IP, algunos de
los valores más comunes se muestran en la tabla 2.2:
Protocolo
ICMP
TCP
UDP
EIGRP
OSPF
Valor decimal
1
6
17
88
89
Valor hexadecimal
0x01
0x06
0x11
0x58
0x59
Tabla 2.2 – Valor decimal y hexadecimal de algunos de los protocolos más utilizados en el
protocolo de Internet.
•
Checksum. Suma de comprobación para control de errores, solo se aplica al
encabezado para corroborar el destino del paquete.
•
Dirección origen. Dirección IP del emisor.
•
Dirección destino. Dirección IP del receptor.
•
Opciones. Estos campos pueden estar o no en los datagramas, estas son variables
en longitud.
Capítulo II. Enfoque teórico
40 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.3.7. Enlace de datos y medio físico.
El propósito general de un modelo de referencia, como el OSI, es la intercomunicación
entre capas, pero de igual manera una ventaja de utilizar un marco como éste es la relativa
independencia de cada una de ellas con respecto a las otras.
Existen varios métodos de acceso al medio, de igual manera especificaciones físicas para
alcanzarlo. Hay muchas combinaciones distintas con respecto a estas especificaciones,
puede tenerse una transmisión por medio de UTP o por aire (Wireless) así mismo varios
accesos al medio (Ethernet, CDMA (Acceso Múltiple por División de Código), TDMA
(Acceso Múltiple por División de Tiempo), etc.). Sin embargo, debido a la independencia
de estas capas se nos brinda la posibilidad de encapsular esta información, dicho de otra
manera, pueden obviarse los accesos al medio y las definiciones físicas siempre y cuando
están no interfieran con lo desarrollado.
Mientras nuestro dispositivo cuente con una dirección de internet y un puerto de escucha,
necesarios para las peticiones hacia la capa alta de protocolo de sesión y de aplicación con
HTTP, la aplicación no necesitará un apartado especial de tratado para estas capas.
Analicemos el funcionamiento básico del sistema de interconexión CEM.
Cuenta con un servicio basado en HTTP y modelado para trabajar sobre este mismo
protocolo, REST (Véase sección 3.2), nuestro punto de partida será el publicado de una
dirección IP con un puerto de escucha, así que como llegue ahí la información no es de la
incumbencia del servicio.
Sus consumidores, los teléfonos móviles inteligentes necesitan la misma dirección y el
puerto para establecer la sesión de envío de información, así que también trabajaran desde
la capa de red a sus superiores, obviando la llegada de información, la segunda función de
éstos es consultar la página de descarga, que es básicamente el mismo proceso pero sobre
un puerto default de internet, así que el caso sigue manteniéndose.
Capítulo II. Enfoque teórico
41 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Finalmente, la página de descarga de la aplicación hace la contraparte del cliente, entregar
desde un servidor de aplicaciones el ejecutable capaz de instalar la aplicación, una vez más
la información llegará encapsulada y mientras llegue de manera correcta -mecanismo que
aseguran el conjunto de protocolos de internet TCP/IP- no importa la manera de llegada.
Así entonces, se hace hincapié en que solo es necesaria la llegada de la información sin
importar como sea esta transportada, haciendo uso de la característica de independencia del
marco de referencia OSI.
2.4. Comunicación en el protocolo de transporte
TCP permite que múltiples aplicaciones se comuniquen al mismo tiempo, esto lo hace
demultiplexando el tráfico de TCP entre los programas, este protocolo utiliza números de
puerto para identificar el destino del tráfico dentro de la máquina, el identificador de este
puerto es un número, compuesto de 2 bytes y que representan 65535 posibles opciones
repartidos como indica la figura 2.18:
Figura 2.18 – Propósito de los puertos del protocolo TCP
Los primeros 1024 puertos son los “puertos conocidos” son utilizados por protocolos
utilizados por el sistema, por ejemplo HTTP, SMTP, etc., desde este punto hasta el puerto
número 49151 son “puertos registrados” y pueden ser utilizados por cualquier aplicación,
finalmente desde el puerto 49152 en adelante se conocen como “puertos dinámicos”
Capítulo II. Enfoque teórico
42 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
debido a que las aplicaciones los utilizan y asignan dinámicamente para crear una
conexión.
Estos puertos crean una abstracción de la conexión recibida, ya que los objetos recibidos
son identificados como circuitos virtuales de conexión y no solo como un número de
puerto, esto es, ya que la naturaleza de TCP es ser un puerto extremo a extremo, las
conexiones son circuitos lógicos de pares de “extremos finales” o “endpoints” –como son
nombrados en toda la literatura acerca de estos-.
Cada extremo de la comunicación corresponde a la dirección IP y el puerto de aplicación,
así entonces, el tráfico TCP será enviado a la aplicación debida mientras pueda ser
identificado por estos dos parámetros, es por esto, que la comunicación puede ser
concurrente y que un puerto TCP puede compartir múltiples conexiones, este esquema de
conexión se describe en la figura 2.19:
Figura 2.19 – Diagrama esquemático del apilamiento de peticiones a través de puertos TCP.
Capítulo II. Enfoque teórico
43 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2.4.1. Sockets de comunicación.
El tipo de conexión abstracta provista por el protocolo TCP es muy importante desde el
punto de intercomunicación de aplicaciones y de la programación de las mismas. Cuando
se desarrolla un programa que tiene como objetivo la interconexión de sistemas pueden
desarrollarse servicios que acepten conexiones simultaneas a distintos recursos que son
servidos desde distintos puertos.
El encapsulamiento de la funciones de comunicación que provee el protocolo de transporte
a través de los puertos es una manera de simplificar la misma intercomunicación de los
sistemas, esto se realiza a través de una interfaz entre las aplicaciones que tratan de
comunicarse a través de dicho protocolo, esto es llamado socket de red.
El socket de red corresponde al proceso mencionado en la sección 2.4 del presente trabajo,
se puede describir como un extremo de la red para un flujo de comunicación entre
procesos, estos deben ser identificados a través de la red con el fin de la localización de los
procesos, esto se realiza por medio de la dirección del socket. Esta dirección corresponde a
la dirección IP de la máquina que realiza la petición y el puerto de aplicación, como se
muestra en la figura 2.20:
Figura 2.20 – Formato de un socket de comunicación red.
Así cuando queremos abrir un socket para comunicación del protocolo HTTP de internet
desde una máquina cuya IP es 126.10.10.10, hacia otra IP cuyo valor es 123.11.11.11 la
dirección del socket quedaría de la siguiente manera:
[126.10.10.10:80] , [123.11.11.11:80] 13
13
Cabe mencionar que el número de puerto correspondiente al protocolo HTTP [80] para la apertura de
socket a través de cualquier navegador está implícito en la llamada, es por ello que si hacemos la petición
Capítulo II. Enfoque teórico
44 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Los sockets de red o sockets de internet pueden ser implementados en los protocolo de
transporte UDP y TCP, así como sobre el protocolo de internet IP, por ello la distinción
entre tipos de sockets es manejada de la siguiente forma:
•
•
•
Socket de datagrama (Datagram socket). Es un socket para redes no orientadas a
conexión, en este tipo de socket solo son enviados en número de puerto destino y
origen, al ser NO orientados a conexión, se implementan en protocolos del mismo
tipo, típicamente UDP.
Socket de flujo de datos (Stream socket). Provee las características de un
protocolo orientado a conexión (Secuenciamiento, comprobación de errores, etc.)
contienen mecanismos para crear y terminar conexiones así como de detección de
errores, permite el envío y mantenimiento de la conexión confiables, típicamente
son implementados en el protocolo de transporte TCP.
Sockets directos (Raw sockets). Son sockets implementados directamente sobre la
capa de red, en el protocolo IP, a diferencia de los otros sockets cuando se
implementan y envían no contienen ningún tipo de cabecera de protocolo superior,
solo el datagrama de IP.
Debido a que el presente trabajo utiliza una arquitectura que decae directamente en el
protocolo TCP y cuyas peticiones remotas se hacen sobre el mismo protocolo, la
explicación pertinente y descripción de utilización de sockets se hará a partir de los del tipo
orientado a conexión.
El proceso de implementación de sockets fue uno de los inicios en la creación de servicios
de consumo por medio de internet. Antes del encapsulamiento de las rutinas de
intercomunicación entre equipos, provista por protocolos e interfaces de uso de protocolo
como RPC, tenemos la implementación por este medio de comunicación.
Es así como se diseña la interfaz para implementación de sockets, el API de sockets
(Socket API). Esta interfaz de programación está diseñada para la comunicación de
aplicaciones sobre los protocolos de internet TCP/IP, asimismo, se puede encontrar que el
trabajo realizado por este API es igualmente nombrado que la abstracción de procesos de
intercomunicación entre aplicaciones de red, el término socket.
126.10.10.10:80 para un recurso de web, también es posible alcanzarlo sin utilizar el puerto TCP, como
126.10.10.10.
Capítulo II. Enfoque teórico
45 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Se puede pensar en el proceso de creación y comunicación por medio de sockets como una
generalización del acceso a un sistema de archivos, esto es, así como en el proceso de
sistema de acceso a un archivo necesario, el sistema operativo debe trazar una ruta de
localización además de crear una conexión para obtener el flujo de datos, manera similar
que lo realizado con el trazado por medio de la dirección del socket y la conexión en el
protocolo TCP por medio de circuitos lógicos.
Para una comunicación por medio de sockets se debe primero crear uno de ellos. Esta
operación proveerá un enlace por medio del sistema operativo hacia un archivo o
dispositivo remoto, por medio de una descripción de socket para después ejecutar alguna
operación primitiva de leer o escribir.
Así entonces, cuando una aplicación crea un socket, resultado de la ejecución de una
petición remota, el origen utiliza la primitiva de escribir para mandar el flujo a través de la
conexión –su contraparte utilizará entonces la primitiva leer para recibir el flujo y ejecutar
la acción- , para hacer esto posible el sistema operativo aloja tanto los descriptores del
socket como de acceso a archivo con el mismo tipo de respuesta y asegurándose que la
respuesta sea alojada en el descriptor del archivo.
Este proceso, aunque fuera del alcance del presente trabajo, debido a la encapsulación por
los procesos de alto nivel que realizan la intercomunicación de los servicios, se retomará
más a fondo en el apéndice B.
Capítulo II. Enfoque teórico
46 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Referencias.
[1]
ISO/IEC 7498-1,
http://www.ecmainternational.org/activities/Communications/TG11/s020269e.pdf
[2]
Douglas E. Comer, Internetworking with TCP/IP: Principles, protocol and architectures.
Prentice Hall, Cuarta Edición.
[3]
Andrew S. Tanenbaum, Redes de computadoras. Pearson, 2003.
[4]
Alfred V. Aho, et al., Compilers: Principles, techniques and tools. Pearson Education,
1986.
[5]
Java SE specifications, http://docs.oracle.com/javase/specs/
[6]
Managed Execution Process, http://msdn.microsoft.com/en-us/library/k5532s8a.aspx.
[7]
Common Language Runtime Overview,
http://msdn.microsoft.com/en-us/library/ddk909ch(vs.71).aspx.
[8]
RFC 2616, http://www.ietf.org/rfc/rfc2616.txt.
[9]
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies, http://tools.ietf.org/html/rfc2045
[10]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Type,
http://tools.ietf.org/html/rfc2046
[11]
The MIME Multipart/Related Content-type, http://tools.ietf.org/html/rfc2387.
[12]
RFC 1057, http://www.ietf.org/rfc/rfc1057.txt.
[13]
RFC 793, http://www.rfc-es.org/rfc/rfc0793-es.txt
[14]
RFC 791, http://tools.ietf.org/html/rfc791
Capítulo II. Enfoque teórico
47 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Capítulo III. Enfoque práctico.
En el capítulo anterior se mostró de manera teórica como se realiza la comunicación entre
dispositivos, en este capítulo se muestra un escenario en la realidad, es decir, que
tecnologías se utilizarían para implementar la comunicación diseñada, también se hará una
breve explicación de estas tecnologías utilizadas en cada una de las principales secciones
de la aplicación propuesta así como la explicación de porqué fueron escogidas de entre
todas las demás.
El sistema propuesto CEM es una aplicación cliente que consumirá un servicio web, el
cuál proveerá de información a los padres acerca de los alumnos registrados, esta
aplicación estará disponible para su descarga desde el navegador nativo de Android y se
instalará en el dispositivo usado para relacionar la información del usuario con las
actualizaciones provistas por el servidor, previo registro.
El diagrama esquemático de la aplicación se muestra en la figura 3.1.
Figura 3.1 – Diagrama esquemático del sistema CEM.
Capítulo III. Enfoque práctico 48 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
En la figura 3.1 se ilustran los principales componentes de la aplicación de prueba CEM,
esto son:
a) Aplicación cliente. Son las aplicaciones consumidoras del servicio Web, estas
aplicaciones están desarrolladas para el sistema operativo Android.
b) Servicio web de actualización. Este servicio desarrollado para la plataforma
Windows (Misma donde reside el servidor de actualización). Corresponde a la
arquitectura de modelado REST (Transferencia de Estado Representacional), cuyas
principales ventajas son la ligereza en cuanto a recursos y el eficiente manejo de
protocolos, conceptos son profundizados en la sección 3.3.
c) Base de datos. Este componente tiene la función primordial de guardar de manera
estructurada los datos necesarios para el funcionamiento del sistema CEM.
d) Aplicación de escritorio CEM. Es la aplicación auxiliar para el llenado de la base
de datos diseñada específicamente para el caso de prueba.
Antes de cualquier tipo de explicación formal acerca de cada uno de los componentes de la
aplicación CEM, nos ocuparemos de la descripción del lenguaje en el cuál son escritos,
esto corresponde a los procesos de compilado y ejecutado, pertenecientes a los componente
que están en contacto con la última capa del modelo OSI, la capa de aplicación.
3.1. Los lenguajes de programación.
Una vez que se tiene la noción de lo que la aplicación realizará y del pertinente diseño, es
decir, el proceso de planeado y modelado de la aplicación, llega el momento de la
codificación. Al término de esto obtendremos una aplicación lista para instalarse. Esta
aplicación desarrollada será el puente entre el usuario y la última de las capas del modelo
Capítulo III. Enfoque práctico 49 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
OSI, la de aplicación, una explicación complementaria se encuentra en la sección 2.3.1,
para ambos lenguajes que se utilizarán en la secciones del sistema CEM.
3.1.1. La aplicación del lado del servidor, C#.
En esta parte se explicara un poco sobre el lenguaje de programación C# (Pronunciado C
Sharp) en el cual están codificadas las secciones correspondientes al servicio Web y la
aplicación prueba de escritorio del sistema CEM (Incisos b y d del modelo 3.1) así como
sus características principales y las facilidades que ofrece frente a otros lenguajes.
Parece pertinente el sentar las bases antes de entrar con la explicación del lenguaje de
programación en sí, ya que este lenguaje es parte del cuadro de trabajo de la plataforma
.Net (.Net framework), se procederá a realizar una breve explicación de este cuadro de
trabajo.
3.1.1.1.
El cuadro de trabajo .Net.
El framework o cuadro de trabajo de .NET es donde conviven los lenguajes de
programación, bibliotecas de clases para el realizado de tareas. En este cuadro de trabajo
encontraremos el lenguaje de programación antes mencionado, C#. El cuadro de trabajo en
el cual el sistema CEM fue desarrollado es la versión 3.5
.Net fue diseñado con tres objetivos en mente:
•
Lograr aplicaciones Windows más estables con mayor grado de seguridad.
•
Amplificar el desarrollo de aplicaciones y servicios web que no solo funcionen en
plataformas tradicionales, sino también en dispositivos móviles.
•
Proporcionar un solo grupo de bibliotecas que pudieran trabajar con diferentes
lenguajes
Capítulo III. Enfoque práctico 50 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Ya sabiendo a que pertenece el lenguaje podemos retomar el concepto. El lenguaje de
programación C# fue creado por el danés Anders Hejlsberg quien diseñó también los
lenguajes Turbo Pascal y Delphi. Este lenguaje de programación está orientado a objetos,
esta forma de programación ahorra mucho código, lo cual indica que partes de código serán
reutilizables para no volverlas a escribir con esto se pretendió que incorporase las ventajas
o mejoras que tiene el lenguaje Java y tuviese las ventajas del C/ C++.
C y C++ han sido los lenguajes elegidos para desarrollar aplicaciones comerciales y de
negocios. Estos lenguajes proporcionan un altísimo grado de control al programador
permitiendo el uso de punteros y muchas funciones de bajo nivel. Sin embargo cuando se
comparan lenguajes como C# con C/C++, uno se da cuenta de que aunque C/C++ son más
potentes, se necesita muchísimo más tiempo para desarrollar una aplicación.
Las principales características del lenguaje de programación C# se enuncian a
continuación:
• Homogéneo. El tamaño de los tipos de datos básicos es fijo e independiente del
compilador, sistema operativo o máquina en la que se compile.
• Orientado a objetos. C# soporta todas las características propias del paradigma de la
programación orientada a objetos: encapsulación, herencia y polimorfismo.
• Facilita el mantenimiento. Incluye una política de versionado que permite crear
nuevas versiones de tipos sin temor a que la introducción de nuevos miembros
provoquen errores difíciles de detectar en tipos heredados previamente desarrollados
y ya extendidos con miembros de igual nombre a los recién introducidos.
• Compatibilidad. Mantiene una sintaxis muy similar a C++ o Java que permite, bajo
ciertas condiciones, incluir directamente en código escrito en C# fragmentos de
código escrito en estos lenguajes.
Se puede concluir que C# es un lenguaje orientado al desarrollo de componentes ya que
estos son objetos que se caracterizan por sus propiedades, métodos y eventos, desaparece
la distinción entre tipos primitivos y objetos de lenguajes como Java o C++, el mecanismo
automático de recolección de basura, la gestión de excepciones, la comprobación de tipos,
Capítulo III. Enfoque práctico 51 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
la gestión de versiones, entre otras, ayudan a desarrollar software fácilmente mantenible y
poco propenso a errores.
Como se mencionó en la sección 2.3.1 este lenguaje de programación será el que estará en
contacto con la última capa del modelo OSI, la capa de aplicación. La aplicación
desarrollada contará con una capa de abstracción propia de Windows que hará que dicha
aplicación pueda ser ejecutada por cualquier hardware mientras utilice el sistema operativo
de Windows. Este escenario se ilustra en la figura 3.2:
Figura 3.2 – Proceso de compilado bajo la tecnología .Net.
El programa compilado nos entregara un código en lenguaje intermedio (CIL14) o
bytecode, el cuál será traducido a lenguaje máquina por medio de la capa de abstracción
antes mencionada, que para Microsoft será el lenguaje en tiempo de ejecución CLR15.
3.1.2. El trabajo del lado del cliente, Java.
El manejo del comportamiento de la aplicación cliente, tomará la perspectiva de desarrollo
en Java, aun cuando sea tarea de Android. Esto es, el desarrollo en Android tiene sus
propias reglas acerca del manejado de objetos, reglas basadas en como el sistema operativo
controla su ciclo de vida, su presentación y su desempeño, este comportamiento se
describe un poco más a detalle en la sección 3.4. Sin embargo no se debe olvidar que las
14
De las siglas Common Intermediate Language.
De las siglas Common Language Runtime. Es un entorno de ejecución para códigos sobre la plataforma
.Net. No es en sí una máquina virtual debido a que cuando el código es compilado corre nativamente sobre un
sistema en Windows, por tal, el CLR solo corre bajo un ambiente de Microsoft Windows. 15
Capítulo III. Enfoque práctico 52 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
llamadas a los métodos descritos por el kit de desarrollo de Android yacen en el lenguaje
de programación Java, en otras palabras el control del sistema lo realizan los componentes
provistos por el SDK (Kit de desarrollo de software) de Android pero la traducción
desarrollada por el programador para el control de estos componentes esta en Java.
Java es un lenguaje que tiene como propósito esencial operar en múltiples plataformas en
redes heterogéneas, mantiene una postura neutral a la arquitectura, además de ser portable
y dinámicamente adaptable [2], está inspirado tanto en C y C++.
Podemos destacar los siguientes puntos del lenguaje de programación:
•
Orientado a objetos. Está diseñado a ser orientado a objetos pero también incorpora
tipos primitivos para el desarrollo, sin embargo estos tipos pueden “elevarse” a la
categoría de objetos envolviéndolos dentro de un objeto en sí.
•
Herencia. Soporta herencia simple, remueve el concepto de herencia múltiple de
C++ pero puede simular este proceso con el uso de interfaces.
•
Desarrollo distribuido. Las aplicaciones pueden ser migradas fácilmente a varios
sistemas. Esta característica está basada en la abstracción de software y hardware que
provee la JVM, por lo que se considera neutro en ese aspecto además de portable sin
sacrificar la confiabilidad de la aplicación.
•
Multihilo. Permite el procesamiento múltiples hilos de ejecución de manera sencilla,
también define librerías para la ejecución de procesos concurrentes de manera
segura, como los mecanismos de cerraduras o esperas de término de hilo.
Java añade un recolector de basura cuyo principal fin es el de eliminar todos los objetos
que no están en uso, esto lo hace básicamente con un mecanismo que revisa lo que se está
ocupando en el instante y revisando las referencias a objetos no necesarios.
La aplicación cliente que yace en el teléfono móvil está programa en este lenguaje de
programación, el uso de Java nos permite la portabilidad de la aplicación en el hardware
que esté corriendo por la implementación de la JVM, para el ámbito de Android esta
abstracción la realiza la máquina Dalvik que se podría considerar un variación de la JVM
optimizada para el sistema operativo de Google.
Capítulo III. Enfoque práctico 53 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Al igual que en el entorno del cuadro de trabajo de .Net, Java utiliza un proceso
intermediario para la abstracción de hardware del ordenador, pero además, incorpora una
abstracción para el sistema operativo en el que yace, esto es, a favor de la interoperabilidad
Java utiliza distintas versiones de su software intermediario para funcionar en distintos
sistemas operativos, cuyo nombre es la máquina virtual de Java (JVM). Este
comportamiento se muestra en la figura 3.3:
Figura 3.3 – Diagrama de compilado de un programa con uso de la JVM
3.1.3. La construcción de la base de datos, SQL.
La sección c del modelo 3.1 correspondiente a la consulta y administración de la base de
datos se realiza con el lenguaje de consulta estructurado SQL (Structured Query Language)
que usa una combinación de álgebra relacional y construcciones del cálculo relacional.
Aunque el lenguaje SQL se considere un lenguaje de consultas, contiene muchas otras
capacidades además de la consulta en bases de datos. Incluye características para definir la
estructura de los datos, para la modificación de los datos en la base de datos y para la
especificación de restricciones de seguridad. [4]
Este lenguaje está basado en consultas o sentencias que pertenecen a dos categorías
principales: Lenguaje de Definición de Datos, DDL y Lenguaje de Manipulación de Datos,
DML.
Capítulo III. Enfoque práctico 54 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Estos se refieren a la manera de clasificar las sentencias de lenguaje SQL en función de su
cometido. La diferencia principal reside en que el DDL crea objetos en la base de datos y
sus efectos se pueden ver en el diccionario de la base de datos; mientras que el DML es el
que permite consultar, insertar, modificar y eliminar la información almacenada en los
objetos de la base de datos.
Se utilizará SQL Server –Véase sección 4.1.3– como motor de base de datos, por lo que el
codificado responde también a la versión de este administrador, siendo T-SQL, un estándar
extendido del mismo SQL.
T-SQL es una extensión al SQL de Microsoft y Sybase, el cuál expande el estándar de
SQL para incluir programación procedural, variables locales, varias funciones de soporte
para procesamiento de cadenas de texto –Strings- , procesamiento de fechas, matemáticas,
etc., y cambios a los estatutos DELETE y UPDATE.
3.1.3.1.
Acceso a base de Datos.
El acceso a SQL Server se da mediante un listado de protocolos que este permite, entre los
que destacan:
•
Memoria compartida. Permite la conexión a una instancia de SQL Server que se
está ejecutando en el mismo equipo. No se puede utilizar para obtener acceso desde
otros equipos de la red.
•
TCP/IP. Permite acceso de red a SQL Server especificando el nombre del equipo y
el de la instancia o la dirección IP y el nombre de instancia.
•
Arquitectura de interfaz virtual (VIA). Se utiliza para redes de área del sistema,
que son redes de alta velocidad que conectan servidores o clústeres de servidores.
Estos protocolos aplican a conexiones entre usuarios e instancias del mismo motor, cuando
se quiere un acceso a la base de datos de SQL Server este trabajo recae en objetos de
conexión, lo que Microsoft denomina ADO.
Capítulo III. Enfoque práctico 55 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
ADO (ActiveX Data Objects) contiene la colección de objetos para crear una conexión a
bases de datos y leer datos desde tablas, trabajando como una interface hacia la fuente de
datos. ADO, sin embargo, no se comunica directamente con la base, sino que accede a ella
a través de una interface intermediaria llamada OLE DB. En general, después de crear una
conexión a la base de datos, se puede ignorar la existencia de OLE DB, debido a que este
driver hace todo su trabajo en segundo plano.
Existen dos maneras para que el proveedor OLE DB brinde acceso a una base de datos.
•
Indirectamente. Mediante un driver ODBC (Open DataBase Connectivity) el cual
es estándar de acceso a bases de datos que utilizan los sistemas Microsoft. A través
de ODBC, en un sistema Windows se puede conectar con cualquier base de datos
de la que exista un driver ODBC
Para conectar con ODBC una base de datos se ha de crear un DSN (Data Source
Name), que es un nombre que asociamos a una conexión por ODBC para referirnos
a ella desde las aplicaciones o programas que deban conectarse con la base de datos.
Cualquier base de datos que se pretenda utilizar desde aplicaciones Windows debe
tener su propio driver ODBC.
•
Directamente. Mediante un driver OLE DB nativo. El proveedor de datos .NET
Framework para OLE DB usa OLE DB nativo con el fin de habilitar el acceso a
datos mediante la interoperabilidad COM, a continuación se enuncian algunos de
los proveedores a distintas bases de datos:
o SQLOLEDB (Proveedor Microsoft OLE DB para SQL Server).
o MSDAORA (Proveedor Microsoft OLE DB para Oracle).
Capítulo III. Enfoque práctico 56 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
3.2. La página de hospedaje.
Es la página desde donde se descarga la aplicación desde el navegador nativo de Android,
está desarrollada en simple HTML y hospedada en el servidor web de Windows IIS. Aun
cuando este componente no está dentro del sistema CEM, es necesario para el
funcionamiento, ya que será aquí donde se obtenga el archivo de instalación del programa
para el teléfono móvil.
Este componente corresponde a una página codificada en el lenguaje de marcado HTML
(Véase sección 3.2.1) desde la cual se obtiene el archivo de instalación a través de un
proveedor del servicio, que en este caso será el servidor de aplicaciones de Microsoft, IIS
(Internet Information Services), descrito en la sección 3.2.2
3.2.1. HTML (HyperText Markup Language)
Es un lenguaje de marcado con el cuál se puede presentar una página web de forma
estructurada, se basa en etiquetas o tags que hacen la función de dar presentación o
adjuntar otro tipo de contenido a la información.
Al igual que otras tecnologías para creación de páginas web, permite el uso de scripts de
programación que son utilizadas para dar contenido dinámico a los elementos en pantalla
así como un comportamiento específico.
La ventaja y razón por la cual se utilizó este lenguaje por encima de otros para la página de
hospedaje son la ligereza y sencillez debido a que solo se necesita mostrar el enlace y las
instrucciones de instalación, a diferencia de lenguajes como ASP o JSP que utilizan el
mismo HTML para la presentación pero guardan código complejo para tareas más
avanzadas como guardar en base de datos, presentaciones secuenciales y asíncronas de la
página, etc.
Capítulo III. Enfoque práctico 57 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Este lenguaje interactúa directamente con el protocolo de la capa OSI HTTP, situado en el
séptimo nivel, la capa de aplicación.
3.2.2. IIS (Internet Information Services).
A través de este servidor de aplicaciones se expone un recurso al internet, que en el caso de
prueba será la página de descarga, mostrada en la figura 3.2.
Se trata del servidor web, lo que quiere decir que trabaja del lado del servidor, como su
nombre lo indica, y que hospedará la página además de brindar los servicios necesarios
para esta tarea, también interactúa sobre la capa 7, de aplicación, del modelo OSI.
Está integrado en el sistema operativo a utilizar para la aplicación propuesta, Windows 7,
solo basta con activar las características dentro del mismo sistema operativo, como se
muestra en 4.3.
Uno de los puntos de referencia para utilizar x o y servidor web se basan en la plataforma a
operar ya sea de la familia Windows o UNIX.
Se utiliza este servidor de hospedaje, en primera por la razón de que aunque la página está
codificada en HTML plano con scripts, puede expandirse a una que necesite código
complejo, nativo de Windows, lo que se traduce en una plataforma .NET, para lo cual IIS
tiene soporte completo, además este servidor web ofrece características de modularidad y
escalabilidad y sobre todo sencillez a la hora de depurar y diagnosticar problemas.16
En segunda, se descartan otras opciones de servidor web, como por ejemplo Apache, por el
hecho de que el servicio de actualización se encuentra físicamente en el mismo equipo que
el servidor de hospedaje y este servicio también está desarrollado en tecnología .NET, que
trabaja en plataforma Windows, y aunque las otras versiones pueden servir también la
página, el servidor web IIS es nativo de Windows.
16
Tomado de http://www.iis.net/overview Capítulo III. Enfoque práctico 58 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
3.3. La aplicación de actualización.
Los servicios web (Web services, en inglés), son software para intercambiar información
entre aplicaciones, estos pueden ser publicados, alojados e invocados a través de Internet,
los web services deben tener las siguientes características:
•
Encapsulados. Lo que quiere decir que no debe mostrarse la implementación de
las funciones internas, lo único que nos interesa saber es lo que realiza y que se
necesita para realizarlo.
•
Vagamente acoplados. Un cambio en su implementación no debe significar un
cambio también en su invocación.
•
Exposición de contrato. El comportamiento y su función debe ser descrito y
accesible para cualquiera que pueda invocarlo.
Un web service nos asegura el soporte eficiente entre Web y ambientes más restringidos
correspondientes a un entorno especializado, además, adopta estándares abiertos17 por lo
que alienta la compatibilidad e interoperabilidad de componentes, así entonces, para
invocar o consumir un servicio no se hace distinción del lenguaje de programación
utilizado o la plataforma sobre la que se corra tanto el servicio como el consumidor.
La tarea principal de un web service es simplemente el intercambio de mensajes, estos
mensajes, como se comentó, viajan a través de internet o de una red local, a través de
protocolos abiertos; los protocolos más utilizados para este intercambio son HTTP,
HTTPS, HTTPR, FTP, SMTP, entre otros.
El diagrama 3.5 representa la relación entre los componentes de un web service:
17
Especificaciones públicas abiertas a cualquiera sin necesidad de pago de regalías, i.e. GSM, TCP, IP, etc. Capítulo III. Enfoque práctico 59 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.4 – Relación entre componentes de un Web-Service.
Como se muestra en la figura 3.4 tenemos tres principales componentes:
•
El distribuidor del servicio, que es un intermediario entre el proveedor y el
consumidor, controla las peticiones y publica las descripciones necesarias.
•
El proveedor del servicio, contiene la información y publica el servicio por medio
del distribuidor.
•
El consumidor del servicio, pregunta al distribuidor acerca de la adquisición
además de crear un enlace con el proveedor
Algunos ejemplos son la consulta de ventas a través de internet, tareas para resolución de
problemas remotamente, etc.
3.3.1. Diferencias entre las arquitecturas REST y SOA
Una vez definido lo que un web service es capaz de hacer nos encontramos con la tarea del
modelado, la planeación de este tópico nos entrega la eficiencia en recursos, el acceso a
estos, entre otras tareas, mismas que deben ser calculadas de acuerdo a nuestras
Capítulo III. Enfoque práctico 60 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
necesidades, por ello parece pertinente hacer una comparación entre las posibles
alternativas. En la actualidad el modelado o estilo de arquitectura recae en los siguientes
listados:
•
RPC (Remote Procedure Calls, Llamadas a procedimientos remotos). Son las
primeras herramientas presentadas para servicios web, se caracterizan por ser
fuertemente acoplados18 y se implementan por el mapeo de servicios directos a
funciones o llamadas a métodos. La unidad de comunicación en la operación es el
documento WSDL.
•
SOA (Service-Oriented Architecture, Arquitectura Orientada a Servicios). La
unidad básica de comunicación es el mensaje, estos servicios están débilmente
acoplados19, además, encapsulan la implementación volviéndose altamente
interoperables. Identifican la utilización del servicio por un “contrato” empleando
SOAP y WSDL.
•
REST (REpresentation State Transfer). Emulan el protocolo HTTP restringiendo la
interfaz a un conjunto de operaciones, este estilo se centra en la interacción del
recurso en lugar del mensaje u operaciones.
En la actualidad, las arquitecturas de modelado de web services más populares son SOA y
REST, es por ello que se entra en debate acerca de cuál sería más adecuado para un
problema propuesto, es por ello que se deben contemplar las ventajas y desventajas de cada
una de ellas, éstas se muestran en la tabla 3.1:
18
En una modelo fuertemente acoplado las aplicaciones o componentes mantienen un alto grado de dependiencia entre ellos, perjudicando la interoperabilidad de componentes y la tolerancia a fallas. 19
Una arquitectura débilmente acoplada favorece la interoperabilidad y la tolerancia a fallos o cambios, esto es debido a que los componentes mantiene un alto grado de independencia, esto es, en esta arquitectura debe aceptarse y compartirse lo menos posible las funciones correspondientes al componente. Capítulo III. Enfoque práctico 61 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Ventajas
REST
SOA
Bajo consumo de recursos.
Fácil de utilizar.
Los clientes pueden tener una
Las operaciones complejas pueden ser
interfaz de escucha para
encapsuladas.
notificaciones.
Variedad de herramientas de
Fácil de construir y adoptar.
desarrollo.
Instancias creadas explícitamente
Desventajas
Se genera un gran número de
Los clientes necesitan conocer el
objetos.
contrato de uso antes de consumirlos.
Descripción informal.
Las instancias se crean implícitamente.
Tabla 3.1 – Comparación de las arquitecturas de servicios web REST y SOA.
Existen varias diferencias entre ambas arquitecturas, a continuación se señalan algunas de
ellas:
•
Manejo del protocolo.
REST utiliza HTTP como protocolo de aplicación, esto es, crea un conjunto de
reglas acerca de cómo utilizar el protocolo HTTP, además tiene una cantidad de
operaciones conocidas sobre éste protocolo para realizar tareas específicas del lado
del servidor, estas son PUT, POST, DELETE y GET, correspondientes a las tareas
de escribir un recurso, procesar una petición, borrar un recurso y obtener un
recurso, mientras que SOA lo utiliza como un protocolo de transporte, para enviar
los mensajes dentro de una “envoltura” sobre dicho protocolo. Este manejo también
es aplicable a la versión segura de protocolo HTTP, HTTPS. Este manejo de la
seguridad del protocolo en la arquitectura REST afecta directamente al paquete
enviado, mismo que contiene la tarea, mientras que para el caso de la arquitectura
SOA, el paquete se realiza de la manera habitual en cuanto a cuestiones de
seguridad, debido a que la “envoltura” nada tiene que ver con la petición , si no con
el “payload” o carga de transferencia.
Capítulo III. Enfoque práctico 62 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
En la figura 3.5 se muestra la manera de envío de mensajes bajo ambas
arquitecturas:
Figura 3.5 – Diferencias entre las arquitecturas a) REST y b) SOA para el manejo del protocolo
HTTP.
•
Estado de la comunicación.
La falta de estado mejora el rendimiento de un web service y simplifica el diseño e
implementación de componente del lado del servidor, esto es debido a que el
servidor no tiene la necesidad de sincronizar los datos de sesión con una aplicación
externa.
Figura 3.6 – Comunicación basada en una arquitectura con estado.
Capítulo III. Enfoque práctico 63 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
En la figura 3.6 se muestra un servicio con estado, la petición a una página implica
el conocimiento de un estado anterior, es por ello que se muestra la petición hacia
una página siguiente en lugar de una página en específico, en un diseño con estado
el servicio incrementa y guarda el resultado de la página previa para saber en qué
estado se encuentra y asumirlo para la siguiente consulta. Con respecto a los
mensajes, estos solo contienen los datos más no alguna información del estado de la
conversación.
Figura 3.7 – Comunicación basada en una arquitectura sin estado.
Cuando se realiza un diseño sin estado, como el mostrado en la figura 3.7, el
servicio genera una respuesta que se enlaza con un número de página y deja al
cliente realizar lo necesario para guardar este valor, es decir, los recursos contienen
además de los datos los enlaces a un estado válido, debido a esto un diseño REST
descansa sobre las responsabilidades de ambas partes que son:
•
Servidor. Genera respuestas que incluyen enlaces a otros recursos que permiten a
las aplicaciones navegar entre recursos relacionados, las respuestas indican si se
guarda o no caché para mejorar el rendimiento reduciendo el número de peticiones
a recursos duplicados.
•
Cliente. Envía peticiones completas que pueden ser provistas independientemente
de otras peticiones, con esto, mantienen el estado siguiendo los enlaces provistos
por el servidor.
Capítulo III. Enfoque práctico 64 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
3.3.2. Web Service REST-WCF
Se utilizó un servicio web con arquitectura en REST, cuyas ventajas entre las que figuran
consumir pocos recursos y tener URIs autodescriptivas fueron yo enlistadas con
anterioridad, sin embargo, el tópico final es como desarrollarlo. Como se mencionó antes
el servidor se basa en un núcleo de Windows, se hará de la misma manera con el servidor
de aplicaciones IIS (Internet Information Services), que es propietario de Microsoft, por lo
que parece pertinente que la exposición del web service también se haga por medio de esta
tecnología. Se opta por la alternativa provista por el mismo cuadro de trabajo de .Net, esta
es un desarrollo en WCF (Windows Communication Foundation).
El kit de desarrollo para REST viene ya incluido en el entorno de programación utilizado
para este caso, Visual Studio 2008, solo implica añadir las librerías para tratamiento web
de dicho IDE, estas son:
-
System.ServiceModel
-
System.Net
Así como realizar el modelado necesario para desempeñar dicha labor, esto es:
a) Desarrollar la tarea.
b) Definir el método.
c) Definir la estructura.
d) Exponer el método.
e) Servir el método.
Capítulo III. Enfoque práctico 65 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.8 – Proceso de modelado de un servicio web.
En resumen, como se muestra en la figura 3.8, los incisos comprendidos de a) a c)
corresponden al modelado de los datos a intercambiar así como su método de serialización,
las tareas realizadas de cada una de la operaciones, además de lo correspondiente a las
bases de datos, respectivamente, es decir, el proceso intrínseco de tratamiento de los datos
a nivel del servicio. Los dos últimos incisos corresponden al diseño del contrato, con eso
nos referimos a la manera en la que el cliente se comunicará con dicho servicio, esto es, los
descriptores necesarios para que la operación se vuelva un punto de entrada a la
funcionalidad y finalmente el proceso de exposición a través de la red, esto es, el canal por
el cuál este servicio estará accesible.
Un punto muy importante para la intercomunicación entre los dispositivos se refiere a
como se va a exponer el método a consumir, para el modelado por REST, y como se
explicó anteriormente, cada uno de éstos corresponde a una URI única dentro del espacio
de nombres que contiene a todo el web service, ésto, en la práctica, significa un modelado
de la petición a realizar, como se muestra en la figura 3.9:
Capítulo III. Enfoque práctico 66 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.9 – Formato de invocación de servicio web.
También en este punto, se debe definir como se invocará a este método, existen, dentro del
framework provisto por Microsoft dos opciones, dependiendo de lo que se necesite
realizar:
a) WebGet. Utilizado para obtener ítems desde el servicio
b) WebInvoke. Permite 3 distintas acciones, que son: POST, PUT y DELETE, para
insertar ítems, actualizar ítems o borrarlos, respectivamente.
3.3.3. Serializado del mensaje.
Finalmente, se tendrá el tipo de codificación en que los mensajes se transmitirán. Para éste
tipo de codificación se elige entre dos, XML o JSON, ambos formatos para intercambio de
datos, utilizados ampliamente para descripción de estructuras o tipos de datos.
XML es un lenguaje autodescriptivo, que puede extenderse después de haber sido
diseñado. En la actualidad, es el más utilizado para formateo de estructuras cuando el
servicio no tendrá un tráfico excesivo, esto es debido a que tiende a volverse demasiado
pesado por su alto nivel de detalle, éste nivel de detalle también complica demasiado la
descripción de las estructuras.
Capítulo III. Enfoque práctico 67 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
JSON es un formato basado en notación de JavaScript utilizado para el intercambio de
datos de fácil conversión o parseo20 y mucho más ligero que XML, también se considera
más sencillo que XML, por ello se opta por esta opción en lugar de su contraparte.
JSON está construido en dos estructuras:
-
Una colección de pares nombre:valor, que representa un objeto o estructura.
-
Una lista de valores ordenados, representando un array o arreglo.
Estas estructuras se muestran en la figura 3.10:
Figura 3.10 – Estructuras de serializado/deserializado en JSON para las estructuras A) Array, B)
Objeto.
20
El término parseo se refiere al proceso de análisis de una expresión para determinar su correcta sintaxis, en adición, este proceso transforma esta expresión a alguna estructura conocida. Capítulo III. Enfoque práctico 68 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
El servicio de actualización se expone con URIs únicas por medio de peticiones HTTP,
como lo explica la arquitectura REST. El consumo de dicho recurso debe de hacerse
también por medio de una petición HTTP, que realizará una aplicación cliente sobre el
sistema operativo para teléfonos móviles inteligentes Android.
3.4. La aplicación cliente.
El último componente del sistema CEM es el que reside en cada usuario, este componente
se trata de una aplicación que solo obtiene las notificaciones por parte del servicio de
actualización. Este componente está desarrollado para el sistema operativo Android, por lo
que antes de entrar en detalle con cualquier aspecto técnico de la aplicación debemos
conocer donde yacerá esta.
Android incluye un sistema operativo, middleware y aplicaciones esenciales para el trabajo
del teléfono, además, el desarrollo en esta plataforma es utilizando Java (Véase sección
3.1.2), aparte de lo incluido en el Android SDK, que provee las herramientas y APIs
necesarios para el control del móvil.
3.4.1. Arquitectura del consumidor
La arquitectura de Android consta de las siguientes capas, que son:
-
Aplicación. Contiene las aplicaciones nativas y desarrolladas por terceros. En esta
capa es donde se encuentra el sistema propuesto.
-
Framework. En esta capa se encuentran todas las aplicaciones esenciales que
controlan las aplicaciones de terceros, son reutilizables y corresponden al cuadro de
trabajo, ésta también sirven como middleware altamente genérico que comunican
Capítulo III. Enfoque práctico 69 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
las
librerías con las aplicaciones en pantalla o servicios programados más
específicos.
-
Librerías. Encontramos las aplicaciones que están en contacto directamente con
los controladores característicos del dispositivo móvil, estos son los controladores
gráficos, de medios y de acceso a datos, los cuales son específicos del móvil
utilizado o versión del sistema operativo, es decir, los que describen a nivel de
hardware el teléfono y los controladores genéricos del sistema operativo en sí. En
esta misma capa se encuentra la máquina virtual Dalvik (De la cual se extenderá en
secciones posteriores) interactuando directamente con las librerías, la cual funciona
como su equivalente, la JVM21, que traduce el código desarrollado en java (.class)
al formato necesario para ser utilizado en Android, el “Dalvik code” (.dex).
El listado de algunas de las librerías más importantes son las siguientes:
-
Librería de medios. Manejan la reproducción y grabación de formatos de video y
audio.
-
Administrador de superficies. Administra el acceso a la pantalla, como el
desplegado de gráficos en 2D o 3D, por parte de las aplicaciones desarrolladas.
-
LibWebCore (Librería de núcleo web). Es un núcleo web que da poder tanto al
navegador web como aplicaciones embebidas web.
-
SQLite. Es el motor que maneja la base de datos relacional, que está disponible
para cualquier aplicación que necesite dichos recursos.
-
Núcleo. El completo sistema de Android es una “transformación” del kernel de
Linux. En esta capa es donde encontramos el reflejo de ello. Este kernel, adaptado a
dispositivos móviles y sobretodo, optimizado a éste, provee la abstracción del
hardware hacia el software utilizado, así entonces, encontramos todos los servicios
del núcleo que controlan el hardware del teléfono móvil, esto es, los controladores
21
Acrónimo de Java Virtual Machine. En resumen, la JVM es un componente de tecnología responsable de
la independencia de hardware y de sistema operativo, con el software desarrollado sobre esta plataforma.
Esta máquina virtual no hace reconocimiento del código programado en Java, solo interpreta el código en
formato binary o bytecode de Java (.class). Capítulo III. Enfoque práctico 70 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
de hardware, de redes, de seguridad e incluso el control de memoria y
procesamiento.
En la figura 3.11 se muestra el diagrama esquemático de la arquitectura de Android, así
como los ejemplos principales de cada una de las capas mencionadas:
Figura 3.11 – Diagrama a bloques de la arquitectura del sistema Android.
Un componente muy importante para el trabajo en Android es el DVM o máquina virtual
Dalvik, esta máquina virtual fue desarrollada específicamente para este sistema operativo,
como se mencionó hace las veces que la java JVM.
La DVM administra todo el hardware y los servicios como una capa intermedia es por ello
que los programadores abstraen todo lo concerniente a hardware específico del dispositivo,
Capítulo III. Enfoque práctico 71 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
es decir, esta capa obvia los aspectos técnicos del teléfono para trabajar únicamente con los
tópicos del sistema operativo. En esencia, la DVM ejecuta archivos optimizados que
aseguran el mínimo de los recursos necesarios para las tareas, estos son los ejecutables .dex
que son compilados de clases java a código Dalvik, como se mencionó.
3.4.2. Proceso de consumo
Las 3 principales tareas del consumidor del WCF-REST desarrollado en .Net, es decir, la
aplicación para el sistema operativo Android, son: Obtener la nueva información
correspondiente al usuario registrado, manipular la información para que sea atractiva para
el usuario, lo que coloquialmente se denomina look & feel, y guardar la información
relevante en el teléfono para ser utilizada sin necesidad de acceso a internet. Desglosando,
tenemos que la primera tarea la desempeña un componente que no es nativo para Android,
más bien uno genérico para un entorno de programación en Java, mientras que los restantes
si son específicos para la plataforma. En el cuadro 3.12 se muestra un resumen de las tareas
de una aplicación cliente.
Figura 3.12 – Tareas del consumidor de un servicio web.
La adquisición de datos desde el servicio de actualización se nos proveerá con un
empaquetado que puede utilizarse en Java, para comunicación en el protocolo HTTP,
Capítulo III. Enfoque práctico 72 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
org.apache.http. Este empaquetado contiene las interfaces y clases de núcleo para
componentes HTTP.
Realiza las tareas más comunes relacionadas al protocolo, como representación de
mensajes incluyendo encabezados y entidades de los mismos, así como la información
sobre las conexiones sobre las cuáles se envía el mensaje.
Antes de realizar la comunicación o después de recibidos los mensajes es necesario
interceptar las peticiones, esto se hace con solicitudes (requests) y respuestas (responses),
respectivamente.
El proceso para el consumo de un servicio se muestra en la figura 3.13:
Figura 3.13 – Procedimiento de consumo de un servicio web.
Capítulo III. Enfoque práctico 73 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
En el inciso e, se refiere al proceso explicado anteriormente acerca de la serialización y
deserialización, el cual se realizará con el formato JSON, la librería utilizada para este
propósito para el lenguaje Java es GSON22.
Esta librería hace el parseo23 o conversión de la respuesta recibida desde el servicio a un
objeto Java que esté definido, esto lo hace “vaciando” el contenido en el objeto
correspondiente a lo recibido utilizando el tipo de dato local correspondiente.
Ya que tenemos la información que recibimos desde el servicio en el formato que
establecimos, podemos presentarla al usuario como mejor nos convenga, en Android, cada
una de las aplicaciones corriendo en el sistema se llaman Actividades (Activities), estas
son manejadas en su totalidad por el administrador de procesos de Android, ni el
programador ni la actividad tienen manera de controlar la vida de este proceso.
3.4.3. Presentación de la información
Android administra estas aplicaciones calculando su prioridad y manteniendo siempre
activa la que más prioridad tiene, estos niveles corresponden a tres principales categorías.
Las actividades24 que están en pantalla, es decir, aquellas que está en contacto con el
usuario siempre es la actividad con más prioridad, después se sitúan aquellas que están en
pantalla pero no en contacto con el usuario o servicios iniciados, finalmente se encuentran
las aplicaciones que no están siendo utilizadas o los servicios en segundo plano, como
describe la figura 3.14:
22
Es una librería Java usada para convertir objetos Java en representaciones JSON, así como convertir una
cadena JSON a su equivalente objeto de Java. La librería contiene el API, la guía de usuario, el docuemento
de diseño y el roadmap (Un documento que constata las nuevas actualizaciones en la versión) se puede
descargar desde http://code.google.com/p/google-gson/ 23
Refiérase a la página 71, nota al pie 20, para la explicación a fondo de este témino. 24
Una actividad se refiere al sector específico de una aplicación siendo utilizada por el usuario, es decir, una pantalla parte de la aplicación completa. Capítulo III. Enfoque práctico 74 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.14 – Prioridad de actividad del sistema operativo Android.
Teniendo en cuenta como el sistema maneja la aplicación que desarrollaremos, ahora
debemos decidir cómo mostrarlo, lo que corresponde al look & feel de la aplicación. La
información que se muestra en pantalla, se hace dentro de un contenedor llamado Layout,
este contenedor rige las propiedades estéticas de la información, como son la alineación y
la ubicación específica de esta en la pantalla, algunos de los más utilizados son los
siguientes:
-
FrameLayout. Es el tipo más simple del objeto Layout. Es un espacio en blanco
que puede ser llenado con un objeto, i.e., una imagen.
-
LinearLayout. Todos los objetos contenidos dentro de este tipo de contenedor se
alinean en una sola dirección, se puede controlar el espacio que ocupan los hijos
con la propiedad weight, la cual establece una prioridad relativa del objeto en
cuestión dentro del Layout, es proporcional al espacio deseado, el objeto con la
propiedad weight mas alta ocupa más espacio en relación con uno con índice
menor.
Capítulo III. Enfoque práctico 75 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.15 – Modelo del objeto LinearLayout
-
TableLayout. Los objetos hijos se ordenan en filas y columnas, como funciona una
tabla en HTML.
Figura 3.16 – Modelo del objeto TableLayout.
Existen más tipos de layouts pero los anteriores son los más comunes y los que se
encontrarán con más frecuencia en la mayoría de las aplicaciones para este sistema
operativo.
Los datos que se muestra en pantalla, en este caso, pueden tener 2 orígenes distintos, el
primero de ellos ya fue explicado, y se refiere a las actualizaciones que se tienen desde el
servicio WCF-REST. El segundo origen es la base de datos, en la cual se guarda la
información obtenida para ser consultada en cualquier momento sin tener que conectarse al
servicio y por ende a internet, en la figura se muestra el flujo de comunicación de la
aplicación:
Capítulo III. Enfoque práctico 76 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 3.17 – Diagrama esquemático del tratamiento de información en el sistema Android.
En la figura 3.17 se muestran los 2 orígenes de datos, el servicio WCF-REST, cuyo acceso
necesita una conexión a internet y la base de datos local, SQLite, que siempre está
disponible.
SQLite es un sistema de base de datos relacional con un motor SQL embebido, las
principales características de este son:
a) Necesita los mínimos recursos externos, ya sean librerías auxiliares o de sistema
operativo.
b) No tiene servidor de comunicación. En la mayoría de los programas de
administración de bases de datos, se tiene un componente intermedio de
comunicación, típicamente TCP/IP, realizando peticiones al servidor y recibiendo
los resultados respaldados, en SQLite el proceso de guardado no tiene
intermediario, lo que quiere decir que cuando se hace un acceso a la base de datos
se escribe o lee directamente de disco.
Capítulo III. Enfoque práctico 77 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
c) No necesita configuración. Por lo tanto no tiene instalación y como tampoco tiene
servidor, el proceso no debe ser iniciado, detenido o configurado.
d) Implementa transacciones para sus procesos, es decir, sigue la regla de ACID25
Esto en Android se traduce en una serie de clases de administración del motor SQLite y
tener una base de datos privada para cada una de las aplicaciones que necesiten la
implementación.
25
Referido a las siglas de los términos en inglés Atomic, Consistent, Isolated and Durable (Atómico,
Consistente, Aislado y Durable), características que debe tener la información dentro de una base de datos.
Capítulo III. Enfoque práctico 78 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Referencias
[1]
Jon Skeet, C# in depth. Manning Publications, 2011.
[2]
The Java language enviroment: A white paper, http://java.sun.com/docs/white/langenv/
[3]
Java SE specifications, http://docs.oracle.com/javase/specs/
[4]
Abraham Silberschatz, et al., Fundamentos de bases de datos. Mc Graw Hill, Cuarta
Edición.
[5]
Libro del mans, 3.1.3.1
[6]
The official Microsoft IIS Site, http://www.iis.net/
[7]
Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software
Architectures. Tesis Doctoral, Universidad de California, 200.
[8]
Ethan Cerami, Web Service essentials. O’Reilly, 2002.
[9]
Leonard Richardson y Sam Ruby, RESTful web services. O’Reilly Media Inc, 2007.
[10]
Introducing JSON, http://www.json.org/.
[11]
Reto Meier, Professional Android Application Development. Wiley Publishing, Inc. 2009
[12]
Android Developers, http://developer.android.com/index.html
Capítulo III. Enfoque práctico 79 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Capítulo IV. La aplicación CEM
Una vez explicado el tratamiento teórico de la aplicación y el ambiente real, describiendo
las tecnologías de desarrollo se mostrará lo relacionado con la construcción de la
aplicación.
En el primer capítulo se describió la manera en la cual el trabajo dentro de un marco de
referencia facilitaba el desarrollo de componentes al límite de poder obviar algunas capas,
asimismo se hizo el tratado correspondiente de la descripción del sistema CEM con
respecto al funcionamiento en cada una de las capas concernientes del modelo OSI.
En el segundo capítulo abordamos como se realizaría el manejo de la teoría con estándares
y modelos reales, por ejemplo, se ejemplifico como el que el protocolo de la capa de
aplicación es utilizado para el intercambio de comunicación en una arquitectura específica
de servicios web (Véase sección 3.3).
En este capítulo se mostrará el desarrollo de la aplicación CEM, se iniciará con los
productos utilizados, así también se explica la arquitectura de construcción, además de
otros aspectos relevantes. También se abordará el tema de la implementación de dicho
sistema y se calculará un estimado de costos en un escenario típico de uso de la aplicación
de notificaciones.
Al tratarse de una aplicación basada en tecnologías de estándares abiertos, esta
construcción puede realizarse bajo cualquier producto mientras se respete el estándar al
cual está relacionado, esto es, no importa la plataforma utilizada por alguna compañía el
resultado es básicamente el mismo.
Con el fin de demostrar que no se tiene compromiso entre plataformas, se decide optar por
una propietaria de Microsoft para el desarrollo del servicio y una “open source” para el
consumo.
Capítulo IV. La aplicación CEM
80 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Estas son un servicio REST (REpresentational State Transfer) sobre WCF (Windows
Communication Foundation) desarrollado en Visual Studio que se conectará a una base de
datos local, la cual estará en SQL Server, también de Microsoft. Se utilizará una versión
del motor 2005 también con su herramienta de trabajo 2005 y por último la aplicación que
consume a dicho servicio sobre Android, que es un sistema operativo basado en Linux y
cuyo desarrollo se desenvuelve sobre Java, donde se opta un desarrollo bajo el IDE
(Integrated Development Environment) de programación Eclipse.
Aparte de este modelo de consumo para el cliente del teléfono móvil, se tiene una
aplicación de escritorio, cuyo objetivo principal es poblar la base de datos con la
información relacionada con cada uno de los tópicos de relevancia, esto es, información
acerca de la escuela, del grupo y del alumno en sí. Entonces, el modelo completo de la
aplicación corresponde a la figura 4.1, con la inclusión del sistema de captura de la
información:
Figura 4.1 – Modelo completo del sistema de notificaciones CEM.
4.1. Los entornos de desarrollo
Se asume que tanto la aplicación de escritorio como la base de datos, al igual que el
proveedor del servicio se encuentran en el mismo ordenador, ya que también se asume la
presencia de esta información para ser provista a través del consumo del servicio. Para
Capítulo IV. La aplicación CEM
81 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
propósitos del caso específico, además de la arquitectura de consumo y servicio, se
desarrolla la aplicación que inserta la información en la base de datos.
Así entonces podemos tener 2 secciones de la arquitectura que convergen en la base de
datos, diseñada en SQL Server, un motor de base de datos propietario de Microsoft pero
que para la codificación utiliza el estándar extendido T-SQL (Transact- Structured Query
Language).
Por una parte tenemos la información agregada en la base de datos y por otro lado el que la
extrae para enviarse por el servicio, así podemos tener la convivencia de ambos sistemas
sin que haya afectación entre sí mismos, este modelado de programación corresponde al
trabajo en capas, esta arquitectura se explicará brevemente en secciones posteriores.
Tanto la aplicación de escritorio como el servicio de actualización se encuentran
codificados en el lenguaje de programación de alto nivel C#, del cual también es
propietario Microsoft. Ambos componentes se desarrollaron mediante un entorno de
trabajo también provisto por Microsoft, Visual Studio.
Del lado del cliente también se utiliza un lenguaje de programación de alto nivel, en este
caso Java, es el encargado de generar las rutinas utilizadas para la invocación del servicio
para su posterior proceso y mostrado. Esto es, el lenguaje se encuentra tanto en la
comunicación por red así como para el manejo del API de programación de Android, se
opta como plataforma de desarrollo el IDE de programación Eclipse.
4.1.1. Microsoft Visual Studio
Microsoft Visual Studio es un entorno de desarrollo integrado (IDE) para sistemas
operativos Windows. Soporta varios lenguajes de programación tales como Visual C++,
Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se han
desarrollado las extensiones necesarias para muchos otros.
Capítulo IV. La aplicación CEM
82 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La pantalla principal de este IDE se muestra en la figura 4.2.
Figura 4.2 – Pantalla de inicio del IDE de programación Visual Studio en su versión 2008.
Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así
como servicios web en cualquier entorno que soporte la plataforma .NET. Así se pueden
crear aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas web y
dispositivos móviles.
Visual Studio tiene sus inicios con su versión Visual Studio 97, hasta la más reciente Visual
Studio 2010. Para el desarrollo se utiliza su versión 2008.
Se opta por este entorno de desarrollo por las prestaciones con respecto a otros entornos,
como por ejemplo las opciones de autocompletado y de depuración en tiempo de ejecución,
además de ser la herramienta recomendada por Microsoft para el desarrollo dentro del
cuadro de trabajo .Net. Otra razón de elección es el hecho de no contar con requisitos
previos, ya que el empaquetado instala todos ellos.
Capítulo IV. La aplicación CEM
83 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.1.2. Eclipse
EL IDE (Integrated Development Environment) de programación de código abierto Eclipse
es típicamente utilizado para desarrollo en el lenguaje de programación Java, pero también
puede soportar otros lenguajes, como por ejemplo C, C++, Perl, etc. El ambiente gráfico de
este IDE, que contiene: El típico editor de texto, las vista de tareas, revisiones de
problemas, así como la consola de ejecución, junto con las opciones de arrastrado y soltado,
menús desplegables y pestañas, lo convierten en una aplicación enriquecida, esto es, que no
está solo atada a características básicas, como las ya dichas de un cliente liviano, pero que
tan poco está ejecutándose sobre el mismo sistema operativo, como lo hace un cliente
pesado, como por ejemplo Visual Studio.
Eclipse tiene las opciones para crear proyectos, editado de código, búsqueda dentro del
mismo código, compilado, ejecutado, depuración y el término utilizado por ellos,
refabricación (refactoring) el cual es una manera de poner el código de manera agradable a
la vista, es decir, con saltos de línea, sangrías, etc., de acuerdo al formateo típico del
código.
Dos características fundamentales de Eclipse son las siguientes:
•
En el terreno práctico no necesita instalación, solo debe descomprimirse el archivo
descargado y ejecutarlo.
•
Puede descargarse software vario, para distintos propósitos desde el mismo IDE,
solo es necesario indicar la URL (Uniform Resource Locator) del repositorio para
añadir los archivos necesarios. Es así como es posible el desarrollo en Android, se
agrega un source o fuente de desarrollo para este software y es posible tener los
complementos necesarios para el desarrollo.
En la figura 4.3 se muestra la pantalla principal de Eclipse así como el logo de la versión
utilizada, Indigo.
Capítulo IV. La aplicación CEM
84 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 4.3 – Pantalla inicial del IDE Eclipse.
La razón para el uso del entorno Eclipse recae en las 2 principales características
enunciadas anteriormente, además, la documentación para la instalación del API
(Application Programming Interface) de desarrollo de Android es facilitada para el trabajo
en este IDE.
4.1.3. Administrador de Base de Datos, SQL Server Management Studio
La información ingresada desde la aplicación de escritorio relacionada con el estatus
académico es obtenida por el tutor en su teléfono móvil en un proceso transparente, el
puente entre estas dos secciones es el servicio web que expone dicha información, pero esta
información es guardada en una base de datos, la cual está diseñada también para un
ambiente Windows, SQL Server es el software utilizado para dicho propósito. Cuya tarea
es la administración y guardado de la base de datos. Ésta es una colección de información
que existe durante un periodo largo, encontramos distintos tipos de bases de datos, a
continuación enunciaremos algunos modelos principales:
Capítulo IV. La aplicación CEM
85 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Base de datos estructurados. A diferencia de los datos de tipo simple que sólo
pueden almacenar un valor, los datos estructurados o estructuras de datos pueden
recolectar varios valores simultáneamente. Se hace una primera introducción a los
datos estructurados destacando en primer lugar que se les asigna una cantidad fija
de memoria durante la ejecución del programa cuando se declara una variable de un
determinado tipo estructurado. Este tipo de estructuras permiten definir vectores,
matrices, tablas y estructuras multidimensionales.
•
Base de datos relacionales. En este modelo todos los datos son almacenados en
relaciones, y como cada relación es un conjunto de datos, el orden en el que éstos se
almacenen no tiene relevancia. Esto tiene la considerable ventaja de que es más fácil
de entender y de utilizar. La información puede ser recuperada o almacenada por
medio de consultas que ofrecen una amplia flexibilidad.
Este modelo considera la base de datos como una colección de relaciones. De
manera simple, una relación representa una tabla que no es más que un conjunto de
filas, cada fila es un conjunto de campos y cada campo representa un valor que
interpretado describe el mundo real.
•
Bases de datos transaccionales. Son bases de datos cuyo único fin es el envío y
recepción de datos a grandes velocidades. Estas bases son muy poco comunes y
están dirigidas por lo general al entorno de análisis de calidad, datos de producción
e industrial, de ahí que es importante entender que su fin único es recolectar y
recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y
duplicación de información no es un problema como con las demás bases de datos.
A este término, la base de datos, en la práctica corresponde al nombre de motor de la base
de datos. Como se mencionó, para el caso de prueba utilizaremos SQL Server. Éste motor
es una plataforma global de base de datos que ofrece administración de datos empresariales
con herramientas integradas de inteligencia empresarial. El motor de la base de datos SQL
Capítulo IV. La aplicación CEM
86 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Server ofrece almacenamiento más seguro y confiable tanto para datos relacionales como
estructurados, lo que le permite crear y administrar aplicaciones de datos altamente
disponibles y con mayor rendimiento.
De la misma manera, la utilización de la expresión base de datos se refiere a la colección de
datos que es administrada por un sistema de administración de base de datos abreviado
DBMS (Data Base Management System, sistema de administración de base de datos), en
otras palabras, serán todos aquellos datos necesarios para el funcionamiento de la
aplicación así como las labores de administración relacionadas con éstos. Se espera que este
sistema:
•
Permita a los usuarios crear otras bases de datos y especificar su esquema
(estructura lógica de los datos) por medio de un lenguaje especializado denominado
lenguaje de definición de datos.
•
Ofrezca a los usuarios la capacidad de consultar los datos y modificarlos, usando
para ello un lenguaje apropiado, llamado a menudo lenguaje de manipulación de
datos.
•
Soporte el almacenamiento de cantidades muy voluminosas de datos durante un
largo periodo, protegiéndolos contra accidentes o utilización no autorizada y
permitiendo el acceso eficiente para hacer consultas y modificar la base de datos.
•
Controle el acceso simultáneo a los datos por parte de muchos usuarios, sin permitir
que las acciones de uno de ellos afecte a los otros ni que los accesos simultáneos
corrompan los datos accidentalmente.
Para el desarrollo de la base de datos, como se mencionó se optó por utilizar SQL Server en
su versión 2005 el cual es un DBMS (Database Management System) de Microsoft basado
en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL.
Para el editado del código referente a la base de datos se utiliza el entorno SQL Server
Management Studio, el cual es un entorno integrado para obtener acceso a todos los
componentes de SQL Server, configurarlos, administrarlos y desarrollarlos. Podemos ver
este software como una capa superior en este modelo. SQL Server Management Studio
Capítulo IV. La aplicación CEM
87 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
combina un amplio grupo de herramientas gráficas con una serie de editores de script
enriquecidos para ofrecer acceso a SQL Server a desarrolladores y administradores de todos
los niveles de especialización [5].
A continuación se muestra una imagen del entorno SQL Server Management Studio:
Figura 4.4 – Pantalla demostrativa del entorno SQL Server Management Studio.
4.2. Arquitectura de diseño.
Ya que se tiene noción de la construcción del sistema de notificaciones se debe tomar en
cuenta la manera en que el código se diseñará. Para este se implementó el uso de un modelo
de tipo N-tier (Modelo de capas).
Este modelo tiene como fundamento la separación de la aplicación en diversas capas
lógicas. Se caracteriza por la descomposición funcional de las aplicaciones, los
componentes de servicio, y su implementación distribuida, mejorando la escalabilidad,
disponibilidad, capacidad de gestión y utilización de recursos así como por el hecho de que
cada capa es completamente independiente –o intenta serlo en la mayor medida- de las
demás, excepto por aquella inmediata superior e inferior. La capa solo debe saber cómo
Capítulo IV. La aplicación CEM
88 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
manejar una solicitud desde la capa n+1, como redirigir una solicitud de la capa n-1 (si es
que existe), y cómo manejar los resultados de la petición.
Los beneficios detectados como resultado del uso del modelo se encuentran los siguientes:
•
Disminución del grado de acoplamiento entre los componentes responsables del
mantenimiento y la presentación de los datos.
•
Los cambios a la interfaz de usuario no logran afectar la forma en que se manejan
los datos.
•
Una reorganización en los datos puede efectuarse sin ningún impacto en la interfaz
de usuario.
•
Al encontrarse desacoplados los elementos de las capas, la solución se vuelve
tolerante a fallas, facilitando el aislamiento de problemas y aplicación de soluciones
con un mínimo impacto a los componentes o capas vecinas.
El diseño, específicamente para la aplicación CEM consta de 3 capas, distribuidas de la
siguiente manera:
•
Capa de Presentación. Aquí se encuentran los componentes responsables de
proveer los elementos para la interacción con la aplicación, dentro de sus tareas se
encuentran: presentar y formatear la salida de datos, así como la validación de los
mismos introducidos por un usuario.
•
Capa de Negocio. Los componentes de esta capa son responsables de implementar
la lógica de procesamiento de información dentro de la aplicación en base a las
reglas de negocio pre-establecidas.
•
Capa de Datos. En esta última capa del modelo escogido encontramos los
componentes responsables de abstraer la lógica necesaria para la extracción y
persistencia de datos de y hacia las fuentes de datos.
Este modelo se encuentra en ambos lados de la aplicación, como se muestra en la figura
4.5:
Capítulo IV. La aplicación CEM
89 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 4.5 – Arquitectura en capas de los componentes del sistema CEM.
La última capa concierne al acceso a los datos de la aplicación. Esto considera la
convivencia con otro software ya mencionado, el motor de la base de datos.
En todo programa informático es esencial el acceso y guardado de datos por ese motivo
CEM Administrador utiliza una herramienta diseñada para ese motivo que se encuentra en
.Net Framework de Microsoft, ésta es ADO.Net.
Todo empezó en la incursión de Microsoft en el acceso de datos universal, misma que
comenzó con la conectividad abierta de base de datos (ODBC). La idea sobre la que se
asienta esta tecnología ODBC (crear un modo estándar de acceso a las bases de datos
mediante programación) ha sido usada en todas las tecnologías de acceso a datos
posteriores procedentes de Microsoft. En el caso de ODBC, este método estándar esta
ejemplificado en el API (Interfaz de Programación de Aplicaciones) de ODBC. Cualquier
proveedor de base de datos que quiera garantizar el cumplimiento del estándar ODBC debe
elaborar el software que convierta una llamada ODBC (hecha de acuerdo con el API) en
una llamada de base de datos nativa. Este software recibe el nombre de controlador ODBC
y es el puente entre una aplicación de cliente genérica y una base de datos específica.
Mediante este enfoque, los programadores de aplicaciones evitan tener que aprender a usar
Capítulo IV. La aplicación CEM
90 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
el API de base de datos específico del proveedor. Todo lo que un programador necesita
saber es como escribir aplicaciones cliente usando el API de ODBC (Open DataBase
Connectivity). Este hecho mejora la productividad y permiten escribir programas que
pueden ser usados con diferentes bases de datos.
De manera similar a este conector, el controlador de Android provee un mecanismo de
guardado de la información, un proveedor de contenidos como es nombrado en dicha
plataforma, como se mencionó en las secciones 3.3.1 y 3.3.3. La base de datos SQLite tiene
como principal característica el no tener ningún instalador ni administrador, además, ésta se
encuentra presente dentro de cada teléfono móvil utilizando Android.
El hecho de que no cuente con ningún tipo de instalación quiere decir que el guardado de
los datos se hace intrínsecamente en el software controlador, por medio de acceso al
sistema de archivos, este proceso aun cuando puede tener ciertos problemas de rendimiento
se traduce en la portabilidad de la base de datos sin ningún tipo de software tercero. La
dirección de guardado de estos directorios de base de datos se encuentran en la dirección:
DATA/data/Nombre de la aplicación/databases26
Finalmente, SQLite para Android, también responde al estándar de SQL (Structured Query
Language), además de añadir tipos de datos con nomenclatura correspondiente a Java,
como son los tipos de datos: texto, entero y real, TEXT, INTEGER y REAL,
correspondientemente. Cualquier aplicación que lo necesite puede generar una base de
datos la cuál será almacenada en la carpeta correspondiente a la aplicación desarrollada, así
entonces tomando el caso específico del sistema CEM, esta carpeta se encontrará en:
DATA/data/CEM/databases
Para crear esta base de datos solo deben seguirse los procesos rutinarios que describe el
estándar de SQL (Structured Query Language).
26
Cabe mencionar el hecho de que esta ubicación está dentro de la unidad de sistema del teléfono a la cual el usuario no tiene privilegios de acceso. Capítulo IV. La aplicación CEM
91 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.3. Las plataformas.
En lo consecuente de esta sección se abordará el tema de la instalación de los productos
desarrollados, además de las consideraciones necesarias para el correcto funcionamiento de
estos, a continuación se muestran dichos pasos.
1. El proceso de instalación de la aplicación servidor, solo se refiere al ejecutado del
empaquetado. Nos encontraremos con un producto que comprende tres
componentes la aplicación en sí, el ejecutable y los archivos necesarios para la
instalación. Solo basta con dar doble clic en el archivo “setup.exe”, aceptar los
términos y seguir las indicaciones del instalador. Esto dará cabida a la aplicación de
consola mostrada en la figura 4.6-c. La figura 4.6 ilustra cada uno de los puntos
descritos anteriormente.
Figura 4.6 – Instalación del servicio CEM. a) Empaquetado de la aplicación servicio
CEM, b) Pantalla de instalación, c) Apariencia de la aplicación de consola del servicio
CEM.
Para volver a ejecutar el servicio se debe acceder al producto instalado desde el
menú de todos los programas, en la carpeta ServiceCEM.
Capítulo IV. La aplicación CEM
92 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
2. Como el sistema que se encarga del insertado de los datos del alumno no es más
que una aplicación de escritorio, también desarrollada en la tecnología .Net, al igual
que el servicio y la página de hospedaje, el instalado corresponde a los mismos
pasos, que se traducen en ejecutar el archivo “setup.exe” y continuar con el
asistente. Al igual que en la instalación del servicio, es necesario aceptar las
condiciones (figura 4.7-a), después de ellos se muestra la pantalla de bienvenida de
la aplicación de escritorio CEM.
Figura 4.7 –Instalación de la aplicación de escritorio CEM. a) Pantalla de instalación, c)
Pantalla de bienvenida de la aplicación CEM administrador.
La diferencia de este sistema con respecto a los previamente instalados (El servicio
web) es que creará la base de datos y además de un acceso a la aplicación.
3. El proceso de instalación de la aplicación cliente, la cual corre en el teléfono móvil
inteligente, se refiere al acceso a la página de descarga y simplemente pulsar en el
botón de descarga (Ver sección 4.4.1). Se recomienda el acceso mediante el mismo
navegador del teléfono, para no tener un proceso intermedio de almacenado de la
aplicación en la computadora y posterior traslado al teléfono para la instalación del
mismo.
Este proceso corresponde a la descarga con el navegador del teléfono accesando a
la dirección de hospedaje de la página, mostrado en la figura 4.8. El sistema
operativo da la opción del instalado, una vez descargada la aplicación [4.8-a], solo
Capítulo IV. La aplicación CEM
93 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
es necesario indicar la instalación del empaquetado [4.8-b]. Terminada la
instalación se verá la página de logueo de la aplicación CEM.
Figura 4.8 – Instalado de la aplicación CEM. a) Descarga de la aplicación. b) Proceso de
instalado
4. El último paso para la configuración es habilitar el servidor web que proveerá la
aplicación de descarga. Para esto es necesario activar dicha característica en el
sistema operativo en el que se está trabajando, que es Windows 7, el proceso de
traduce
solamente
en
entrar
a
“Panel
de
controlÆDesinstalar
un
programaÆActivar o desactivar las característica de Windows” y seleccionar
“Internet Information Services”. Este proceso se describe en la figura 4.9.
Figura 4.9 – Pantalla de activación de características de Windows 7.
Capítulo IV. La aplicación CEM
94 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
a. La manera de verificar si el servidor web está instalado, se muestra en la
figura 4.10, la cual simplemente es acceder a la dirección IP loopback27 o la
local y visualizar el mensaje de bienvenida de IIS (Internet Information
Services)
Figura 4.10 – Pantalla de confirmación de la correcta instalación del servidor web IIS 7.
5. Con el propósito de acceder al servicio web desarrollado debe añadirse una
excepción al firewall de Windows para el puerto con el que se accederá a la
aplicación, se dejará el default que es el 3753, como se muestra en la figura 4.11:
Figura 4.11 – Proceso para crear la excepción en el firewall para la intercomunicación con el
servicio web.
27
Se refiere a una dirección especial de cualquier host trabajando bajo la suite de protocolos de internet cuyo
propósito es la redirección del tráfico hacia sí mismo, puede ser cualquier dirección de rango 127.X.X.X,
aunque típicamente se utiliza 127.0.0.1. Capítulo IV. La aplicación CEM
95 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
6. Este proceso realizado se lleva a cabo con el fin de permitir la instalación de la
página desde la cual se hará la descarga. Se entregará un instalador propio de la
tecnología Microsoft, en sí un Instalador de Microsoft (MSI), mostrado en la figura
4.12 –a. En este proceso solo se debe indicar la ruta de instalación, la cual es el
servidor web local IIS (Internet Information Services), como se muestra en la figura
4.12 –b y seguir los pasos indicados por el instalador, figuras 4.12 c y d.
Figura 4.12 – Instalación del portal CEM. a) Instalador de Microsoft, b)Selección de la
ruta dentro del servidor web, c)Proceso de instalación y d)Correcta instalación de la
página de descarga.
4.4. Los productos.
En esta sección se mostrará la apariencia de cada una de las aplicaciones que conforman el
sistema CEM, correspondiente al modelo 4.1, de la misma manera se procederá a describir
cada uno de estos componentes que conforman dicho sistema.
Cabe mencionar que en las secciones siguiente no se tratará de ninguna manera el diseño de
la base de datos ya que este componente no se distribuye en ningún punto al usuario o
contratante del sistema.
Capítulo IV. La aplicación CEM
96 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.4.1. La descarga de la aplicación.
La descarga de la aplicación se realiza desde una página web, lo cual quiere decir que
puede obtenerse desde cualquier navegador, incluso desde el incorporado por default en el
sistema operativo Android. Debido a que el servidor web (IIS) reside en el mismo equipo
que provee el servicio de actualización, no es necesaria infraestructura aparte para el
comunicado y servido del instalador de la aplicación.
La figura 4.13 muestra la apariencia de la página de descarga y se muestra resaltado el
enlace de descarga:
Figura 4.13 – Página de descarga de la aplicación CEM.
Prácticamente el proceso de instalación de la aplicación es transparente para el usuario, ya
que basta con hacer clic sobre el enlace que accede a la aplicación y esta se instala, para
después dar paso a la aplicación cliente. Lo único que debe saberse es la URL (Uniform
Resource Locator) de descarga de la aplicación para tener acceso a ella.
Capítulo IV. La aplicación CEM
97 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.4.2. Portal de administrador CEM.
El segundo componente del conjunto se refiere a la aplicación encargada de la introducción
de la información a la base de datos, el portal de administrador CEM. El propósito de esta
aplicación es agregar todo lo concerniente con la información, tanto relacionada con el
alumno así como la de la escuela. Para mantener la pertinente separación de las capas sin
olvidar la tarea principal de ésta, el portal solo debe realizar la tarea de la inserción de los
datos a la base generando la convergencia de ambos sistemas.
A continuación se enuncian las principales pantallas de esta aplicación:
•
Pantalla de logueo. La tarea principal de ésta es autenticar a un usuario
determinado. Estos usuarios pueden ser el administrador de la aplicación de
escritorio, el cual se encarga de agregar nuevos grupos, alumnos, etc. Además de
este tipo de usuario, también hay profesores y prefectos, los cuales dan de alta
calificaciones o reportes individuales de usuario o grupo. En la figura 4.14 se
muestra la pantalla de logueo del portal de administrador CEM.
Figura 4.14 – Pantalla de login de la aplicación de administrador CEM.
Así como usuarios, esta aplicación cambia las opciones de acuerdo al usuario y
password introducidos, para tener una relación de jerarquía entre ellos.
Introduciendo un usuario y contraseña de nivel de administrador, la sesión originada
será también como administrador, el cual es capaz, como se dijo de añadir o borrar
Capítulo IV. La aplicación CEM
98 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
alumnos, escuelas, materias, etc. La figura 4.15 muestra la apariencia de la pantalla
administrador de la aplicación CEM. En la sección superior de la pantalla se
observan las tareas que el administrador es capaz de hacer, misma que se enuncian
bajo la figura.
Figura 4.15 – Pantalla correspondiente al logueo de un usuario administrador.
o Alta de escuela. Es el primer nodo de toda la raíz, debe darse de alta una
escuela, debido a que todo tiene relación con ella, ya sea directa o
indirectamente. Así mismo, el borrado de escuela solo se podrá realizarse
cuando ningún otro dato que tenga relación con ella exista.
o Alta de grupo. Guarda un grupo con el grado escolar y la escuela al que
pertenece.
o Alta de alumnos. En esta sección se guarda el nombre del alumno, la escuela y
grupo al que pertenece, además de relacionarle un tutor a dicho alumno. Este
proceso es necesario para poder asociar posteriormente la información recibida
en el teléfono móvil, la figura 4.15 muestra esta secuencia:
Figura 4.16 – Alta de alumno y relacionado con el tutor correspondiente.
Capítulo IV. La aplicación CEM
99 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
o Alta de materia. En esta sección es guardado el nombre de la materia, escuela y
año o grado del cual es parte.
o Alta de administrador. Guarda nombre, teléfono, email y se añade un
password para que tenga acceso a la ventana de administrador. Cuando se
ejecuta por primera vez la aplicación CEM Administrador el formulario aparece
para que se dé de alta al primer administrador.
o Alta de profesor. Se guarda el nombre, email y escuela, también tiene opción
de guardar un password para tener acceso a la ventana de profesor.
o Alta de prefecto. Provee las mismas opciones que el alta de profesor, con la
diferencia de que al indicar este usuario la sesión sería de prefecto.
o Alta de clases. En esta sección se relacionan escuela, grupo, profesor y materia
para formar una clase.
•
La sección correspondiente a los mensajes tiene tres niveles alumno, grupo y
escuela, este mensaje es el que se debe de visualizar en el teléfono móvil una vez
añadido. Esta pantalla está disponible tanto para los administradores, profesores
como prefectos y se muestra en la figura 4.17.
Figura 4.17 – Pantalla de mensajes.
Capítulo IV. La aplicación CEM
100 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.4.3. Servicio de actualización.
El servicio de actualización solo presenta la dirección en la cual corre dicho servicio,
además del puerto, es decir, la dirección del socket TCP (Transmission Control Protocol).
El formato de los mensajes de actualización es JSON (JavaScript Object Notation) –
explicado en la sección 3.3.3 del presente-, por lo que la serialización en este extremo y
deserialización en la aplicación cliente deben corresponder a este formato. Además, la
arquitectura corresponde a un servicio REST (REpresentational State Transfer) –descrito
en la sección 3.3.2-, que se comunica por medio del protocolo HTTP (Hypertext Transfer
Protocol) utilizando una URL (Uniform Resource Locator) única para cada una de éstas.
La figura 4.18 muestra la apariencia de la aplicación de consola que provee el servicio:
Figura 4.18 – Apariencia de la aplicación proveedora del servicio de actualización del sistema
CEM.
Esta aplicación solo provee la comunicación cuando se ejecuta, mientras tanto este
procedimiento es inaccesible para los usuarios.
Capítulo IV. La aplicación CEM
101 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.4.4. Aplicación cliente.
La aplicación cliente, desarrollada para el sistema operativo para teléfonos móviles
Android, tiene como tarea primordial el envío de peticiones de actualización de estatus con
el servicio de actualización WCF (Windows Communication Foundation). Se trata de un
cliente ligero que deserializa los mensajes recibidos y después los presenta regido por la
arquitectura del sistema Android, –descrito en la sección 3.4.1- además del presentado y
almacenado de la información para consultas sin necesidad de conexión con respecto a lo
mostrado en la sección 3.4.3.
El siguiente listado muestra cada una de las pantallas de interacción de usuario además de
la descripción de la tarea realizada dentro del sistema completo:
•
Pantalla de identificación o login. Se presenta al inicio y solo la primera vez que
la aplicación se instala. Se muestra con el fin de identificar al usuario, registrarlo en
el lado del servidor y asociar un alumno a él. Ésta pantalla inicial es mostrada en la
figura 4.19.
Figura 4.19 – Pantalla de inicio de la aplicación CEM.
•
Pantalla de mostrado de mensajes generales. En esta pantalla se muestran los
mensajes recibidos correspondientes al grupo y escuela del o los alumnos asociados
al tutor.
Capítulo IV. La aplicación CEM
102 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 4.20 – Pantalla de sincronización de mensajes generales.
•
Pantalla de despliegue de mensajes personales. En esta sección se muestran los
mensajes de cada uno de los alumnos asociados.
Figura 4.21 – Pantalla de sincronización de mensajes personales.
•
Pantalla de calificaciones. Se muestran las calificaciones del alumno, en el
semestre actual y dividido por parcial.
Capítulo IV. La aplicación CEM
103 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 4.22– Pantalla de visualización de calificaciones. •
Preferencias. Opciones de preferencia, cambiar el temporizador de actualizaciones
automáticas, registrar nuevo alumno, etc.
Figura 4.23 – Pantalla de preferencias.
•
Nuevo alumno. Pantalla donde se introduce la boleta de un nuevo alumno y se
asocia al tutor para recibir actualizaciones.
Capítulo IV. La aplicación CEM
104 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Figura 4.24 – Pantalla para asociar un nuevo alumno al tutor.
Cada una de las pantallas de mensaje presenta el encabezado cuya tarea es el de ir a la
pantalla señalada, además, utilizando la función de opción del teléfono móvil se puede ir a
la pantalla de preferencias, descrita anteriormente.
4.5. Costos relacionados con la aplicación CEM.
Esta última sección del presente trabajo se enfoca a realizar un estimado de los costos de la
aplicación de notificaciones CEM. Parece pertinente el hacer una distinción entre estos, es
por ello que los costos relacionados con la aplicación serán divididos en 2. Los costos de
realización o desarrollo y los costos de implementación de la aplicación.
4.5.1. Costos de desarrollo de la aplicación CEM.
Lo primero a tratar en cuanto a costos relacionados serán los costos concernientes al
proceso de planeamiento, construcción y desarrollo del sistema en sí.
Capítulo IV. La aplicación CEM
105 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Estos costos comprenden desde la mano de obra por parte del desarrollador, las licencias
necesarias para el desarrollo, entre otros tópicos. Nótese que en esta sección no tratará de
ninguna manera aquellos costos que están relacionados con la implementación de un caso
funcional en el terreno escolar, de estos temas nos encargaremos en la siguiente sección.
Primero nos ocuparemos de los costos de los ambientes de programación, esto solo es
válido para las tecnologías de Microsoft, ya que tanto Java como lo necesario para el
desarrollo en Android se refieren a licencias libres, aun así se nombrarán sin algún costo
relacionado. Se asume la previa presencia de un ordenador con las especificaciones
necesarias de soporte además de un sistema operativo compatible para el software que se
enlista en la tabla 4.1.
Componente
Motor de base de datos
Producto
(USD)
SQL Server 2005 developer
49.95
edition28
Servicio Web + Aplicación de
Microsoft Visual Studio 2008
escritorio
Professional29
Aplicación cliente
Costo por ordenador
499.00
Eclipse Classic 3.7.2 + Android
0.00
SDK
548.95
Tabla 4.1 – Costo de licencias para el desarrollo del sistema CEM.
Aparte de los costos de licencias de software se tiene también la mano de obra de los
desarrolladores, la aplicación prueba se desarrolló en 20 días efectivos, es decir 480 horas
de trabajo con dos desarrolladores.
28
Se provee el precio de SQL Server 2008 R2 Developer Edition, desde el sitio oficial de venta de Microsoft [9], la versión actual del motor de base de datos, debido a que el producto mencionado se encuentra en descontinuación al retail solo se provee a partners de desarrollo. 29
Se proporciona el precio de la versión actual del IDE de programación Visual Studio 2010 Professional, debido a las mismas razones que con el motor de la base de datos, relacionadas con la descontinuación del producto. El precio es obtenido del sitio oficial de venta de Micosoft [9]. Capítulo IV. La aplicación CEM
106 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Para el cálculo del costo correspondiente al proporcional de mano de obra se cubrirán los
puntos siguientes: Salario del personal, costos relacionados con prestaciones, amortización
o depreciación del activo fijo30 y finalmente, la ganancia esperada para el producto.
El primer costo, el salario del personal, es conocido como costo/hora/hombre, que como su
nombre lo indica es el costo del personal especializado realizando el trabajo, para ello
utilizaremos un salario de 12 USD31 por desarrollador o especialista, calculado como sigue:
A este costo es necesario agregarle un factor agregado de entre 3 y 4 por efectos de
prestaciones de los empleados, entre las que figuran vacaciones, seguro social, además de
lo referido a pago de servicios (teléfono, internet, etc.), se utilizará el factor más bajo,
siendo 3, como se muestra a continuación:
Finalmente, como se dijo, por efectos de depreciación de activo fijo se agrega una tasa del
2%, como se ilustra:
Siendo esta la cifra a la cual se le aplicará la ganancia esperada, la cual será de entre el 20 y
40 porciento, manejándose para el caso de prueba un 25%, teniéndose el costo total a
continuación mostrado:
30
El activo fijo es un bien que es necesario para el funcionamiento de la empresa pero que no se destina a la
venta, i.e. los bienes inmuebles, maquinaria, equipo de oficina, etc. 31
Tomando una cotización de 12.80 pesos mexicanos por USD (dólar) Capítulo IV. La aplicación CEM
107 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
De la misma manera tienen que ajustarse los costos de licencias para cada uno de los
ordenadores, en este caso específico estamos hablando de dos ordenadores, por los dos
desarrolladores.
4.5.2. Costos de implementación de la aplicación CEM.
Finalmente se hará un estimado del costo de implementación del sistema CEM en un
escenario típico.
La tarea del cálculo de los costos de implementación es proporcional al caso de uso, es
decir, el caso de prueba. Para esto se utilizará un caso ficticio en el cuál se implementaría
para una escuela con 2000 usuarios.
Aparte del número de usuarios esperado es necesario realizar el cálculo promedio de
transferencia por petición, esto es, la cantidad de datos enviados cuando se realiza una
petición, por efectos prácticos de bits de protocolos, es decir, los bits agregados por
encabezado, se hará una estimación en la que cada byte (8 bits) de información se
consideren como 10 bits.
El mensaje más grande, por parte del servicio, el primer componente a analizar, es aquél
que contiene: Identificador (Campo entero de 2 dígitos), descripción (De máximo 200
caracteres), asunto (Máximo 50 caracteres), fecha (Campo de 10 caracteres), fecha de
creación (10 caracteres), ruta de imagen a obtener (Máximo 120 caracteres) y finalmente
identificador alumno (Campo de 10 caracteres). Lo que nos dará un máximo de 402
caracteres, es decir 402 bytes, a lo cual le agregaremos el 15 por ciento por los efectos
descritos anteriormente, y un 10 por ciento referente a los descriptores de campos,
quedándonos un mensaje de tamaño máximo de 500 bytes, por mensaje de petición. Se
Capítulo IV. La aplicación CEM
108 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
tomará un promedio de 3 mensajes por petición estándar, es decir, aproximadamente 1.5 kb
por petición32. Este será nuestro tamaño base para los cálculos pertinentes de transferencia.
El segundo componente es la página de descarga, la cual solo es utilizada cuando se
requiere la aplicación que correrá bajo el celular, esta página completa tiene un peso de
aproximadamente 25 kb, ya con el agregado mencionado. Debido al escaso uso de este
componente se asumirá dentro de las peticiones del servicio, sin tomar en cuenta un cálculo
especial para ésta.
Otro punto de especificación para implementar un servidor es la capacidad de
almacenamiento, fuera de la cantidad de espacio del sistema operativo –tema que se tratará
a continuación- y de los complementos necesarios (motor de la base de datos, etc.), es
esencial reservar el espacio que la misma base de datos ocupará. Para el caso de prueba de
2000 alumnos (Proporcional a los 2000 usuario mencionados, a razón 1 a 1) se traduce en
aproximadamente 1 Gb de espacio, exclusivos para la base de datos. A este valor se le da
un margen del 100 por ciento, esto es debido a un plazo de futuro crecimiento además del
factor de error, necesitando un total de 2 Gb de espacio en disco para la base de datos.
En resumen, se requiere implementar un servidor que sea capaz de atender a los 2000
usuarios, igualmente con un margen del 50 por ciento, es decir, 3000 usuarios, los cuales
realizaran peticiones al servicio durante el día; una petición automática de actualización
está compuesta de 3 peticiones individuales a razón de 3 al día, es decir, 27000 peticiones
diarias, más un 50 por ciento por las actualizaciones manuales, se calcula un promedio de
aproximadamente 40000 peticiones por día, es decir, menos de una petición por segundo33.
El comportamiento general de la mayoría de estas peticiones se traduce en recibir el
usuario, la acción, consultar la base de datos y regresar el mensaje, es por esto, que para el
modelado del servidor se recomienda tener por lo menos dos procesadores, para utilizar dos
hilos independientes, uno recibiendo y contestando las peticiones y otro consultando la base
32
Nótese que el cálculo realizado corresponde al tamaño máximo de los campos del mensajes, es por ello que
el valor medio esperado puede ser igual o menor al establecido, esta cifra está relacionada directamente con el
rendimiento del servicio, es decir, si se garantiza este volumen de transferencia estarán cubiertos los
escenarios reales.
33
Basado en tráfico constante y sin variación a través de las 24 horas del día.
Capítulo IV. La aplicación CEM
109 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
de datos. Esto solo es válido cuando las pruebas de estrés lo requieran, es decir, mientras no
haya el suficiente número de usuarios convergiendo hacia el mismo lugar no será necesaria
esta arquitectura34.
Se realizan pruebas de rendimiento dentro de la plataforma Visual Studio, básicamente es
generar peticiones al servicio y ver los límites de carga soportados por el sistema, es decir,
pruebas de carga (Load test).
Esta prueba de carga se realiza en 2 tiempos estimados de operación con el fin de realizar
un promedio, serán para 2 y 5 minutos de operación.
El equipo en el que se prueba cuenta con un procesador de cuatro núcleos trabajando a una
frecuencia de 3.3 GHz y 4 Gb en RAM, como se muestra en tabla siguiente:
Especificaciones
Procesador
1 x Intel Core i5-2500 @3.30 GHz
Memoria RAM
1 x 4 Gb RAM DDR3 @1333 MHZ
Disco Duro
1 x 160 Gb HDD
Tabla 4.2 – Especificaciones del equipo de pruebas.
El test de carga se compone de los tres mensajes principales del servicio, los relacionados a
los mensajes personales, mensajes de grupo y mensajes de escuela, relacionados con un
alumno de prueba. Cada una de estas peticiones cuenta con 3 mensajes internos. La carga
de cada uno de los mensajes es respectivamente 447, 496 y 450 bytes, muy parecida a la
carga de transferencia impuesta35.
34
Esto se refiere al concepto de multi-threading, típicamente un sistema trabajando con un solo núcleo
planifica la tarea a realizar a razón del tiempo, al generar un proceso con 2 hilos –threads- de trabajo, cada
uno de ellos trabajará a la mitad de velocidad por efectos de la planificación.
35
Este valor está relacionado con lo explicado acerca de los tamaños máximos de cada uno de los campos,
véase página 108.
Capítulo IV. La aplicación CEM
110 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Los parámetros de las pruebas son simulando un navegador de teléfono inteligente a una
velocidad de 1.5 Mbps36 con un patrón de carga de 20 usuarios simultáneos37. En la figura
4.25 a y b, se muestran los resultados de carga para la prueba de dos y cinco minutos,
respectivamente.
Figura 4.25 – Resumen de resultados para pruebas de carga para una petición de mensajes
personales, grupales y de escuela del servicio CEM para a) 2 minutos, b) 5 minutos.
De la prueba de rendimiento obtenemos una respuesta promedio de aproximadamente un
décimo de segundo, para la petición de transferencia estándar impuesta, esto es que para un
sistema como el ejemplo este será nuestro número de peticiones soportadas, es decir, se
pueden solucionar los requerimientos de 10 usuarios en 1 segundo.
Será ahora necesario tomar un equipo con características menores al de prueba para ajustar
los valores y precios. Se opta por un servidor con procesador i3-2100 a 3.10 GHz. Este
procesador es de 2 núcleos físicos, por lo que se espera menor desempeño. Esta
disminución es de alrededor del 42 por ciento, de acuerdo a pruebas de rendimiento
(Benchmarking), obtenidas de un sitio especializado con ello [7], como lo muestra la tabla
4.3.
36
Se toma este valor como un promedio de la velocidad de un enlace estándar en México tanto por medio de
ISP fijo como por telefonía móvil propia del teléfono móvil.
37
Este valor solo hace sentido cuando pasa un tiempo estándar desde la petición hasta que expira la conexión,
el valor del protocolo HTTP 408-TimeOut, véase apéndice A, es decir, a converger varios usuarios para
acceso a un recurso el tiempo de servicio aumentará a razón de tiempo individual de la petición. Capítulo IV. La aplicación CEM
111 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Procesador
Benchmarking
Intel Core i3-2100 @ 3.10GHz
3854
Intel Core i5-2500 @ 3.30GHz
6598
Tabla 4.3 – Comparación de rendimiento entre procesadores i3-2100 e i5-2500..
Así mismo se reducirá la cantidad de memoria RAM con el fin de disminuir el precio del
servidor con respecto a los requerimientos calculados, quedando las especificaciones del
servidor como se muestra en la tabla 4.4.
Especificaciones
Procesador
1 x Intel Core i3-2100 @3.10 GHz
Memoria RAM
1 x 2 Gb RAM DDR3 @1333 MHZ
Disco Duro
1 x 80 Gb HDD
Tabla 4.4 – Especificaciones del servidor para implementación.
Un servidor de estas características puede costearse con alrededor de 750 USD, más
específicamente 753.77 USD obteniéndose en el link de referencia38, así mismo, con este
equipo podemos garantizar la satisfacción de mínimo 11 usuarios cada 2 segundo –5.5
usuarios por segundo-, esta cifra se justifica en adición con la sección 4.5.4 de trabajo
futuro.
Finalmente, como se mencionó en la sección 3.2, el servicio y el hospedaje están
desarrollados en el cuadro de trabajo .Net, que trabaja sobre la capa de abstracción del CLR
(Common Language Runtime) el cual solo es válido dentro de la plataforma Windows, es
por ello la necesidad de utilizar un servidor basado en esta misma plataforma, siendo
Windows Server, es por ello que para el requerimiento de sistema operativo se opta por una
licencia de Windows Server 2008 R2 en su versión estándar cuyo precio oscila en alrededor
38
http://espanol.bestbuy.com/enes/site/Lenovo+-+ThinkServer+044113U+5U+Tower+Server++1+x+Intel+Core+i3+i3-2100+3.10+GHz++Business+Black/4285975.p?id=1218468391200&skuId=4285975&st=i3&cp=1&lp=9
Capítulo IV. La aplicación CEM
112 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
de 1,200 USD, para la labor de administración39 y una licencia del motor de la base de
datos SQL Server en su versión 2005, cuyo costo ronda también los mismos 1,200 USD.
Además de esto, se encuentra el hecho de tener un medio de exponer el servicio y que el
usuario pueda encontrarlo. Típicamente cuando realizamos un contrato de internet se asigna
una dirección IP dinámica, lo que quiere decir que cambia con el tiempo, este mecanismo
no permite saber a ciencia cierta a que dirección referirnos, por ellos es necesario contar
con una dirección IP fija o estática.
El costo de la IP estática está relacionado con el volumen de la transferencia y la velocidad
de la misma. Si se calcularon 40,000 peticiones por día de aproximadamente 1.5 kb
tendríamos un volumen de transferencia de aproximadamente 60 Mb por día, 1.8 Gb por
mes, mismo que debe cubrir el proveedor en el momento de la renta del enlace. Por otro
lado, se tiene que garantizar la velocidad de transferencia de las peticiones, nuevamente se
hace un estimado de una petición por segundo, es decir, de aproximadamente unos 5 KB/s,
la conexión estándar de precio más económico ofrece un velocidad de transferencia de 640
Kbps, es decir, 80 Kbyte por segundo, con lo que queda cubierta la demanda de peticiones.
El precio de una renta de un enlace con estas características se divide en dos: El costo del
enlace y el costo adicional por la IP estática. Estos serán, un enlace con una transmisión de
640 Kbps, el cual ya tiene la opción de realizar el registro de un dominio de internet –
necesario para el hospedaje de la página de descarga– y con 3 Gb de volumen de
transferencia al mes cuyo precio es de 706.08 pesos mexicanos, 55.20 USD. Por otro lado
se tiene el costo de la dirección estática añadiéndosele 1,160 pesos al costo base, 90.62
USD, un total de 145.82 USD mensuales, para el cálculo inicial se utilizará este costo base
por los 12 meses de operación, es decir, 1,949.49 USD40.
39
Se refiere al sistema operativo Windows Server 2008 R2 Standard para procesadores de 64 bits y acceso
hasta a 10 clientes. El precio se obtiene del sitio oficial de venta de Microsoft [9].
40
Precios tomados de un enlace ADSL para negocio, desde la página oficial de Telmex.
http://www.telmex.com/mx/negocio/internet/banda-ancha.html.
De igual manera se toman los registros de volumen de transferencia correspondientes para dicho enlace de la
página oficial. http://www.telmex.com/mx/asistencia_negocio/internet/preguntas-frecuentes-volumen-detransferencia.html.
Capítulo IV. La aplicación CEM
113 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Podemos concluir que para el volumen de peticiones necesarias diarias, inclusive en
horarios críticos (Suponiendo una demanda 5 veces mayor), con un equipo con las
especificaciones anteriores podrían ser servidas sin problema alguno, de la misma manera
se tiene un margen de más del 100% en cuanto al volumen de transferencia y con respecto a
la velocidad de transferencia impuesta se tienen un margen teórico de 20 veces la velocidad
promedio necesaria, por lo que podemos estipular en materia de costos lo mostrado en la
tabla 4.5:
Componente
Costo unitario (USD)
Servidor
753.77
Windows Server 2008 R2
1,209.00
Standard Edition
SQL Server 2005 Standard
1,209.00
Edition41
Renta de 12 meses IP estática.
1,949.49
5,121.26
Tabla 4.5 – Costos de implementación del sistema CEM.
41
Al igual que el software de desarrollo, se presenta el precio de la versión actualizada del producto, SQL
Server 2008 R2 Standard para un sistema de 64 bits, obtenido desde el sitio oficial de venta de Microsoft [9].
Capítulo IV. La aplicación CEM
114 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.5.3. Costos finales del sistema
Para los costos finales del sistema solo debemos sumar ambos costos, de desarrollo e
implementación, con el fin de obtener una cifra final, esto se muestra en la tabla 4.6:
Costo Unitario (USD)
Cantidad
Costo total (USD)
548.95
2
1,097.90
5,121.26
1
5,121.26
42,301.44
1
42,301.44
Componentes de
desarrollo
Componentes de
implementación
Mano de obra de
desarrollo
48,520.60
Tabla 4.6 – Desglose de costos finales del sistema CEM.
Este precio debería aumentar en un mínimo de 145.82 USD por mes adicional de operación
una vez terminado el plazo de los 12 meses iniciales, por efecto de la renta del enlace de
transferencia.
Finalmente, se deberá especificar una tarificación mensual relacionada con la
administración de cada alumno dentro del sistema, se estima que para el pago de renta de
enlace y sueldo del personal de administración y monitoreo esta cifra se consideraría como
1 USD mensual por alumno registrado.
Capítulo IV. La aplicación CEM
115 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
4.6. Trabajo futuro relacionado con la aplicación CEM.
Se realizó una aplicación de intercomunicación entre sistemas abiertos, por medio de un
cuadro de referencia con el fin de ejemplificar el trabajo dentro de este tipo de marcos. Sin
embargo, en la aplicación se asumen dos factores, lo cuáles pueden ser tomados como
futuros componentes del sistema.
El primero de ellos es que se asume la presencia de la información a mostrar, es decir, se da
por hecho la presencia de los mensajes dentro de la base de datos, aun cuando se realiza una
aplicación que inserta los mensajes42. Este será el primer componente a visualizar como
trabajo futuro, se propone una interfaz web que se comunique con otro servicio web
especializado, esto es, crear una interfaz de usuario cuyo fin sea el insertar dentro de la base
de datos central –la utilizada para mostrar los mensajes en el teléfono móvil– y que esté al
servicio del personal –proceso mostrado en la aplicación de inserción prueba– , profesores
y prefectos en general, además de un usuario privilegiado que sea capaz de administrar
cada uno de los tópicos de la escuela.
El segundo factor que se asume es el hecho de solo el servicio solo será accesado por medio
de un teléfono móvil inteligente cuyo sistema operativo sea Android –específicamente de
su versión 2.1 (Eclair) en adelante–, por ello también se debería proveer una interfaz capaz
de ser usada desde cualquier navegador de internet, así entonces, también se propone una
aplicación basada en web que utilice el mismo servicio ya desarrollado y presente de
manera agradable la información y que además conviva conjuntamente con la aplicación
del Smartphone.
Así entonces, suponiendo el acceso a estos 2 componentes adicionales se esperaría que el
aumento en el acceso al servidor se duplique –Por efectos de acceso de maestros, prefectos
y administradores, además de usuarios en un ordenador personal–, es por ello que el cálculo
realizado tanto para el servidor como para el enlace de transferencia se realizó con cierto
margen de crecimiento.
42
Nótese que la aplicación de este componente es solo para el caso de prueba.
Capítulo IV. La aplicación CEM
116 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Finalmente podríamos pensar en el sistema CEM después de dicha planeación y
construcción figura como se muestra en la figura 4.26.
Figura 4.26 – Diagrama esquemático del sistema CEM después de consideraciones futuras.
Se tendrían que desarrollar tres nuevos componentes: la aplicación que consume el servicio
web actual y que lo muestra al usuario en una página ASP, un nuevo servicio web cuya
funcionalidad sea insertar los reportes en la base de datos y por último la aplicación web
que consume este servicio y lo muestra para uso del personal encargado del alta de los
reportes.
Esto supondría un aumento de entre un 60 y 70 por ciento del desarrollo manteniendo el
mismo número de personal, así mismo el mismo porcentaje en aumento de precio total de la
aplicación, ya que los componentes de exposición –Enlace estático– y servido –Servidor–,
como se dijo, fueron calculados tomando en cuenta este desarrollo posterior.
Capítulo IV. La aplicación CEM
117 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Referencias
[1]
Microsoft Developer Network, http://msdn.microsoft.com/es-mx/ms348103.
[2]
Eclipse Platform – Technical Overview,
http://www.eclipse.org/whitepapers/eclipse-overview.pdf.
[3]
White Paper: e4 Technical Overview,
http://www.eclipse.org/e4/resources/e4-whitepaper.php.
[4]
About SQL Server, http://www.microsoft.com/sqlserver/en/us/product-info.aspx.
[5]
Referencia de uso SQL Server Management Studio,
http://msdn.microsoft.com/es-es/library/ms174173.aspx.
[6]
Roger S. Pressman, Software Engineering: A Practitioner’s Approach. Mc-Graw Hill,
Quinta Edición.
[7]
CPU Benchmarks, http://www.cpubenchmark.net/
[8]
Understanding Load Tests.
http://msdn.microsoft.com/en-US/library/ms182562(v=vs.80).aspx
[9]
Microsoft Store. http://www.microsoftstore.com/store/msstore/home
Capítulo IV. La aplicación CEM
118 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Conclusiones
Como fue expuesto a lo largo del trabajo, la interconexión entre sistemas es un tópico que
en la actualidad ha tomado mucha importancia en la vida diaria de los usuarios, es por ello
que se atiende al principio básico de oferta y demanda. Entre más usuarios necesiten estos
sistemas también existirá más proliferación de los mismos.
Por otro lado, esta creciente en la demanda –la cual puede ser simplemente un cambio en la
opción así como la evolución de la misma- también se traduce en distintas maneras de
conexión entre ellos, lo cual impacta directamente a aquellos cuya ocupación es el
desarrollo tanto de la infraestructura de comunicación como de los sistemas y dispositivos
que las utilizan.
Uno de los principales objetivos era el mostrar un enfoque de desarrollo el cual fuera
resistente a estos cambios y opciones, a lo largo del trabajo se hizo especial hincapié en el
trabajo en capas, tanto intrínsecas del sistema como las correspondientes al desarrollador,
esto es, el trabajo dentro de un marco de referencia –tomando el marco de referencia OSI
en este trabajo- como el desarrollo de una aplicación en capas.
Este trabajo dentro de un marco ofrece varias ventajas, las cuales se ejemplificaron tanto
teórica como prácticamente, entre las cuales se destaca la correcta trasferencia entre
tecnologías, dispositivos y propietarios así como la encapsulación de la información a
varios niveles, lo cual nos entregó como resultado el poder obviarse entre sí sin que esto
afecte el funcionamiento del producto final.
Finalmente esto se ejemplifica con una aplicación trabajada dentro de este marco, la cual
tiene como característica el realizar su función, la cual es el notificado de eventos de
relevancia para los padres de familia con respecto al comportamiento y aprovechamiento
académico de su hijo o hijos, no importando el método de conexión de este, siempre y
cuando llegue al punto desde donde se empieza el trabajo. Internamente en el proceso de
desarrollo también se resalta la independencia característica de cada uno de los
Conclusiones
119 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
componentes, los cuales no hacen distinción del propietario de la herramienta o tecnología,
ya que este yace directamente en estándares abiertos capaces de conectarse entre sí.
Podemos ver a ciencia cierta que mientras se mantenga un alto grado de independencia
entre componentes, un cambio en alguno de ellos no tendrá un impacto drástico en la
solución completa, y que de la misma manera, la correcta colaboración entre cada una de
ellas nos entrega como resultando varias capas trabajando juntas con un solo propósito y
alcanzando la misma meta.
Conclusiones
120 Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Apéndices
Apéndice A. Códigos de estatus del protocolo HTTP.
Una respuesta por parte del servidor en el protocolo HTTP consta de los campos de línea
de estatus, encabezados –De nivel alto y perteneciente a la respuesta- y el cuerpo del
mensaje, además de los separadores y delimitadores, como se muestra en la figura 2.8,
dentro de esta respuesta encontramos un campo que es la línea de estatus, cuyo formato se
muestra en la figura 2.10.
La línea de estatus contiene en sí el estado del servidor, este es descrito por los campos de
Código de estatus y Razón. El código de estatus es un identificador de 3 dígitos resultado
de la petición y la razón es una descripción acerca del código de estatus, el cliente solo
requiere la examinación del código de error, mientras que la razón es un campo para el uso
humano, lo códigos están distribuidos de acuerdo al primer dígito y los dos siguientes no
tienen ninguna distribución especial, solamente la identificación del estatus. Estos códigos
se muestran en la tabla A.1:
Código
Función
Descripción
1XX
Informacional
Petición recibida, indica la continuación
del proceso.
2XX
Éxito
La acción fue recibida, entendida y
aceptada de manera satisfactoria.
3XX
Redireccionamiento
Indica que es necesario realizar una
acción
complementaria
para
poder
completar la petición.
4XX
Error del cliente
La sintaxis de la petición no es correcta
o no puede ser cumplida.
5XX
Error del servidor
El servidor falló para cumplir una
petición valida.
Tabla A.1 – Grupos de códigos informacionales del protocolo HTTP.
Apéndices
xvii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Es posible ampliar la descripción de cada una de las asignaciones anteriores como sigue:
•
Informacional. Este tipo de respuestas indican una respuesta provisional, las
respuestas consisten solamente de la línea de estatus, encabezados –Que son
opcionales- y delimitadores, se tienen las siguiente respuestas específicas en esta
sección:
o 100 - Continue. Continuar con la petición, se informa que la primera parte
de la petición ha sido recibida y que debe seguirse mandando el resto.
o
101 – Switching protocols. El servidor conmuta protocolos de aplicación
usados actualmente en la conexión.
•
Éxito. Indica que la petición realizada por el cliente fue satisfactoriamente recibida
y aceptada, las respuestas que se encuentran en esta sección son:
o 200 – OK. Regresa una respuesta de éxito a la petición realizada.
o 201 – Created. Petición exitosa que resultó en un nuevo recurso creado, la
URI del nuevo recurso se envía en la entidad de la respuesta.
o 202 – Accepted. Se aceptó la petición exitosamente pero el procesamiento
relacionado con esta aún no está terminado, este comportamiento esta
premeditado, esta respuesta permite que el servidor pueda atender otros
procesos mientras realiza el procesamiento.
o 203 – Non Authoritative Information. Indica que lo recibido no está
disponible en el servidor pero es una copia local o de terceros de la
información.
o 204 – No Content. El servidor recibió correctamente la petición pero no
necesita regresar contenido en la entidad como respuesta.
o 205 – Reset Content. Petición recibida correctamente, el cliente debe
recargar el visor debido a la respuesta.
o 206 – Partial Content. Se entrega exitosamente el contenido parcial del
recurso.
Apéndices
xviii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Redireccionamiento. Indica que es necesario tomar acciones adicionales para que
la petición pueda ser servida exitosamente, las siguientes respuestas son parte de
esta sección:
o 300 – Multiple choices. El recurso corresponde a varias representaciones
cada una con distintas localidades.
o 301 – Moved permanently. El recurso ha sido asignado a una nueva URO
de manera permanente y las referencias futuras deben apuntar a este.
o 302 – Found. El recurso reside temporalmente en una URI diferente, por lo
que las futuras peticiones deben redirigirse a la nueva localidad.
o 303 – See other. La respuesta a esta petición se encuentra en una URI
distinta y se usará el método de invocación GET para regresar dicho
recurso.
o 304 – Not modified. El documento no ha sido modificado desde el último
acceso.
o 305 – Use proxy. La localidad entrega una URI de un proxy, por lo que
recurso debe accesarse a través de uno.
o 306. Código reservado, sin uso.
o 307 – Temporary redirect. Recurso temporalmente en otra URI, sin
embargo la peticiones pueden ser hechas a la misma localidad
•
Error del cliente. Esta sección pertenece a respuestas indicando que el cliente está
errado, estas son:
o 400 – Bad request. Petición no entendida por el servidor debido a una mala
sintaxis.
o 401 – Unauthorized. La petición necesita autenticación del usuario.
o 402 – Payment required. Para uso futuro.
o 403 – Forbidden. El servidor entiende la petición pero se niega a
responder, la autorización no ayuda con el proceso y la petición no debería
ser repetida.
o 404 – Not found. El servidor no encuentra un recurso con la URI solicitada.
Apéndices
xix Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
o 405 – Method not allowed. El método especificado en la petición no está
permitido por el recurso identificado por la URI de petición.
o 406 – Not aceptable. El recurso de petición no es capaz de generar las
entidades de respuesta de acuerdo con la información enviada.
o 407 – Proxy Authentication Required. Indica que el cliente debe
autenticarse primero con el proxy.
o 408 – Request Timeout. El cliente no continuó con la petición durante el
tiempo que el servidor está preparado para esperar.
o 409 – Conflict. La petición no pudo ser completada debido a un conflicto
en el estado del recurso.
o 410 – Gone. El recurso solicitado no está disponible y el servidor no conoce
una nueva dirección de acceso, esta condición se considera permanente.
o 411 – Length Required. El servidor se rehúsa a servir una petición sin una
longitud de contenido especificada.
o 412 – Precondition Failed. Las precondiciones dadas en los encabezados
de la petición se evalúan como falsas.
o 413 – Request Entity Too Large. El servidor se rehúsa a procesar la
petición ya que la entidad de esta es más grande de lo que el servidor está
preparado para procesar.
o 414 – Request URI Too Long. El servidor se rehúsa a servir la petición por
que la URI de petición es demasiado larga de lo que el servidor está
preparado a interpretar.
o 415 – Unsupported Media Type. El servidor se rehúsa a servir debido a
que la entidad de la petición no está en un formato soportado por el recurso
del método de petición.
o 416 – Requested Range Not Satisfiable. El servidor no puede entregar la
parte del archivo solicitada.
o 417 – Expectation Failed. El comportamiento, definido por el campo
Expect en el encabezado no es conocido por el servidor.
Apéndices
xx Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
Error del servidor. En esta sección se encuentran las respuestas que indican que el
servidor erró o que es incapaz de regresar una respuesta, entre estas están:
o 500 – Internal Server Error. El servidor encontró una condición no
definida que no permite servir exitosamente la petición.
o 501 – Not Implemented. El servidor no soporta la funcionalidad necesaria
para completar la petición.
o 502 – Bad Gateway. Cuando el servidor actúa como gateway, recibe una
respuesta inválida de nivel alto que impidió una respuesta exitosa.
o 503 – Service Unavailable. El servidor se encuentra en estado en el cuál no
puede manejar peticiones, esto puede ser debido a una sobrecarga o
mantenimiento.
o 504 – Gateway Timeout. El servidor no recibe respuesta en el tiempo
indicado de nivel alto o de un servidor auxiliar, mientras está funcionando
como gateway o proxy.
o 505 – HTTP Version Not Supported. El servidor no soporta la versión del
protocolo HTTP que se utiliza en el mensaje de petición.
Apéndices
xxi Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
Apéndice B. Manejo de sockets de red.
El funcionamiento de los sockets se explicó en la sección 2.4.1, donde se hizo un
preámbulo general de la comunicación entre ellos, se puntuó acerca de las similaridades
entre la comunicación de acceso a ficheros con el paradigma de los sockets, por medio de
las primitivas (read - write). En este apéndice se mostrará de manera breve el manejo
básico de los sockets de red bajo el API de sockets.
Antes de realizar cualquier tarea por medio de un socket de red es necesario, al igual que
en cualquier acceso a un fichero, definir como se accesará, es por ellos que el primer paso
es crear un socket. Esta tarea puede tener dos distintos acercamientos, el generar un socket
individual o un par enlazado de sockets.
El primer acercamiento corresponde a crear un socket de manera individual, en este se
debe indicar la familia de protocolos, el tipo de socket a crear y el protocolo de
comunicación, dentro del API de socket existe la función socket que realiza esta tarea
devolviendo un identificador de socket en el proceso, como se muestra:
Dónde:
•
fProt. Familia de protocolos a usar en el socket, algunos valores comunes son
PF_INET (TCP/IP), PF_UNIX (Sistema de archivos UNIX), etc.
•
tipo. Tipo de comunicación deseada, corresponde a los tipos mencionados en la
sección
2.4.1,
toma
valores
de
SOCK_STREAM,
SOCK_DGRAM
y
SOCK_RAW, para tipos orientados a conexión, NO orientados a conexión y de
protocolo IP, respectivamente.
•
protocolo. Protocolo de comunicación puede ser UDP, IP, TCP, etc, incluso la
opción Raw para paquetes “crudos” de IP.
Apéndices
xxii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
La segunda forma es crear un par enlazado de socket, en el intento de un acercamiento
parecido a un pipe o pipeline43 de sistema de archivos, es generado por la función
socketpair, esta función es muy útil cuando se conoce la dirección destino del socket de
comunicación, por ello, además de los argumentos especificados en el primer acercamiento
es necesario un identificador de ambas direcciones, un arreglo conteniendo las dos
direcciones de los sockets, el argumento sockArray:
Esta función tiene la particularidad de crear dos sockets simultáneamente.
Una tarea ligada al proceso de creado de un socket es su terminación, cuando este ya
concluyó su tarea, esto se realiza por medio de la función close, como se muestra:
esta función toma como argumento el identificador producido por el proceso de creación
del socket. Internamente este llamado se deshace de la referencia al socket y lo destruye.
Cuando un socket es creado de la primera manera este no contiene una dirección hacia su
contraparte así que debe indicársele a la tarea la dirección de envío, a este proceso se le
conoce como enlace del socket, provisto por la función bind del API.
dónde:
•
socket. Descriptor del socket a enlazar.
43
Pipe, pipeline o tubería se refiere la conexión de procesos, la principal característica de este arreglo es que la salida de un proceso es la entrada de otro, son típicamente implementados en sistemas operativos multitarea. Apéndices
xxiii Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
•
localAddr. Especifica la dirección local del socket, el formato de la dirección debe
ser una estructura que siga con el diseño de la figura B.1.
•
lengthAddr. Especifica la longitud de la dirección en bytes.
Figura B.1 – Estructura del argumento localAddr.
Cuando un socket se crea -y se enlaza a alguna dirección, si es necesario-, se encuentra
desconectado, lo que quiere decir que no está asociado a ninguna dirección, por lo que
debe conectarse con el fin establecer un lazo permanente –mientras no se termine
explícitamente la conexión-, esto se realiza con la función connect.
Esta función toma como argumentos el identificador del socket (socket), la dirección del
socket destino, descrita como en la figura B.1 (addrDest) y la longitud de dicha dirección
(lengthAddr).
Una vez terminado el proceso de creado, enlazado local y remoto del socket, se puede
iniciar con el proceso de envío de datos, en este apéndice se describirá el funcionamiento
de las primitivas write, send y read, para escribir, enviar y recibir datos, respectivamente.
La función write transmite datos a través de la conexión creada, toma 3 argumentos, el
primero de ellos es el descriptor del socket seguido del buffer que contiene la dirección de
memoria de los datos a enviar y finalmente el número de bytes a enviar en el proceso,
como se muestra a continuación:
Apéndices
xxiv Diseño y construcción de un sistema de notificaciones para el control del estatus académico
estudiantil.
De igual manera, para enviar información se cuenta con la función send, ésta, además del
envío de la información toma un último argumento que corresponde a las banderas de
control de transmisión, de la manera siguiente.
El receptor tiene el trabajo de leer la información enviada para su posterior tratamiento,
esto se realiza con la función read, que puede ser utilizada solamente si el socket está
conectado, consta de tres argumentos, el descriptor del socket del cual se leen los datos, la
dirección de memoria donde se guardarán los datos recibidos y el máximo número de bytes
para leer.
Para el programador que desarrolla una aplicación para intercomunicación en red, la
manera de comunicación puede ser obviada y no debería tener que preocuparse por cómo
se desarrolla la conexión entre dispositivos, menos aún que protocolo debe de ser usado y
como describir cada una de las direcciones de enlace, esta capa está por debajo del alcance
de la aplicación, es por ello que con el pasar de los años se desarrollaron protocolos de
capas superiores así como herramientas cuyo propósito era obviar estos detalles, uno de
estos protocolos está descrito en la sección 2.3.4 del presente, utilizado para el consumo de
servicios orientados a servicios, RPC.
Apéndices
xxv