SepadMex: Framework para el descubrimiento y descripción de los elementos de SEPAD

Texto completo

(1)Universidad Central de las Villas Facultad de Matemática, Física y Computación Carrera de Ciencias de la Computación. Trabajo de Diploma. SepadMex: Framework para el descubrimiento y descripción de los elementos de SEPAD.. Autor Yenier Cruz Brito Tutor Lic. Didiosky Benítez Erice. 2007.

(2) Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencias de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del jefe del Seminario.

(3) A los que ya no están físicamente pero que siempre viven en mis pensamientos; a las personas que prácticamente son mi vida: a mi madre Idonis y mi abuela Firma Rosa..

(4) Agradecimientos. A mi tutor, Didiosky, quién aportó las ideas principales que motivaron esta investigación. A mi familia, por su preocupación, apoyo y su eterna confianza. A mis restantes compañeros de investigación: Víctor, Wilder, Roberto Carlos y Yoilán, por estar siempre y saber que puedo contar con ellos. A mis compañeros de aula: Julito, el Luci, Joaquín, Frankito, Yadroy, todos en general, por acompañarme en cinco años de grandes esfuerzos y momentos inolvidables. A mis amigos, por hacerme sentir que son mucho más que eso. A todos los que de una u otra forma dieron su aporte para llevar este trabajo a feliz término..

(5) Resumen El Sistema de Enseñanza Personalizada a Distancia (SEPAD) es una plataforma que se encarga de gestionar la enseñanza asistida por computador, usando Internet como medio de transporte entre la comunidad desarrolladora de materiales educativos y sus consumidores, proporcionándoles un entorno de aprendizaje práctico a estos últimos. La aspiración principal del sistema es llevar la educación a todos independientemente de su capacidad tecnológica o de conectividad.[1] En este trabajo se detalla la propuesta de diseño e implementación de un framework para el descubrimiento y descripción de los elementos de SEPAD, el mismo posee una herramienta para publicar dichos elementos en un directorio o catálogo y luego brinda la posibilidad de obtenerlos y mostrarlos al proveer varios módulos como son una capa de abstracción, un servicio Web y una librería de componentes visuales. Se ha optado por el uso de las implementaciones de un estándar llamado UDDI (Universal Description, Discovery, and Integration) el cual representa un directorio. Este proyecto pretende estimular el interés de muchos usuarios por la plataforma SEPAD..

(6) Summary The Personalized Distance Education System (SEPAD) is a platform that manages the teaching and learning processes using Internet creating a communication system between the community that develops educational materials and its consumers, providing a practical learning environment to the last ones, its main aim is to facilitate the access to the education to everybody, independently of their technological capacities. [1] In this work it is detailed the design proposal and implementation of a framework for a better discovery and description of the elements of SEPAD, the same one possesses a tool to publish this elements in a directory or catalog and then it offers the possibility to obtain them and to show them when providing several modules like they are a abstraction layout, a Web Service and a library of visual components. It has been opted by the use of the implementations of a called standard UDDI (Universal Description, Discovery, and Integration) which represents a directory. This project seeks to stimulate the interest of many users for the platform SEPAD..

(7) Índice. Índice INTRODUCCIÓN ............................................................................................................................................ 1 1. BASES PARA EL DESCUBRIMIENTO Y DESCRIPCIÓN DE LOS ELEMENTOS DE SEPAD .... 3 1.1 SISTEMA DE ENSEÑANZA PERSONALIZADO A DISTANCIA (SEPAD) ......................................................... 4 1.1.2 Modelo de objetos y descripción de los elementos de SEPAD ......................................................... 4 1.2 NECESIDAD DE UN MEJOR DESCUBRIMIENTO DE LOS ELEMENTOS DE SEPAD .......................................... 6 1.3 SOLUCIÓN A LA NECESIDAD ...................................................................................................................... 7 1.3.1 ¿Qué es un framework? ................................................................................................................... 7 1.4 ¿QUÉ ES UML?......................................................................................................................................... 7 1.5 ¿QUÉ ES XML?......................................................................................................................................... 9 1.6 ¿QUÉ ES REST? ........................................................................................................................................ 9 1.7 ¿QUÉ ES JAVASCRIPT Y/O JSCRIPT? ........................................................................................................ 11 1.8 ¿QUÉ ES JSON? ...................................................................................................................................... 12 1.9 ¿QUÉ ES AJAX? ..................................................................................................................................... 13 1.10 ¿QUÉ ES SOAP? ................................................................................................................................... 14 1.11 ¿QUÉ ES WSDL? .................................................................................................................................. 15 1.12 SERVICIOS WEB .................................................................................................................................... 17 1.13 ¿QUÉ ES UDDI? ................................................................................................................................... 18 1.13.1 Modelo de objetos y descripción de los elementos de UDDI ....................................................... 19 1.14 MODELO DE SIMILITUD ........................................................................................................................ 22 2. DISEÑO E IMPLEMENTACIÓN DEL FRAMEWORK PARA EL DESCUBRIMIENTO Y DESCRIPCIÓN DE LOS ELEMENTOS DE SEPAD ................................................................................ 26 2.1 DISEÑO DE LOS MÓDULOS DEL FRAMEWORK .......................................................................................... 27 2.1.1 Diseño del módulo SepadMEXPublisher ....................................................................................... 27 2.1.1.1 Diagrama de casos de usos ......................................................................................................... 27 2.1.1.2 Diagramas de estados de los casos de usos ................................................................................ 28 2.1.1.3 Representación de clases utilizadas en el módulo. ..................................................................... 29 2.1.2 Diseño del módulo SepadMEXPHP ............................................................................................... 35 2.1.2.1 Representación de clases utilizadas en el módulo ...................................................................... 35 2.1.2.2 Diagrama de clases del módulo SepadMEXPHP ....................................................................... 37 2.1.3 Diseño del módulo SepadMEXREST ............................................................................................. 39 2.1.3.1 Representación de clases utilizadas en el módulo ...................................................................... 39 2.1.3.2 Estructura del servicio Web que implementará el módulo. ........................................................ 41 2.1.4 Diseño del módulo SepadMEXAJAX ............................................................................................. 43 2.2 IMPLEMENTACIÓN DE LOS MÓDULOS DEL FRAMEWORK .......................................................................... 44 2.2.1 Implementación del módulo SepadMEXPublisher ......................................................................... 44 2.2.1.1 Delphi.......................................................................................................................................... 44 2.2.1.2 Componentes DBExpress de la VCL de Delphi 7 ....................................................................... 45 2.2.1.3 Tecnología .NET y Microsoft UDDI SDK ................................................................................... 45 2.2.2 Implementación del módulo SepadMEXPHP ................................................................................ 46 2.2.2.1 ¿Qué es PHP? ............................................................................................................................. 46 2.2.2.2 Librería PHP-UDDI ................................................................................................................... 46 2.2.2.3 Librería para gestionar XML ...................................................................................................... 47 2.2.2.4 Zend Studio ................................................................................................................................. 47 2.2.3 Implementación del módulo SepadMEXREST ............................................................................... 48 2.2.3.1 Librería en PHP para llevar a formato JSON ............................................................................ 48 2.2.4 Implementación del módulo SepadMEXAJAX ............................................................................... 48 2.2.4.1 Dojo Foundation y su Dojo Toolkit ............................................................................................ 49 2.3 RELACIÓN ENTRE LOS MÓDULOS DEL FRAMEWORK ................................................................................ 49.

(8) Índice 3. DOCUMENTACIÓN DEL FRAMEWORK PARA EL DESCUBRIMIENTO Y DESCRIPCIÓN DE LOS ELEMENTOS DE SEPAD ................................................................................................................... 51 3.1 MANUAL DE USUARIO DEL MÓDULO SEPADMEXPUBLISHER ................................................................. 52 3.2 FAQ DEL MÓDULO SEPADMEXPUBLISHER ............................................................................................ 57 3.3 MANUAL DE DESARROLLADOR DEL MÓDULO SEPADMEXPHP .............................................................. 59 3.4 MANUAL DE DESARROLLADOR DEL MÓDULO SEPADMEXREST............................................................ 65 3.5 MANUAL DE DESARROLLADOR DEL MÓDULO SEPADMEXAJAX ........................................................... 68 CONCLUSIONES .......................................................................................................................................... 72 RECOMENDACIONES ................................................................................................................................ 74 BIBLIOGRAFÍA ............................................................................................................................................ 75.

(9) Introducción. Introducción En los últimos años se ha apreciado un amplio desarrollo en el campo de las Nuevas Tecnologías de la Información y las Comunicaciones (NTIC). Se han implementado muchas plataformas orientadas al e-learning por la importancia y la necesidad que estas han adquirido. Actualmente la enseñanza a distancia tiene un gran seguimiento en cuanto a desarrolladores y personal interesado en adquirir superación por esta novedosa vía. Ejemplos de esas plataformas son Microcampus, Moodle, Aprendist y muchas más, como SEPAD (Sistema de Enseñanza Personalizado a Distancia), plataforma sobre la cual se hablará en este trabajo. En la actualidad los usuarios que estén interesados en módulos publicados en SEPAD, o que necesiten informarse sobre estos módulos o las modalidades a las que pertenecen, están obligados a visitar los servidores existentes de SEPAD ya que no existe un directorio o algo similar donde se haga público lo que estos poseen, por lo que se torna necesario un mejor descubrimiento de estos elementos de la mencionada plataforma. Se pretende en este trabajo dar una propuesta de diseño e implementación de un framework que esté enfocado a cubrir esa necesidad al proveer herramientas de publicación y muestra de los elementos de SEPAD hacia y desde un directorio para facilitar su descubrimiento. Se hace uso de las implementaciones de un estándar que brinda innumerables funcionalidades. denominado UDDI (las siglas del catálogo de negocios de Internet. Universal Description, Discovery, and Integration [2]) como estructura base de este framework.. 1.

(10) Introducción Se ha dividido el trabajo en viarios objetivos específicos que al cumplirlos con todo éxito se soluciona el objetivo principal de esta investigación: •. Estudiar detalladamente la estructura del modelo de objetos de UDDI.. •. Proponer un Modelo de Similitud que muestre los puntos comunes entre el modelo de objetos de UDDI y el de SEPAD.. •. Diseñar e implementar un módulo que, basándose en el Modelo de Similitud descrito, sea capaz de publicar elementos de SEPAD en un directorio UDDI.. •. Diseñar e implementar un módulo que sea una capa de abstracción al proveer métodos que obtengan los elementos de SEPAD publicados en un directorio UDDI.. •. Diseñar e implementar un módulo que funcione como Servicio Web y sea capaz de devolver los elementos de SEPAD en algún formato de fácil uso y gran utilidad.. •. Diseñar e implementar un módulo que obtenga los elementos de SEPAD del Servicio Web anterior y muestre los elementos de SEPAD en componentes visuales.. El trabajo está estructurado de la manera siguiente: El Capítulo 1 está dedicado primeramente a la plataforma de aprendizaje enfocada en esta investigación (SEPAD), las causas que han llevado al desarrollo de la misma y lo propuesto para cubrir esas necesidades. Además, se aborda sobre el estado actual de algunas tecnologías imprescindibles en la solución y sobre el Modelo de Similitud que muestra los puntos comunes entre el modelo de objetos de UDDI y el de SEPAD. El Capítulo 2 posee los detalles de diseño e implementación de los módulos del framework para el descubrimiento y descripción de los elementos de SEPAD, además menciona el software utilizado y algunas tecnologías importantes en el diseño e implementación. El Capítulo 3 está reservado para la documentación y escenarios de uso de los módulos del framework.. 2.

(11) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1. BASES PARA EL DESCUBRIMIENTO Y DESCRIPCIÓN. DE. LOS. SEPAD. 3. ELEMENTOS. DE.

(12) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I El capítulo está destinado al abordaje de la plataforma SEPAD, la necesidad de esta investigación así como de algunas tecnologías utilizadas en la implementación de la solución propuesta.. 1.1 Sistema de Enseñanza Personalizado a Distancia (SEPAD) El Sistema de Enseñanza Personalizado A Distancia (SEPAD) es una plataforma para la tele-formación,. cuya. aspiración. principal. es. llevar. la. educación. a. todos,. independientemente de su capacidad tecnológica o de conectividad. Para ello cuenta con varias interfaces que van desde el clásico ambiente Web para usuarios que tienen la posibilidad de conexión en línea, o un cliente para acceder a los servicios de la plataforma a través de protocolos de correo electrónico, o la versión multimedia capaz de ejecutarse sin necesidad de conexión alguna. Además cuenta con una herramienta para la elaboración de los módulos que no requiere de conexión en línea. La plataforma cuenta con un aula virtual donde se accede a los materiales didácticos, búsquedas, autoevaluaciones, calificaciones y los servicios de tutorías como son la mensajería interna, los foros de debates, el sistema de anuncios, las noticias y las salas de Chat temáticas. Desde el punto de vista de los tutores y profesores el sistema cuenta con ambientes donde estos pueden seguir el proceso de aprendizaje de sus alumnos. [3]. 1.1.2 Modelo de objetos y descripción de los elementos de SEPAD La estructura metodológica del SEPAD en su antigua versión 1.2, tenía como nivel máximo el Módulo cuya funcionalidad era muy limitada y más bien era una forma de organizar los Cursos que constituían el siguiente nivel. Los Cursos tenían un prólogo que detallaba sus datos generales, tenían asignados un grupo de tutores o profesores, pero no había una definición de quién era el profesor principal ni quiénes eran los alumnos asignados a cada tutor. Los tutores debían seguir el aprendizaje de sus alumnos al tiempo que se desarrollaba el proceso educativo de todos los estudiantes, mezclados con los demás que no le pertenecían.. 4.

(13) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I A partir de la actual versión 1.5 se establece una nueva estructura. La Modalidad Académica contiene uno o varios Módulos, posee también una funcionalidad bien definida, puede ser un Diplomado, Curso, Entrenamiento, Doctorado, Maestría, etc. Aparece entonces, ligado a la Modalidad Académica, un nuevo rol: el coordinador, cuya función es ser el responsable de la modalidad y todos sus módulos, velar por el claustro de profesores, atender las solicitudes de matrículas así como crear los nuevos Módulos y designar sus respectivos profesores principales. Las modalidades tienen una sección de Generalidades que sería similar a lo que era el prólogo para un módulo en la versión 1.2, pero con muchos más datos, una presentación del claustro y los módulos que contiene. El Módulo es lo que era antes el Curso. Elemento novedoso lo constituye el profesor principal asignado, cuyo rol radica en ser responsable del módulo y de crear los subgrupos tutoreados. El subgrupo tutoreado está conformado por una serie de alumnos matriculados en la modalidad, a los que se les asocia un tutor que tiene que ser parte del claustro de la modalidad. Ello genera un nuevo rol: el tutor, cuya responsabilidad es dar seguimiento al proceso de aprendizaje de sus alumnos y su acceso está limitado a monitorear a los alumnos correspondientes, o sea, no tiene ningún tipo de vínculo con el resto de los estudiantes. La modalidad académica es creada en línea y los módulos son publicados con la herramienta de publicación por los profesores principales. Resumiendo: La actual estructura es: •. Modalidad Académica. •. Módulos. •. Lecciones. •. Materiales. •. Autoevaluaciones. 5.

(14) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Los roles son: •. Administrador. •. Coordinador de la modalidad académica. •. Profesor Principal del módulo. •. Tutor del subgrupo tutoreado. •. Alumno. •. Usuario. De estos roles solo es absoluto en términos de dominio el rol de administrador, el resto son relativos a la sección donde se encuentre, por ejemplo el coordinador de una modalidad académica puede ser un simple alumno para otra modalidad donde esté matriculado o un usuario sin acceso a una modalidad donde no esté matriculado. [4]. 1.2 Necesidad de un mejor descubrimiento de los elementos de SEPAD En la actualidad los módulos (elementos en sentido general) pertenecientes a los distintos servidores de SEPAD no gozan de una amplia publicidad para los usuarios que son potenciales a su interés; solo se pueden descubrir recurriendo al servidor específico donde se encuentran, siendo necesario conocer la existencia y exacta ubicación de dichos elementos. Debido a esto la plataforma podría dejarse de usar con el decursar del tiempo. Hacer públicos estos elementos para un mejor descubrimiento y descripción de los mismos, puede revertirse en el incremento en los usuarios pertenecientes a SEPAD, es decir, el reconocimiento de la utilidad de la plataforma transformado en prestigio.. 6.

(15) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1.3 Solución a la necesidad Como solución a esta necesidad se presenta la creación de un framework que suministre múltiples herramientas a los desarrolladores con el fin de publicar y mostrar los elementos de SEPAD haciendo posible un mejor descubrimiento y descripción de los mismos.. 1.3.1 ¿Qué es un framework? En el desarrollo de software, un framework es una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, bibliotecas y un lenguaje de scripting entre otros softwares para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Un framework representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio. Los frameworks son diseñados con el intento de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. [5]. 1.4 ¿Qué es UML? Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran manera por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. 7.

(16) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Es importante remarcar que UML es un "lenguaje" para especificar y no un método o un proceso, se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir -es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para soportar una metodología de desarrollo de software tal como RUP (Rational Unified Process) -pero no especifica en sí mismo qué metodología o proceso usar. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. [6]. Diagramas pertenecientes al UML. 8.

(17) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1.5 ¿Qué es XML? XML (eXtensible Markup Language) es un Lenguaje de Etiquetado Extensible muy simple, pero estricto, que juega un papel fundamental en el intercambio de una gran variedad de datos. Su función principal es describir datos y no mostrarlos. Es un formato que permite la lectura de datos a través de diferentes aplicaciones. Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. Sirve además para estructurar, almacenar e intercambiar información. Que un documento sea "bien formado" solamente habla de su estructura sintáctica básica, es decir que se componga de elementos, atributos y comentarios como XML manda que se escriban. Ahora bien, cada aplicación de XML, es decir cada lenguaje definido con esta tecnología, necesitará especificar cuál es exactamente la relación que debe verificarse entre los distintos elementos presentes en el documento. Esta relación entre elementos se especifica en un documento externo expresada como DTD (Document Type Definition que quiere decir Definición de Tipo de Documento) o como XSchema. Crear uno de estos documentos equivale a crear un nuevo lenguaje de marcado, para una aplicación específica. Los documentos XML que se ajustan a su DTD o a su XSchema se denominan válidos. [7]. 1.6 ¿Qué es REST? La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la Web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo. [8]. 9.

(18) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Según el propio Roy Fielding: “La Transferencia de Estado Representacional intenta evocar una imagen de cómo una aplicación Web bien-diseñada se comporta: una red de páginas Web (una máquina de estado virtual), dónde el usuario progresa a través de una aplicación seleccionando los enlaces (las transiciones de estado), produciendo la próxima página (representando el próximo estado de la aplicación) siendo transferida al usuario y visualizándola para su uso.” [9] Si bien, el término REST, se refería originalmente a un conjunto de principios de arquitectura, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz Web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de Servicios Web SOAP. Es posible diseñar sistemas de Servicios Web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, es importante señalar que RPC (Remote Procedure Call, llamadas a procedimientos remotos) no es un ejemplo de REST. REST afirma que la Web ha disfrutado de escalabilidad como resultado de una serie de principios o diseños fundamentales clave: •. Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST).. •. Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en sí define un conjunto pequeño de operaciones, las más 10.

(19) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema. •. Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su URI.. •. El uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional. [10]. 1.7 ¿Qué es JavaScript y/o JScript? JavaScript es un lenguaje interpretado, es decir, que no requiere compilación, utilizado principalmente en páginas Web. No es un lenguaje orientado a objetos propiamente dicho, ya que no dispone de herencia, es más bien un lenguaje basado en prototipos, ya que las nuevas clases se generan clonando las clases base (prototipos) y extendiendo su funcionalidad. Todos los navegadores interpretan el código JavaScript integrado dentro de las páginas Web. El lenguaje fue inventado por Brendan Eich en la empresa Netscape Communications, que es la que fabricó los primeros navegadores Web comerciales. Apareció por primera vez en el producto de Netscape llamado Netscape Navigator 2.0. Tradicionalmente, se venía utilizando en páginas Web HTML, para realizar tareas y operaciones en el marco de la aplicación únicamente cliente, sin acceso a funciones del servidor. JavaScript se ejecuta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. 11.

(20) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Los autores inicialmente lo llamaron Mocha y más tarde LiveScript pero fue rebautizado como JavaScript en un anuncio conjunto entre Sun Microsystems y Netscape, el 4 de diciembre de 1995. En 1997 los autores propusieron JavaScript para que fuera adoptado como estándar de la the European Computer Manufacturers' Association ECMA, que a pesar de su nombre no es europeo sino internacional, con sede en Ginebra. En junio de 1997 fue adoptado como un estándar ECMA, con el nombre de ECMAScript. Poco después también lo fue como un estándar ISO. JScript es la implementación de ECMAScript de Microsoft, muy similar al JavaScript de Netscape, pero con ciertas diferencias en el modelo de objetos del navegador que hacen a ambas versiones con frecuencia incompatibles.[11]. 1.8 ¿Qué es JSON? JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de muchos lenguajes. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos. JSON está constituido por dos estructuras: •. Una colección de pares de nombre/valor. En varios lenguajes esto es conocido como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo.. •. Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o secuencias.. 12.

(21) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una forma u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras.[12]. 1.9 ¿Qué es AJAX? AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript y XML asíncronos), es una técnica de desarrollo Web para crear aplicaciones interactivas. Éstas se ejecutan en el cliente, es decir, en el navegador del usuario, y mantiene comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre la misma página sin necesidad de recargarla. Esto significa aumentar la interactividad, velocidad y usabilidad en la misma. AJAX es una combinación de tres tecnologías ya existentes: •. XHTML (o HTML) y hojas de estilos en cascada (CSS) para el diseño que acompaña a la información.. •. Document Object Model (DOM) accedido con un lenguaje de scripting por parte del usuario, especialmente implementaciones ECMAScript como JavaScript y JScript, para mostrar e interactuar dinámicamente con la información presentada.. •. El objeto XMLHttpRequest para intercambiar datos asincrónicamente con el servidor Web.. •. XML es el formato usado comúnmente para la transferencia de vuelta al servidor, aunque cualquier formato puede funcionar, incluyendo HTML preformateado, texto plano, JSON entre otros.. AJAX no constituye una tecnología en sí, sino que es un término que engloba a un grupo de éstas que trabajan conjuntamente.[13]. 13.

(22) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1.10 ¿Qué es SOAP? SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML, es uno de los protocolos utilizados en los servicios Web y funciona sobre cualquier protocolo de Internet generalmente HTTP (HyperText Transport Protocol). Usa el código fuente en XML, siendo una ventaja ya que facilita su lectura por parte de humanos, pero también es un inconveniente dado que los mensajes resultantes son más largos. El término Object en el nombre significa que se adhiere al paradigma de la programación orientada a objetos. Está diseñado en una parte cabecera y otra de desarrollo. La cabecera Header es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones. El desarrollo Body contiene la información principal, que se conoce como carga útil (payload). HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos. [14]. Ejemplo de estructura de SOAP. 14. [15].

(23) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1.11 ¿Qué es WSDL? Las siglas WSDL significan Web Services Description Language [16] o sea lenguaje de descripción de servicios Web. Dado que los protocolos de comunicaciones y los formatos de mensajes están estandarizados en la comunidad del Web, cada día aumenta la posibilidad e importancia de describir las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática XML que describe los servicios de red como colecciones de puntos finales de comunicación capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan documentación para sistemas distribuidos y sirven como fórmula para automatizar los detalles que toman parte en la comunicación entre aplicaciones. Los documentos WSDL definen los servicios como colecciones de puntos finales de red o puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se están intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red: •. Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por ejemplo XSD (XML Schema Definition)).. •. Message: definición abstracta y escrita de los datos que se están comunicando.. •. Operation: descripción abstracta de una acción admitida por el servicio.. •. Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales.. 15.

(24) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I •. Binding: especificación del protocolo y del formato de datos para un tipo de puerto determinado.. •. Port: punto final único que se define como la combinación de un enlace y una dirección de red.. •. Service: colección de puntos finales relacionados.. Es importante observar que WSDL no introduce un nuevo lenguaje de definición de tipos. WSDL reconoce la necesidad de disponer de diferentes sistemas de tipos para describir los formatos de mensaje y admite como sistema de tipos canónico la especificación de los esquemas XML (XSD). Sin embargo, puesto que no es razonable esperar una única gramática del sistema de tipos que se utilice para describir todos los formatos de mensajes presentes y futuros, WSDL permite el uso de otros lenguajes de definición de tipos mediante la extensibilidad. Asimismo, WSDL define los mecanismos de enlace común. Éstos se utilizan para adjuntar un protocolo, un formato de datos o una estructura específica a un mensaje abstracto, una operación o un punto final de red. Permite la reutilización de definiciones abstractas. Además del marco de definición de servicio principal, esta especificación introduce extensiones de enlace específicas para los siguientes protocolos y formatos de mensaje: •. SOAP 1.1. •. HTTP GET / POST. •. MIME. Las extensiones de lenguaje anteriores están en una capa superior respecto al marco de definición de servicio principal. Nada impide el uso de otras extensiones de enlace con WSDL.[17]. 16.

(25) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. 1.12 Servicios Web Los servicios Web XML son los bloques de construcción básicos en la transición al proceso distribuido en Internet. Los estándares abiertos y el foco en la comunicación y colaboración entre las personas y aplicaciones han creado un entorno donde los servicios Web XML se están convirtiendo en la plataforma para la integración de aplicaciones. Las aplicaciones se construyen utilizando múltiples servicios Web XML desde diversas fuentes que trabajan conjuntamente con independencia de dónde residen o cómo hayan sido implementadas. Probablemente existan tantas definiciones de los Servicios Web XML como compañías que los desarrollan, pero casi todas las definiciones tienen estos aspectos comunes: •. Los Servicios Web XML exponen funcionalidad útil a los usuarios Web mediante un protocolo Web estándar. En la mayoría de casos, el protocolo utilizado es Simple Object Access Protocol (SOAP).. •. Los Servicios Web XML proporcionan un modo de describir sus interfaces con suficiente detalle para permitir a un usuario construir una aplicación cliente para hablar con ellos. Esta descripción se proporciona generalmente en un documento XML que responde al nombre de documento Web Services Description Language (WSDL).. •. Los Servicios Web XML se registran de modo que los potenciales usuarios puedan encontrarlos. Esto se realiza mediante Universal Discovery Description and Integration (UDDI).. La mayoría de la información está ya disponible en la Web, pero los servicios Web XML hacen que su acceso programático sea más fácil y fiable. Exponer las aplicaciones existentes como servicios Web XML permitirá a los usuarios construir nuevas y más potentes aplicaciones que utilicen servicios Web XML como bloques de construcción. [16]. 17.

(26) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. Interacción de un conjunto de servicios Web. [15]. 1.13 ¿Qué es UDDI? UDDI (Universal Description Discovery and Integration) es un registro público diseñado para almacenar de forma estructurada información sobre empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la categorización. Lo más importante es que UDDI contiene información sobre las interfaces técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de software basado en servicios Web. ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta que existe una colección de software de miles (quizás millones) de servicios Web, se plantean varias cuestiones difíciles: •. ¿Cómo se descubren los servicios Web?. 18.

(27) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I •. ¿Cómo se categoriza la información de forma coherente?. •. ¿Cómo repercute esto en la localización?. •. ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la interoperabilidad del mecanismo de descubrimiento?. •. ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de descubrimiento cuando mi aplicación depende de un servicio Web?. La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas, incluidas Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más, unieron sus esfuerzos para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y publicaciones sin coste alguno. A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un entorno de software de servicios Web. [18]. 1.13.1 Modelo de objetos y descripción de los elementos de UDDI El modelo de objetos de UDDI contiene los siguientes elementos: •. businessEntity: Representa una entidad o empresa física.. •. businessService: Representa un servicio ofrecido por una entidad.. •. bindingTemplate: Detalles de cómo invocar un servicio. 19.

(28) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I •. tModel: En esencia, un tModel puede ser representado por cualquier objeto que tenga un nombre y una descripción.. Para un mejor entendimiento del modelo de objetos se puede observar la siguiente imagen donde se muestra una representación en UML (Unified Modeling Language) de los citados elementos.. Relación entre los elementos pertenecientes al modelo de objetos de UDDI. De este diagrama se infiere que una entidad (empresa, compañía) tiene una URL descriptiva que puede decir más sobre ella y una lista de sus contactos. Además, un businessEntity tiene una lista de businessServices.. Hay varias formas de invocar cada. businesService. Cada invocación es descrita por un bindingTemplate. Un bindingTemplate describe en detalles como acceder a un servicio, esto puede beneficiar al tener una serie de elementos de documentación que describan como realizar este acceso. La conexión entre un bindingTemplate y esta necesaria documentación se ha realizado a través de lo que se ha llamado tModel. En el diagrama esta relación es en forma simple representada por ahora como un bindingTemplate teniendo una colección de tModels. Como bien se ha citado anteriormente un tModel puede ser un objeto o cualquier ente que posea nombre y descripción.. 20.

(29) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Usando otro diagrama UML (Unified Modeling Language) se mostrará la relación existente entre bindingTemplates y tModels.. Relación entre bindingTemplates y tModels. Del diagrama se puede ver. como un bindingTemplate puede apuntar hacia una. especificación técnica identificada por un tModel. Esta especificación técnica tiene dos partes: •. Tipo de especificación (ej., email, fax, WSDL, servicio SOAP, etc.). •. Entradas y salidas de las identificaciones de documentos (en el caso de un servicio SOAP, estos documentos pueden ser formatos de mensajes de entrada/salida de XML). También pertenecen al modelo de objetos de UDDI los elementos IdentifierBag y CategoryBag. Como bien se había mencionado un tModel es básicamente un nombre y una descripción y que puede contener una URL para más detalles. Un tModel puede ser identificado usando un IdentifierBag y categorizado por un CategoryBag. La siguiente figura muestra un diagrama que ayuda en la explicación o aclaración de estos elementos y como se relacionan en el modelo de objetos.. 21.

(30) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. Explicación de IdentifierBag y CategoryBag. 1.14 Modelo de Similitud UDDI contiene algunos tModels básicos que apoyan muchas de sus funcionalidades como es el caso de la categorización de elementos. La inclusión de algunos tModels básicos hará posible una mejor categorización de los elementos de SEPAD publicados en el directorio UDDI. Para una mejor identificación se nombrarán tModels canónicos. La relación de estos tModels se da a continuación: •. sepad:types: categoriza el tipo de elemento de SEPAD (entidad, instancia, modalidad académica, módulo).. •. sepad:type_name: categoriza el nombre de los elementos de SEPAD.. •. sepad:modality_certificate: categoriza el certificado que otorga una modalidad.. •. sepad:modality_coordinator: categoriza el coordinador de una modalidad.. 22.

(31) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I •. sepad:module_owner: categoriza el profesor principal de un módulo.. •. sepad:module_description: categoriza la descripción de un módulo.. Uno de los objetivos concebidos en este trabajo es la publicación de elementos de SEPAD en un directorio UDDI. Al trabajar los modelos de objetos de cada uno de ellos, urge entonces plantear un modelo que aporte los puntos comunes entre ambas plataformas, de gran utilidad a la hora de implementar este importante objetivo, a dicho modelo se le llamará Modelo de Similitud y se muestra a continuación.. 23.

(32) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I Modelo de Similitud SEPAD. UDDI. Entidad. businessEntity. Nombre Descripcion. Name Description. Instancia. businessService. Nombre. Name. Modalidad Academica Nombre Coordinador URL. KeyedReference CategoryBag. tModelKey keyname keyvalue. tModel Referencia. tModelKey Name. Modulo Nombre Profesor principal URL Descripcion Palabras Claves. Modalidad Académica. Módulo. Palabra Clave. Modalidad Academica Nombre Coordinador URL. Modulo Nombre Profesor principal URL Descripcion Palabras Claves. 24. BindingTemplate. tModelInstanceInfo. description accespoint. tModelKey description.

(33) Bases para el descubrimiento y descripción de los elementos de SEPAD Capítulo I. Este capítulo abordó la plataforma SEPAD y la necesidad de un mejor descubrimiento y descripción de los elementos pertenecientes a esta. Planteó, además, la creación de un framework como solución al tiempo que se describen algunas tecnologías a usar y se expone el Modelo de Similitud.. 25.

(34) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.. DISEÑO. E. IMPLEMENTACIÓN. DEL. FRAMEWORK PARA EL DESCUBRIMIENTO Y DESCRIPCIÓN. DE. LOS. SEPAD. 26. ELEMENTOS. DE.

(35) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II En este capítulo se especifican los detalles de diseño e implementación de cada uno de los módulos que conforman el framework para el descubrimiento y descripción de los elementos de SEPAD así como las relaciones existentes entre estos módulos.. 2.1 Diseño de los módulos del framework En el diseño de cada uno de los módulos del framework se hará uso de los diagramas que aporta el UML para dar una mejor visión de las funcionalidades implementadas.. 2.1.1 Diseño del módulo SepadMEXPublisher Basado en el Modelo de Similitud, descrito anteriormente, surge la creación del módulo SepadMEXPublisher, el cual brinda la posibilidad de publicar elementos de SEPAD en cualquier directorio UDDI, cumpliendo uno de los objetivos parciales de esta investigación. El módulo esta formado por la implementación de los casos de usos, siendo este una aplicación orientada a wizard como facilitadora de una interfaz amigable a los usuarios que hacen uso de ella.. 2.1.1.1 Diagrama de casos de usos El caso de uso exclusivo de este módulo se basa en la publicación de elementos de SEPAD en un directorio UDDI. Se presenta a continuación el diagrama de casos de usos de este módulo.. Diagrama de casos de usos. 27.

(36) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.1.1.2 Diagramas de estados de los casos de usos El caso de uso de este módulo queda detallado en un diagrama que muestra cada uno de los estados donde se encontrará la aplicación cada vez que el usuario ejecute una acción determinada. El diagrama está diseñado de la siguiente forma:. Diagrama de estado. Los actores de este módulo se detallan en el diagrama de casos de usos. Específicamente, pueden ser profesores que hayan creado módulos en SEPAD o administradores de la plataforma SEPAD.. 28.

(37) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.1.1.3 Representación de clases utilizadas en el módulo. Para lograr una mayor organización y modularización se crearon varias clases con diversas funcionalidades, detalladas a continuación. Clase TUDDIClass Esta clase se encarga de la conexión al directorio UDDI, se le especifica las direcciones de búsqueda y publicación del directorio, además, del modo de autenticación que se utilizará.. Clase TUDDIClass. Clase TDBClass Contiene la información referente a la base de datos de SEPAD del cual se publicará así como el propio nombre de la base de datos y el nombre del servidor donde está alojada.. Clase TDBClass. 29.

(38) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase TCanonicTModels Esta clase tiene la función principal de obtener los identificadores de los tmodels canónicos para su uso posterior.. Clase TCanonicTModels. Clase TEntityClass Esta clase representa una entidad que publica elementos de SEPAD en un directorio UDDI, los atributos y operaciones quedan descritos a continuación en la siguiente figura.. 30.

(39) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase TEntityClass. Clase TEntitiesClass Posee como atributo una lista de entidades y como métodos, las acciones sobre la lista.. Clase TEntitiesClass. Clase TInstanceClass Esta clase representa una instancia o servidor de SEPAD, desde la que se publican elementos en un directorio UDDI, los atributos y operaciones se pueden ver a continuación en la siguiente figura.. Clase TInstanceClass. Clase TInstancesClass Posee como atributo una lista de instancias y como métodos, las acciones sobre la lista.. 31.

(40) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase TInstancesClass. Clase TModalityClass Esta clase representa una modalidad de SEPAD a publicar en un directorio UDDI. Los atributos y operaciones quedan descritos a continuación en la siguiente figura.. Clase TModalityClass. Clase TModalitiesClass Posee como atributo una lista de modalidades y como métodos, las acciones sobre la lista.. Clase TModalitiesClass. 32.

(41) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase TModuleClass Esta clase representa un módulo de SEPAD a publicar en un directorio UDDI. Los atributos y operaciones quedan descritos a continuación en la siguiente figura.. Clase TModuleClass. Clase TBusinessServicesClass Representa un business services perteneciente al modelo de UDDI.. 33.

(42) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. Clase TBusinessServicesClass. Clase TBindingTemplateClass Representa un binding template perteneciente al modelo de UDDI.. Clase TBindingTemplateClass. 34.

(43) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.1.2 Diseño del módulo SepadMEXPHP Este módulo esta concebido como una capa de abstracción que provee las herramientas necesarias para facilitar el acceso y operaciones de consulta desde ambiente Web a un directorio UDDI. Permite aislar los conceptos de UDDI y los detalles del Modelo de Similitud y expone los elementos y metadatos de SEPAD. Adicionalmente, posee una caché de datos para mejorar el tiempo de acceso a estos elementos.. 2.1.2.1 Representación de clases utilizadas en el módulo El módulo está compuesto por varias clases que se detallan a continuación. Clase Catalog Esta es la clase principal del módulo y contiene los datos necesarios para la conexión al catálogo o directorio UDDI. Implementa las peticiones básicas de obtención de todos los elementos de SEPAD.. Clase Catalog. 35.

(44) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase Entity Representa el concepto de Entidad y contiene sus metadatos. Posee métodos para obtener todos los elementos que pertenecen a ella.. Clase Entity. Clase Instance Representa el concepto de Instancia y contiene sus metadatos. Posee métodos para obtener todos los elementos que pertenecen a ella.. Clase Instance. 36.

(45) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Clase Modality Representa el concepto de Modalidad Académica y contiene sus metadatos. Posee métodos para obtener todos los elementos que pertenecen a ella.. Clase Modality. Clase Module Representa el concepto de Módulo y contiene sus metadatos.. Clase Module. 2.1.2.2 Diagrama de clases del módulo SepadMEXPHP A continuación, se muestra como queda definido el diagrama de clases de éste módulo. 37.

(46) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. Diagrama de clases del módulo SepadMEXPHP. 38.

(47) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.1.3 Diseño del módulo SepadMEXREST Este módulo se identifica como un servicio Web que sigue los principios de arquitectura definidos por REST y utiliza el módulo SepadMEXPHP para obtener los metadatos de SEPAD publicados en el directorio UDDI. Los elementos de SEPAD quedan expresados como recursos representados en formato JSON y son localizables a través de URLs, de forma tal que el módulo constituye una herramienta más para la obtención de los elementos de SEPAD publicados en un directorio UDDI.. 2.1.3.1 Representación de clases utilizadas en el módulo Se han desarrollado varias clases que representan los recursos a acceder. En este caso son los elementos de SEPAD a solicitar, siguiendo lo planteado por REST. Se presenta como quedan las mencionadas clases. Clase RESTEntity Esta clase representa el recurso entidad, un elemento de SEPAD que ha sido publicado en el directorio o catálogo UDDI.. Clase RESTEntity. Clase RESTInstance Esta clase representa el recurso instancia, un elemento de SEPAD que ha sido publicado en el directorio o catálogo UDDI.. 39.

(48) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. Clase RESTInstance. Clase RESTModality Esta clase representa el recurso modalidad, un elemento de SEPAD que ha sido publicado en el directorio o catálogo UDDI.. Clase RESTModality. Clase RESTModule Esta clase representa el recurso modalidad, un elemento de SEPAD que ha sido publicado en el directorio o catálogo UDDI.. Clase RESTModule. 40.

(49) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II En estas clases, los atributos que representarían las listas de elementos, en realidad son direcciones para acceder, directamente, a otros recursos, cumpliendo los principios que plantea REST.. 2.1.3.2 Estructura del servicio Web que implementará el módulo. Se propone entonces la creación de un sitio basado en la arquitectura REST que resuelva las peticiones de cada recurso a ser accedido utilizando las clases definidas, anteriormente, y devolviendo el resultado en formato JSON. Solicitando Entidades El sitio debe tener una página para las solicitudes de entidades. Para solicitar todas las entidades del directorio o catálogo UDDI la URL sería: http:// nombre del dominio / directorio / página de entidades Para solicitar una entidad específica: http:// nombre del dominio / directorio / página de entidades ?id= id de la entidad Solicitando Instancias Debe tener otra página para la solicitud de instancias de SEPAD. Para solicitar todas las instancias del directorio o catálogo UDDI la URL sería: http:// nombre del dominio / directorio / página de instancias Para solicitar una instancia específica: http:// nombre del dominio / directorio / página de instancias ?id= id de la instancia Para solicitar las instancias publicadas por una entidad específica: http:// nombre del dominio / directorio / página de instancias ?entity= id de la entidad 41.

(50) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II Solicitando modalidades Debe tener otra página para la solicitud de modalidades de SEPAD. Para solicitar todas las modalidades del directorio o catálogo UDDI la URL sería: http:// nombre del dominio / directorio / página de modalidades Para solicitar una modalidad específica: http:// nombre del dominio / directorio / página de modalidades ?id= id de la modalidad Para solicitar las modalidades publicadas por una entidad específica: http:// nombre del dominio / directorio / página de modalidades ?entity= id de la entidad Para solicitar las modalidades publicadas de una instancia específica: http:// nombre del dominio / directorio / página de modalidades ?instance= id de la instancia Solicitando módulos Finalmente, debe tener otra página para la solicitud de módulos de SEPAD. Para solicitar todos los módulos del directorio o catálogo UDDI la URL sería: http:// nombre del dominio / directorio / página de módulos Para solicitar un módulo específico: http:// nombre del dominio / directorio / página de módulos ?id= id del módulo Para solicitar los módulos publicados por una entidad específica: http:// nombre del dominio / directorio / página de módulos ?entity= id de la entidad Para solicitar los módulos publicados de una instancia específica: 42.

(51) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II http:// nombre del dominio / directorio / página de módulos ?instance= id de la instancia Para solicitar los módulos publicados de una modalidad específica: http:// nombre del dominio / directorio / página de módulos ?modality= id de la modalidad Cada una de estas URLs navega directo a una página que devuelve elementos de SEPAD publicados (utilizando el SepadMEXPHP) en directorios o catálogos UDDI en dependencia del recurso o elemento que se solicite. La información se devolverá como un objeto de las clases descritas anteriormente, llevado a formato JSON.. 2.1.4 Diseño del módulo SepadMEXAJAX El presente módulo representa una biblioteca de componentes visuales cuya funcionalidad es mostrarles a los usuarios los elementos de SEPAD publicados en los directorios o catálogos UDDI y hacerlo de diversas maneras según el criterio o necesidad de dichos usuarios. Este trabajo se ha centrado, solamente, en la creación de componentes de árboles visuales. El módulo se apoyará en el SepadMEXREST para obtener objetos en formato JSON que representan los elementos de SEPAD que conformarán el componente visual. Como bien indica el nombre, la filosofía del módulo esta basada en AJAX, se pretende que los componentes visuales la implementen. El módulo consiste en un archivo JavaScript que deberá ser incluido en las páginas Web donde vaya a ser usado de manera que los componentes visuales sean fácilmente insertables en cualquier tipo de páginas Web. Los componentes visuales serán creados con la capacidad de ser configurables en cuanto a etiquetas o textos de encabezamientos, estilos, niveles de muestra, entre otros, para que sean más adaptables a las condiciones de las personas que harán uso de ellos.. 43.

(52) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.2 Implementación de los módulos del framework Este punto se centrará en algunas tecnologías, software utilizado y detalles esenciales en la implementación de cada uno de los módulos que forman el framework.. 2.2.1 Implementación del módulo SepadMEXPublisher Como bien se había mencionado antes, este módulo es una aplicación capaz de publicar elementos de SEPAD en un directorio UDDI. Para llevar a cabo la implementación, se utilizó el Delphi en su versión siete y otras tecnologías de las cuales se hablarán.. 2.2.1.1 Delphi Delphi es un entorno de desarrollo de software diseñado para la programación de propósito general con énfasis en la programación visual. En Delphi se utiliza como lenguaje de programación una versión moderna de Pascal llamada Object Pascal. Es producido comercialmente por la empresa estadounidense CodeGear. En sus diferentes variantes, permite producir archivos ejecutables para Windows, Linux y la plataforma .NET. CodeGear ha sido escindida de la empresa Borland, donde Delphi se creó originalmente. Un uso habitual de Delphi (aunque no el único) es el desarrollo de aplicaciones visuales y de bases de datos cliente-servidor y multicapas. Debido a que es una herramienta de propósito múltiple, se usa también para proyectos de casi cualquier tipo, incluyendo aplicaciones de consola, aplicaciones de Web (por ejemplo servicios Web, CGI, ISAPI, NSAPI, módulos para Apache), servicios COM y DCOM, y servicios del sistema operativo. Delphi incluye una biblioteca de clases bien diseñada denominada VCL (Visual Component Library, Biblioteca de Componentes Visuales) y, en sus versiones 6 y 7, una jerarquía multiplataforma paralela denominada CLX. Estas jerarquías de objetos incluyen componentes visuales y no visuales, tales como los pertenecientes a la categoría de acceso a datos, con los que puede establecerse conexiones de forma nativa o mediante capas intermedias a la mayoría de las bases de datos relacionales existentes en el mercado. La VCL también está disponible para el desarrollo en .NET.[19] 44.

(53) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II. 2.2.1.2 Componentes DBExpress de la VCL de Delphi 7 Para gestionar la conexión y extracción de los elementos de SEPAD de sus bases de datos se utilizó los componentes DBExpress pertenecientes a la VCL de Delphi 7, estos son un conjunto de drivers de base de datos que provee un rápido acceso a servidores de base de datos SQL (gestor de base de datos, acrónimo de Structure Query Language).[20]. 2.2.1.3 Tecnología .NET y Microsoft UDDI SDK Para poder conectarse de la aplicación a un servidor UDDI y lograr publicar en él se utilizó el Microsoft UDDI SDK perteneciente a la tecnología .NET de Microsoft Corporation. Microsoft.NET es el conjunto de nuevas tecnologías en las que Microsoft Corporation ha estado trabajando durante los últimos años con el objetivo de obtener una plataforma sencilla y potente para distribuir el software en forma de servicios que puedan ser suministrados remotamente y que puedan comunicarse y combinarse unos con otros de manera totalmente independiente de la plataforma, lenguaje de programación y modelo de componentes con los que hayan sido desarrollados. Microsoft.NET representa un intento de unificación de tecnologías en aspectos importantes del desarrollo de la computación como pueden ser: Soporte para Bases de Datos, Web, Programación distribuida, etc. Propone una compatibilidad aceptable con tecnologías desarrolladas anteriormente por Microsoft Corporation. Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web y establece el XML como norma en el transporte de información en sus productos y lo promociona como tal en los sistemas desarrollados utilizando sus herramientas. Microsoft UDDI SDK es un SDK (Microsoft Development Kit) para las especificaciones de UDDI, habilita aplicaciones clientes para interactuar a un alto nivel de abstracción con los servidores de UDDI que soportan dichas especificaciones. Estos servidores pueden. 45.

(54) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II funcionar privadamente o en una intranet, conjuntamente en una extranet, o públicamente en Internet. Este SDK soporta la especificación de la versión 2.0 de UDDI y requiere .NET Framework versión 1.1. Además consiste en una documentación, el Microsoft UDDI assembly para el framework de .NET y algunas aplicaciones de ejemplo.[21]. 2.2.2 Implementación del módulo SepadMEXPHP El módulo SepadMEXPHP como bien indica el nombre está implementado en PHP (PHP Hypertext Pre-processor). A continuación se detallará las tecnologías, librerías y software que se utilizó para su realización.. 2.2.2.1 ¿Qué es PHP? PHP es un idioma de scripting extensamente usado, con la posibilidad de empotrarse en HTML [22], es un lenguaje interpretado usado para la creación de aplicaciones para servidores, o creación de contenido dinámico para sitios Web. Es un acrónimo recurrente que significa “PHP Hypertext Pre-processor” (inicialmente PHP Tools, o, Personal Home Page Tools). Fue originalmente diseñado en Perl (otro lenguaje de scripting), por el programador danéscanadiense Rasmus Lerdorf en el año 1994 para mostrar su currículum vitae y guardar ciertos datos, como la cantidad de tráfico que su página Web recibía. [23] Corre en los sistemas operativos más comunes y es compatible con muchos servidores Web.. 2.2.2.2 Librería PHP-UDDI En este módulo se utilizó una librería de UDDI para PHP la cual provee de métodos para el acceso a un directorio UDDI. Este proyecto empezó en noviembre de 2002 por Lee Reinolds y Jon Stephens. El intento original era proporcionar una sinopsis de las especificaciones de UDDI, encontrar una biblioteca de PHP buena para UDDI, y demostrar su uso. Sin embargo, había un problema: 46.

(55) Diseño e implementación del Framework para el descubrimiento y descripción de los elementos de SEPAD Capítulo II mientras hay bibliotecas de UDDI disponible para otros lenguajes, no había ninguna para PHP. Así que, se decidió desarrollar una propia. En la actualidad se desarrollaron clases para el soporte de las versiones 1.0/2.0 de las Inquiry APIs de UDDI, pero se piensa implementar todas las APIs cliente-servidor de las 3 versiones de la especificación de UDDI en el futuro. También se desea integrar otros rasgos que podría ser útil a diseñadores de PHP y se está considerando su compatibilidad con PEAR (PHP Extention and Application Repository).[24]. 2.2.2.3 Librería para gestionar XML El uso de la librería PHP-UDDI y la aplicación de sus métodos en este módulo, devuelven la información en formato XML, lo cual conlleva a la búsqueda de algún mecanismo para gestionar de una mejor forma los datos devueltos en el citado formato. Como alternativa a la problemática se utilizó una librería de código abierto para la gestión de XML que posee dos métodos fundamentales: • Método XML_unserialize: dada una cadena XML pasada como parámetro devuelve una estructura de datos de PHP basada en arreglos asociativos. • Método XML_serialize: realiza la acción inversa.[25]. 2.2.2.4 Zend Studio Por el buen prestigio que posee el Zend Studio se quiso desarrollar este módulo en este editor de texto el cual es muy cómodo y ofrece muchas ventajas a la hora de programar. Se trata de un programa de la casa Zend, impulsores de la tecnología de servidor PHP, orientada a desarrollar aplicaciones Web en lenguaje PHP. El programa, además de servir de editor de texto para páginas PHP, proporciona una serie de ayudas que pasan desde la creación y gestión de proyectos hasta la depuración de código.. 47.