Você está na página 1de 86

Tabla de contenido

Pá gi na

LIS T A D E F I GU R AS .................................................................................................................................. III


LIS T A D E T AB L AS ......................................................................................................................................V
IN T R OD UC C IÓN ............................................................................................................................................1
1. 2 M AR C O C O N C E P T U A L ........................................................................................................................3
1. 2 . 1 D e fi ni c ió n d e C o me r ci o E l e c tró n ic o ..........................................................................3
1. 2 . 2 D e fi ni c ió n d e M er c ad o E le c tró ni c o ............................................................................4
1. 2 . 3 D e fi ni c ió n d e s e rv ic io Web .............................................................................................5
1. 2 . 4 T e cn o lo g í as d e Se rv ic io s W e b ......................................................................................7
1. 3 A N T E C E D E N T E S D E L P R O Y E C T O ....................................................................................................8
1. 4 O B J E T I V O S .............................................................................................................................................9
1. 5 J U ST I F I C A C I Ó N Y B E N E F I C I O S .......................................................................................................10
1. 6 O R G AN I Z AC I Ó N D E L D O C U M E N T O ................................................................................................11
R E SU M EN D E T R AB A J OS R EL AC I ON AD OS ...............................................................................12
2. 1 T R AB AJ O S R E L AC I O N AD O S A N I V E L M U N D I A L ........................................................................13
2. 2 T R AB AJ O S R E L AC I O N AD O S E N M É XI C O .....................................................................................18
ES P E C IF IC AC IÓN D E R E QU ER I MIE N T OS ....................................................................................20
3. 1 . 1 Á mb i to ........................................................................................................................................21
3. 2 D E S C R I P C I Ó N G E N E R AL ...................................................................................................................21
3. 2 . 1 P e r sp e c t iv a d el p r od u c to ...............................................................................................21
3. 2 . 2 F un ci o n e s d el p ro to tip o ..................................................................................................21
3. 2 . 3 D e s c ri pc ión d e la s fu n c io n e s ......................................................................................22
3. 2 . 4 P ro c e s o d e pu b li ca c ión d e se rv ic i o s W eb ...........................................................22
3. 2 . 5 P ro c e s o d e re g i s t ro d e a r tíc ulo s ...............................................................................22
3. 2 . 6 P ro c e s o d e re g i s t ro d e s o l ic i tud e s ..........................................................................23
3. 2 . 7 P ro c e s o d e re g i s t ro d e v e n d ed o re s o c o mp ra do re s .....................................23
3. 2 . 8 N iv el e s d e u s ua rio s d el p ro to tip o ............................................................................23
D IS EÑ O D E L P R OYE C T O .......................................................................................................................24
4. 1 E S Q U E M A G E N E R A L D E O P E R AC I Ó N D E L SI S T E M A .................................................................25
4. 2 M Ó D U L O S D E L A AR Q U I T EC T U R A .................................................................................................26
4. 2 . 1 M ód u l o p u bl i ca do r ..............................................................................................................26
4. 2 . 3 M ód u l o R e gi s tro ...................................................................................................................26
4. 2 . 4 M ód u l o In te rm e d ia r io ........................................................................................................27
4. 2 . 5 M ód u l o N o ti fi ca d o r .............................................................................................................29
4. 3 D I S E Ñ O C O N C E P T U A L ......................................................................................................................30
4. 3 . 1 D ia g r am a s d e c as os d e u s o ..........................................................................................30
4. 3 . 2 D ia g r am a s d e A c tiv i d a d ..................................................................................................32
IMP L E ME N T AC I ÓN ....................................................................................................................................37
5. 1 M E T O D O LO G Í A D E D E S A R R O L L O ..................................................................................................38
5. 2 M O D U L O P U B LI C AD O R .....................................................................................................................38
5. 2 . 1 A p i’ s u ti liz a d a s .....................................................................................................................39
5. 2 . 2 Im p l em en ta c ió n d e l Mó d u l o P u b li c ad or ................................................................41
5. 3 M Ó D U L O C O N C I L I AD O R ....................................................................................................................50
5. 3 . 1 A P I´s u t ili z ad a s ....................................................................................................................50

i
5. 3 . 2 D e s c ri pc ión d e la m e to d o lo g í a e m pl e ad a en l a c on c ili a ci ó n ..................52
5. 4 M Ó D U L O N O T I F I C A D O R ....................................................................................................................54
5. 5 M O D U L O D E R E G I S T R O D E C O M P R AD O R E S Y V EN D E D O R E S ................................................54
PL AN D E PR U EB AS ..................................................................................................................................55
6. 1 C ASO 1: C O N T R O L D E A C C E S O D E U SU A R I O S ........................................................................56
6. 2 C ASO 2: A LT A Y E D I C I Ó N D E U S U AR I O S ....................................................................................57
6. 3 C ASO 3: R E G I S T R O D E AR T Í C U L O S D E V EN D E D O R E S ...........................................................59
6. 4 C ASO 4: R E G I S T R O D E AR T Í C U L O S D E C O M P R AD O R E S .......................................................61
6. 5 C ASO 5: P U B LI C AC I Ó N D E S E R VI C I O S W E B D E V E N D E D O R E S ...........................................62
6. 6 C ASO 6: E LI M I N AC I Ó N D E S E R V I C I O S W E B D E V E N D ED O R E S ............................................63
6. 7 C ASO 7: V I S U AL I Z A C I Ó N D E S E R V I C I O S W E B D E V E N D ED O R E S .......................................64
6. 8 C ASO 8: E ST A B L EC E R V Í N C U L O S M E D I AN T E U N C O N C I LI AD O R ........................................64
6. 9 C ASO 9: E N VÍ O D E C O R R E O S E L E C T R Ó N I C O S M E D I A N T E U N M Ó D U L O D E
N O T I F I C A C I Ó N .............................................................................................................................................66
6. 1 0 C AS O 1 0: V I S U AL I Z AC I Ó N D E S E R V I C I O S E N C O N T R A D O S ................................................67
6. 1 1 R E S U M E N D E LO S C AS O S D E P R U E B A ......................................................................................68
C ON C L U S ION E S Y T R AB AJ OS F U T U R OS ...................................................................................70
7. 1 C O N C L U S I O N E S ..................................................................................................................................71
7. 2 T R AB AJ O S F U T U R O S .........................................................................................................................71
8. R E F E R EN C I AS .......................................................................................................................................73

ii
Lista de figuras

Página
Figura 1.1 Esquema de un Servicio Web........................................................................... 6
Figura 2.1 Esquema del funcionamiento del Catalogo Electrónico (AMECE) ......... 19
Figura 4.1 Esquema general del sistema......................................................................... 25
Figura 4.2 Muestra el funcionamiento del módulo publicador ..................................... 26
Figura 4.3 Proceso del módulo de registro.................................................................... 27
Figura 4.4 Diseño conceptual de la Base de Datos ....................................................... 27
Figura 4.5 Muestra el funcionamiento del módulo intermediario.................................. 28
Figura 4.6 Diseño conceptual del repositorio RDF ......................................................... 29
Figura 4.7 Diagrama de casos de uso para el modulo de publicación....................... 30
Figura 4.8 Diagrama de caso de uso del inicio de sesión............................................. 31
Figura 4.9 Diagrama de caso de uso del proceso de artículos .................................... 31
Figura 4.10 Diagrama de casos de uso del módulo intermediario............................... 32
Figura 4.11 Diagrama de casos de uso del módulo notificador ................................... 32
Figura 4.12 Diagrama de actividad del proceso de publicación de una organización y
de sus servicios .................................................................................................................... 33
Figura 4.13 Diagrama de actividad del proceso de búsqueda de una organización y
de sus servicios .................................................................................................................... 34
Figura 4.14 Diagrama de actividad del proceso de registrar artículos ........................ 34
Figura 4.15 Diagrama de actividades del proceso del intermediario........................... 35
Figura 4.16 Diagrama de actividades del proceso de notificación............................... 36
Figura 5.1 Arquitectura JAXR ........................................................................................... 41
Figura 5.2 Clases del paquete núcleo .............................................................................. 42
Figura 6.1 Pagina de acceso al mercado electrónico .................................................... 56
Figura 6.2. Pagina de bienvenida del mercado electrónico .......................................... 57
Figura 6.3 Formulario de alta de vendedores.................................................................. 58
Figura 6.4 Registro insertado dentro de la tabla de vendedores ................................. 59
Figura 6.5 Tabla de vendedores........................................................................................ 59
Figura 6.6 Tabla de productos de los compradores ....................................................... 60

iii
Figura 6.3 Pantalla de cambios a artículos...................................................................... 62
Figura 6.4 Alta de servicios Web ....................................................................................... 63
Figura 6.5 Consulta de los servicios Web........................................................................ 63
Figura 6.6 Consulta de los servicios Web........................................................................ 64
Figura 6.7 Tabla de conciliaciones, muestra las vinculaciones entre los productos. 65
Figura 6.8 Muestra los correos electrónicos recibidos................................................... 67
Figura 6.9 Correo electrónico del usuario comprador.................................................... 68

iv
Lista de tablas

Página
Tabla 5.1 Propiedades estandarizadas en JAXR………………………….43
Tabla 6.1 Análisis de conciliaciones…………………………………………65
Tabla 6.2 Tabla de resumen de los casos……………………………….…68

v
Capitulo I Introducción

6
Ca p ítulo 1

Introducción

Las redes mundiales de información que existen hoy en día están


transformando nuestro mundo y acercándonos más a la gente a través
de avances tecnológicos e innovaciones de las comunicaciones, esto
da origen a cambios en muchas áreas, como lo son: la competitividad,
y la venta de productos, entre otras. Mediante estas nuevas
tecnologías, se han librado obstáculos como el tiempo y la distancia,
debido a que las redes mundiales de información, permiten dirigirnos a
una audiencia masiva, y proporcionan un alcance mundial o local.

1
Capítulo 1 Introducción

El gran interés en el mundo informático, ha permitido la creación


de muchas tecnologías, y esto a su vez, ha permitido la creación de un
nuevo mercado el cual está basado en una economía ahora digital;
donde los productores, proveedores de bienes y servicios, y usuarios
tienen acceso y difusión mundial de la información en forma sencilla y
económica, ya sea con fines comerciales o sociales. Las empresas
que tienen implantados sistemas de comercio electrónico empezaron
hace un poco más de dos décadas con la introducción del intercambio
electrónico de datos (por sus siglas en inglés, EDI). El comercio
electrónico ha evolucionado desde el significado que tenia hace un par
de décadas, hasta el significado actual que abarca todos los aspectos
de los procesos de mercado y empresas de Internet.

Esta evolución ha originado un cambio en el comportamiento de


los diferentes protagonistas (f abricantes, consumidores y
distribuidores) que inciden en el mercado y su ento rno. Lo que ha
propiciado el desarrollo de mercados electrónicos, para obtener una
mayor difusión de las ofertas y demandas de artícul os y/ o servicios.

Internet es la red pública que ofrece un entorno global ideal para


la incorporación de los mercados electrónicos. Sin embargo, aun
existen aspectos importantes que se deben considerar para la
ejecución de mercados electrónicos en Internet. Uno de los aspectos
más relevantes es la interoperabilidad. Para f avorecer la participación
de vendedores y compradores en mercados electrónicos basados en
Internet, se debe incorporar el uso de tecnologías basadas en
estándares de interoperabilidad.

En este trabajo de investigación se presenta el desarrollo de una


arquitectura de un mercado electrónico, en particular se aborda el
problema de la interoperabilidad entre participante s del mercado, y se

2
Capítulo 1 Introducción

of rece una solución para la búsqueda y conciliación entre vendedores


y compradores.

1.2 Marco conceptual

1.2.1 Definición de Comercio Electrónico

Es la aplicación de la avanzada tecnología de información para


incrementar la eficacia de las relaciones empresariales entre socios
comerciales [4].

Es el uso de las tecnologías computacionales y de


telecomunicaciones que se realiza entre empresas o bien entre
vendedores y compradores, para apoyar el comercio de bienes y
servicios [2].

Tipos de Comercio Electrónico.

• Negocio-Consumidor, (B2C) Esta categoría ha tenido gran


aceptación, y se refiere al intercambio de bienes y servicios
entre empresas y clientes.

• Negocio-Negocio, (B2B) Esta clasificación se refiere a una


compañía que hace uso de una red para realizar órdenes de
compra a sus proveedores, recibir f acturas así como realizar los
pagos correspondientes.

A pesar del éxito del B2C en países de alto desarrollo, muchos


analistas coinciden en que estas compras desde el hogar o la
oficina pueden ser eclipsadas por el Comercio Electrónico entre
empresas o B2B. Por ejemplo, el sitio de Comercio Electrónico
editorial para venta de libros de mayor éxito mundial,
amazon.com, vendió aproximadamente 17 millones de dólares en

3
Capítulo 1 Introducción

el 2000. En comparación, las ventas B2B totalizaron más de 180


mil millones, en este mismo año [1].

• Negocio-Administración, (B2A) Se ref iere a todas las


transacciones llevadas a cabo entre las empresas y distintas
organizaciones gubernamentales, se puede decir que esta
categoría está apenas en sus inicios pero conforme el gobierno
empiece a realizar uso de sus propias operaciones, esta
alcanzara su máxima capacidad.

• Consumidor-Administración, (C2A) Esta categoría aun no ha


nacido, sin embargo el gobierno esta realizando extensiones para
efectuar transacciones electrónicas como serian pagos de
asistencia social y devolución de pago de impuestos, un ejemplo
seria el Sistema de Administración Tributaria [1].

• Consumidor-Consumidor, Más recientemente ha surgido un


nuevo tipo de Comercio Electrónico, el C2C (cliente a cliente)
como subastas en línea, donde cualquier particular puede colocar
a la venta un producto en un sitio especial al efecto, el cual
brinda una plataf orma para todos los ciudadanos que deseen
vender directamente sus bienes o artículos. Estos sitios no
necesariamente deben ser comerciales; durante el 2000 uno de
los sucesos de mayor impacto en Internet fue el sitio creado por
universitarios norteamericanos para el intercambio gratuito de
música. En menos de un año obtuvo decenas de millones de
asociados, y recibió una demanda de las casas discográficas,
pero creó un concepto de sistema de distribución descentralizado
aplicable con fines comerciales [1].

1.2.2 Definición de Mercado Electrónico

4
Capítulo 1 Introducción

Los mercados electrónicos por principio se refieren a ventas y


subastas en Internet, por ejemplo, mercados de comercio de
computadoras y otros artículos.

El mercado electrónico se ref iere al nuevo mercado económico


donde los productores, intermediarios y consumidore s interactúan
electrónicamente o digitalmente de alguna forma, donde el mercado
electrónico es un representante virtual de los mercados f ísicos.

El mercado electrónico de manera similar a los mercados físicos,


incluyen los siguientes componentes de la economía digital:

• Participantes (agentes del mercado como empresas,


abastecedores, intermediarios, tiendas y consumidores)

• Productos (artículos y servicios) y

• Procesos (abastecimiento, producción, marketing,


competición, distribución, consumo, etc.)

La diferencia radica en que en el mercado electrónico, éstos


componentes son virtuales, además, los procesos de negociación,
publicidad, entre otros se llevan a cabo mediante agentes; un agente
es un componente de software autónomo el cual es capaz de
comunicarse con otros agentes a través del intercambio de
información.

1.2.3 Definición de servicio Web

Un Servicio W eb es cualquier servicio que se encuentra disponible


sobre la Internet, utiliza un sistema de mensajes XML estándar, y no
está atado a ningún sistema operativo o lenguaje de programación.

5
Capítulo 1 Introducción

Tres propiedades que pueden tener los Servicios W eb, son las
siguientes:

Debe ser auto descriptivo.

Debe ser descubrible.

Debe ser publicable.

Ejemplos de servicios:

Passport de Microsof t, servicio de autentificación. [3]

Servicio de Bolsa de Valores, que regresa el valor o cotización de


una acción de acuerdo a un símbolo designado, por ejemplo:
www.ecobolsa.com.

Servicio de compra, que permite a los usuarios de sistemas de


cómputo adquirir artículos de oficina cuando se proporciona un código
de artículo y una cantidad, por ejemplo: www.ubid.com.

Otra definición de Servicio W eb: Es una interfaz, accesible por


protocolos (estándar o no) usados en Internet, que permite acceder a
las funcionalidades de un objeto concreto, sin importar las tecnologías
ni plataformas implicadas en la petición [3].

1Figura 1.1 Esquema de un Servicio Web

6
Capítulo 1 Introducción

En la Figura 1.1 se muestra el esquema de ejecución de un


servicio W eb. La ejecución de un servicio W eb se inicia cuando un
usuario o programador busca un servicio que cumpla con sus
requerimientos, luego se realiza una invocación del servicio mediante
una descripción, internamente el servicio puede estar formado por uno
o varios procesos, por último se regresa el resultado al proceso
invocador.

1.2.4 Tecnologías de Servicios Web

UDDI (por sus siglas en inglés, Universal Description, Discovery and


Integration). Es un registro de servicio W eb, el cual contiene
información a escala de los servicios prestados. Existen otras
arquitecturas similares a UDDI, por ejemplo ebXML.

Características de las UDDIs:

Provee dos categorías de API:

La API de publicación, provee el mecanismo para que los


proveedores de servicios registren sus servicios en el Registro UDDI.

La API de consulta permite a los subscriptores de servicios


buscar los servicios disponibles. Provee dos tipos de llamadas, un
mecanismo de búsqueda y un mecanismo de obtención, cuando ya se
tiene disponible toda la información referente a la disponibilidad de un
servicio.

ebXML (por sus siglas en inglés, Electronic Business eXtensible


Markup Language). Es un framework que establece las condiciones
para hacer comercio electrónico entre las empresas. Proporciona una
serie de especificaciones, que deberán ser respetadas por el software
y los servicios desarrollados sobre ellas. Se basa en la experiencia

7
Capítulo 1 Introducción

acumulada con el EDI (por sus siglas en inglés, Electronic Data


Interchange), pero también saca provecho de nuevas tecnologías que
usa, como la flexibilidad de XML y la ubicuidad de Internet. Existen
disponibles algunos repositorios como Oasis ebXML.

SOAP (por sus siglas en inglés, Simple Object Access Protocol). En el


núcleo de los servicios W eb se encuentra el protocolo simple de
acceso a datos SOAP, que proporciona un mecanismo estándar de
empaquetar mensajes. SOAP ha recibido gran atención debido a que
facilita una comunicación al estilo RPC (por sus siglas en inglés,
Remote Procedure Call) entre un cliente y un servidor remoto. Un
mensaje SOAP se compone de un sobre que contiene el cuerpo del
mensaje y cualquier información de cabecera que se utiliza para
describir el mensaje.

WSDL (por sus siglas en inglés, Lenguaje de Descripción del Servicio


W eb). Es el lenguaje que servirá para realizar la descripción funcional
y técnica del servicio W eb. Incluirá la declaración de los tipos y
nombres de funciones del servicio Web, así como también su uso, que
se debe esperar de él, con que datos se llama, como se responde e
incluso donde se debe realizar la petición del servicio (URI), es decir
en que localización física se halla el objeto que atenderá la petición
del usuario.

1.3 Antecedentes del pro yecto

El trabajo de investigación que se presenta en esta tesis forma parte


de un proyecto institucional, cuyo objetivo es el de desarrollar
arquitecturas y herramientas de comercio electrónico basadas en W eb,
de alta tecnología y bajo costo. Los trabajos de investigación que
anteceden a esta tesis se describen a continuación:

8
Capítulo 1 Introducción

1. Diseño e implementación de la arquitectura de un sistema de


comercio electrónico para pequeñas y medianas empresas (PY MES).
El resultado de este trabajo de tesis se evaluó mediante el desarrollo
de un prototipo basado en esta arquitectura, integrando componentes
de bajo costo. A este prototipo se le realizaron varias pruebas cuyos
resultados fueron satisfactorios [5].

2. Investigación y análisis de los mecanismos de pago que ofrece la


banca comercial en México. A partir del resultado de esta investigación
se incorporaron varios mecanismos de pago en el desarrollo de un
prototipo de comercio electrónico. Como resultado del trabajo de esta
tesis se presentaron todo un conjunto de pruebas f uncionales,
mediante las cuales se mostró la posibilidad de realizar pagos por
Internet, considerando los aspectos de seguridad que requieren los
bancos para establecer transacciones seguras. Los mecanismos de
pago por Internet que se probaron fueron pago con tarjeta de crédito y
deposito referenciado [6].

3. Implementación de un sistema Intermediario facilitador del comercio


electrónico para PYMES basado en Web. Esta tesis consistió en el
desarrollo de un módulo de software para la publicación y
administración de catálogos de productos para un si tio de comercio
electrónico. Un módulo de una plaza virtual, que incorpora varios sitios
de comercio electrónico, el cual permite la adición de nuevos sitios, la
modificación y su salida del sistema [7].

1.4 Objetivos

Objetivo General
• Diseñar una nueva arquitectura de un sistema de mercado
electrónico que incorpore las funciones de conciliación entre

9
Capítulo 1 Introducción

vendedores y compradores mediante el uso de servici os estándar


de interoperabilidad.

Objetivos particulares
• Diseñar dicha arquitectura mediante sof tware libre .
• Realizar la implementación y pruebas del prototipo basado en la
arquitectura propuesta.

1.5 Justificación y beneficios

Justificación

Aunque se han desarrollado varios sistemas de mercados electrónicos


basados en Internet, aún quedan por resolver aspectos muy
importantes. La investigación y desarrollo que se realice con este fin
debe considerar los factores que se sabe que afectan de manera
importante el proceso de automatización: plataformas de desarrollo
basadas en estándares ínteroperables, lenguajes enriquecidos
semánticamente y su integración en mercados abiertos basados en
Internet [8,9,10,11].

Beneficios
• Acceso a proveedores, productos y servicios.
• Comparación de precios de distintos proveedores.
• Disminución de los tiempos de búsqueda de información.
• Reutilización, interoperabilidad, e integración de aplicaciones
empresariales.
• La conciliación basada en el método por clasif icaciones:
o Facilita una rápida conciliación
o Libera procesos innecesarios

10
Capítulo 1 Introducción

o Realiza mejor filtrado de la inf ormación

1.6 Organización del documento


Este documento se organiza de la siguiente forma: El Capítulo 2
describe los trabajos relacionados que justifican este trabajo. En el
Capítulo 3 se describe la especificación de requerimientos, el cual
especifica las características y requerimientos que debe cumplir este
sistema. En el Capítulo 4 se describe la arquitectura y diseño del
proyecto, los esquemas de operación y módulos del sistema. En el
Capítulo 5 se describe la implementación del sistema, las API’s, y los
métodos requeridos para su desarrollo. En el Capítulo 6 se presentan
las pruebas experimentales desarrolladas en este trabajo de
investigación. En el Capítulo 7 se presentan los comentarios f inales
entre los cuales se incluyen trabajos f uturos.

11
Ca p ítulo 2
Resumen de trabajos relacionados

Se hizo una revisión prof unda de los sistemas de mercados


electrónicos y el entorno de investigación constituido por grupos,
investigadores y universidades. Como resultado se identificaron las
principales diferencias y deficiencias de estos sistemas. En este
Capítulo se presenta un resumen y análisis de los trabajos más
importantes en el área de investigación, identificándose los problemas
abiertos.

12
Capítulo 2 Resumen de trabajos relacionados

2.1 Trabajos relacionados a nivel M undial

Peer to Peer Transactions in Agent-mediated Electronic Comerse


(2001)

Este trabajo propone crear un modelo arquitectónico basado en


agentes, y un sistema activo que muestra el modelo en
funcionamiento. El sistema activo es una colección de agentes de
software independientes que reciben, modifican y re transmiten
mensajes con el objetivo de realizar negociaciones.

Esta arquitectura define un mercado descentralizado controlado por


comerciantes a través de un nuevo protocolo de agentes de
negociación distribuida. Se proponen múltiples agentes que resuelvan
los intereses de los participantes, mediante ciclos para reescribir o
negociar un contrato comprendido de descripciones y términos
flexibles, enfocados a las necesidades de cada comerciante.

Los agentes de este mercado utilizan un protocolo de contrato


sobre red (por sus siglas en inglés, CNP). El CNP es un método para
la coordinación en un sistema de multi agentes. Los agentes de
software buscan recursivamente las partes interesadas y así generan
una red de agentes cooperativos descentralizados. Estos agentes
tienen conversaciones interactivas en lugar de solicitudes uno a uno
para realizar una amplia búsqueda y encontrar términos f avorables. A
través de las búsquedas, los agentes descubren los precios del
mercado, negocian, y realizan todas las actividades de los
participantes [21].

13
Capítulo 2 Resumen de trabajos relacionados

Una limitante de esta arquitectura es que no está basada en el


uso de estándares de interoperabilidad como lo son los servicios W eb,
lo que dificulta la mantenibilidad y reutilización.

MAGM A (por sus siglas en inglés, Minnnesota AGent Marketplace


Architecture): An Agent-Based Virtual Market for Electronic
Commerce (1997)

Es una arquitectura para un mercado virtual basado en agentes, e


incluye todos los elementos requeridos para la simulación real de un
mercado. Estos elementos incluyen una comunicación de
infraestructura, mecanismos para almacenaje y transf erencia de
bienes, banca y transacciones monetarias, y mecanismos económicos
para transacciones directas entre cliente-productor. [8]

MAGMA es un prototipo de un sistema virtual de mercado


electrónico. La implementación consiste de un servidor escrito en
Allegro Common Lisp y un conjunto de agentes escritos en Java que
trabajan sobre la W eb. La actual versión de MAGMA esta diseñada
para trabajar con bienes electrónicos que pueden ser fácilmente
trasferidos sobre la Internet.

MAGMA incluye múltiples Agentes negociantes, un servidor de


publicidad y una banca.

Los agentes negociantes conducen todos sus negocios en el


sistema. Ellos son responsables de comprar y vender bienes y de
negociar precios. El servidor de publicidad provee un servicio
clasificado de publicidad el que incluye búsqueda y recuperación de
anuncios por categoría. La banca provee un conjunto de servicios
básicos de banca que incluye cuenta de cheques, líneas de crédito y

14
Capítulo 2 Resumen de trabajos relacionados

dinero electrónico. Todos los agentes son funcionalmente


independientes y se comunican entre ellos a través de conexiones tipo
socket.

Para facilitar la comunicación entre agentes, se utiliza un


servidor de difusión el que mantiene todas las conexiones de “sockets”
y enruta mensajes entre agentes basados en un único nombre de
agente.

Mientras en este sistema todos los agentes tienen similares


capas de comunicación y son escritos en un lenguaje, MAGMA esta
diseñado para ser un estándar abierto, para conectarse al sistema se
cuenta con la API MAGMA, la cual permite registrarse con el servidor
de difusión, y conducir negocios sobre la infraestructura MAGMA.

Esto permite la posibilidad de crear módulos MAGMA que se


acoplen a sistemas legados desarrollados por banco s (tales como
Oracle, Sybase)

Todos los agentes en la actual versión de MAGMA pueden ser


adaptados con soporte SQL usando el protocolo JDBC. Este activa a
agentes para hacer una interfaz con bases de datos relacionales
existentes, como también con la banca y los catálogos de bases de
datos.

En conclusión, MAGMA es una arquitectura extensible que


provee todos los servicios esenciales para las actividades comerciales.
Estos servicios son libres a través de un estándar abierto de
mensajería API, los cuales nos permiten usar un conjunto de agentes
heterogéneos, independientemente de la plataforma y el lenguaje.

15
Capítulo 2 Resumen de trabajos relacionados

Sin embargo, MAGMA tiene una desventaja, el uso de “sockets”


para la comunicación entre agentes limita la incorporación de otros
agentes negociadores o hace más difícil desde el punto de vista del
programador la incorporación de éstos.

Otra limitante de esta arquitectura es que su extensibilidad no


está basada en el uso de estándares de interoperabilidad lo que
dificulta la mantenibilidad y reutilización.

Kasbah: An Agent Marketplace for Buying and Selling Goods

Es un sistema basado en W eb, donde los usuarios pueden crear


agentes autónomos que compran y venden bienes en lugar del usuario.
El sistema usa un módulo de anuncio donde los agentes publican sus
of ertas en un mecanismo de pizarrón que tienen en común, y se
quedan ahí hasta que obtienen una respuesta. Este es un sistema que
se ejecuta del lado del servidor, lo cual es posible al usar una
combinación de agentes en un mercado [9].

Cuando el usuario crea un nuevo agente vendedor, proporciona


una descripción de los productos que quiere vender.

Los agentes vendedores Kasbah son pro activos, básicamente


tratan de vender por si mismos, contactado a las partes interesadas
(llamados agentes compradores) y negociando con ellos, para así
encontrar el mejor trato.

Un agente vendedor es autónomo, una vez liberado dentro del


mercado, el negocia y toma decisiones propias, sin la intervención del
usuario. Los usuarios tienen alto nivel de control de su
comportamiento, porque el usuario al crear un nuevo agente vendedor,

16
Capítulo 2 Resumen de trabajos relacionados

establece los parámetros que sirven de guía para vender el producto


especificado parámetros para guiarlos y así ellos traten de vender el
producto especificado.

Estos parámetros son:

Fecha deseada para que sea vendido,


Precio deseado,
Precio mas bajo aceptado.

Estos parámetros pueden ser cambiados por el usuario a la hora


que el lo desee.

La desventaja de este sistema es que su arquitectura en su


extensibilidad no está basada en el uso de estándares lo que dificulta
la mantenibilidad y reutilización, para solucionar este problema en esta
propuesta se incorpora el uso de servicios W eb.

Bargain Finder

Es un agente que busca en tiendas de música para encontrar precios


bajos en CDs y casetes. El sistema es esencialmente un motor de
búsqueda base de datos. La compra es limitada para los minoristas
que se suscriben y pagan por remisiones. Los clientes tienen que
conocer y escribir correctamente los nombres de ambos: los artistas y
el álbum. Este sistema esta más orientado hacia los usuarios que
saben lo que quieren de un vendedor [11].

FireFly

17
Capítulo 2 Resumen de trabajos relacionados

Es un agente basado en correo (órdenes de salida). A través de


revisiones, el sistema intenta establecer las preferencias de los
usuarios en estilos de música y artistas. Ofrece al usuario una lista de
CDs conforme a sus preferencias. Este sistema trabaja muy bien
después de cinco minutos de búsqueda (entrando y revisando CDs),
regresa un conjunto completo de miles de álbumes. FireFly es un
buen coleccionador, pero esta limitado a un minorista y no ofrece
mecanismos de comparación de compras [12].

Aunque estos dos últimos sistemas proveen interesan tes


experiencias de compra, muchos otros sistemas simil ares, no alcanzan
a ser un mercado virtual, ya que no incluyen toda la infraestructura y
mecanismos necesarios para el comercio electrónico. En conclusión,
estos sistemas generalmente carecen de facilidades para compras
automatizadas y cooperación entre agentes.

2.2 Trabajos relacionados en México

Catalogalo.com.mx

Es una herramienta para la publicación de catálogos electrónicos a


través de la W eb. Esta herramienta es desarrollada y administrada por
AMECE (Asociación de Estándares de Comercio Electrónico en
México), y se fundamenta en la recomendación del estándar de EAN
Internacional. EAN (por sus siglas en inglés, European Article
Numbering Association) es un sistema internacional que permite la
identificación y comunicación de productos, servicios, unidades de
transporte, asentamientos y locaciones. Los estándares del sistema
son manejados por EAN Internacional a través de una red de
organizaciones nacionales que desarrollan y mantienen estándares de
codificación para todos los usuarios, y tienen en mente el desarrollo de

18
Capítulo 2 Resumen de trabajos relacionados

un estándar global, multisectorial con el objetivo de proveer un


lenguaje común para el comercio [10].

Catalógalo es una gran base de datos a través de Internet que


almacena la información estándar y comercialmente relevante de los
productos de los asociados de AMECE (industria y comercio), validada
y precisa.

La principal desventaja de este catálogo es que no utiliza


estándares de interoperabilidad y requiere que las compañías se
acoplen a un único modelo para el manejo de datos.

2Figura 2.1 Esquema del funcionamiento del Catalogo Electrónico (AMECE)

19
Capítulo 3

Especificación de requerimientos

En este Capítulo, se especifican las características y requerimientos


que debe cumplir el sistema de mercado electrónico.

20
Capítulo 3 Especificación de requerimientos

3.1.1 Ámbito
El sistema de mercado electrónico basado en servicios W eb; que se
describe en esta sección, se puede definir como una aplicación W eb
destinada a realizar búsquedas y conciliaciones entre vendedores y
compradores, es decir facilita la realización de transacciones de
compra-venta dentro de Internet. Esta aplicación fue publicada en
Internet; y se pudieron registrar tanto compradores como vendedores,
permitiendo la agregación de artículos deseados u ofrecidos,
respectivamente. También se pudo realizar la publicación de servicios
W eb ofrecidos, por ejemplo: una cotización de un producto, o algún
método de control de acceso.

3.2 Descripción general

3.2.1 Perspectiva del producto


Como requisito inicial se planteó la necesidad de i mplementar un
sistema de mercado electrónico que incorporara la tecnología de los
servicios W eb; el cual permitiera establecer vínculos entre
compradores y vendedores.

3.2.2 Funciones del prototipo


El sistema de mercado electrónico debe permitir que se realicen las
siguientes funciones principales:

• Registro de vendedores
• Registro de compradores
• Publicación de artículos
• Publicación de servicios W eb
• Monitorear la lista de solicitudes de compra
• Monitorear el registro UDDI de productos y servicios

21
Capítulo 3 Especificación de requerimientos

• Establecer vínculos mediante un servicio entre


vendedores y compradores

3.2.3 Descripción de las funciones


Los compradores y vendedores deben poder interactua r con el
mercado electrónico mediante páginas W eb, de esta manera
ejecutarían cualquiera de las operaciones del sistema.

En cuanto a las operaciones principales que poden realizar el


vendedor y comprador se establecieron las siguiente s:

1. Registrar artículos, para permitir al vendedor dar a conocer los


artículos que desea vender.
2. Registrar solicitudes para permitir al comprador dar a conocer los
artículos que desea.
3. Publicar servicios W eb, para permitir al vendedor dar a conocer
los servicios que está ofreciendo, por ejemplo un servicio de
pedidos de artículos.
4. Visualizar posibles acciones de compra-venta, se refiere a la
acción de dar un recorrido por la página de conciliaciones
encontradas.

Se estableció también que los usuarios del sistema deberían


escoger las operaciones a realizar por medio de un menú de opciones.

3.2.4 Proceso de publicación de servicios Web


Para que el vendedor pueda realizar una publicación de servicios, el
sistema tendrá una opción para agregar servicios; de esta manera se
podrá introducir los datos relacionados al servicio.

3.2.5 Proceso de registro de artículos

22
Capítulo 3 Especificación de requerimientos

Esta función permite al vendedor, registrar el artículo dentro del sitio,


de tal manera que en las siguientes ocasiones en que visite el
mercado, el vendedor podrá localizar interesados en su producto, por
medio de una página en la que se muestran las conciliaciones
encontradas o bien en su cuenta de correo.

3.2.6 Proceso de registro de solicitudes


Esta función permitiría al comprador, registrar las solicitudes dentro
del sitio, de esta manera en las siguientes ocasiones en que visite el
mercado, el comprador podrá localizar a posibles vendedores de ese
artículo o servicio deseado, por medio de una página en la que se
muestran las conciliaciones encontradas o bien en su cuenta de
correo.

3.2.7 Proceso de registro de vendedores o compradores


Esta función permitiría que un usuario del mercado electrónico, pueda
registrarse de manera permanente, de tal forma que en las siguientes
ocasiones en que visite el mercado, pueda proporcionar su nombre de
usuario para que se carguen sus datos.

3.2.8 Niveles de usuarios del prototipo


Se especificaron inicialmente tres tipos de usuarios, que a
continuación se describen.
Administrador. Es el encargado del mercado electrónico, entre sus
funciones se encuentran las de administración y mantenimiento del
mercado electrónico.
Vendedor. Este nivel, se refiere a la persona que entra a la página
para encontrar y realizar posibles ventas.
Comprador. Este nivel, se refiere a la persona que entra a la página
para encontrar y realizar posibles compras.

23
Capítulo 4

Diseño del proyecto

En este Capítulo se presenta el diseño detallado de la arquitectura del


sistema de mercado electrónico que se propuso como desarrollo de
esta tesis. El diseño de un sistema de software es la descripción de la
estructura del software que se va a implementar, los datos que son
parte del sistema y las interfaces entre los componentes del sistema.

24
Capítulo 4 Diseño del proyecto

4.1 Esquema general de operación del sistema

En la Figura 4.1 se muestra la arquitectura general del sistema de


mercado electrónico, esta arquitectura está integrada por varios
módulos:

El módulo de publicación; el cual sirve para realizar altas, bajas, y


consultas de los vendedores y de sus servicios W eb, sobre un registro
público UDDI.
El módulo de registro, tiene la funcionalidad de interactuar con la
base de datos para el registro de compradores, artículos deseados,
cuentas de acceso, entre otros.
El módulo intermediario, se encarga de realizar la conciliación entre
los compradores y vendedores.
El módulo notificación, realiza la notificación de las conciliaciones
encontradas por el intermediario.

3 Figura 4.1 Esquema general del sistema

25
Capítulo 4 Diseño del proyecto

4.2 Módulos de la arquitectura

4.2.1 Módulo publicador

Este módulo tiene como objetivo realizar altas, bajas, consultas de los
vendedores, así como también debe contar con la capacidad de
publicar sus servicios W eb (ver Figura 4.2).

4 Figura 4.2 Muestra el funcionamiento del módulo publicador

4.2.3 Módulo Registro

Este módulo realiza un registro de los datos personales y artículos que


los compradores desean, en otras palabras tiene el objetivo de realizar
las altas, bajas, cambios y consultas referente a la información de los
compradores del m ercado electrónico (ver Figura 4.3 y 4.4).

26
Capítulo 4 Diseño del proyecto

5Figura 4.3 Proceso del módulo de registro

6 Figura 4.4 Diseño conceptual de la Base de Datos

4.2.4 Módulo Intermediario

Este módulo realiza la conciliación entre lo que los compradores


desean y lo que los vendedores ofrecen; la conciliación se realiza en
base a ciertos datos o especificaciones que tengan los productos; tales

27
Capítulo 4 Diseño del proyecto

datos como el precio deseado, el precio mas bajo a aceptar, fecha de


entrega, entre otros. Tiene la capacidad de realizar búsquedas en una
UDDI; debido a que los datos de los vendedores se encontraran ahí,
así como sus servicios W eb (ver Figura 4.5).

7 Figura 4.5 Muestra el funcionamiento del módulo intermediario

28
Capítulo 4 Diseño del proyecto

4.2.4.1 Repositorio de clasificaciones

Este repositorio se encuentra en formato RDF, y tiene la finalidad de


auxiliar al módulo de intermediario, para lograr clasificar a los
productos del mercado electrónico, es decir es un documento en el que
se tiene una lista de sustantivos, y las clasif icaciones para cada uno
de ellos (ver Figura 4.6).

Figura 4.6 Diseño conceptual del repositorio RDF


8

4.2.5 Módulo Notificador

Este módulo se encuentra siempre activo de tal manera que mediante


un servidor de correos; puede estar enviando ciertos mensajes de
notificación para los vendedores y compradores. En este módulo se
notifica sobre la existencia de un posible comprador así como de un
vendedor, respectivamente.

29
Capítulo 4 Diseño del proyecto

4.3 Diseño Conceptual

4.3.1 Diagramas de casos de uso

Dentro de un modelo conceptual basado en UML, podemos reconocer a


los actores que interactúan con este módulo, los cuales están
representados en el diagrama de caso de uso (ver Figura 4.7).

9 Figura 4.7 Diagrama de casos de uso para el módulo de publicación

En el diagrama de casos de uso se pueden apreciar d os actores que


interactúan con la arquitectura: el vendedor y el comprador. El
vendedor realiza la publicación de los servicios que desea hacer
disponible. El comprador consulta en el repositorio UDDI para
conseguir los servicios que se encuentren publicados en el sistema, es
decir, realiza una búsqueda de servicios en base a cierto patrón dado.

30
Capítulo 4 Diseño del proyecto

Figura 4.8 Diagrama de caso de uso del inicio de sesión

El diagrama de casos de uso del módulo registro, muestra que el


vendedor y comprador requieren interactuar con ciertas entidades para
publicar los artículos deseados y ofrecidos respectivamente (ver
Figura 4.9).

Figura 4.9 Diagrama de caso de uso del proceso de artículos

31
Capítulo 4 Diseño del proyecto

Figura 4.10 Diagrama de casos de uso del módulo intermediario

Figura 4.11 Diagrama de casos de uso del módulo notificador

4.3.2 Diagramas de Actividad

Un diagrama de actividad es un diagrama de flujo del proceso de


múltiples propósitos que se usa para modelar el comportamiento.

32
Capítulo 4 Diseño del proyecto

4.3.2.1 Proceso de publicar una organización y sus servicios Web

Este proceso es iniciado por el vendedor, al momento de que desea


registrarse en el repositorio (UDDI), una vez hecho esto, el puede
empezar a publicar sus servicio W eb; para que estén disponibles en el
mercado electrónico (ver Figura 4.12).

Figura 4.12 Diagrama de actividad del proceso de publicación de una organización y de sus
servicios

4.3.2.2 Proceso de búsqueda de organizaciones vendedoras y sus


servicios Web

Este proceso es iniciado por un posible comprador, al momento en el


que desea buscar y ejecutar algún servicio que tenga un vendedor
disponible; por ejemplo, una cotización en una empresa especifica (ver
Figura 4.13).

33
Capítulo 4 Diseño del proyecto

Figura 4.13 Diagrama de actividad del proceso de búsqueda de una organización y de sus
servicios

4.3.2.3 Proceso de registro de artículos

Este proceso es iniciado por un comprador o vendedor, al momento en


el que desea vender ó comprar respectivamente. De esta manera, se
hace disponible el artículo dentro del mercado electrónico (ver Figura
4.14).

Figura 4.14 Diagrama de actividad del proceso de registrar artículos

34
Capítulo 4 Diseño del proyecto

4.3.2.4 Proceso del intermediario

Este proceso es iniciado por el módulo intermediario, al momento en el


que es activado. En este momento, empieza a buscar posibles
transacciones de compra-venta (ver Figura 4.15).

17 Figura 4.15 Diagrama de actividades del proceso del intermediario

4.3.2.5 Proceso del notificador

Este proceso es iniciado por el módulo notificador, al momento en el


que es activado. En este momento, empieza a verificar en la tabla de
espera, para comenzar a enviar las notif icaciones de conciliación a las
partes interesadas en el proceso de compra-venta. (ver Figura 4.16)

35
Capítulo 4 Diseño del proyecto

Figura 4.16 Diagrama de actividades del proceso de notificación

36
Ca p ítulo 5

Implementación

En este Capítulo se describe la metodología utilizada para la


implementación del mercado electrónico, así como las herramientas de
desarrollo de software y las tecnologías empleadas durante esta f ase.

37
Capítulo 5 Implementación

5.1 Metodología de desarrollo

Existen diversas metodologías para el desarrollo de software, las


cuales pueden ser utilizadas de acuerdo a las necesidades y
requerimientos del sistema.

Durante muchos años, el proceso de diseño del producto en cascada


ha sido el modelo estándar. Mediante este proceso, el proyecto
atraviesa una serie de fases secuenciales y no lineales. Asimismo,
utiliza hitos como los puntos de transición y valoración y asume que se
han completado todos los pasos anteriores antes de pasar a la
siguiente fase. El método en cascada puede resultar muy eficaz en un
proyecto complejo en el que varios proveedores son responsables de
distintos aspectos de dicho proyecto (por ejemplo, un proveedor se
encarga del análisis de requisitos, otro de la especificación, etc.). Sin
embargo, la utilización de este método se complica según se avanza y
se descubren los cambios que se deben efectuar [20].

Por el contrario, el proceso de diseño del producto en espiral es


iterativo y cíclico. Este proceso permite una mayor creatividad y facilita
la realización de cambios según se avanza. En parti cular, para el
desarrollo de este sistema de mercado electrónico se utilizó el método
en espiral, debido a que se podrá estar en distintas fases para
diferentes áreas funcionales del producto, cuenta con fases tales como
previsión, planificación, prototipos, desarrollo, estabilización y
preparación [20].

5.2 Modulo Publicador

38
Capítulo 5 Implementación

5.2.1 Api’s utilizadas


Para el implementación de este módulo se utilizaron dos APIS de Java:
JAXR y UDDI4J. A continuación se muestra su funcionamiento:

5.2.1.1 API’s de Java para registros XML


La API de Java para registros XML proporciona una manera
estandarizada para realizar accesos a diferentes clases de registros
XML. Un registro XML es una infraestructura que permite la
construcción, deposito y descubrimiento de servicios Web. Dentro de
la arquitectura propuesta para el desarrollo de un Mercado Electrónico,
el registro corresponde a una parte neutral ó central que permite el
acoplamiento dinámico de Negocios a Negocios (B2B) [19].

Actualmente existen una variedad de especificaciones para


registros XML, estas incluyen las siguientes:

Con formato: Numeración y


• El registro ebXML y repositorio estándar, el cual es patrocinado viñetas

por la Organización para el avance de la información


estructurada (OASIS) y el Centro de Naciones Unidas para la
Facilitación de Procedimientos y Practicas en Administración,
Comercio y Transporte. (U.N./CEFACT)
• El proyecto UDDI, el cual esta siendo desarrollado por miembros
del consorcio W 3C.

Un registro proveedor es una implementación de un registro de


negocios que se conf orma por unas especificaciones para registros
XML.

5.2.1.2 API de Java para registros (JAXR)

39
Capítulo 5 Implementación

Es un conjunto de clases para el acceso a registros XML para los


programadores de Java, que permite escribir en registros mediante la
creación programas del lado cliente. La actual especificación de JAXR
incluye f unciones especificas para registros ebXML y UDDI [19].

Mediante el uso JAXR los negocios pueden registrar sus


productos o servicios que deseen vender, o puedan localizar servicios
o productos de otros negocios que deseen comprar.

La arquitectura JAXR consiste de las siguientes partes:

Con formato: Numeración y


• Un cliente JAXR: Un programa cliente que usa la API JAXR para viñetas

el acceso a registros de negocios vía proveedor JAXR.


• Un proveedor JAXR: Una implementación de la API JAXR que
proporciona un acceso a un proveedor de registro.

Un proveedor JAXR implementa dos paquetes principales:

Con formato: Numeración y


• javax.xml.registry, el cual consiste de un conjunto de viñetas

interfases API y clases que definen los accesos a registros.


• javax.xml.registry.infomodel, el cual consiste de interfaces
que definen el modelo de la información para el JAXR.
Estas interfaces definen los tipos de objetos que residen en
un registro y como se relacionan unos con otros. La interfaz
básica en este paquete es la interfaz RegistryObject.

Las interf ases basicas en el paquete javax.xml.registry son:

Con formato: Numeración y


• Connection. La interfaz Connection representa una sesión viñetas

cliente con un proveedor de registros, es decir el cliente debe

40
Capítulo 5 Implementación

crear una conexión con el proveedor JAXR para poder usar un


registro.
• RegistryService. El cliente obtiene un objeto RegistryService a
partir de su conexión, en otras palabras este objeto permite al
programa cliente obtener las interfaces necesarias para acceder
al registro.
• BusinessLifeCycleManager. Permite al cliente realizar búsquedas
en un registro.
• BusinessLifeCycleManager. Permite al cliente poder realizar
modificaciones de la información que se encuentra alojada en el
registro (ver Figura 5.1).

Figura 5.1 Arquitectura JAXR

5.2.2 Implementación del Módulo Publicador

Para la implementación del módulo publicador, se utilizo la tecnología


JSP (por sus siglas en inglés, Java Server Pages), el paquete JW SDP
(por sus siglas en inglés, Java W eb Services Developer Pack) y las
API’s de Java como lo son: JAXR, y UDDI4J.

41
Capítulo 5 Implementación

Se desarrollo el paquete núcleo; el cual contiene las clases


necesarias para realizar una interacción con un servidor UDDI (ver
Figura 5.2).

Figura 5.2 Clases del paquete núcleo

En esta sección se van a describir brevemente algunas funciones


necesarias para la implementación del paquete núcleo; mediante
estas funciones se lograron realizar búsquedas, actualizaciones sobre
un registro UDDI, entre otras; el paquete núcleo es un conjunto de
clases requeridas para acceder al repositorio, usando las API’s JAXR y
UDDI4J.
Para crear una conexión, el cliente debe crear un conjunto de
propiedades que especifiquen la dirección URL del registro. Por
ejemplo, el siguiente código proporciona la URL del servicio de
búsqueda y publicación para un registro local. (usando el JW SDP)

Proper ties props= new Properties();

42
Capítulo 5 Implementación

props .setProper ty(“j avax .xml.registry.q ueryManagerURL”,


“http ://loca lho st:8080/Reg is tryServer /”);
props .setProper ty(“j avax .xml.registry.lifeCycleManagerURL ”,
“http ://loca lho st:8080/Reg is tryServer /”);

Luego, el cliente debe fijar las propiedades para la crear la


conexión:

connF ac tory.se tProp erties(pr ops) ;


Connec ti on co nectar = con nFactory.crea teConnection() ;

JAXR permite fijar un número de propiedades para una conexión.


Algunas de estas son propiedades estándares definidas en la
especificación de JAXR. En la siguiente tabla se muestran algunas
propiedades estándares:

Tabla 5.2 Propiedades estandarizadas en JAXR


Nombre de la propiedad y descripción Tipo de
dato
javax.xml.regitry.queryManagerURL
Especifica la URL del servicio manejador de Cadena
búsquedas.
javax.xml.registry.lifeCycleManagerURL Cadena
Especifica la URL del servicio manejador del ciclo de
vida. (para realizar actualizaciones)
javax.xml.registry.security.authentication-
Method Cadena
Proporciona una marca al proveedor JAXR sobre el
método de autentificación.
javax.xml.registry.uddi.maxRows
El numero máxima de filas a ser regresado por una Entero
búsqueda.

43
Capítulo 5 Implementación

javax.xml.registry.postalAddressScheme
El identificador de un ClassificationScheme a ser Cadena
usado como un esquema de dirección postal por
defecto.

Después de crear la conexión, en el paquete núcleo se usa la


conexión para obtener un objeto RegistryService, es decir:

RegistryService rs = conectar.g etRegi stryService();


Bus inessQ ueryMan ager bqm = rs .g etBusi ness Query Ma nag er();
Bus inessL ifeCycle Manag er blcm = rs.getBusinessLifeCycleManager();

Normalmente, se obtiene el objeto BusinessQueryMana ger y el


BusinessLifeCycleManager; donde una será usada para realizar
solamente consultas y la otra para realizar actuali zaciones,
respectivamente.

A continuación, se muestran las funciones principales dentro del


paquete núcleo:

1. Búsquedas de organizaciones

Para realizar búsquedas de organizaciones por nombre, primero se


utiliza una combinación de propiedades (especifican el orden de la
búsqueda) y patrones de nombre (especifican las cadenas a ser
buscadas). El método findOrganizations toma una colección de
objetos findQualifier. A continuación muestro un fragmento de código
para ilustrar una búsqueda de todas las organizaciones dentro de un
registro, ordenadas alfabéticamente:

//se defin en las pro pied ades de bú squed a y p atrones de bú sq ueda.

44
Capítulo 5 Implementación

Collection bu sque daPropied ades = ne w ArrayL is t();


busqu edaPropiedade s.a dd(FindQuali fier .SORT_ BY_N AME_D ESC);
Collection no mbr ePa tron es = new ArrayL ist() ;

// donde % es un c ualq uier patrón


nombrePatr ones.add(“%”) ;

//bús queda usando e l nombre de l a orga ni zación


Bul kRespo nse res pu esta =
bqm.findOrga ni za tio ns(busq ued aPro pi ed ades,nombrePatr one s,null ,nu ll ,nul l,
null) ;
Collection orgs= res puesta.getCol lection ();

Para realizar una búsqueda de organizaciones de acu erdo a su


clasificación, se requiere establecer la clasificación dentro de un
esquema de clasificaciones particulares y entonces se especifica la
clasificación como un argumento al método findOrganizations.

El siguiente fragmento de código muestra como encontrar todas


las organizaciones correspondientes a una clasificación:

Class ific ationScheme c Sch eme =


bqm.findC lass ificatio nSchemeByName(nu ll ,”n tis-g ov :na ics”);
Class ific ation clasifi caci on =
blcm.crea teC lassi fication(cScheme,”Computador as ”,”8 00 304 ”);
Collection c lasi ficaci ones = ne w ArrayLis t();
Clasi fica ci ones.add(clasi ficacion);

//se rea li za u na pe tició n JAXR .


Bul kRespo nse res pu esta =
bqm.findOrga ni za tio ns(nu ll ,null,clasifica ciones ,nu ll,nul l,null);
Collection orgs = respuesta .getC ol lection();

45
Capítulo 5 Implementación

2. Encontrar los servicios W eb

Después de que un cliente tiene localizada a una organización, se


pueden localizar los servicios W eb que tiene la organización, así como
los enlaces que tiene asociados.

A continuación se muestra un f ragmento del código necesario:

Itera tor org Iter = orgs.iterator();


while (orgIter.hasNext() )
{
Organiza tion org = (Organiza tion) orgIter .ne xt() ;
Coll ec ti on servicios= org.g etServ ic es();
Iterator svcIter = servic ios.iterator() ;
wh il e (svcIter.hasNe xt())
{
Serv ice svc = (Ser vi ce) svcIter.nex t();

Sys te m.out.println(“Nombre del Servicio :” + getName(svc)) ;


Sys te m.out.println(“Descripc ió n:” + ge tD escriptio n(svc)) ;
Coll ec ti on servicio Enla ces = svc .ge tService Binding s();
Iterator sbIter = serv icioEnl aces .i tera tor();
While (sb Iter.hasNext())
{
Service Binding sb = (ServiceBinding) sbIter.next();
System.ou t.prin tl n(“URI:” + g etAcc essUR I());
}

}
}

46
Capítulo 5 Implementación

3. Publicación de una Organización

Para realizar actualizaciones sobre el registro se requiere que el


programa cliente tenga autorización, es decir el cliente debe de enviar
el nombre del usuario y clave al registro. En el siguiente fragmento de
código se ilustra como realizar esto:

Str ing usuar io = “arc turus”;


Str ing cla ve = “c la ve ”;

//para c onseguir autori za ci ón de l registro.


PasswordAu the ntication cla veAuth = new
PasswordAu the ntication( usuar io ,clave.to CharArray());

Set creds = new H ashSet();


Creds.a dd(clav eAu th);
conectar.setCredentials(creds);

En la arquitectura propuesta, se planean crear organizaciones en


el registro, las cuales representan a los vendedores que se
encuentran registrados en nuestro mercado electrónico. Dentro de la
API JAXR existe un objeto Organization, el cual es uno de los más
complejos, y se conf orma de:

Con formato: Numeración y


• Un objeto Name, viñetas

• Un objeto Description,
• Un objeto Key, este representa el identificador, es decir la
clave con la que es conocida la organización. Es importante
decir que esta clave es creada por el registro de f orma
automática y no por el usuario,

47
Capítulo 5 Implementación

• Un objeto PrimaryContact, se refiere al contacto dentro de


la organización, y incluye datos como el nombre de la
persona, teléfono, dirección de correos, código postal,
• Una colección de objetos Classification, y
• Un objeto Service y sus objetos enlaces.

A continuación, se muestra un fragmento de código que ilustra


como se crea una organización:

//crea u na no mbr e d e organi za ci ón


Organ izatio n org = blcm.crea teOrga ni za ti on(“Comp uPar tes”);
In tern ac ionalStrin g s = b lcm.crea te InternationalString(“Ven ta de equipo de
computo ”);
org.setDescripti on(s) ;

//crea u n con ta cto pr imari o


User con ta ctoPrimario = blcm.cr ea teU ser();
PersonNa me pNo mbre= b lcm.crea te Pers onName(“Mar isol C. Acosta”) ;
contactoPri mar io .setPersonNa me( pNomb re);

//fija numero telefoni co


Tel ephoneNu mber tNum= blc m.cre ateTelep hon eNumber();
tNum.s etNu mber(“(01 6 64) 554-6912”);
Collection te le fon oNumer o = n ew Arra yLi st() ;
te le fonoNumero .ad d( tNum) ;
contactoPri mar io .setTel eph oneNumbers(tele fo noNu mero);

//fija dirección de c orreo el ectrón ico


Ema ilAddress email Direccion=
blcm.crea teEmailAd dress(“mar_sol@corr eo.net”);
Collection e mailD irecciones = new ArrayLis t() ;
emai lD irecci ones.ad d(emai lDireccion);

48
Capítulo 5 Implementación

contactoPri mar io .setEmai lAddresses(emailD irecciones) ;

//se co lo can los d ato s del con tacto e n organi zación


org.setPr imaryContact(contac to Primario) ;

Una vez que contamos con la organización vendedora en nuestro


registro, podemos agregarle servicios W eb. De la misma manera que
un objeto Organization, el objeto Service tiene un nombre, una
descripción y una llave, la cual es generada por el registro al momento
de ser el registrado.

49
Capítulo 5 Implementación

5.3 Módulo conciliador

5.3.1 API´s utilizadas

Para la implementación de este módulo se utilizaron dos API’s de la


W eb Semántica sobre la plataf orma J2EE como son: Jena y Sesame.

La W eb Semántica, pretende desarrollar lenguajes que faciliten


la inclusión en la W eb de contenido legible por las máquinas, como por
ejemplo sistemas basados en catálogos o en palabras clave, sistemas
automáticos de obtención y gestión de información, sistema de
búsqueda autónoma que informa cuando encuentra algo interesante,
entre otros [18].

A continuación se describen las herramientas y API’s em pleadas:

RDF (por sus siglas en inglés, Resource Description Framew ork)

Es una recomendación del W 3C para la formulación de meta datos en


la W eb, se trata de un modelo para definir relaciones semánticas entre
distintas URI’s (por sus siglas en inglés, Identificador Uniforme de
Recursos). RDF esta basado en la sintaxis de XML, y permite describir
semánticamente una URI asociándole un conjunto de propiedades y
valores. Los meta datos especificados con RDF son compresibles por
las máquinas, y por tanto, procesables de forma automática [15].

Ejemplo: canario es de color amarillo

<rdf:RDF xmlns:rd f="h ttp ://www.w3 .org /1 999 /02 /22-rd f-syn ta x-ns# "
xmlns:s="h ttp://w ww. sentidos.net/"

50
Capítulo 5 Implementación

<rdf:Descri ption abo ut=”h ttp ://miDire ccio n/# canario ">
<s:tieneCo lor >Amar il lo </s:tieneColor>
</rd f:D es criptio n>
</rd f:R DF>

Sesame

Esta herramienta constituye un importante avance que va mas allá de


la f orma actual de almacenar y consultar en RDF, dado que es la
primera implementación pública para la semántica de RDF Schema.

Es necesario resaltar la característica de la arquitectura Sesame


que permite su implementación en una gran variedad de repositorios,
ya sea en bases de datos relacionales, almacenamiento de Triplas
RDF o a nivel remoto, debido a la independencia en relación al DBMS.

Dentro de esta implementación, Sesame fue una aplicación


basada en servidor, y por lo tanto puedo ser usado como un servicio
remoto de almacenamiento y consulta en la W eb Semántica [17].

Jena

Es desarrollado en los laboratorios de la HP. Jena es una Api de Java


para manipulación de modelos RDF, soporta análisis, procesamiento y
escritura de RDF con soporte para DAML+OIL (por sus siglas en
inglés, DARPA Agent Markup Language) y OW L (por sus siglas en
inglés, W eb Ontology Language). Mediante esta API se pueden crear
clases, subclases, propiedades, y definir dominios, rangos y
cardinalidades para poder definir ontologías [16].

51
Capítulo 5 Implementación

Dentro de esta implementación, Jena fue una API utilizada para


la creación del documento RDF que contiene las clasif icaciones de los
productos.

5.3.2 Descripción de la metodología empleada en la conciliación

La distinción entre forma y materia juega un papel muy importante,


cuando nos disponemos a describir como nosotros reconocimos las
cosas en el mundo. Por el solo hecho de reconocer algo, nosotros
ordenamos las cosas en distintos grupos o categoría s.

Es decir, cuando vemos un caballo, luego vemos otro caballo, y


otro más. Los caballos no son completamente idénticos, pero tienen
algo en común, algo que es igual para todos los caballos, y
precisamente eso que es igual para todos los caballos, es lo que
constituye la f orma del caballo. Lo que es diferente o individual,
pertenece a la materia del caballo.

De esta manera nosotros andamos por el mundo clasificando las


cosas en distintas categorías o clasificaciones. Colocando los libros en
las estanterías, los libros de la escuela en la mochila, etc.

Con base a esta lógica, se creo una solución para el módulo


conciliador, el cual es el encargado de realizar conciliaciones entre
productos y/o servicios considerando la descripción y la forma del
producto. Para esto se creo un repositorio RDF de categorías el cual
permite clasif icar a los productos del mercado electrónico y para
poder lograr una mejor conciliación entre productos escritos distintos
pero con el mismo signif icado, se creo una tabla de sinónimos la cual
se construyo bajo MySQL, principalmente por la rapidez que nos brinda
este manejador.

52
Capítulo 5 Implementación

La solución dada para poder realizar una conciliación adecuada,


es decir no realizar una conciliación de cadena a cadena, fue el
empleo del algoritmo de Levenshtein.

El algoritmo de cálculo de distancia de Levenshtein consiste en


calcular las diferencias léxicas, y ha sido usado en:
– Chequeo ortográfico
– Reconocimiento de dictado
– Análisis de ADN
– Detección de plagios

La distancia es el número de inserciones, eliminaciones, o


substituciones requeridas para transformar s en t.

Por ejemplo:

• Si s es "prueba" y t es "prueba", entonces DL(s,t) = 0, porque no


se requieren transformaciones.

• Si s es "prueba" y t es "trueba", entonces DL(s,t) = 1, porque


solo una substitución es requerida para transformar s en t.

Al algoritmo de Levenshtein, se le agrego el uso de una tabla de


sustantivos, con la finalidad de realizar unas comparaciones con un
grupo de palabras léxicamente cercanas, sobre los productos y/o
servicios que se desean conciliar.

A continuación se muestra el Pseudo código del conciliador

Tomar la s palabras descriptivas de ta bl a co mpra s


Hacer mientras se tengan re gistro s ac tua les

53
Capítulo 5 Implementación

Real izar el procedimien to de fi ltro de p al abras


Real izar so ndeo de palabra descr ip tiva con tab la sus tan tivos
Tomar clasifica ciones e n base a palabra descriptiv a y palabr as
si mi lares
Depurar cl asificacio nes
Tomar artículos de tabla ventas en base a c lasi ficaciones
Hacer mien tras se te ngan regis tro s de ve nta s
Comparar cada pala bra descriptiva d e co mpras con palabra
descr ip tiva de venta
(Usando el algoritmo de c al cu lo de dis tancia auxiliado de u na tabla de
sinón imos)
Si existe s imili tud en tre l os reg istros
R eali zar i nserc ió n e n tabla de no ti fi cación
Fin si
Fin de hacer mientras
Fin d e hac er mientras

5.4 Módulo notificador

Este módulo se encarga de realizar la notificación de las partes


interesadas, el notificador toma de la tabla notifi cación los registros
que aun no han sido enviados, y a través de un servidor de correo,
realiza un envió de mensajes electrónicos.

5.5 Modulo de registro de compradores y vendedores

Este módulo se encarga de realizar altas, bajas, consultas y


modificaciones de los compradores y vendedores del mercado
electrónico a través del JDBC de java, las operaciones realizadas se
ven reflejadas en la base de datos, cuyo manejador de base de datos
empleado es el postgresql.

54
Capítulo 6

Plan de pruebas

En este Capítulo se describen los casos de prueba que se realizaron al


mercado electrónico. Para cada caso se presenta su objetivo, el
procedimiento que se siguió, datos de entrada y las pantallas de los
resultados obtenidos.

55
Capítulo 6 Plan de pruebas

6.1 Caso 1: Control de acceso de usuarios

Objetivo

Mostrar que el sitio realiza un control de acceso, verificando el registro


del comprador o vendedor, antes de que se pueda realizar cualquier
movimiento en el m ercado electrónico.

Procedimiento

1. Teclear el nombre de usuario previamente obtenido


2. Teclear la clave de acceso
3. Dar clic en el botón de entrar (ver Figura 6.1)

En la Figura 6.1 se muestra la página donde se solicita el nombre


de usuario y clave de acceso, para tener acceso al mercado
electrónico.

Figura 6.1 Pagina de acceso al mercado electrónico

Resultado

En la Figura 6.2 se muestra la página presentada al introducir


correctamente el nombre del usuario, y clave de acceso.

56
Capítulo 6 Plan de pruebas

Figura 6.2. Pagina de bienvenida del mercado electrónico

6.2 Caso 2: Alta y edición de usuarios

Objetivo

Comprobar que se cumple el requerimiento de dar de alta, recuperar y


modificar los datos previamente registrados de los usuarios.

Caso 2.1 Alta de usuarios

Procedimiento

1. Se oprime el botón de darse de alta de vendedores o


compradores
2. Se llena la pagina presentada con los datos apropiados
3. Se oprime el botón de dar de alta (ver Figura 6.3)

Este es un ejemplo de los datos que se introducen:

Login: perez
Clave: perez

57
Capítulo 6 Plan de pruebas

Nombre contacto: Arturo


Apellido paterno: Perez
Apellido materno: Cebreros
Pais: Mexico
Estado: Sinaloa
Rfc: pecj800304bn07
Curp: pecj800304hslrbn07
Nombre Empresa: Cenidet Inc.
Calle: Apatzingan
Numero Interior: 1546
Colonia: Palmira
C.P.: 62756
Municipio: Cuernavaca

Figura 6.3 Formulario de alta de vendedores

Resultado

El resultado del alta de un vendedor realizada en el mercado


electrónico, se puede apreciar en la Figura 6.4

58
Capítulo 6 Plan de pruebas

Figura 6.4 Registro insertado dentro de la tabla de vendedores

Caso 2.2 Edición de usuarios

Procedimiento

1. Se entra al mercado electrónico


2. Se oprime el botón editar
3. Se devuelven los datos previamente registrados
4. Se realizan modif icaciones sobre los datos
5. Se oprime el botón actualizar

Resultado

Para la comprobación de este caso, se sustituyo el campo de


estado de Sinaloa a Sonora. El resultado de esta modificación
realizada sobre un campo en especif ico, se puede apreciar en la
Figura 6.5.

Figura 6.5 Tabla de vendedores

6.3 Caso 3: Registro de artículos de vendedores

Objetivo

59
Capítulo 6 Plan de pruebas

Comprobar que el sistema permite registrar todos los artículos que los
vendedores desean of recer en el mercado.

Procedimiento

1. Entrar al mercado electrónico, como usuario vendedor


2. Teclear los datos del articulo
3. Dar clic en el botón de agregar

Se introducen los siguientes datos:

Nombre del artículo: monitor


Descripción del articulo: monitor LCD de 15 pulgadas
Existencia: 15
Precio: 5000
Precio mas bajo aceptado: 4500
Ubicación: Aguascalientes
Fecha de inicio: 2005-04-07
Fecha de f in de búsqueda: 2005-04-28

Resultado

En la Figura 6.6, se muestra la tabla de productos de los


vendedores, donde se puede apreciar el registro previamente
insertado.

26 Figura 6.6 Tabla de productos de los compradores

60
Capítulo 6 Plan de pruebas

6.4 Caso 4: Registro de artículos de compradores

Objetivo

Comprobar que el sistema permite registrar todos los artículos que los
compradores desean adquirir.

Procedimiento

• Entrar al mercado electrónico, como usuario comprador


• Teclear los datos del artículo
• Dar clic en el botón de agregar

Se introducen los siguientes datos:

Nombre articulo: monitor


Descripción del artí culo: monitor LCD
Cantidad solicitada: 1
Precio: 4500
Precio mas alto aceptado: 5000
Ubicación: Aguascalientes
Fecha de inicio: 2005-04-07
Fecha de f in de búsqueda: 2005-04-28

Resultado

En la Figura 6.3, se muestra la pantalla de cambios de artículos


previamente registrados donde se comprueba que se ha realizado
correctamente el registro de los datos presentados anteriormente.

61
Capítulo 6 Plan de pruebas

27 Figura 6.3 Pantalla de cambios a artículos

6.5 Caso 5: Publicación de servicios Web de vendedores

Objetivo

Mostrar que el sistema permite publicar servicios W eb en el directorio


de servicios.

Procedimiento

• Entrar al mercado electrónico, como usuario vendedor


• Teclear los datos referentes al servicio
• Dar clic en el botón de agregar

Datos de entrada:

Nombre del servicio W eb: Pedido


Descripción: Realiza un pedido de productos
URI: http://www.cenidet.edu/mercado/pedido.asmx

62
Capítulo 6 Plan de pruebas

Figura 6.4 Alta de servicios Web

Resultado

En la Figura 6.5, Se muestra una consulta de los servicios W eb


el cual comprueba su previo registro.

Figura 6.5 Consulta de los servicios Web

6.6 Caso 6: Eliminación de servicios Web de vendedores

Objetivo

Verificar que el sistema permite la eliminación de un servicio en el


directorio de servicios.

Procedimiento

5. Entrar al mercado electrónico, como usuario vendedor


6. Oprimir el botón de mostrar servicios W eb
7. Dar clic en el botón de eliminar servicio

63
Capítulo 6 Plan de pruebas

Resultado

En la Figura 6.6, se muestra una consulta de los servicios W eb,


el cual muestra la eliminación del servicio llamado pedido.

Figura 6.6 Consulta de los servicios Web

6.7 Caso 7: Visualización de servicios Web de vendedores

Objetivo

Verificar que el sistema permite realizar la consul ta de los servicios


W eb disponibles para la organización.

Procedimiento

Entrar al mercado electrónico, como usuario vendedor


Dar clic en el botón de mostrar los servicios W eb

Resultado

En la Figura 6.5, mostrada anteriormente se comprueba la


funcionalidad de la consulta de servicios W eb.

6.8 Caso 8: Establecer vínculos mediante un conciliador

64
Capítulo 6 Plan de pruebas

Objetivo
Verificar que el módulo conciliador realiza la vinculación entre los
productos ofrecidos por el vendedor y los deseados por el comprador.

Procedimiento

1. Ejecutar el módulo conciliador


2. Verificar la tabla de notif icación para ver los resultados

Resultado
En la Figura 6.7, se puede verificar las conciliaciones
encontradas entre los productos de vendedores y compradores.

Figura 6.7 Tabla de conciliaciones, muestra las vinculaciones entre los


productos

Las pruebas del proceso conciliador mostraron satisf actoriamente


que en una conciliación cadena a cadena no hubiera sido posible
encontrar ninguna vinculación. Se muestra que entre chamarras, trajes
y relojes encontró una similitud, esto se debe a que en el árbol de
clasificaciones se tiene una rama en común (ver Tabla 6.1).
Tabla 6.1 Análisis de conciliaciones
Descripción de Peticiones Porcentaje
vendedor del de
comprador similitud
Monitor crt a
colores de 15 Monitor lcd 75
pulgadas
Monitor lcd de 15
Monitor lcd 100
pulgadas

65
Capítulo 6 Plan de pruebas

Monitor crt a
colores de 15 Monitor crt 100
pulgadas
Monitor lcd de 15
Monitor crt 75
pulgadas
Batería para Batería de
75
celulares rock
Batería para Bateria de
80
tocar musica rock
Playstation
Playstation 2 negra version 80
2
Mueble de
Mueble ejecutivo 88
piel ejecutivo
Batería para Teléfono
75
celulares celular
Teléfono
Teléfono con fax 75
celular
Teléfono con
Teléfono con fax 88
fax incluido
Chamarras muy Relojes
50
elegantes1 marca casio
Trajes de baño Relojes
50
para mujer marca casio
Relojes para
Relojes
caballero marca 100
marca casio
Casio

6.9 Caso 9: Envío de correos electrónicos mediante un módulo de


notificación

Objetivo

Mostrar que el módulo de notificación toma los datos conciliados y


envía los correos electrónicos a las partes interesadas.

Procedimiento

Levantar el servicio de correo electrónico


1
En la Tabla 6.1 se obtuvo una similitud de 50 puntos, debido a que ambos artículos tienen en comun una rama
del arbol de clasificaciones.

66
Capítulo 6 Plan de pruebas

Ejecutar el módulo notificador


Verif icar en las cuentas de correos de las partes vinculadas

Resultado

En la Figura 6.8, se puede apreciar que los correos electrónicos


de las vinculaciones son recibidos en las cuentas electrónicas
previamente registradas.

Figura 6.8 Muestra los correos electrónicos recibidos

6.10 Caso 10: Visualización de servicios encontrados

Objetivo

Mostrar que el comprador recibe en su cuenta de correo las


conciliaciones encontradas.

Procedimiento

El comprador verif ica su cuenta electrónica


Dar clic en la liga dada
Se visualizan los servicios del vendedor

67
Capítulo 6 Plan de pruebas

Resultado

En la Figura 6.9, se muestra el correo electrónico recibido por el


usuario comprador, donde se proporciona una liga para una
visualización de los servicios W eb del vendedor

Figura 6.9 Correo electrónico del usuario comprador

6.11 Resumen de los casos de prueba

Tabla 6.2 Tab la de resumen de los caso s


Caso d e prue ba Descripc ió n R esul tad o
Caso 1 Autentific ac ión d e Se comprobó qu e se
usuar ios realiza una va lida ci ón
de usuario y c la ve ,
antes de e ntrar al
mercado elec tró nico
Caso 2 Alta y e di ci ón de Se comprobó qu e el
usuar ios sis tema reali za al tas y
modificaciones de lo s
usuar ios. (ven ded or es
y compr adore s)
Caso 3 Registro de artíc ul os Se comprobó qu e el
de vended ores sis tema p ermite
registrar tod os los
productos de los
vendedores
Caso 4 Registro de artíc ul o Se comprobó qu e el
de comprad ores sis tema d io d e a lta
todos l os ar tícu los d e
los compradores
Caso 5 Pub licación de Se comprobó qu e el
servicio s W eb de sis tema p ermite una

68
Capítulo 6 Plan de pruebas

vende dores publicac ión d e


servic io s W eb haci a
una UDDI
Caso 6 Elimi nación de Se comprobó qu e el
servicio s W eb de sis tema puede dar d e
vende dores baja un serv icio W eb
Caso 7 Vis ua li zación de Se comprobó qu e el
servicio s W eb de sis tema p ermite
vende dores realizar u na co nsul ta
de los serv ic ios W eb
publicado s
Caso 8 Estab lecer vínculos Se comprobó qu e se
media nte un guardan las
conc il ia dor vincul aciones en una
tabla de
espera/concil iaci ón
Caso 9 Env ió de c orreos Se comprobó qu e se
electró nicos med ia nte realiza n los env ío s de
un mó du lo de correo e lectrón ico a
notif icac ió n las partes interesa das
Caso 1 0 Vis ua li zación de Se comprobó qu e el
servicio s enc on trados comprador p uede ve r
los ser vicio s W eb,
mediante una l iga
recibid a en su c uen ta
de correo

69
Capítulo 7

Conclusiones y Trabajos Futuros

En este Capítulo se presentan las conclusiones sobre los resultados


obtenidos de este proyecto, las aportaciones que se obtuvieron y los
trabajos a futuro que se visualizan a partir de la investigación
desarrollada.

70
Capítulo 7 Conclusiones y trabajos futuros

7.1 Conclusiones

En este trabajo se muestra que es factible el desarrollo de una


arquitectura de mercado electrónico que incorpore funciones de
conciliación entre vendedores y compradores, mediante el uso de
servicios estándar de interoperabilidad.

Una aportación importante de este trabajo fue el desarrolló de un


método innovador de búsqueda y conciliación de productos y servicios
entre descripciones de compradores y vendedores el cual integra
tecnologías de la W eb semántica y servicios W eb. A este método se le
aplico un conjunto de casos de prueba y se estableció un umbral de
similitud de un 80 por ciento, obteniendo resultados satisfactorios en
todas las pruebas.

Mas allá de los objetivos planteados para esta tesis, se


desarrollo un mecanismo para optimizar el tiempo de respuesta del
algoritmo conciliador, el cual consistió en un módulo que efectúa un
preprocesamiento de inf ormación de los productos, agrupándolos por
tipos de productos. Se constataron los tiempos de respuestas y se
observo que lo reducía en un promedio de 50 por ciento.

7.2 Trabajos futuros

Una vez culminado el trabajo de investigación, se enuncian


algunos aspectos que se recomiendan para ser tratados en desarrollos
posteriores sobre esta línea de investigación. Entre los trabajos a
futuro se sugieren los siguientes:

Desarrollar e incorporar agentes de vendedores y compradores


para favorecer la automatización de los procesos de negocios que se

71
Capítulo 7 Conclusiones y trabajos futuros

realizan dentro del mercado.

• Diseñar e implementar una ontología de comercio electrónico, que


permita resolver las dificultades que enf rentan los participantes
del mercado por falta de entendimiento común durante el
intercambio de mensajes.
• Diseñar e implementar un marco de trabajo que realice la
invocación automática de los servicios de compradores y
vendedores después de haber sido localizados y enla zados.
• Realizar un estudio de los beneficios que aportaría la
incorporación de enf oques de la W eb semántica en arquitecturas
orientadas al comercio electrónico.
• Diseñar un programa punto a punto semántico, el cual tenga como
objetivo compartir documentos de investigación como son:
publicaciones, tesis, etc.
• Diseñar un sistema explorador semántico, capaz de catalogar los
diferentes documentos y archivos en general que se encuentran
localmente en nuestro ordenador.
• Diseñar un sistema de agentes para la realización de un marcado
automático de sitios W eb, es decir un agente con la capacidad de
describir los sitios W eb.

72
Referencias

[1] Efrain Turban, David King , Jae K. Lee , Dennis Viehland:


Electronic Commerce, A Managerial Perspectiva, Technical report
(2003)

[2] Halchmi,Z., Hommel, K., y Avital., O.: Electronic Commerce,


Technical report (1996)

[3] Joan Ribas Lequerica: W eb Services, Editorial Anaya, Madrid,


España (2003)

[4] Efraim Turban, David King: Introduction to E-Commerce, Prentice


Hall, New Jersey, U.S.A. (2002)

[5] C. Baeza: Arquitectura de un sistema de comercio electrónico para


pequeñas y medianas empresas, Tesis de maestría, Cenidet
(2003)

[6] Maricela Claudia Bravo Contreras: Desarrollo de un prototipo de


comercio electrónico incorporando sistemas de pago, Tesis de
maestría, Cenidet (2003)

[7] Roberto Vega Castillo: Una Arquitectura de Comercio Electrónico


Orientado a P YMES, Incorporando Sistemas de Pago, 1er.
Congreso de Sistemas y Computación del Instituto Tecnológico
de Zihuatanejo, Cenidet (2005)

[8] M. Tsvetovatyy, M. Gini, B. Mobasher, and Z. W ieckowski: MAGMA


an agent-based virtual market for electronic commerce, Ph. D.
Thesis, University of Minnesota, U.S.A. (1997)

73
[9] Chavez, A and Maes, P.: Kasbah, An agent marketplace for buying
and selling goods, In Proc. Of the First International Conference
on the Practical Application of Intelligent Agents and Multi-Agent
Technoogy, Ph. D. Thesis, London, U.K. (1996)

[10] Catalogalo Amece: Disponible en http://www.catalogalo.com .mx

[11] B. Krulwich: Bargain finder agent prototype, Technical report,


Anderson Consulting (1995)

[12] Ana Paula Rocha, Eugénio Oliveira: Electronic Commerce, a


technological perspective, Technical report, Faculdade de
Engenharia, Universidade do Porto (1997)

[13] Sun Microsystems, Antonio Palos: Tutorial sobre el Api JAXR


(2001)

[14] Eric Armstrong, Jennifer Ball: Java W eb Services Tutorial, Sun


Microsystems (2003)

[15] Tim Berners-Lee, Hendler, Lassila: The Semantic W eb, Scientific


American (2001)

[16] Brian McBride, Andy Seaborne: Jena Tutorial (2002)

[17] Jeen Broekstra, Arjohn Kampman: Sesame, A Generic Architecture


for Storing and Querying RDF and RDF Schema, Vrije
Universiteit, Ámsterdam, Holanda (2003)

74
[18] Roberto Carlos Toledo Flandes: Generación de una Ontología de
Dominio Lingüístico para le Español a partir de Documentos de
Texto, Tesis de maestría, Cenidet (2005)

[19] Dave Chappell : Java W eb Services, Editorial O’really, New York,


U.S.A. (2002)

[20] Boehm , Barry W .: Software Engineering, Editorial Prentice Hall,


New York, U.S.A. (1981)

[21] James E. Youll: Peer to Peer Transactions in Agent-mediated


Electronic Commerce, Massachussets Institute of Technology,
Ph. D. Thesis (2001)

75