Download xdc_sc

Ampliación y Optimización De Un Repositorio De Metadatos De
Componentes De Software Para PyMEs Colombianas
David Ortega y Jorge A. Beltrán
Carrera de Ingeniería de Sistemas
Universidad Javeriana
Bogotá, Colombia
{david.ortega, jnull}@javeriana.edu.co
Documento de Definición de los Servicios que van a prestar los
WebService
JUSTIFICACION
Los Webservices son aplicaciones modulares y reutilizables que se comunican
por la Web, o al interior de una organización, para llevar a cabo una funcion
especifica del negocio. Basandose en una serie de protocolos estandar de
comunicación, una de las principales motivaciones para la implementacion de
Webservices en nuestro poyecto es que estos son idependientes de la
plataforma y tecnologia y pueden ser unidos muy facilmente. La comunicación
entre diferentes sistemas es uno de sus fuertes, con estos, el proceso para la
conexión de los procesos se hace mucho más sencillo y flexible.
La filosofia del Repositorio de metadatos es la de prestar servicios a nuestras
Pymes Colombianas, y los webservices son los precursores para la adopcion
de una arquitectura orientada a servicios. Esta arquitectura promete eficiencia
en costos, integracion simplificada, la facilidad de incorporacion de nueva
tecnologia y la valoracion de los activos actuales. Factores que van de la mano
con las necesidades de nuestro mercado objetivo.
IMPLEMENTACION
Inicialmente en este documento se va a hacer una breve descripcion de la
funcionalidad actual del prototipo funcional de la biblioteca de componentes
para luego definir los servicios que van a ser publicados en el WebService,
describiendo su funcionalidad a nivel general.
Funcionalidades actuales del Repositorio:

Registro de Proveedor :
Puerta de entrada a los modulos de ingreso y actualizacion de metadatos de
componentes. En el registro se solicita la siguiente informacion: Nombre, Login,
Email, Password, Re-Password. Retornando un mensaje de éxito en caso de
que el registro se halla realizado correctamente.

Autenticación de Proveedor :
Paso obligatorio del sistema para tener acceso a los modulos de ingreso y
actualizacion. Aca son solicitados el usuario y el password del proveedor
previamente registrado.

Ingreso de metadatos de un componente
Aca es posible ingresar los metadatos que describen un componente, esta
operación se puede realizar luego de que se ejecute la autenticacion del
proveedor. Durante toda esta operación se va a ir ingresando de a poco la
informacion de un componente basandose en el Estandar de Descricion de
Componentes desarrollado por el director del proyecto PICS. Inicialmente se
ingresa y modifica la información básica del componente. A continuacion se
ingresa la descripcion del componente con la informacion solicitada por el
formulario. Luego, es requerida la informacion del creador, publicador,
contribuyente, formato, relaciones y los derechos del componente. El sistema
informara de los errores o el éxito de las operaciones.

Actualizacion de metadatos de un componente previamente ingresado
En este modulo el sistema solo dara autorizacion de actualizacion al proveedor
que ingreso el componente, es importante en este punto, que el sistema trae
los componentes publicados previamente por el proveedor autenticado.

Consulta de componentes almacenados bajo los siguientes criterios: tipo
de arquitectura, sistema operativo, lenguaje de programacion,
funcionalidad y palabra clave.
En este modulo el sistema permite consultar los metadatos de los componentes
teniendo en cuenta la informacion de filtro para ejecutar la busqueda
TRANSFORMACION AL ESTANDAR DE DESCRIPION DE COMPONENTES
(XDC_SC)
Actualmente toda esta informacion esta contenida en objetos java, la propuesta
consiste en hacer de esta informacion, o por lo menos aquella que se valla
publicar en el webservice, un procesamiento previo para dejarla toda en
formato XML con la estructura del Estandar de Descripcion de Componentes,
de esta forma el cliente que consuma el servicio va a poder aprovechar todas
las ventajas y oportunidades que provee este formato.
Otra razon por la cual se llevara a cabo este procesamiento previo, es debido a
un acuerdo con el director del proyecto en donde es más conveniente tener
esta informacion que se va a publicar en clases aparte de las que ya se
encuentran desarrolladas.
Ademas de esto, otro de los motivos por el cual se pasa la informacion a
formato XML, es porque vemos que la base de todo el proyecto es el Estandar
de Descripcion de Componentes desarrollado por rafael gonzales y en esencia
este es un archivo descriptor XML donde esta reflejada de alguna forma toda la
funcionalidad del Repositorio de Componentes y en la actualidad esta
informacion no esta en este formato, nos parece conveniente que los clientes
que consuman los servicios publicados en el webservice conoscan el contenido
de la informacion almacenada en el repositorio en el formato como fue
concebido inicialmente.
Teniendo en cuenta los dos puntos tratados anteriormente, funcionalidad actual
y procesamiento previo a XML, vamos a definir los servicios a publicar en el
WebService.
SERVICIOS:
Es importante aclarar que los servicios que necesiten de la autenticacion previa
de usuarios, esta operación se hara efectiva, por lo tanto es necesario que para
este tipo de consultas se solicite el usuario y password.
Ahora mismo vamos a mencionar tres grupos generales de servicios a prestar

Consulta de componentes almacenados bajo criterios de selección
(Detalle del Componente).
Los criterios de busqueda son los mismos que estan definidos en la aplicación
desarrollada en la primera etapa del proyecto, para este servicio será publicada
la funcionalidad actual del sistema como servicio Web, sin ninguna
transformación previa a ningún formato diferente al que ya esta definido en el
repositorio, para este servicio se creara un cliente de prueba en el que se usara
el formato adecuado para el consumo del servicio.

Actualización de un componente previamente ingresado, manteniendo la
regla de que el proveedor que lo ingreso sea el unico con autorizacion
para actualizarlo.
La aclaracion anterior de solicitar usuario y password aplica para este tipo de
servicio, en este punto, el cliente que va consumir este servicio debe conocer
de antemano la informacion del componente que va a actualizar, es esto
necesario.

Ingreso de un componente
Para el ingreso de un componente, el servicio inicialmente tomara toda la
informacion tenida en cuenta en el flujo de la aplicación desarrollada en la
etapa inicial del proyecto en donde se ingresa la descripcion del componente
con la informacion solicitada por el formulario. Luego, es requerida la
informacion del creador, publicador, contribuyente, formato, relaciones y los
derechos del componente. Ahora mismo esta definido que el cliente use de una
vez el Estandar de Descripcion de Componentes y sea este nuestro formato
para el ingreso de toda esta inforamcion al sistema. El servicio debe estar en
capacidad de tomar toda esta informacion (un String XML) y en la medida de
que la informacion sea solicitada por el flujo de la aplicación, esta va a ser
suministrada a partir del archivo descriptor (XDC_SC).
La facilidad de esto es la forma facil y clara en que el cliente puede ingresar a
traves de un solo formato, lo que se le estaba enviando en diferentes
momentos dentro de la sesion.
Aclaramos que toda esta implementacion esta sujeta a cambios ya que todo el
desarrollo esta de algun modo sujeto a la arquitectura inicial del repositorio.
Ahora mismo, la propuesta es la siguiente:
Contamos con una arquitectura j2ee, la cual nos brinda una funcionalidad
basica, y lo que se propone hasta ahora es seguir con la misma funcionalidad,
de tal forma que vamos a reutilizar tanto el modelo de datos, como la logica del
negocio ya desarrollada, y que para la transformacion previa a la publicacion
del servicio la informacion sea tomada desde el mismo punto en donde los
datos son preparados para ser desplegados en pantalla.
DETALLES TECNICOS DE LA IMPLEMENTACION DE LOS SERVICIOS:
Anteriormente comentamos que para dos de los tres servicios que van a ser
publicados, se va a utilizar el formato XML que define el estándar de
componentes, esta funcionalidad esta representada en un componente
desarrollado que denominamos GATEWAY.
Contexto
Precondición
Poscondición
Parámetros
GATEWAY es un componente que nace como una iniciativa
para dar solución al problema de procesar la petición hecha
por un cliente desde el servicio Web y para mejorar el
rendimiento de la aplicación durante el desarrollo.
El objetivo de implementar este componente, es centralizar
los llamados de las funciones implementadas por la lógica de
negocio por los servicios Web, con esto se busca reducir el
tiempo de implementación para el procesamiento de los
servicios pendientes de la aplicación.
Elaboración, por parte del Cliente, de la cadena de texto a
partir de la cual GATEWAY da inicio a su funcionalidad. Esto
se refiere al String XML, que representa el XDC_SC.
Invocación correcta, en tiempo de ejecución, del método de
objeto de negocio. Encargado de la petición hecha por parte
del usuario.
1 Cadena de texto que representa un documento XML, el
XDC_SC especificamente, con la información necesaria
para invocar de forma dinámica los métodos de los
objetos de negocio que procesan el requerimiento.
Funcionalidad
1
Lectura XML
Como primera medida es necesario procesar la cadena
de texto que llega como parámetro de la petición hecha
por el usuario y construir el documento XML a interpretar.
En java, para la interpretación de documentos XML
hacemos uso de la Liberia JDOM que nos proporciona
funciones que permiten de una forma ágil y sencilla
reconocer y manipular un documento XML.
Lo principal de esta fase, es reconocer el id definido en la
petición hecha por el cliente para poder hacer el llamado
al método correspondiente.
Este id es un atributo que se adiciona al XDC_SC el cual
indica al GATEWAY que operación de las dos definidas
se va a ejecutar, Ingresar o Actualizar un componente,
este atributo se adiciona en el tag <xdc_sc >
<xdc_sc SQLAction="ActualizarComponente">
<xdc_sc SQLAction="IngresarComponente">
2
Mapeo del identificador con el método que debe ser
invocado (clase, nombre del método, parámetros).
El identificador, es un id único, definido por nosotros y
hace referencia a ese atributo adicional al tag <xdc_sc >,
a través del cual podemos reconocer la clase y el método
que van ser invocados. Esta fase consiste simplemente,
en relacionar el identificador con los métodos y clases
creados en los objetos de negocio, así el componente
sabe que objeto debe instanciar de forma dinámica.
Luego, la información obtenida del mapeo debe ser
administrada y para esto usamos el API REFLECTION
DE JAVA.
3
Administración dinámica
(Llamado y Retorno)
del
método
invocado.
El API Reflection es una herramienta muy poderosa que
nos permite realizar en Java cosas que en otros
lenguajes es imposible.
Todos los objetos en java heredan de la clase
java.lang.Object y por ello están dotados de un método
getClass, cuya firma es public final Class getClass(). Este
método nos devuelve un objeto java.lang.Class, que va a
ser nuestro punto de partida para el diseño de nuestro
componente GATEWAY.
Los pasos a seguir, haciendo uso del API, son los
siguientes:




Cargar la clase obtenida de la tabla de mapeo.
Instanciar el objeto.
Invocar el método obtenido de la tabla de mapeo.
Retornar respuesta del método.
Cargar la clase obtenida de la tabla de mapeo
Class clase;
clase = Class.forName("className ");
java.lang.Class forName(String className): Carga una
clase del classpath a partir de su nombre (nombre
completo, con todos los paquetes. Si la clase no se
puede cargar, porque no se encuentra en el classpath, se
lanzará una java.lang.ClassNotFoundException.
Instanciar el objeto
Object objeto;
objeto = clase.newInstance();
Obtenemos simplemente la instancia (objeto) de la clase
cargada anteriormente, esto con el fin de tener acceso al
método que se necesite invocar, ya que mas adelante
este objeto hace parte de los parámetros de entrada de la
función que permite llamar dinámicamente el método
definido en nuestro mapeo. Si el objeto no puede ser
instanciado
de
lanzará
una
java.lang.InstantiationException.
Invocar el método obtenido de la tabla de mapeo
Method metodo;
metodo
clase.getMethod(map.getMetodo(),arrayParamTypes);
=
java.lang.reflect.Method getMethod(String name, Class[]
parameterTypes): Devuelve un método público de la
clase, a partir de su nombre, y de un array con las clases
de los parámetros del método. Si la clase no contiene
ningún método con ese nombre y esos parámetros, se
lanzará una java.lang.NoSuchMethodException.
Retornar respuesta del método
En este punto, el método del API que permite invocar el
método adecuado es:
public Object invoke(Object obj, Object[] args): Ejecuta el
método sobre un objeto, pasándole los parámetros
necesarios, y devuelve su resultado. Si al invocar este
metodo se genera algún error, se lanzará una
java.lang.reflect.InvocationTargetException.
API
Clase
public class Gateway
Extiende
Constructor public Gateway()
Permite
instanciar
la
clase sin tener
que
pasar
parámetros.
Métodos
public
String Método
que
Gateway1(String cad)
concentra toda la
funcionalidad del
componente.
public
Mapeo Encargado
de
Mapear(String id)
mapear el id con
el método y la
clase
correspondiente,
se conecta a la
base de datos
public
Document Interpreta
la
convertStringToXML(String cadena que llega
cad)
de la capa de
presentación y lo
transforma a un
documento XML.
Toda esta funcionalidad se debe desarrollar del lado del servidor, es claro que
para efectos de pruebas debe ser desarrollado un cliente que haga uso de todo
lo planteado anteriormente, para esta parte, va a ser desarrollada una interfaz
de usuario en Swing en la cual se va a reflejar el flujo tal cual esta diseñado en
la aplicación Web, pero que va a hacer uso del GATEWAY, de un servicio de
autenticación y del otro servicio que se va a publicar que hacer referencia a la
consulta de componentes.
Cliente Swing prueba del WebService
Para acceder a los servicios de ingreso y actualización de componentes, el
proveedor debe estar previamente registrado y autenticado. En el caso del
ingreso de componentes el cliente de prueba desarrollado desplegara una serie
de pantallas mediante las cuales el proveedor ingresara la información
correspondiente a la descripción del componente que desea almacenar en el
repositorio. Se describirán las pantallas describiendo la funcionalidad y el flujo
de cada servicio:
Es clave anotar que en la aplicación Web durante la ejecución del programa, el
flujo de la aplicación hace un uso muy importante de la sesión del usuario
(HttpSession), de esta forma la información recolectada en las jsp’s de las
funcionalidades de ingreso y actualización de componentes, se mantiene
almacenada en lo que se denomina sesión de usuario, para nuestro cliente del
servicio Web hemos definido, para reemplazar las facilidades que el
HttpSession brinda, una clase contenedora en la cual almacenamos toda la
información de los flujos que cada servicio requiere que tiene la particularidad
que su implementación sigue el patrón de desarrollo Simgleton el cual actúa
como una variable global en la medida de que se diligencian los frames de la
interfaz swing y así al final construir de una vez el documento XDC_SC que se
va a enviar como parámetro de los servicios Web definidos.
Antes de usar cada uno de los servicios el proveedor debe autenticarse frente
al sistema. Para esto encontrara la siguiente pantalla:
Figura: Interfaz Cliente Webservice, Autenticación Proveedor

Consulta de componentes almacenados bajo criterios de selección
(Detalle del Componente).
Figura: Interfaz Cliente Webservice, servicio Consultar Componente
Luego de escoger el primero de los servicios, la primera pantalla será igual a la
que encontramos en la aplicación Web que hace referencia a la búsqueda
general de un componente.
Figura: Interfaz Cliente Webservice, servicio Consultar Componente
Para este servicio Web, que depende de la parte del tema de optimización de
consultas, no se ha construido la interfaz definida como ultima versión eso
depende de cómo vamos a integrar esos temas en el desarrollo, así que ahora
mismo queda pendiente mostrar la interfaz definitiva que muestra el resultado
de las consultas.

Actualización de un componente previamente ingresado, manteniendo la
regla de que el proveedor que lo ingreso sea el único con autorización
para actualizarlo.
Para este servicio las pantallas del flujo, usando la clase Singleton, de la q
hablamos anteriormente, son las siguientes:
Figura: Interfaz Cliente Webservice Actualizar Componente, – Básico
Figura: Interfaz Cliente Webservice Actualizar Componente, – Descripción
Figura: Interfaz Cliente Webservice Actualizar Componente, – Creador,
Publicador, Contribuyente (tienen la misma información de entrada)
Figura: Interfaz Cliente Webservice Actualizar Componente, – Formato
Figura: Interfaz Cliente Webservice Actualizar Componente, – Relaciones
Figura: Interfaz Cliente Webservice Actualizar Componente, – Drechos

Ingreso de un componente
Para este servicio el flujo anterior de actualización es el mismo, usa la misma
interfaz.
El resultado de cada una de estas operaciones del lado del cliente da como
resultado el siguiente archivo xml, que describe el estándar de componentes
adicionando el atributo que mencionamos anteriormente:
…………..
Esta solución se va a llevar a cabo como esta planteado este documento. Con
esto ganamos todas las oportunidades explicadas en los documentos de la
primera fase del proyecto, y en la primera parte de este documento, pero
pensando un poco en lo que viene con el tema de la optimizacion de consultas
vemos que nos encontramos sujetos a ciertas caracteristicas, como las
consultas basicas prestadas por el repositorio hasta este momento. Entonces si
queremos hacer cambios sobre el modelo de datos mas adelante, la logica del
negocio va a verse afectada y por lo tanto tendriamos que hacer cambios sobre
la logica y asi sucesivamente, y no se esta respetando la constante de
mantener el desarrollo implementado en la primera fase del proyecto. Es así
como nuestro desarrollo va a tratar de respetar esto al máximo, pero
cumpliendo con nuestros objetivos iniciales.
Por ultimo, este desarrollo va a incluir un manual de instalación junto con el
cual se va hacer entrega de dos instaladores, el primero de ellos es la Maquina
Virtual de Java, componente necesario para ejecutar programas JAVA y el
segundo instalador va a ser el cliente swing que tiene como característica que
este instalador es un archivo de extensión .exe que va a poder ser descargado
de la pagina Web del nuestro proyecto y automáticamente generara un acceso
al desarrollo a través del menú inicio de Windows, de esta forma al cliente le
parecerá mas cómodo ejecutar este cliente y hacer uso de los servicios Web
publicados.