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:john.doe@example.com

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.