Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
19
CAPÍTULO 2. ESTADO DEL CAMPO DEL
CONOCIMIENTO
2.1 Introducción
El estado del campo del conocimiento consiste en un apartado donde se describe las bases de la
investigación, recalcando aquellos temas importantes bajo los cuales se sustenta la investigación
y describiendo los conceptos con los cuales se han hecho las consideraciones particulares.
También proporciona una descripción de los temas relacionados a la investigación, esto
incluyendo aquellas investigaciones que presentan resultados similares, alternos o contrarios a
la investigación realizada, con el propósito de contextualizar el entorno durante el desarrollo de
una investigación.
Dentro de la situación de la problemática actual se incluyen el Marco Teórico que describe las
definiciones fundamentales bajo las que se sustenta la tesis. También se considera el marco
contextual o referencial que son todos aquellos trabajos relacionados con la investigación,
incluyendo trabajos académicos, investigaciones científicas y desarrollos académicos.
El Tecnológico Nacional de México (TecNM) es un órgano desconcentrado de la Secretaría de
Educación Pública (SEP), con autonomía técnica, académica y de gestión. El cual tiene
actualmente adscritos a 266, institutos tecnológicos, unidades y centros de investigación,
docencia y desarrollo de educación superior tecnológica. De los cuales 126 son Institutos
Tecnológicos Federales, 134 Institutos Tecnológicos Descentralizados, 4 Centros Regionales de
Optimización y Desarrollo de Equipo (CRODE), un Centro Interdisciplinario de Investigación
y Docencia en Educación Técnica (CIIDET) y un Centro Nacional de Investigación y Desarrollo
Tecnológico (CENIDET). [16]
20
2.2 Marco teórico
2.2.1 Dominio de conocimiento de la problemática
La Dirección General de Tecnológico Nacional de México es el órgano rector de las actividades
que se realizan en todos los tecnológicos y se compone de la Dirección General, cuatro
secretarías: la Secretaría de Planeación Evaluación y Desarrollo Institucional, la Secretaría
Académica de Investigación e Innovación, la Secretaría de Extensión y Vinculación y la
Secretaría de Administración, y cuatro direcciones adyacentes: la Dirección de Institutos
Tecnológicos Descentralizados, la Dirección Jurídica, la Dirección de Cooperación y Difusión
y la Dirección de Apoyo y Orientación a la Comunidad. En el eje de la Secretaría Académica,
se puede encontrar la Dirección de Posgrado, Investigación e Innovación. A continuación, en la
Figura 2.1, se muestra el esquema organizacional de la Dirección General.
Figura 2.1. Organigrama Operativo de la Dirección General de Tecnológico Nacional de México [1]
La Dirección de Posgrado, Investigación e Innovación (DPII) tiene como función “Coordinar y
evaluar la elaboración de normas, instrumentos, lineamientos y criterios para regular las
actividades de posgrado, investigación científica e innovación, y vigilar su aplicación” [16, p.
Dirección General
Dirección de Institutos Tecnológicos
Descentralizados
Dirección Jurídica
Dirección de Cooperación y Difusión
Dirección de Apoyo y Orientación a la
Comunidad
Secretaría de Planeación Evaluación
y Desarrollo Institucional
Dirección de Planeación y Evaluación
Dirección de Programación,
Presupuestación e Infraestructura Física
Dirección de Tecnologías de Información y Comunación
Dirección de Aseguramiento de la
Calidad
Secretaría Académica de Investigación e
Innovación
Dirección de Docencia e Innovación Educativa
Dirección de Posgrado,
Investigación e Innovación
Dirección de Asuntos Escolares y Apoyo a
Estudiantes
Secretaría de Extensión y Vinculación
Dirección de Vinculación e
Intercambio Académico
Dirección de Educación Continua y a Distancia
Dirección de Educación Continua y a Distancia
Dirección de Promoción Cultural y
Deportiva
Secretaría de Administración
Dirección de Personal
Dirección de Finanzas
Dirección de Recursos Materiales y Servicios
21
14], así como “Coordinar la creación, desarrollo y consolidación de eventos, concursos,
congresos, simposios, seminarios y reuniones de carácter académico y científico en el TecNM,
en el nivel de estudios de posgrado, para desarrollar la investigación aplicada, científica y
tecnológica.” [16, p. 15]
2.2.2 Arquitecturas en las que se apoya la propuesta de solución
Esta Tesis cuenta con un diseño basado en tres especificaciones y estilos de arquitectura de
sistemas de información para la World Wide Web (WWW), estas especificaciones y estilos de
arquitectura son fundamentales para llevar a cabo la propuesta y proporcionar la máxima
flexibilidad y extensibilidad de los recursos obtenidos, ofreciéndolos como servicios y que a su
vez reducirán las redundancias innecesarias en los procesos de seguimiento de las actividades
académicas vinculadas a la investigación. A continuación, se describirán brevemente estas
arquitecturas fundamentales:
Protocolo de Transferencia de Hipertexto (HTTP): es un protocolo estándar
utilizado ampliamente en la World Wide Web, y que en su utilización práctica es capaz
de atender conexiones cliente-servidor mediante peticiones y respuestas.
Representational State Transfer (REST): Es un estilo de arquitectura de software
aplicada al diseño de componentes en sistemas distribuidos basados en hipermedia que
proporciona una arquitectura de alto rendimiento y mantenimiento de los sistemas de
información en la World Wide Web.
OAuth 2.0: Estándar abierto para autorización que permite a los usuarios acceso a
Sitios Web de terceros utilizando sus cuentas sin exponer la contraseña vinculada a la
misma.
Protocolo de Transferencia de Hipertexto (HTTP)
Para dar inicio con los estándares que sustentan a esta tesis encontramos al Protocolo de
Transferencia de Hipertexto (HyperText Transfer Protocol), en lo sucesivo HTTP, “es un
protocolo a nivel de aplicación para sistemas distribuidos, colaborativos y de hipermedia. Es
genérico, sin estado, el cual puede ser utilizado para múltiples tareas diferentes a su uso del
hipertexto, como nombres de servidores y sistemas de administración de objetos distribuidos,
22
por medio de extensión de sus métodos de peticiones, códigos de error y encabezados. Una
característica de HTTP es la negociación entre los tipos de representación de datos, permitiendo
a los sistemas ser construidos de forma independiente a los datos que serán transferidos.” [17]
El uso de este protocolo resulta vital para soportar el sistema de información planteado en la
tesis y resulta de apoyo, en conjunto a una serie de conceptos para poder extender no únicamente
la operación del sistema, sino para permitir la apertura y la comunicación libre entre la propuesta
y futuros proyectos.
La especificación de HTTP 1.1 utiliza un número de Términos para referirse a los roles que
representan los participantes y objetos en la comunicación por HTTP. Estos términos son:
- Conexión (connection): Una capa de transporte de circuitos virtuales establecidos entre
dos programas para el propósito de comunicación.
- Mensaje (message): La unidad básica de comunicación HTTP, consistente en una
secuencia estructurada de octetos encajando con la sintaxis específica del protocolo y
transmitida por medio de la conexión.
- Petición (request): Un mensaje de petición de HTTP.
- Respuesta (response): Un mensaje de respuesta HTTP.
- Recurso (resource): Un objeto de datos o servicio que puede ser identificado por una
URI (Uniform Resource Identifier). Los recursos pueden estar disponibles en múltiples
representaciones.
- Entidad (entity): La información transferida como la carga de la petición o respuesta.
Una entidad consiste de metainformación en la forma de campos de encabezado de la
entidad y contenido en la forma de cuerpo de la entidad.
- Representación (representation): Una entidad incluida con una respuesta que esté
sujeta al contenido de negociación. Existen múltiples representaciones asociados con un
estado particular de respuesta.
- Negociación del Contenido (content negotiation): El mecanismo para seleccionar la
representación apropiada cuando se atiende a una petición.
23
- Variante (variant): Un recurso puede tener una, o más de una representación asociada
en un instante dado. Cada una de estas representaciones es definida como ‘variante’. El
uso del término ‘variante’ no necesariamente implica que el recurso está sujeto a
negociación del contenido.
- Cliente (client): Se refiere a un programa que establece conexiones con el propósito de
enviar peticiones.
- Agentes de usuario (user agent): El cliente el cual inicia la petición. Estos son a
menudo navegadores, editores, spiders, u otras herramientas para el usuario final.
- Servidor (servidor): Un programa de aplicación que acepta las conexiones en orden de
servir peticiones devolviendo respuestas. Cualquier programa de aplicación puede ser
capaz de ser ambos, un cliente y un servidor; el uso de este término se refiere únicamente
al rol empleado por un programa para una conexión en particular.
- Servidor de Origen (origin server): El servidor en el cual un recurso dado reside o será
creado.
- Proxy: Un programa intermediario que actúa como ambos, un servidor y un cliente para
el propósito de hacer peticiones de intermedio con otros clientes. Las peticiones son
servidas internamente o por traspaso, con posible traducción a otros servidores. Un
proxy DEBE implementar ambos requerimientos, los del cliente y del servidor, de esta
especificación.
- Pasarela (gateway): Un servidor el cual actúa como un intermediario para otros
servidores. A diferencia de un proxy, una pasarela recibe las peticiones como fuese el
servidor de origen para los recursos solicitados. El cliente que hace la solicitud puede no
ser consciente de que se está comunicando con una pasarela.
- Túnel (tunnel): Un programa intermediario que actúa como relevador ciego entre dos
conexiones. Una vez activado, un túnel no es considerado como un participante en la
comunicación HTTP, a través del túnel es posible que se inicie la comunicación
mediante una petición HTTP. El túnel deja de existir, cuando ambos extremos cierran
las conexiones relevadas.
- Cache: Un almacenamiento de programa local de los mensajes de respuesta y el sistema
que controla esos mensajes de almacenamiento, recuperación y borrado. Una caché
24
almacena respuestas cacheables con la intención de reducir el tiempo de respuesta y el
consumo de ancho de banda en el futuro para peticiones equivalentes. Cualquier cliente
o servidor debería incluir una caché.
- Cacheable: Una respuesta es cacheable si la caché está concedida para almacenar una
copia del mensaje de respuesta para el uso en peticiones de respuestas subsecuentes.
Incluso si un recurso es cacheable, deben existir restricciones adicionales en cuando
puede utilizarse una copia de caché para una petición particular.
- Primera mano (first-hand): Una repuesta es de primera mano si proviene directamente
y sin retraso innecesario del servidor de origen, quizás por medio de uno o más proxys.
Una respuesta también puede ser de primera mano si su validez ha sido verificada
directamente con el servidor de origen.
- Tiempo de expiración explícito (explicit expiration time): El tiempo en el que el
servidor de origen indica que una entidad ya no será regresada por caché sin mayor
validación.
- Tiempo de expiración heurístico (heuristic expiration time): Un tiempo de
expiración asignado por una caché cuando no existe tiempo de expiración está
disponible.
- Edad (age): La edad de una respuesta es el tiempo desde el que fue enviada por o
satisfactoriamente validada por el servidor de origen.
- Tiempo de vida de frescura (freshness lifetime): La longitud de tiempo entre la
generación de una respuesta y su tiempo de expiración.
- Frescura (fresh): Una respuesta es fresca si su edad no ha excedido su tiempo de vida
de frescura.
- No fresco (stale): Una respuesta es no fresca, si su edad ha pasado el tiempo de vida de
frescura.
- Semánticamente transparente (semantically transparent): Una caché se comporta en
una forma “semánticamente transparente”, con respecto a una respuesta particular,
cuando su uso no afecta ni al cliente ni al servidor de origen, con excepción de mejorar
el rendimiento. Cuando una caché es semánticamente transparente, el cliente recibe
25
exactamente la misma respuesta (excepto por los encabezados de salto) que pueden
recibirse si la petición fue enviada por el servidor de origen.
- Validador (validator): Es un elemento del protocolo (ejemplo, una etiqueta de entidad
o el tiempo de última modificación) que es utilizado para encontrar es una copia
equivalente de una entidad.
- Flujo de subida y Flujo de bajada (upstream/downstream): el flujo de subida y el
flujo de bajada describen el flujo de un mensaje: todos los mensajes fluyen de subida a
bajada.
- Entrante y Saliente (inbound/outbound): Entrante y Saliente se refiere a los caminos
que toman las peticiones y respuesta para los mensajes. “Entrante” significa “viajando
hacia el servidor de origen” y “Saliente” significa “viajando hacia el agente de usuario”.
Resumen de la operación completa
El protocolo HTTP es un protocolo de petición/respuesta. Un cliente envía una petición al
servidor con el formato del Método, URI y Versión del protocolo, seguido por modificadores
del mensaje al estilo MIME, información del cliente, y posiblemente contenido del cuerpo sobre
una conexión con un servidor. El servidor responde con una línea de estado, que incluye la
versión del mensaje de protocolo y un código de error o cumplimiento, seguido nuevamente por
un mensaje al estilo MIME conteniendo información del servidor, entidad, metainformación y
un contenido del cuerpo de la entidad.
La mayoría de las comunicaciones HTTP son iniciadas por un agente de usuario y consiste en
peticiones que serán aplicadas a un recurso con algún servidor de origen. En el más simple de
los casos, como se visualiza en la Figura 2.2, esto puede obtenerse por medio de una única
conexión entre el agente de usuario y el servidor de origen.
26
Conexión
Agente de Usuario
Servidor de Origen
Petición
Respuesta
Figura 2.2. Conexión simple HTTP.
Una situación más complicada ocurre cuando uno o más intermediarios están presentes en la
cadena de peticiones y respuestas. Existen tres tipos de intermediarios: proxy, pasarelas y túnel.
Agente de usuario
IntermediarioA
IntermediarioB
IntermediarioC
Servidor de origen
Petición
Petición
Petición
Petición
Respuesta
Respuesta
Respuesta
Respuesta
Figura 2.3. Conexión HTTP con Intermediarios.
En la Figura 2.3 se muestran tres Intermediarios entre el agente de usuario y el servidor de
origen. Un mensaje de petición o respuesta que viaje toda la cadena, pasa por cuatro diferentes
conexiones. Esta distinción es importante porque algunas opciones de comunicación HTTP
pueden aplicar sólo a la conexión con la más cercana, sin túnel de intermedio, únicamente en
los extremos de la cadena o para todas las conexiones de la cadena. A pesar de que el diagrama
es lineal, cada participante puede tener comunicaciones múltiples y simultáneas. Por ejemplo,
27
B puede estar recibiendo peticiones de varios clientes, diferentes de A y/o enviando peticiones
a servidores distintos de C, al mismo tiempo que atiende la petición de A.
Cualquier participante de la comunicación el cual no esté actuando como un túnel, puede
emplear una caché interna para manejar las peticiones. El efecto de una caché es aquel en el que
la cadena es acortada por uno de los participantes porque cuenta con una respuesta cacheada
aplicable a esa petición. La Figura 2.4 ilustra la cadena resultante si el Intermediario B tiene una
copia cacheada de una respuesta anterior del Servidor de Origen por medio del Intermediario C,
la cual no fue cacheada por el Agente de usuario o el Intermediario A.
Agente de usuario
IntermediarioA
IntermediarioB
IntermediarioC
Servidor de origen
Petición
Petición
Respuesta (cacheada)
Respuesta
Figura 2.4. Conexión HTTP con intermediarios y uso de Caché.
No todas las respuestas son útiles siendo cacheables y algunas peticiones pueden contener
modificadores los cuales tienen requerimientos especiales en el comportamiento de la caché.
La comunicación HTTP normalmente es realizada mediante conexiones TCP/IP. El puerto
predeterminado es el 90, pero otros puertos pueden utilizarse. Esto no imposibilita que HTTP
sea implementado en la parte superior de cualquier protocolo sobre Internet, o en otras redes.
Uniform Resource Identifiers (URI)
Un Identificador Uniforme de Recurso (Uniform Reource Identifier), en adelante URI, es una
secuencia compacta de caracteres que identifica un recurso abstracto o físico. La especificación
define la sintaxis genérica de una URI y el proceso para resolver referencias de URI que pueden
ser relativas a una forma, en conjunto con lineamientos y consideraciones de seguridad para el
uso de URIs en el Internet. La sintaxis URI define una gramática que es un superconjunto de
28
todas las URIs, permitiendo una implementación para convertir los componentes comunes de
una referencia de URI sin saber los requerimientos específicos de esquema para cada posible
identificador. [18]
Las URIs son caracterizadas de la siguiente manera:
Uniforme: La uniformidad proporciona múltiples beneficios. Permite diferentes tipos
de identificadores de recursos para ser utilizados en el mismo contexto, incluso cuando
los mecanismos utilizados para acceder a esos recursos puedan diferir. También permite
la introducción de nuevos tipos de recursos sin interferir en la manera que los existentes
son utilizados. Permite a los identificadores ser utilizados en múltiples contextos
diferentes, permitiendo a nuevas aplicaciones o protocolos atender a un gran conjunto
de identificadores de recursos.
Recurso: En la especificación RFC3896 no se limita el alcance de lo que puede ser un
recurso; en lugar de ello, el término recurso es utilizado en un sentido general para
cualquier cosa que pude ser identificado por una URI. El recurso, no necesariamente es
accesible por medio de Internet.
Identificador: Un identificador representa la información requerida para distinguir que
está siendo identificado de todas las otras cosas dentro del alcance de identificación. Los
términos “identificable” e “identificando” se refieren al propósito de distinguir un
recurso de entre otros recursos.
A continuación de muestran algunos ejemplos de URIs para ilustrar múltiples esquemas de URI
y variaciones en sus componentes comunes de la sintaxis:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc2396.txt
ldap://[2001:db8::7]/c=CB?objectClass?one
mailto:[email protected]
news:comp.infosystems.www.servers.unix
tel: +1-816-555-1212
29
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
La URL para HTTP
El esquema de “http” es utilizado para localizar recursos de red por medio del protocolo HTTP.
A continuación, se define la sintaxis específica y semántica de las URLs para http.
http_URL = “http:” “//” anfitrión [ “:” puerto] [ ruta_absoluta [ “?” query]]
Si el puerto está vacío o no es proporcionado, el puerto 80 es asumido. Las semánticas que las
que identifican, están localizadas en el servidor escuchando por conexiones TCP en el puerto de
ese anfitrión, y la URI de petición para el recurso es una ruta absoluta. Utilizar las direcciones
IP en las URLs deberá ser evitado cuando sea posible. Si la ruta absoluta no está presente en la
URL, entonces debe colocarse como “/” cuando es utilizada como una URI de petición para un
recurso.
Tipos de Medio
HTTP utiliza los Tipos de Medio de Internet en los encabezados de Content-Type y Accept en
orden de proporcionar negociación abierta y extensible de los tipos de datos proporcionados.
Los tipos de medios se describen: tipo “/” subtipo (“;” parámetro). Los atributos tipo, subtipo y
parámetros no deben ser sensibles a mayúsculas y minúsculas. El espacio en blanco lineal no
debe ser utilizado entre el tipo y el subtipo.
Los valores de Tipos de Medios son registrados por la Internet Assigned Number Authority
(IANA). Los procesos para el registro de un tipo de medio se describen en el RFC 1590. El uso
de tipos de medio no registrados no se recomienda. [19]
Peticiones
Un mensaje de petición de un cliente a un servidor, incluye dentro de la primera línea del
mensaje, el método para ser aplicado en el recurso, el identificador del recurso y la versión del
protocolo que se está utilizando.
30
Ejemplo de una petición:
http://www.ejemplo.com/ruta/de/ejemplo
GET /ruta/de/ejemplo HTTP/1.1
Host: ejemplo.com
User-Agent: Navegador
Cuerpo del mensaje de petición.
Línea de petición
La línea de petición comienza con el token del método, seguido por la URI de Petición y la
versión del Protocolo, terminando con un salto de línea (CRLF). Los elementos se separan con
caracteres de espacio (SP). No se permiten los CR o LF con la excepción del final de la
secuencia.
Método
El token del método indica el proceso para ser realizado en el recurso identificado por la URI
de petición. El método es sensible a mayúsculas y minúsculas. Algunos de estos métodos son:
OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE y CONNECT.
La lista de los métodos permitidos por un recurso puede ser especificado en el encabezado
Allow. El código de retorno de la respuesta siempre notifica al cliente cuando un método está
actualmente permitido en algún recurso, ya que los métodos permitidos pueden cambiar
dinámicamente. Un servidor de origen devolverá el código de estado 405 (Method Not Allowed)
si el método es conocido por el servidor, pero no permitido para el recurso solicitado, y 501 (Not
Implemented) si el método no es reconocido o no está implementado por el servidor de origen.
Los métodos GET y HEAD deben ser soportados por todos los servidores de propósito general.
Los otros métodos son opcionales; sin embargo, si los métodos son implementados, deberá
utilizarse la semántica especificada.
URI de Petición
La URI de Petición es un Identificador Uniforme de Recurso que especifica al recurso que será
aplicada la petición.
31
URI-Petición = “*” | URIabsoluta | ruta_absoluta | autoridad
Las cuatro opciones para la URI son dependientes de la naturaleza de la petición. El asterisco
“*” significa que la petición no aplica a un recurso en particular, sino al servidor mismo, y es
únicamente permitido cuando el método que sea utilizado no necesariamente aplique a un
recurso.
La URI absoluta es requerida cuando la petición está siendo realizada a un Proxy. El proxy
requiere que la petición o servicio sea enviada en forma de una caché valida y regresar la
respuesta. Nótese que el proxy puede enviar la petición a otro proxy o directamente al servidor.
La más común de las formas de Petición es identificar a un recurso en un servidor de origen o
pasarela, en este caso, la ruta absoluta debe ser transmitida como una ubicación de red y la
autoridad será transmitida en el encabezado de Host.
Campos de encabezado en la Petición
Los encabezados de campos permiten al cliente pasar información adicional acerca de la
petición e información del cliente al servidor. Estos campos funcionan como modificadores de
la petición con semánticas similares a los parámetros en un lenguaje de programación por
invocación de métodos. Algunos encabezados comunes para las peticiones son: Accept,
Authorization, Expect, From, Host, If-Modified-Since, Max-Forwards, Range, Referer,
User-Agent, etc.
Respuesta
Después de recibir e interpretar el mensaje de petición, un servidor responde con un mensaje
HTTP de respuesta.
HTTP/1.0 200 OK
Date: Mon, 16 Mar 2016 17:13:32 GMT -06:00
Content-Type: text/html
Content-Length: 45
<html>
<body>
<h1>Hola Mundo</h1>
</body>
</html>
32
La primera línea de un mensaje de respuesta es la Línea de Estado, consistiendo en la versión
del protocolo, seguida por un código numérico de estado y su frase textual asociada. Cada
elemento es separado por espacios (SP). No se permiten retornos de carro (CR) o saltos de línea
(LF) con la excepción de la secuencia final CR-LF.
El código de estado y la frase de razón
Los elementos de código de estado son un código de 3 dígitos para el intento de entender y
satisfacer una petición. La frase de razón está enfocada a proporcionar una descripción textual
descriptiva del código de error. El código de error tiene la intención de ser utilizado por un
autómata y la frase para el usuario humano. El cliente no requiere examinar o desplegar la frase
de razón.
El primer dígito del código de estado define la clase de la respuesta. Los últimos dos dígitos no
cuentan con algún rol de categorización. Estos son los cinco valores para los primeros dígitos:
1xx: Informacional – La petición fue recibida y continúa procesándose.
2xx: Satisfactorio – La acción fue atendida, recibida, entendida y aceptada
satisfactoriamente.
3xx: Redirección – Alguna acción adicional debe realizarse con el propósito de
completar la petición.
4xx: Error del cliente – La petición contiene una sintaxis incorrecta o no puede ser
atendida.
5xx Error del servidor – El servidor falló en atender una petición aparentemente válida.
Los valores individuales de los estados numéricos definidos por HTTP/1.1 y un ejemplo
conjunto de las frases de razón correspondientes son presentados en la página 146. Las frases
listadas son únicamente recomendaciones y pueden ser reemplazadas por equivalentes locales
sin afectar al protocolo.
Los códigos de estado HTTP son extensibles, las aplicaciones de HTTP no requieren entender
el significado de todos los códigos registrados, aunque dicho entendimiento es evidentemente
33
deseable. Sin embargo, las aplicaciones deben entender la clase de cualquier código de estado.
Y deberán tratarlo como el equivalente de la base de cada clase x00 con la excepción de que la
respuesta no deberá ser cacheada.
Conclusión
La utilización del protocolo HTTP permite una comunicación directa entre los agentes de
usuario y los servidores, este protocolo es fundamental en el uso de la World Wide Web y resulta
sumamente efectivo para una comunicación síncrona. Este protocolo representa la base de un
estilo de arquitectura, usualmente denominado REST, para la comunicación de sistemas
distribuidos.
Representational State Transfer (REST)
Cuando se habla de Sistemas de Información en la Web, se piensa en un sitio web mediante
documentos HTML (HypertText Markup Language) con algún tipo de funcionalidad vinculada
a una base de datos. Sin embargo, los protocolos de Internet no fueron diseñados para ese único
propósito, sino para compartir recursos de hipermedia con múltiples entidades y acordando
representaciones de la información para ser compartida. Con base en esto surge la Transferencia
de Estado Representativo (Representational State Transfer), en lo sucesivo REST, que se define
como “es un estilo de arquitectura para sistemas de hipermedia distribuidos. Consiste en un
estilo híbrido derivado de varios estilos de arquitectura basadas en red y combinadas con
restricciones adicionales que definen una interfaz de conexión uniforme.” [20]
Este estilo de arquitectura soporta la ventaja de que los recursos no sólo se comparten
directamente entre un servidor hacia un agente de usuario por un usuario final, sino también
entre múltiples sistemas de información que pueden comunicarse entre sí encontrándose en
servidores distintos.
Características fundamentales de REST
El diseño de la arquitectura REST, fue desarrollado con base al estilo Null (Figura 2.5), en el
cual se describe un sistema en el que no existen límites entre los componentes y a partir de ese
punto se comienzan a colocar restricciones.
34
Figura 2.5. Estilo Null [20]
La primera restricción es el estilo de arquitectura cliente-servidor (Figura 2.6). La separación
concerniente a la restricción de cliente-servidor, es aislar la interfaz de los usuarios de los
almacenamientos de datos, lo cual mejora la portabilidad de la interfaz de usuario a través de
múltiples plataformas y mejorar la escalabilidad simplificando los componentes del servidor.
Figura 2.6. Cliente-Servidor [20]
La segunda restricción es que la interacción entre el cliente y servidor debe ser sin estado (Figura
2.7), esto significa que cada petición del cliente debe contener toda la información necesaria
para entender la petición y no tomar partido de cualquier contexto almacenado en el servidor.
Esta restricción introduce propiedades de visibilidad, confiabilidad y escalabilidad. La
visibilidad es mejorada porque un sistema de monitoreo no tiene que mirar más allá de una única
petición para determinar la naturaleza de la petición. La confiabilidad se mejora, debido a que
facilita la tarea de recuperar de fallas parciales. La escalabilidad es mejorada, porque no se tiene
que almacenar un estado entre peticiones, lo que permite que los componentes del servidor sean
liberados rápidamente y además simplifica la implementación puesto que el servidor no tiene
que administrar recursos a través de peticiones.
Una desventaja de la segunda restricción es que puede reducir el rendimiento de la red porque
se incrementa el uso de datos repetitivos enviados en series de peticiones, debido a que los datos
no pueden dejarse en el servidor para contexto compartido. Adicionalmente, colocar el estado
de una aplicación en el cliente, reduce el control del servidor sobre un comportamiento
consistente.
35
Figura 2.7. Comunicación Cliente-Servidor sin estado [20]
La tercera restricción es el uso de cachés (Figura 2.8), normalmente se utilizan para mejorar la
eficiencia de la red. Las restricciones de caché requieren que los datos dentro de la respuesta a
una petición sean implícitamente o explícitamente etiquetados como cacheables o no
cacheables. Si una respuesta es cacheable, entonces la caché del cliente tiene el derecho de
reusar esa respuesta para posterior en peticiones equivalentes.
Figura 2.8. Comunicación Cliente-Servidor sin estado y con caché. [20]
La cuarta restricción es el uso de Interfaces Uniformes (Figura 2.9), como elemento central que
distingue el estilo de arquitectura REST de otros estilos basados en redes, este enfatiza una
interfaz uniforme entre los componentes. Aplicando el principio de la ingeniería de generalidad
a los componentes de interfaz, la arquitectura del sistema, por completo, es simplificada y la
visibilidad de interacciones es mejorada. Las implementaciones son desacopladas de los
servicios que proveen, lo cual fomenta la evolución independiente.
36
Figura 2.9. Cliente-Servidor sin estado, con caché y uniforme. [20]
Con el propósito de mantener la interfaz uniforme, múltiples restricciones de arquitectura se
necesitan para guiar el comportamiento de los componentes. REST está definido por cuatro
restricciones de interfaz, las cuales son: identificación de recursos; manipulación de recursos a
través de representaciones, mensajes auto-descriptivos e, hipermedia como el motor del estado
de la aplicación.
Como quinta restricción se añaden las restricciones de un sistema basado en capas (Figura 2.10).
Porque los sistemas basados en capas permiten a una arquitectura ser colocada en niveles de
jerarquía restringiendo el proceder de los componentes, haciendo que cada componente no
pueda “ver” más allá de la capa intermedia con la cual interactúan. Restringiendo el
conocimiento del sistema a una única capa, se pone un límite entre la complejidad de un sistema
en general y se promueve la independencia del sustrato.
Figura 2.10. Sistema Cliente-Servidor, sin estado, con caché, uniforme y basado en capas. [20]
37
El mayor problema de los sistemas basados en capas, es que añaden latencia en el procesado de
datos y reducen el rendimiento percibido por el usuario. Para un sistema basado en red que
utilice caché, esto puede ser ignorado, ya que se puede beneficiar del cacheo que realizan los
intermediarios.
Como sexta y última restricción, se debe seguir el estilo de código bajo demanda. Lo que hace
que los clientes permitan la funcionalidad de REST para ser extendida, descargando y
ejecutando código en forma de applets o scripts. Esto simplifica a los clientes la reducción de
características requeridas para ser pre-implementadas. Permitiendo que las características sean
descargadas después de ser implantado lo que mejora la extensibilidad. Sin embargo, también
reduce la visibilidad, y es una restricción opcional dentro de REST.
Figura 2.11. REST
Elementos de la arquitectura REST
El estilo de REST es una abstracción de los elementos de arquitectura dentro de sistemas
distribuidos de hipermedia. REST ignora los detalles de componentes de implementación y
sintaxis de protocolos con la intención de enfocarse en los roles de los componentes, las
restricciones de su interacción con otros componentes y su interpretación de elementos de datos
significantes.
Elementos de datos
A diferencia del estilo distribuido de objetos, donde todos los datos están encapsulados y ocultos
por los componentes de procesamiento, la naturaleza y estado de una arquitectura de datos es el
38
aspecto clave de REST. La racionalización para este diseño puede ser vista en la naturaleza de
hipermedias distribuidas. Cuando un enlace es seleccionado, la información necesita moverse
de su ubicación donde se encuentra almacenado a la ubicación donde será utilizado, en la
mayoría de los casos, un lector humano. Esto a diferencia de otros paradigmas de procesamiento
distribuido, donde es posible, y normalmente más eficiente, mover el agente de “procesamiento”
a los datos en lugar de los datos al procesador.
REST proporciona un híbrido enfocándose en el entendimiento compartido de los tipos de datos
con metadatos, pero limitando el alcance de lo que se esté revelando a una interfaz limitada. Los
componentes de REST se comunican transfiriendo una representación de un recurso en un
formato que coincide con un conjunto de tipos de datos estándar, seleccionados dinámicamente,
basados en las capacidades y deseos del solicitante y del recurso.
Los recursos son cualquier información que puede ser un documento, una imagen o un servicio
temporal, una colección de otros recursos, un objeto no virtual entre otros. En otras palabras,
cualquier concepto que pueda ser objetivo de una referencia de hipertexto. Un recurso es una
variación temporal, en la cual las entidades o valores son equivalentes. Los valores pueden ser
representaciones del recurso o identificadores.
Las representaciones de los recursos capturan el estado actual de un recurso y transfieren esa
representación entre componentes. La representación es una secuencia de bytes, más la
representación de metadatos para describir esos bytes. Una representación consiste de datos,
metadatos que describen los datos y en ocasiones, metadatos para describir los metadatos. Los
metadatos vienen en forma de pares de nombres y valores, donde el nombre corresponde a un
estándar que define la estructura y semántica del valor. Los mensajes de respuesta pueden incluir
ambas representaciones de metadatos y metadatos del recurso.
El formato de una representación de datos es conocido como un tipo de medio. Una
representación puede incluirse en el mensaje y procesado por el receptor de acuerdo al control
de datos del mensaje y a la naturaleza del tipo de medio. Algunos tipos de medios tienen la
intención de procesamiento automatizado, algunos la intención de ser renderizado para
visualización del usuario y algunos cuantos para ambos.
39
El diseño de un tipo de medio, puede impactar directamente en el rendimiento percibido por el
usuario de un sistema distribuido de hipermedia. Cualquier dato que deba ser recibido antes que
el destinatario puede comenzar a renderizar la representación, agrega latencia de una
interacción. Un formato que coloca la información más importante al principio, como la
información inicial, puede ser renderizada incrementalmente mientras que el resto de la
información es recibida, proporcionando un rendimiento más aceptable para el usuario.
REST utiliza diferentes tipos de conectores para encapsular las actividades de acceso a recursos
y transferir representaciones de los recursos. Los conectores presentan una interfaz abstracta
para la comunicación de componentes, mejorando la simplicidad, proveyendo de una separación
de preocupaciones y ocultando la implementación inferior de mecanismos de comunicación y
recursos. Los tipos de conectores que utiliza REST son: clientes, servidores, control de caché,
resolución de direcciones y tunelización. Por lo anterior, debido a que todas las comunicaciones
de REST son sin estado, entonces cada petición debe tener la información necesaria para que
cada uno de estos conectores pueda trabajar de forma independiente de los datos que las
peticiones que hayan precedido. Así mismo, los componentes que elaboran las bases de REST
son: Servidor de Origen, Pasarela, Proxy y Agente de Usuario.
Implementación
Existen diversas reglas para la implementación y al no ser un modelo estandarizado, existen
diferencias sustanciales entre los distintos autores que describen el cómo llevar a cabo la
conformación de la arquitectura, sin embargo, es también sabido que existen una serie de
convencionalismos a los cuales se puede ajustar el diseño y será entendido fácilmente por
usuarios de este recurso.
Algo a tomar en cuenta que para el diseño de una arquitectura REST, en algunas ocasiones
denominada RESTful si cumple con todas las características del diseño, es que los usuarios de
esta aplicación serán los desarrolladores. Si bien una API REST puede ser diseñada con sus
propias reglas, es conveniente utilizar algunos principios básicos para mantener la consistencia
para los mismos usuarios.
40
URIs
Siguiendo las reglas del paradigma Web, todo recurso debe ser identificado por una URI.
Conclusión
La implementación del estilo de arquitectura denominado REST, permite la comunicación entre
dos sistemas heterogéneos, operando uno por lo menos en la World Wide Web. El uso
compartido de datos en sistemas de hipermedia requiere aplicar medidas de seguridad para
proteger la información almacenada en los sistemas, así como permitir acceso a recursos
restringidos de forma independiente para los distintos usuarios.
OAuth 2.0
El framework de autorización OAuth 2.0 permite a aplicaciones de terceros obtener acceso
limitado a través de un servicio HTTP, ya sea en nombre del propietario de un recurso,
obteniendo una interacción para aprobar el acceso a un recurso de un propietario a un servicio
HTTP o permitiendo a la aplicación obtener acceso con su propio nombre. Esta especificación
remplaza y hace obsoleto al protocolo OAuth 1.0, añadiendo simplicidad a las tareas de
autenticación y facilitando el trabajo para establecer el esquema, para los desarrolladores. [9]
En el modelo tradicional de autenticación por cliente-servidor, el cliente solicita un acceso
restringido a un recurso (recurso protegido) en el servidor, autenticándose con el servidor
utilizando las credenciales del propietario. Para proveer a las aplicaciones de terceros, acceso a
los recursos protegidos, el propietario comparte sus credenciales con el tercero, lo cual provoca
varios problemas y limitaciones:
o Las aplicaciones de terceros requieren almacenar las credenciales del propietario para
uso futuro, normalmente una contraseña en texto plano.
o Los servidores requieren soporte para autenticación de contraseñas, a pesar de la
debilidad inherente a las contraseñas.
o Las aplicaciones de terceros obtienen acceso amplio a los recursos protegidos del
propietario, dejando a los propietarios de recursos sin la capacidad de restringir la
duración o el acceso limitado a un subconjunto de recursos.
41
o Los propietarios de los recursos no pueden revocar el acceso a terceros de forma
individual, sin revocar el acceso a todos los terceros, y debe hacerse cambiando la
contraseña.
o Compromete a cualquier aplicación de tercero a que los compromisos de los usuarios
finales y todos los datos protegidos por esa contraseña.
OAuth resuelve estos problemas introduciendo una capa de autorización y separando el rol del
cliente del propietario de recursos. En OAuth, el cliente solicita acceso a recursos controlados
por el propietario de recursos, almacenándolos por el servidor de recursos, y es proporcionado
un conjunto diferente de credenciales a las del propietario de los recursos.
En lugar de utilizar las credenciales del propietario de los recursos para acceder a recursos
protegidos, el cliente obtiene un Access Tokens – una cadena que denota un alcance específico,
tiempo de vida y otros atributos de acceso. Los Access Tokens son otorgados a los terceros por
un servidor de autorización con la aprobación del propietario de los recursos.
Roles en OAuth 2.0
OAuth define cuatro roles distintos:
Propietario de recursos: Una entidad capaz de proporcionar acceso a un recurso
protegido. Cuando el propietario de recursos es una persona, es referido como un usuario
final.
Servidor de recursos: el servidor de almacenamiento de los recursos protegidos, capaz
de aceptar y responder a peticiones de recursos protegidos utilizando Access Tokens.
Cliente: Una aplicación haciendo peticiones de recursos protegidos en el nombre del
propietario de los recursos y con su propia autorización. El término “cliente” no implica
alguna implementación de características.
Servidor de autorización: Es el servidor que proporciona los Access Tokens al cliente
después de que el propietario de los recursos se ha autenticado y el propietario ha
obtenido autorización.
42
La interacción entre el servidor de autorización y el servidor de recursos está más allá del alcance
de la especificación. El servidor de autorización puede ser el mismo servidor de recursos o una
entidad diferente.
Flujo del protocolo
El flujo basado en la concesión por Código de Autorización es un tipo utilizado para acceder a
los Access Tokens y los Refresh Tokens y está optimizada para clientes confidenciales. Debido
a que este es un flujo basado en redirecciones, el cliente debe ser capaz de interactuar con el
agente de usuario del Propietario de Recursos (típicamente el navegador web) y capaz de recibir
peticiones entrantes (por medio redirección) desde el servidor de autorización.
Propietario de los Recursos
Agente de usuario
Servidor de autorización
Cliente(Aplicación)
(B)
(B) Usuario se autentica
(C) Código de Autorización
(A) Client ID& URI de Redirección
(C)(A)
(D) Código de Autorización& URI de Redirección
(E) Access Token(con Refresh Token, opcional)
Figura 2.12. Flujo Abstracto del Protocolo OAuth 2.0 basado en la concesión por Código de Autorización.
El flujo ilustrado en la Figura 2.12 se lleva a cabo mediante los siguientes pasos:
(A) El cliente inicia el flujo, redirigiendo al agente de usuario del propietario de recursos
al punto de autorización. El cliente incluye su identificador de cliente, alcance
solicitado, estado local, y una URI de redirección a la cual el servidor de autorización
43
le enviará de nuevo al agente de usuario, una vez que el acceso haya sido otorgado (o
denegado).
(B) El servidor de autorización autentica el propietario de los recursos (por medio del
agente de usuario) y establece, ya sea la concesión del propietario de recursos o la
denegación de la petición de acceso al cliente.
(C) Asumiendo que el propietario de recursos concede acceso, el servidor de autorización
redirige al agente de usuario de nuevo al cliente utilizando la URI de redirección
proporcionada anteriormente (en la petición o durante el registro del cliente). La URI
de redirección incluye un código de autorización y cualquier estado local
proporcionado previamente por el cliente.
(D) El cliente solicita un Access Token al servidor de autorización, para ello, anexando
el código de autorización obtenido en el paso anterior. Cuando se realiza la petición,
el cliente se autentica con el servidor de autorización, el cliente incluye la URI de
redirección utilizada para obtener el código de autorización utilizada en la
verificación.
(E) El servidor de autorización autentica al cliente, valida el código de autorización, y
asegura que la URI de redirección recibida, encaja con la URI utilizada para redirigir
al cliente en el paso (C). Si es válido, el servidor de autorización responde con un
Access Token y, opcionalmente, un Refresh Token.
2.2.3 Herramientas utilizadas en el producto final
Framework MVC para PHP
La implementación del producto final utiliza un framework diseñado con la funcionalidad
principal, el cual consiste en la codificación de proyectos de software aplicados a la World Wide
Web y que requieran hacer consultas frecuentes y extensas a base de datos.
El desarrollo de este framework se inició para aplicarse en el proyecto “GAABIN” un software
para la Gestión Administrativa de Agroempresas Basada en Inteligencia de Negocios. Y
posteriormente fue adaptada para permitir la implementación de otros proyectos como lo son:
el sitio de la División de Estudios de Posgrado e Investigación del Instituto Tecnológico de
44
Colima y la segunda versión de la “Plataforma para Gestión de Posgrados y el Programa
Nacional ‘1000 Jóvenes en la Ciencia’” de la Dirección de Posgrado, Investigación e Innovación
del Tecnológico Nacional de México.
Un framework es una estructura con organización definida, que incluye una serie de artefactos
o módulos concretos de software. Sirve para la base de organización y desarrollo de un software,
así como es posible que incluya programas, bibliotecas o alguna sintaxis de lenguaje particular
para ayudar a la unión de los distintos componentes.
Descripción de MVC
La estructura MVC (Modelo-Vista-Controlador) consiste en un patrón de arquitectura de
software que separa los datos y la lógica de una aplicación de la interfaz de usuario y el módulo
encargado de gestionar los eventos y las comunicaciones. Para ello se propone la construcción
de tres componentes distintos que son el modelo, la vista y el controlador. Haciendo esta
descomposición dentro de la arquitectura de software, es posible la reutilización del código y la
separación de conceptos, con lo que se facilita el proceso de desarrollo y el mantenimiento de
las mismas.
Características principales del Framework
Motor de consultas integrado. Cuenta con un conjunto de instrucciones capaces de
mantener la independencia del Sistema Gestor de Base de Datos y que al mismo tiempo
es capaz de adaptar la estructuración de las consultas para que de manera óptima puedan
realizarse consultas múltiples y anidadas con el menor costo en recursos y tiempo de
ejecución posible.
Motor de renderización dinámico. Implementa rutinas para generar salidas de datos
predeterminadas para las variables especificadas, así como la capacidad de soportar
rutinas adicionales para obtener una representación distinta de los datos.
Motor de control flujo. El diseño y arquitectura de la aplicación permite establecer
técnicas para el control del flujo de navegación del usuario o sistema que se conecte a la
45
aplicación que implementa el software. Asímismo, realiza de forma automatizada los
procesos de verificación y autenticación de la seguridad en las conexiones.
Gestión de librerías dinámicas. Permite la carga de librerías y diferentes componentes
de forma dinámica en los controladores de la aplicación, de manera que puedan ser
invocadas tantas veces sea necesario y manteniendo el consumo óptimo de memoria y
procesamiento.
JSON (JavaScript Object Notation)
Introducción
La notación de objetos de JavaScript o JSON (JavaScript Object Notation) es un formato de
texto que facilita el intercambio estructurado de datos entre todos los lenguajes de
programación. Consiste en una sintaxis basada en llaves “{ }”, corchetes “[ ]”, dos puntos “:”,
y comas “,” que son útiles para múltiples contextos, perfiles y aplicaciones. Su estructura está
basada en las literales de objetos de ECMAScript “JavaScript”, con el propósito de no imponer
el lenguaje sobre otros, sino como un subconjunto de representaciones textuales en conjunto a
otros lenguajes de programación.
Los lenguajes de programación varían ampliamente en la manera en que soportan los objetos, y
de esa manera, qué características y restricciones se ofrecen para los objetos. Los sistemas de
modelado de objetos pueden ser divergentes y continúan evolucionando. JSON proporciona una
notación sencilla para expresar colecciones de pares de nombres y valores. La mayoría de los
lenguajes de programación tendrán alguna característica para representar estas colecciones, las
cuales, pueden tener nombres como record, struct, dict, map, hash u object.
JSON también soporta valores de listas ordenadas. Todos los lenguajes de programación tendrán
alguna característica para representar estas listas bajo los nombres array, vector o list.
Debido a que los objetos y los arreglos pueden ser anidados y componer árboles u otras
estructuras, pueden ser intercambiados fácilmente entre lenguajes de programación
incompatibles.
46
La cadena JSON
Una cadena JSON es una secuencia de tokens unidos por puntos de código Unicode que
conforman el valor de la gramática JSON. El conjunto de tokens incluye seis tokens
estructurales, cadenas, números y tres tokens de valor literal. Estos conjuntos se describen a
continuación.
Los seis tokens estructurales son:
[ U+005B corchete izquierdo
{ U+007B llave izquierda
] U+005D corchete derecho
} U+007D llave derecha
: U+003A dos puntos
, U+002C coma
Los tres tokens de valor literal son:
true U+0074 U+0072 U+0075 U+0065
false U+0066 U+0061 U+006C U+0073 U+0065
null U+006E U+0075 U+006C U+006C
Los espacios en blanco sin significado pueden incluirse antes o después de cualquier token. Los
caracteres de espacio en blanco son: tabulación (U+0009), nueva línea (U+000A), retorno de
carro (U+000D) y espacio (U+0020). Los espacios en blanco no se aceptan dentro de cualquier
token, con la excepción de aquellos correspondientes a las cadenas.
Estructura del JSON
Los valores de los JSON pueden ser objetos, arreglos, números, cadenas, true, false o null. De
esta manera, cada valor, incluyendo los subvalores de las propiedades de los objetos, los
elementos de los arreglos, pueden componerse por cualquiera de estos siete posibles elementos,
tal cual como se muestran en la Figura 2.13.
47
Figura 2.13. Valor en JSON. [21]
Los objetos en JSON, tal cual como se muestran en la Figura 2.14, son representados como un
par de llaves alrededor de cero o más pares de nombres y valores. El nombre es una cadena. Se
utilizan dos puntos después de cada nombre, separando el nombre del valor. Un token de coma
se utiliza para separar el valor del siguiente nombre.
Figura 2.14. Objeto en JSON. [21]
En JSON, los arreglos se representan como una estructura con un par de corchetes envolviendo
0 o más valores, como se puede ver en la Figura 2.15. Estos valores son separados por coma. El
orden de los valores es significante.
Figura 2.15. Arreglos en JSON. [21]
Los números se representan en formato de base 10 sin ceros superfluos a la izquierda. Pueden
ir precedidos por un signo de menos (U+002D). Pueden contener. (U+002E) para separar la
48
parte fraccional. Pueden tener un exponente de base 10, prefijado con e (U+0065) o E (U+0045)
y opcionalmente + (U+002B) o – (U+002D). Los dígitos son aquellos representados por los
caracteres desde el U+0030 hasta el U+0039, tal cual como se muestran en la Figura 2.16.
Figura 2.16. Números en JSON. [21]
Finalmente, las cadenas son secuencias de código Unicode envueltas entre pares de comillas (“,
U+0022). Todos los caracteres pueden ser colocados dentro de las comillas, con excepción de
aquellos caracteres que deben ser escapados, por ejemplo: comillas (U+0022), diagonal
invertida (U+005C) y los caracteres de control del U+0000 hasta el U+001F. Existen dos o más
representaciones de la secuencia de escape para algunos caracteres como se muestran en la
Figura 2.17. A continuación, se muestran algunas secuencias de escape.
\" representa el carácter de comilla (U+0022)
\\ representa a la diagonal invertida (U+005C)
\/ representa a la diagonal común (U+002F)
\b representa al carácter de retroceso (U+0008)
\f representa el carácter de nuevo formulario (U+000C)
\n representa el carácter de nueva línea (U+000A)
\r representa el carácter de retorno de carro (U+000D)
\t representa el carácter de tabulación (U+0009)
49
Así, por ejemplo, una cadena puede contener únicamente la diagonal invertida si se representa
como “\\”.
Cualquier código puede ser representado mediante un número hexadecimal. El significado de
dicho número es determinado por la ISO/IEC 10646. Si el código está en el Plano Básico Multi-
idioma (desde U+0000 hasta U+FFFF), entonces puede representarse como una secuencia de
seis caracteres: una diagonal invertida, seguida de la u minúscula, seguida de cuatro dígitos
hexadecimales.
Si el carácter no se encuentra en el Plano Básico Multi-idioma, entonces se representará con una
secuencia de doce caracteres, codificando el par subrogado de UTF-16. Así, por ejemplo, una
cadena que tenga el carácter U+1D11E puede representarse como “\uD834\uDD1E”.
Figura 2.17. Cadena en JSON. [21]
50
2.3 Marco contextual o referencial
2.3.1 Sistemas existentes que afrontan problemáticas similares
Resulta importante considerar que el concepto de esta propuesta no es nuevo y, por lo tanto, es
fácil imaginar que existan soluciones de software similares y ataquen a la misma problemática
planteada en esta tesis. Sin limitarse a la institución actual, es posible encontrar que otras
instituciones han creado sus propias plataformas para el registro de proyectos y la gestión de los
productos obtenidos. Asimismo, a nivel nacional se encuentran en funcionamiento dos sistemas
de información con el propósito de hacer seguimiento de la productividad académica en todas
las instituciones, principalmente a nivel superior.
SAPPI (Sistema de Administración de Programas y Proyectos de Investigación)
Este sistema fue diseñado por el Instituto Politécnico Nacional para atender a las necesidades
informáticas para la gestión administrativa de las actividades de investigación dentro de la
misma institución.,
La plataforma tiene la capacidad de permitir el registro de las propuestas de proyectos de
investigación y el seguimiento de los proyectos recibiendo la presentación de informes parciales
del avance obtenido.
Figura 2.18. Página principal del SAPPI. [22]
51
Sistema de Proyectos de Investigación de la Universidad Autónoma de Aguascalientes
Este sistema permite presentar proyectos de investigación en convocatorias internas de la
Universidad Autónoma de Aguascalientes, está dirigida a profesores-investigadores. El manual
indica que “Dicho sistema fue elaborado para agilizar el proceso de entrega y evaluación de
los proyectos de investigación”.
Figura 2.19. Sistema de Proyectos de Investigación de la Universidad Autónoma de Aguascalientes. [23]
CVU CONACyT
Esta plataforma tiene como propósito dar seguimiento a las actividades de investigación y
desarrollo tecnológico a nivel nacional, así como ser el “documento” universal para las
actividades académicas y de investigación a nivel nacional. El sistema es impulsado por el
Consejo Nacional de Ciencia y Tecnología (CONACyT), siendo la institución responsable de
elaborar las políticas de ciencia y tecnología en México, y de dar seguimiento a los avances
científicos y tecnológicos del país.
52
Figura 2.20. Pantalla principal de acceso a CVU en CONACyT. [24]
Módulo de captura de curriculum y solicitudes PRODEP
Este sistema desarrollado para la Secretaría de Educación Pública, fue diseñado con el propósito
de llevar un seguimiento de las actividades académicas y docencia, de los profesores de tiempo
completo y que laboren en instituciones de educación superior.
Su funcionalidad corresponde a la gestión del personal registrado en el Programa para el
Desarrollo Profesional Docente (PRODEP).
Como el nombre del sistema lo indica, consiste en un sistema de captura para el curriculum del
profesor, así como un sistema para la generación de solicitudes a distintas convocatorias del
mismo organismo. El curriculum generado por este sistema es comúnmente utilizado como
referente de actividades docente en las instituciones de educación superior.
53
Figura 2.21. Pantalla principal y de avisos del Módulo de Captura del Curriculum y Solicitudes PRODEP. [25]
Diferencias cruciales entre los sistemas existentes y la propuesta de esta tesis
La funcionalidad básica de GAAPI puede compararse con los cuatro sistemas anteriores, debido
a que comparte algunas características funcionales o algún procedimiento similar, las cuales
son:
Gestión de proceso de registro y avance de proyectos de investigación en la institución.
Seguimiento de las actividades de investigación.
Sin embargo, la propuesta toma en consideración los aciertos y desaciertos de las diferentes
plataformas entre las cuales podemos encontrar como aciertos:
La gestión basada en tecnologías de la información, lo que permite hacer un seguimiento
continuo y una evaluación casi instantánea de los avances obtenidos.
La gestión independiente de los procesos internos institucionales a los perfiles de
información universales, tales como la formación académica, la información de contacto
y la productividad académica.
54
El despliegue de estas plataformas mediante la web, lo que permite el acceso a estos
sistemas a una mayor cantidad de usuarios.
Capacidad para exportar la información capturada en estos sistemas como documentos
que representen en forma completa o resumida las actividades del usuario.
Los desaciertos de los sistemas anteriores consisten en limitaciones de las propuestas, que, si
bien han funcionado durante varios años, en varias situaciones causan desagrado por parte de
los usuarios. A continuación, se describen las deficiencias encontradas en los proyectos:
Sistema cerrado. Los tres sistemas anteriores funcionan como sistemas cerrados e
independientes, que no permiten recibir información desde una fuente distinta o no la
comparten directamente con otros sistemas de información. Esta es la principal causa de
la diversificación de este tipo de propuestas
Mínima evolución ante nuevas tecnologías. No se presentan interfaces de usuarios
adaptadas para facilitar la captura o que resulten atractivas para el usuario, asimismo,
carecen de capacidad responsiva para desplegarse y funcionar en dispositivos móviles.
Propósito único. Esta deficiencia la muestran en mayor o menor grado los sistemas
descritos, sin embargo, se refiere a que la funcionalidad presentada no puede extenderse
hacia otras actividades.
2.3.2 Propuestas académicas que aportan a la solución
Propuesta de diseño del SIAPI (Sistema de Administración de Proyectos de Investigación)
El Sistema de Administración de Proyectos de Investigación es una propuesta de diseño
presentada en otoño de 2012 por Bernardo González Franco como tema de tesis para la Maestría
en Ciencias en Informática del Instituto Politécnico Nacional. Esta propuesta de diseño consiste
en la utilización de las Tecnologías de la Información y Comunicaciones (TIC) como
herramientas para “el registro, seguimiento sistemático del proceso y control de los proyectos
de investigación y desarrollo tecnológico, autorizados a los Institutos Tecnológicos y Centros
que tengan posgrados vigentes en la convocatoria emitida anualmente por el Área de
55
Investigación de la Dirección de Estudios de Posgrado e Investigación (DEPI) en la DGEST”.
[8]
La implementación aplicaría la metodología XP (eXtreme Programming, Programación
eXtrema) y utilizando el lenguaje de programación Java con el Framework para el desarrollo
STRUTS, el cual opera bajo la arquitectura MVC (Modelo-Vista-Controlador). De igual
manera, aplicando un sistema gestor de base de datos como MySQL y servidor Web Apache
Tomcat.
Figura 2.22. Pantalla Principal de SIAPI.
Sistema de Gestión de la Investigación en la Universidad de Talca, Chile
El Sistema de Gestión de la Investigación (SGI) tiene el propósito de coadyuvar las actividades
académicas que realizan los investigadores en la Universidad de Talca. El sistema se planteó
con miras al apoyo de la investigación por medio de un sitio Web. Su estructuración inició con
servicios de información exclusiva en base en los perfiles de usuario, respecto a programas,
proyectos, eventos y productos de las actividades de investigación desarrolladas. [26]
Cuenta con un conjunto de indicadores de gestión y estadísticas relacionadas con las
capacidades de investigación disponibles en la institución, apoyando así, al fortalecimiento de
56
los posgrados, al desarrollo de nuevos grupos interdisciplinarios e incentivando el desarrollo de
la investigación. [26]
El SGI, para la integración con los sitios web de las unidades académicas, los programas de
investigación y los centros tecnológicos, comparte la información mediante Web Services,
evitando reingresos de información y logrando mayor agilidad en los procesos. Asimismo,
permite la generación de currículos estandarizados, que recopilan información de otros
subsistemas de gestión académica. [26]
2.4 Conclusiones
Al analizar el estado del campo del conocimiento se han detectados diferentes herramientas que
coadyuvan a la gestión de proyectos de investigación, por mencionar: el Sistema de
Administración de Programas y Proyectos de Investigación del Instituto Politécnico Nacional,
Sistema de Gestión de la Investigación en la Universidad de Talca, Chile, la propuesta de diseño
del Sistema de Administración de Proyectos de Investigación de la DGEST. Dichas
herramientas están basadas en tecnologías web.
Asimismo, la presente propuesta, al ser también un desarrollo web, pretende aprovechar las
características de esta tecnología aplicando técnicas innovadoras y estandarizadas para el
intercambio seguro de información, extendiendo las capacidades y funcionalidades de la misma,
minimizando redundancias.
Por lo anterior, se concluye que al integrar las tecnologías web con los procesos de gestión de
PI y sus productos derivados, se mejora el control y aprovechamiento de los recursos operativos
y académicos, así como, del capital humano.