S.E.P. S.E.S. D.G.E.S.T. CENTRO NACIONAL DE INVESTIGACION Y DESARROLLO TECNOLOGICO INTERMEDIARIO FACILITADOR DEL COMERCIO ELECTRONICO PARA PYMES BASADO EN WEB T E S I S PARA OBTENER EL GRADO DE M A E S T R O E N C I E N C I A S EN CIENCIAS DE LA COMPUTACION P R E S E N T A : R O B E R TO V E G A C A S T I L L O DIRECTOR DE TESIS DR. JOAQUIN PEREZ ORTEGA CODIRECTOR DE TESIS DR. RODOLFO A. PAZOS RANGEL CUERNAVACA, MORELOS, MEXICO AGOSTO DEL 2005
Dedicatorias A mi esposa, por todo su amor, apoyo, paciencia y comprensión que me permitieron concluir mis estudios de postgrado. A mi hija, por ser mi inspiración, motivación y la fuerza para continuar en los tiempos difíciles. i
Agradecimientos Al Centro Nacional de Investigación y Desarrollo Tecnológico por darme la oportunidad de realizar mis estudios de postgrado. A COSNET y SEP por brindarme su apoyo económico, ya que sin éste no hubiera sido posible la conclusión de esta tesis. A mis compañeros de generación por ser grandes amigos y brindarme su apoyo incondicional en todo momento. A mi director de tesis Dr. Joaquín Pérez Ortega, por guiarme y orientarme durante el desarrollo de mi trabajo de tesis. ii
Tabla de contenido Lista de figuras. vi Lista de tablas... vii 1. Introducción. 1 1.1. Contexto de la Tesis... 3 1.2. Planteamiento del problema. 5 1.3. Objetivos... 7 1.4. Organización del documento 8 2. Marco Teórico. 9 2.1. Comercio electrónico.. 10 2.2. Aplicaciones Web 15 2.3. Arquitecturas Web orientadas a tecnologías java. 16 2.4. Tecnologías java orientadas a aplicaciones Web. 20 2.5. Marcos de trabajo para aplicaciones Web.. 23 3. Estado del arte 29 3.1. Trabajos de tesis relacionados. 30 3.2. Tabla comparativa de trabajos relacionados.. 34 4. Arquitectura y diseño del sistema 35 4.1. Esquema general de operación del sistema.. 36 4.2. Arquitectura detallada del sistema... 36 4.3. Detalles en la implementación de los módulos del prototipo.. 39 4.3.1. Módulo de administración 39 4.3.2. Módulo de catálogos.... 43 4.3.3. Módulo de diseño 44 4.3.4. Sitio de comercio electrónico.. 45 iii
5. Plan de pruebas. 48 5.1. Consideraciones generales de los casos de prueba 49 5.2. Casos de prueba. 50 6. Conclusiones... 69 6.1. Conclusiones generales. 70 6.2. Trabajos futuros.. 70 6.3. Publicaciones.. 72 Referencias.. 73 iv
Lista de figuras Figura 1.1 Arquitectura del prototipo de la tesis Arquitectura de un Sistema de Comercio Electrónico para Pequeñas y Medianas Empresas. Figura 1.2. Arquitectura del prototipo de la tesis Desarrollo de un Prototipo de Comercio Electrónico Incorporando Sistemas de Pago. Figura 2.1 Modelo MVC. Figura 2.2 Modelo 1. Figura 2.3 Modelo 2. Figura 2.4 Modelo 2X. Figura 2.5 Petición de una página JSP Figura 2.6 Pasos del ciclo de vida petición-respuesta JavaServer Faces. Figura 2.7 Esquema del marco de trabajo Struts. Figura 4.1 Esquema general del sistema. Figura 4.2 Arquitectura del submódulo de creación de sitios de CE del módulo de administración. Figura 4.3 Arquitectura del submódulo de edición del módulo de catálogos. Figura 4.4 Arquitectura del submódulo de diseño del módulo de catálogos. Figura 4.5 Arquitectura del submódulo de publicación del módulo de catálogos. Figura 4.6 Creación de sitios de comercio electrónico. Figura 4.7 Consulta de los sitios de comercio dentro de la plaza. Figura 4.8 Reiniciar o detener aplicaciones dentro de la plaza. Figura 4.9 Iniciar una aplicación ya registrada dentro de la plaza. Figura 4.11 Agregar un nuevo producto al catálogo. Figura 4.12 Modificar o eliminar un producto del catálogo. Figura 4.13 Personalizar la apariencia del sitio de comercio electrónico. Figura 4.14 Proceso de serialización. Figura 4.15 Esquema del sitio de comercio electrónico. Figura 4.16 Extensión del marco de trabajo Struts. Figura 5.1 Contexto de la aplicación de comercio electrónico dentro del servidor Web. Figura 5.2. Menú del administrador. v
Figura 5.3. Formulario para alta de sitio de comercio electrónico. Figura 5.4. Confirmación de datos de sitio de comercio electrónico. Figura 5.5. Confirmación de alta de sitio de comercio electrónico. Figura 5.6. Resultados de la consulta del estado de los sitios existentes en la plaza de comercio electrónico. Figura 5.7. Elegir la aplicación de comercio electrónico a detener. Figura 5.8. Confirmar detener la aplicación de comercio electrónico. Figura 5.9. Confirmación de que la aplicación de comercio electrónico se detuvo. Figura 5.10. Confirmar reiniciar la aplicación de comercio electrónico. Figura 5.11. Confirmación de que la aplicación de comercio electrónico se reinició. Figura 5.12. Confirmar iniciar la aplicación de comercio electrónico. Figura 5.13. Confirmación de que la aplicación de comercio electrónico se inició. Figura 5.14. Confirmar eliminar la aplicación de comercio electrónico. Figura 5.15. Confirmación de que la aplicación de comercio electrónico se eliminó. Figura 5.16. Menú de la empresa. Figura 5.17. Formulario de captura de datos de nuevo producto. Figura 5.18. Elegir imagen nuevo producto. Figura 5.19 Elegir categoría nuevo producto. Figura 5.20. Confirmar datos nuevo producto. Figura 5.21. Confirmación eliminar producto del catálogo. Figura 5.22. Elegir el producto a modificar. Figura 5.23. Confirmación modificación de producto. Figura 5.24. Lista de productos en el catálogo. Figura 5.25. Datos de la empresa que publica el sitio de comercio electrónico. Figura 5.26. Logotipo de la empresa que publica el sitio de comercio electrónico. Figura 5.27. Datos, logotipo y plantilla de diseño de la empresa que publica el sitio de comercio electrónico. vi
Lista de tablas Tabla 3.1. Tabla comparativa de trabajos relacionados vii
Capítulo 1 Introducción En este capítulo se exponen los antecedentes que motivaron la realización de la presente tesis. Además se incluye la descripción del problema, los alcances, limitaciones y los objetivos de la misma. 1
Capítulo 1. Introducción El Comercio Electrónico es una de las áreas de mayor evolución y desarrollo en Internet durante los últimos años, debido principalmente a factores tales como el crecimiento exponencial de los usuarios de Internet, el desarrollo de nuevas herramientas de software, el interés por parte de las empresas en participar en el comercio electrónico y la apertura de la banca comercial para brindar servicios de transacciones en línea. El concepto de comercio electrónico no solamente abarca actividades tales como la compra-venta electrónica de bienes, información o servicios, sino que incluye actividades previas y posteriores a la venta, tales como la publicidad, la búsqueda de información, negociaciones, trámites administrativos, etc. Actualmente en México existen grandes empresas que utilizan Internet como mecanismo de venta de sus productos y servicios; sin embargo, no es el caso de las pequeñas y medianas empresas (PyMEs). Las PyMEs tienen características muy diferentes a las de las grandes corporaciones, tanto en organización como en recursos, por lo que requieren aplicaciones a la medida y al alcance de sus posibilidades económicas. Desde hace poco más de 2 años, dentro del CENIDET se ha trabajado en un proyecto institucional, cuyo objetivo es desarrollar aplicaciones de comercio electrónico orientadas a los modelos de negocio de las pequeñas y medianas empresas de México. Los requerimientos principales de estas aplicaciones de comercio electrónico son: bajo costo y fácil uso [Bravo 2003]. Actualmente se cuenta con un prototipo de comercio electrónico que cumple con los requerimientos estipulados, sin embargo, la funcionalidad de este prototipo es limitada, en lo particular, está orientado a una sola tienda, y el mantenimiento tiene que hacerse directamente sobre el código fuente. Debido a estas limitaciones se planeó el dar funciones de administración adicionales a este prototipo, algunas de las cuales fueron desarrolladas en la presente tesis. 2
Capítulo 1. Introducción 1.1. Contexto de la tesis El presente trabajo de tesis forma parte de un proyecto institucional cuyo objetivo es desarrollar aplicaciones de comercio electrónico orientadas a los modelos de negocio de las pequeñas y medianas empresas de México. Previo a la realización del presente trabajo de tesis se desarrollaron dos trabajos de tesis más sobre esta línea de investigación. A) Arquitectura de un Sistema de Comercio Electrónico para Pequeñas y Medianas Empresas [Baeza 2002]. B) Desarrollo de un Prototipo de Comercio Electrónico Incorporando Sistemas de Pago [Bravo 2003]. A continuación se da un resumen de estos trabajos: [Baeza 2002] su objetivo fue proponer la arquitectura de un sistema de comercio electrónico que integre componentes de bajo costo, que esté orientado a la pequeña y mediana empresa, e implementar un prototipo que muestre las bondades de la arquitectura propuesta. La Figura 1.1 muestra la arquitectura propuesta para el sitio de comercio electrónico, misma que se utilizó para el desarrollo del prototipo de tesis. Debido a que este prototipo fue pensado para ser de bajo costo, fue desarrollado con herramientas de software de código abierto, tales como: el sistema operativo Linux, SMBD PostgreSQL, Servidor Web Tomcat y Java como lenguaje de programación. Las características de este prototipo, desafortunadamente son limitadas; concretamente, está orientado a una sola tienda, y el mantenimiento de los catálogos se realiza por comandos sobre el SMBD del sistema. A pesar de esto se han logrado incorporar funciones tales como: el manejo de un carrito de 3
Capítulo 1. Introducción compras, registro de los clientes y mecanismo de seguridad a través del protocolo SSL, entre otras. Figura 1.1 Arquitectura del prototipo de la tesis Arquitectura de un Sistema de Comercio Electrónico para Pequeñas y Medianas Empresas [Bravo 2003] Su objetivo principal fue el desarrollo e implementación de un prototipo de comercio electrónico, de bajo costo, que incorpore sistemas de pago por Internet, y que esté orientado a las pequeñas y medianas empresas de México. En general, dicho trabajo se realizó un análisis de los sistemas de pago por Internet, con el objeto de determinar los requisitos establecidos por los bancos para el manejo de transacciones en línea. Como resultado de este análisis se desarrolló un nuevo prototipo, con el fin de demostrar la factibilidad de implementación de un sistema de comercio electrónico orientado a las pequeñas y medianas empresas que incorpore sistemas de pago en línea. La arquitectura de este sistema se representa en la Figura 1.2. 4
Capítulo 1. Introducción Figura 1.2. Arquitectura del prototipo de la tesis Desarrollo de un Prototipo de Comercio Electrónico Incorporando Sistemas de Pago 1.2. Planteamiento del problema La problemática general para las pequeñas y medianas empresas que desean incursionar en el comercio electrónico, se presenta principalmente en la etapa de implantación y en la etapa de mantenimiento del sitio de comercio electrónico. Durante la etapa de implantación, el monto de la inversión necesaria para el establecimiento de un sitio de comercio electrónico es muchas veces una limitante para empresas con pocos recursos. 5
Capítulo 1. Introducción La conjunción de esfuerzos individuales (cooperativas, sociedades anónimas) en busca de la disminución de costos ha sido una alternativa probada que ha obtenido buenos resultados. Aplicando esta práctica a la tecnología de comercio electrónico, nos encontramos con agrupaciones de sitios de comercio electrónico denominadas plazas virtuales de comercio electrónico, las cuales ofrecen ventajas en cuanto a la disminución de costos de operación, mantenimiento y comercialización. Durante la etapa de mantenimiento, el problema más común tiene que ver con la forma en que se han de actualizar los datos de los productos publicados en el sitio de comercio electrónico. Actualmente, en muchos sitios de comercio electrónico se invierte mucho tiempo y esfuerzo para mantener actualizada la información de los productos que ahí se comercializan. Muchos de estos sitios todavía hacen la actualización de sus catálogos de productos de manera manual. Al trabajar de esta forma, se requiere de personal con conocimientos sobre la arquitectura del sistema y sobre la tecnología utilizada para crear el sitio de comercio electrónico. Si consideramos el ejemplo de un sitio de comercio electrónico de mediana magnitud, tal vez se requiera un número moderado de actualizaciones al día. En cambio, si se trata de administrar varios sitios a la vez, se convierte en un problema de considerable magnitud. Cabe mencionar que se han hecho desarrollos tanto en empresas dedicadas a proporcionar soluciones de tecnología Web, como en instituciones de educación e investigación, para tratar de facilitar las labores de actualización de catálogos de productos para sitios de comercio electrónico. Sin embargo, no son muchos los que han invertido su tiempo en el desarrollo de prototipos orientados a pequeñas y medianas empresas. 6
Capítulo 1. Introducción Existen muchas propuestas de arquitecturas y tecnologías para el desarrollo de sitios y plataformas de comercio electrónico, sin embargo ninguna ha destacado tanto sobre las demás como para considerarse una tendencia y mucho menos un estándar. En lo que se refiere a México, la AMECE (Asociación Mexicana de Estándares de Comercio Electrónico) en conjunto con la AMCE (Asociación Mexicana de Comercio Electrónico) se han dado a la tarea de definir estándares y proponer soluciones para ofrecer a las empresas sistemas de comercio electrónico. Actualmente tienen disponible un sistema de publicación de catálogos denominado cat@logalo [AMECE 2005], el cual permite a las empresas que lo soliciten, publicar su catálogo de productos y a su vez consultar el catálogo de todas las empresas registradas, a través de un directorio de empresas. Desgraciadamente, es necesario que la empresa que adopte estas soluciones cuente previamente con una infraestructura informática de alto costo (que permita la implantación de un DATAWAREHOUSE), infraestructura que no existe en la mayoría de las PyMEs de México. El problema a resolver en la presente tesis consiste en el desarrollo de un módulo de software para la administración de catálogos de productos para un sitio de comercio electrónico y un módulo adicional que represente una plaza virtual, que permita la adición de nuevos sitios, así como su modificación y su salida del sistema, que cuente con un esquema de seguridad y que sea de fácil uso. 1.3. Objetivos El objetivo general de esta tesis es el de desarrollar un prototipo de un sistema computacional que represente una plaza virtual de comercio electrónico orientada a las pequeñas y medianas empresas de México. 7
Capítulo 1. Introducción Objetivos específicos. a) Desarrollar un sistema computacional que represente una plaza virtual de comercio electrónico, que cuente con herramientas de administración para la misma. b) Desarrollar una herramienta de software de ayuda al diseño y mantenimiento de catálogos de productos, que permita la definición, publicación y actualización de catálogos por las propias empresas. 1.4. Organización del documento El presente documento de tesis se organiza de la siguiente manera: Capítulo 2: En este capítulo se presenta la teoría relacionada con la implementación de sistemas de comercio electrónico. Capítulo 3: En este capítulo se presenta un resumen de los trabajos de comercio electrónico relacionados con la presente tesis en los ámbitos nacional y mundial. Capítulo 4: En este capítulo se presenta la arquitectura de los módulos del prototipo de tesis, así como los detalles de implementación del mismo. Capítulo 5: En este capítulo se describen los casos de prueba para el prototipo. En cada caso se especifica su objetivo, el procedimiento a seguir y los resultados de dicho procedimiento. Capítulo 6: En este capítulo se presentan las conclusiones y aportaciones del presente trabajo de tesis. Además se sugieren trabajos futuros, los cuales pueden ser desarrollados a partir de los resultados obtenidos en este proyecto. 8
Capítulo 2 Marco Teórico En este capítulo se presenta la teoría relacionada con la implementación de sistemas de comercio electrónico. 9
Capítulo 2. Marco Teórico 2.1. Comercio electrónico El comercio electrónico se puede definir como cualquier forma de transacción o intercambio de información comercial basada en la transmisión de datos sobre redes de comunicación como Internet. En este sentido, el concepto de comercio electrónico no solamente incluye la compra y venta electrónica de bienes, información o servicios, sino también el uso de la red para actividades anteriores o posteriores a la venta, como los siguientes [Ministerio 1999]: La publicidad. La búsqueda de información sobre productos y proveedores. La negociación entre comprador y vendedor sobre el precio y condiciones de entrega. La atención al cliente antes y después de la venta. El cumplimiento de trámites administrativos relacionados con la actividad comercial. La colaboración entre empresas con negocios comunes (a largo plazo). Estas actividades no necesariamente tienen que estar presentes en todos los escenarios de comercio electrónico. En el comercio electrónico participan como actores principales las empresas, los consumidores, las instituciones bancarias y las administraciones públicas. 2.1.1. Tipos de comercio electrónico A) Entre empresas B2B (business to business) Este tipo de comercio se realiza entre dos o más empresas con el objetivo de intercambiar bienes o servicios, a través de Internet o de otras redes de comunicaciones. Es comúnmente utilizado para el intercambio de presupuestos, pedidos y facturas entre otros. 10
Capítulo 2. Marco Teórico B) Entre empresa y consumidor B2C (business to consumer) En este caso, el intercambio de bienes y servicios a través de Internet o de otras redes de comunicaciones, se realiza entre empresas y clientes finales. El crecimiento y popularidad de este tipo de comercio electrónico se debe a que agiliza y minimiza los costos, ofreciendo productos de forma más rápida y económica. C) Entre empresa y administración B2A (business to administration) Este tipo de comercio abarca todas las transacciones entre las empresas y las organizaciones gubernamentales; por ejemplo, el pago de impuestos o servicios a través de Internet. D) Entre consumidor y administración C2A (consumer to administration) Este tipo de comercio vincula la administración y los consumidores finales. A través de esta modalidad del comercio electrónico, los gobiernos pueden posibilitar el pago de algunos servicios. 2.1.2. Elementos de un sistema de comercio electrónico Una tienda virtual es un tipo concreto de aplicación Web, donde todo el diseño se orienta al máximo rendimiento del proceso comercial. Los elementos más comunes dentro de un sistema de comercio electrónico son los siguientes [IAE 2005]: A) Catálogo de productos Se trata del vértice de la aplicación, y su finalidad es la de mostrar el abanico de productos o servicios ofertados en la tienda virtual. 11
Capítulo 2. Marco Teórico El catálogo de productos ha de ser estructurado en familias o categorías, permitiendo así la facilidad de localización de un artículo dentro de un rango de productos concretos. Del mismo modo, la información de los productos en el catálogo ha de ser completa, proveyendo la información necesaria para la identificación única e inequívoca del artículo. B) Buscador de productos Cuando un catálogo de productos contiene una cierta cantidad de artículos, es altamente recomendable la incorporación a la tienda virtual de un buscador de productos. De esta forma se elimina la necesidad de tener que navegar por diferentes familias de productos para alcanzar un producto concreto. C) Carrito de compras En el carrito de compras es donde propiamente se realiza la acción del comercio electrónico, puesto que es el lugar en el que se registran los artículos solicitados por el cliente o distribuidor, y a partir del cual se iniciará el proceso de compra electrónica. D) Medios de pago Para que una operación comercial se lleve a cabo, se debe hacer efectiva una transacción económica por la cual el cliente abona a la empresa el importe requerido por ésta, según se indica en el carrito de la compra. Los medios de pago son aquellos intermediarios entre la empresa y el cliente por las cuales se hacen efectivas las transacciones económicas, y son de vital importancia para el ejercicio del comercio electrónico. 12
Capítulo 2. Marco Teórico La importancia de los medios de pago viene determinada por la percepción que de éstos tienen los clientes, puesto que pueden constituirse en una barrera si les provocan desconfianza. E) Seguimiento de pedidos Una tienda virtual no sólo debe proporcionarle al cliente un medio fácil y confiable de compra de productos o servicios, sino que debe considerar en todo momento la satisfacción del cliente. El plazo entre el proceso de compra y la recepción del producto es vital para la percepción del sistema de comercio electrónico por parte del cliente, y por ello resulta muy satisfactorio el contar con información continua sobre el estado del pedido. F) Integración en buscadores El éxito de una tienda virtual viene determinado por las ventas que se generen a partir de ella, y el número de éstas es un factor directamente proporcional al número de visitas que reciba. La principal fuente de visitas en Internet son los buscadores: más del 80% de visitantes provienen de los principales motores de búsqueda. Por eso es vital que exista una adecuada integración de una tienda virtual en los buscadores más usados, permitiendo que los productos ofertados puedan ser localizados por los potenciales clientes a través de ellos. G) Administración remota Al igual que el comercio tradicional, el escaparate y el catálogo de productos deben ser actualizados periódicamente. Un adecuado sistema de comercio electrónico para compras por Internet, debe permitir renovar con facilidad la información publicada de los productos. 13
Capítulo 2. Marco Teórico De la misma forma, la tienda virtual debe proveer al administrador un método eficiente para las labores administrativas, permitiendo consultar pedidos, entregas, cobros, etc. H) Integración en la infraestructura informática existente Una adecuada solución para tiendas virtuales no debe proporcionar tan sólo soluciones puntuales de presencia en Internet, sino que todo el proceso comercial debe estar integrado en la infraestructura informática existente en la empresa: la gestión de artículos, clientes y pedidos debe estar perfectamente integradas, convirtiendo a la tienda virtual en un escaparate más de la empresa. 2.1.3. Beneficios del comercio electrónico Una adecuada implantación de un sistema de comercio electrónico apropiado repercute en importantes beneficios [PADSOFT 2005]: A) Para la empresa Crecimiento de mercado: las fronteras desaparecen, expandiendo la cobertura geográfica, permitiéndole así captar nuevos clientes. Reducción de costos: Internet es un medio económico, por lo que ahorrará en comparación con los medios de comunicación tradicionales (teléfono, fax, correo ordinario, etc.). Reducción de tiempos de producción: la velocidad en las comunicaciones por Internet hace posible la minimización de tiempos de espera, acelerando el proceso productivo en cualquiera de sus etapas. Posición estratégica (competitividad): la empresa es capaz de rivalizar con las de su sector, ofreciendo mejores servicios. 14
Capítulo 2. Marco Teórico Amortización a corto plazo: la inversión realizada se amortiza rápidamente con los nuevos clientes adquiridos y por la satisfacción de sus clientes existentes. Percepción por parte del cliente: el cliente adquiere una imagen de empresa dinámica y flexible que se adapta a las nuevas tendencias tecnológicas, proyectando en el cliente la imagen de empresa emprendedora. B) Para los clientes Disponibilidad: los clientes podrán establecer comunicación con la empresa sin depender de horarios, pudiendo relacionarse en el momento en que lo consideren necesario. Velocidad: los accesos a los servicios no requieren colas de espera ni trámites especiales, por lo que los clientes obtienen lo que necesitan en el instante. Comodidad: a los clientes no les supone desempeñar esfuerzos adicionales para conseguir sus objetivos, los pueden llevar a cabo cómodamente sentados frente a sus computadoras. Flexibilidad: los clientes pueden realizar cualquier tipo de operaciones y consultas adecuándolas a sus necesidades en todo momento. Economía: los clientes ahorrarán tiempo y dinero en las comunicaciones establecidas con la empresa. Atención personalizada: podrá adecuar los contenidos ofrecidos a los clientes, procurándoles los servicios a su medida. 2.2. Aplicaciones Web Una "aplicación Web" es un conjunto de páginas Web cuyo contenido puede variar de forma automatizada dependiendo de fuentes internas o externas (bases de datos o sistemas servidores de información), las cuales, el usuario 15
Capítulo 2. Marco Teórico invoca usando un navegador el cual contacta algún servidor vía Internet. Para los usuarios y navegadores pasa usualmente inadvertida a diferencia entre contactar un servidor Web que tenga solamente páginas estáticas y uno que contenga solamente aplicaciones Web, pero a diferencia de las páginas estáticas, las aplicaciones Web crean sus páginas dinámicamente. Un sitio Web construido dinámicamente utiliza un programa de computadora para conseguir el dinamismo. Este tipo de aplicaciones dinámicas pueden ser escritas en algún tipo de lenguaje de programación [ZOPE 2005]. 2.3. Arquitecturas Web orientadas a tecnologías java La arquitectura Web provee la manera más simple y eficiente de construir, administrar y mantener cualquier tipo de aplicación Web, optimizando los costos y tiempos de desarrollo. Las arquitecturas de las aplicaciones Web están evolucionando hacia modelos más avanzados que les permitan adaptarse a los nuevos enfoques de desarrollo. Siguiendo esta tendencia, en los últimos años se han propuesto múltiples arquitecturas y marcos de trabajo orientados a tecnologías Java, las cuales se describen brevemente a continuación. 2.3.1. MVC En el paradigma MVC (Figura 2.1), los datos que maneja la aplicación, la lógica de negocio y la vista que el usuario recibe están explícitamente separados en 3 objetos, cada cual especializado en su tarea. La vista gestiona el aspecto de la presentación gráfica (look & feel) que recibe el usuario [Kofman 2003]. El controlador interpreta los datos que da el usuario coordinando la vista y el modelo para que la aplicación se comporte conforme a lo esperado. Y por último, el modelo maneja los datos y el estado de la aplicación, responde a las peticiones de información sobre su estado que hace la vista y responde a las instrucciones que le da el controlador para que modifique su estado. 16
Capítulo 2. Marco Teórico Figura 2.1 Modelo MVC. 2.3.2. Modelo 1 En los inicios de los JSPs (JavaServer Pages), la forma natural de trabajar era la de usar estos mismos para realizar casi todas las tareas dentro de la aplicación Web, tales como: extraer los parámetros de la solicitud HTTP, hacer llamadas a las clases de la lógica del negocio (implementada en los JavaBeans) o directamente dentro de los JSPs, manejar la sesión de HTTP (HyperText Transfer Protocol) y generar el documento HTML (HyperText Markup Language) de salida. Este enfoque de programación fue denominado Modelo 1 y es mostrado en la Figura 2.2. Aunque el Modelo 1 es ideal para aplicaciones sencillas, no lo es tanto para aplicaciones más complejas, debido a que hace difícil el mantenimiento, la escalabilidad y el rehúso de componentes, el código tiende a no ser modular, y se duplica gran cantidad de código ya que varias páginas implementan las mismas rutinas [Orbeon 2004]. 17
Capítulo 2. Marco Teórico Figura 2.2 Modelo 1. 2.3.3. Modelo 2 El Modelo 2, mostrado en la Figura 2.3, es una implementación de la arquitectura MVC (Model-View-Controller) orientada a tecnologías Java. En el Modelo 2 el controlador está constituido por servlets, los cuales tienen la función de controlar el flujo de la aplicación, el modelo está integrado por JavaBeans, los cuales encapsulan la lógica del negocio, y la vista se construye con JSPs, cuya función es la de elaborar el código HTML de salida. Figura 2.3 Modelo 2. 18
Capítulo 2. Marco Teórico Este modelo permite una separación más clara de la lógica del negocio y la presentación, haciendo más fáciles las tareas de mantenimiento y rehúso de componentes. Los elementos de la vista no deben conocer los objetos del modelo y viceversa. El ejemplo más popular de un marco de trabajo que implementa el Modelo 2 es un proyecto de Apache Jakarta llamado Struts [Seshadri 2004]. 2.3.4. Modelo 2X Los marcos de trabajo basados en el Modelo 2 son un gran paso en la dirección correcta, sin embargo, en algunos casos no es óptimo entregar código HTML directamente de los JSPs al navegador Web del usuario. Figura 2.4 Modelo 2X. El modelo 2X, mostrado en la Figura 2.4, surge como una evolución del Modelo 2, con el objeto de dar solución a la necesidad de desarrollar aplicaciones multicanal; es decir, aplicaciones Web que pueden ser accedidas desde diferentes tipos de clientes remotos. Así una aplicación Web multicanal 19
Capítulo 2. Marco Teórico podrá ejecutarse desde una PDA (Personal Digital Assistant), un teléfono móvil, o desde cualquier navegador en una computadora personal. La forma para poder publicar la misma aplicación para distintos dispositivos, es usando plantillas XSL (extensible Stylesheet Language) para transformar los datos contenidos en documentos XML (extensive Markup Language) al formato de salida que se ajuste al dispositivo que hace la solicitud, ya sea WML (Wireless Markup Language), HTML, etc [Orbeon 2004]. 2.4. Tecnologías java orientadas a aplicaciones Web A). JavaServer Pages La tecnología de las JavaServer Pages (JSP) aparece para aliviar la molestia que supone generar páginas Web mediante servlets. Además, de esta forma es posible dividir el trabajo de construir una aplicación Web entre programadores (servlets) y diseñadores gráficos (JSPs). Una página JSP no es más que una página HTML que contiene ciertas etiquetas especiales (acciones) o fragmentos de código (scriptlets) para incluir contenido dinámico en dicha página. El código HTML se añade tal cual a la respuesta, mientras que los elementos dinámicos se evalúan con cada petición. Cuando un cliente pide esa página al servidor (Figura 2.5) de aplicaciones, se traduce a un archivo fuente de Java que implementa un Servlet, se compila y se ejecuta para devolver el resultado de la petición. Una vez compilado el servlet, las peticiones posteriores se reducen a ejecutar dicho servlet en lugar de realizar el proceso una y otra vez. Esta es la razón por la que la primera petición tarda mucho más en responderse que las siguientes. Dado que una JSP no es más que un servlet, hay que recordar que todo el código se ejecuta en el servidor y las respuestas son puramente páginas HTML. 20
Capítulo 2. Marco Teórico Figura 2.5 Petición de una página JSP B). Servlets Los servlets son módulos que extienden los servidores orientados a peticiónrespuesta, como los servidores Web compatibles con Java. Por ejemplo, un servlet podría ser responsable de tomar los datos de un formulario de entrada de pedidos en HTML y aplicarle la lógica de negocios utilizada para actualizar la base de datos de pedidos de la compañía. Los servlets son para los servidores lo que los applets son para los navegadores. Sin embargo, al contrario que los applets, los servlets no tienen interfaz gráfica de usuario. Son un reemplazo efectivo para los scripts CGI. Proporcionan una forma de generar documentos dinámicos que son fáciles de escribir y rápidos en ejecutarse. Los servlets también solucionan el problema de hacer la programación del lado del servidor con APIs específicos de la plataforma. Estos pueden ser incluidos en muchos servidores diferentes porque el API Servlet que se utiliza no supone nada sobre el entorno o protocolo del servidor. 21
Capítulo 2. Marco Teórico C). JavaBeans Los JavaBeans se idearon como un mecanismo para diseñar componentes, generalmente de tipo gráfico, que pudiesen ser reutilizados por los entornos de desarrollo integrado (IDE). Para ello la interfaz de un JavaBean debería ser capaz de mostrar su contenido en tiempo de ejecución. Esta característica ha hecho que los JavaBeans se utilicen en otros entornos, tal como el desarrollo de aplicaciones Web. Un JavaBean no es más que una clase java que sigue ciertas convenciones en el nombrado de sus métodos, de forma que sea posible operar con ella en tiempo de ejecución. Se dice que un JavaBean tiene propiedades o atributos, y dependiendo de que los métodos getpropiedad() y setpropiedad() estén definidos, la propiedad será de lectura, de escritura o de lectura/escritura. D). XML XML "Extensible Markup Language" es un metalenguaje usado para definir documentos que contienen datos estructurados. Las características y beneficios del XML se pueden agrupar en tres áreas principales: Extensibilidad: Como metalenguaje, XML puede usarse para crear sus propios lenguajes de marcas. Hoy en día existen muchos lenguajes de marcas basados en XML, incluyendo "Wireless Markup Language" (WML). Estructura precisa: HTML sufre de una pobre estructura que hace difícil procesar eficientemente documentos HTML. Por otro lado, los documentos XML están bien estructurados, cada documento tiene un elemento raíz y todos los demás elementos deben estar anidados dentro de otros elementos. 22
Capítulo 2. Marco Teórico Hay dos tipos principales de documentos XML. Documentos válidos: un documento XML válido está definido por una "Document Type Definition" (DTD), que es la gramática del documento que define qué tipos de elementos, atributos y entidades podría haber en el documento. El DTD define el orden y también la ocurrencia de elementos. Documentos bien-formados: un documento XML bien formateado no tiene que adherirse a una DTD, pero debe seguir dos reglas: 1) todo elemento debe tener una etiqueta de apertura y otra de cierre, y 2) debe haber un elemento raíz que contenga todos los otros elementos. Extensión poderosa: Como se mencionó anteriormente, XML sólo se usa para definir la sintaxis. En otras palabras, se usa para definir contenido. Para definir la semántica, el estilo o la presentación, necesitamos usar "Extensible Stylesheet Language" (XSL). Un documento podría tener múltiples hojas de estilo que podrían ser usadas por diferentes usuarios. El XML se ha convertido en el formato estándar de facto para la representación de datos en Internet. Los datos XML se pueden procesar e interpretar en cualquier plataforma. XML es un compañero perfecto para las aplicaciones Java que necesitan datos portables. 2.5. Marcos de trabajo para aplicaciones Web Los marcos de trabajo orientados a objetos son la piedra angular de la moderna ingeniería del software, y están ganando rápidamente la aceptación debido a su capacidad para promover la reutilización del código del diseño y el código fuente. Los marcos de trabajo son los generadores de aplicaciónes que se relacionan directamente con un dominio específico, es decir, con una familia de problemas relacionados. 23
Capítulo 2. Marco Teórico La capacidad de reutilización del código y del diseño de marcos de trabajo orientados a objetos permite una productividad mayor y un tiempo de entrega breve en el desarrollo de aplicaciones, en comparación con el desarrollo tradicional de los sistemas de software. Existen múltiples beneficios en el uso de marcos de trabajo, entre los que se encuentran: Apego a estándares y políticas. Congruencia de la aplicación sobre múltiples plataformas. Proporciona un método para el rehusó de componentes. Producción de aplicaciones más robustas, rápidas, estables y consistentes. Menor tiempo de programación. Permite extensiones para darle mayor funcionalidad. A continuación se describen algunos marcos de trabajo para aplicaciones Web basados en tecnologías java. 2.4.1. Cocoon Apache Cocoon es un marco de trabajo basado en XML y tecnologías XSLT, diseñado para obtener un mejor desempeño y escalabilidad en base a procesamiento SAX. Cocoon ofrece un ambiente flexible basado en la separación de contenidos, lógica y estilo. Cocoon interactúa con múltiples fuentes de datos, incluyendo sistema de archivos, RDBMS, LDAP, bases de datos nativas XML y orígenes de datos sobre redes de trabajo. Adapta los contenidos de salida a las capacidades de diferentes dispositivos como HTML, WML, PDF, SVG y RTF, entre otros [Garvey 2003]. 24
Capítulo 2. Marco Teórico 2.4.2. JavaServer faces La tecnología JavaServer Faces [Armstrong 2003] es un marco de trabajo de interfaces de usuario (UI) del lado de servidor para aplicaciones Web basadas en tecnología Java. Los principales componentes de la tecnología JavaServer Faces son: Un API y una implementación de referencia para: representar componentes UI y manejar su estado; manejar eventos, validar del lado del servidor y convertir datos; definir la navegación entre páginas; soportar internacionalización y accesibilidad; y proporcionar extensibilidad para todas estas características. Una biblioteca de etiquetas JavaServer Pages (JSP) personalizadas para dibujar componentes UI dentro de una página JSP. Este modelo de programación bien definido y la biblioteca de etiquetas para componentes UI, facilitan de forma significativa la tarea de construcción y mantenimiento de aplicaciones Web con UIs del lado del servidor. Una de las grandes ventajas de la tecnología JavaServer Faces es que ofrece una clara separación entre el comportamiento y la presentación. Las aplicaciones Web construidas con tecnología JSP conseguían parcialmente esta separación. Sin embargo, una aplicación JSP no puede mapear peticiones HTTP al manejo de eventos específicos de los componentes o manejar elementos UI como objetos con estado en el servidor. La tecnología JavaServer Faces nos permite construir aplicaciones Web las cuales implementan una separación entre el comportamiento y la presentación del lado del cliente. Otro objetivo importante de la tecnología JavaServer Faces es mejorar los conceptos familiares de componente-ui y capa-web sin limitarnos a una tecnología de script particular o un lenguaje de marcas. Aunque la tecnología JavaServer Faces incluye una biblioteca de etiquetas JSP personalizadas para 25
Capítulo 2. Marco Teórico representar componentes en una página JSP, los APIs de la tecnología JavaServer Faces se han creado directamente sobre el API JavaServlet. Esto nos permite hacer algunas cosas: usar otra tecnología de presentación junto a JSP, crear nuestros propios componentes personalizados directamente desde las clases de componentes, y generar salida para diferentes dispositivos cliente. Pero lo más importante, la tecnología JavaServer Faces proporciona una rica arquitectura para manejar el estado de los componentes, procesar los datos, validar la entrada del usuario, y manejar eventos. El ciclo de vida de una página JavaServer Faces es similar al de una página JSP: El cliente hace una petición HTTP de la página, y el servidor responde con la página traducida a HTML. Sin embargo, debido a las características extras que ofrece la tecnología JavaServer Faces, el ciclo de vida proporciona algunos servicios adicionales mediante la ejecución de algunos pasos extras. Figura 2.6 Pasos del ciclo de vida petición-respuesta JavaServer Faces. 26
Capítulo 2. Marco Teórico Los pasos que se ejecutan en el ciclo de vida dependen de si la petición se originó o no desde una aplicación JavaServer Faces y si la respuesta es o no generada con la fase de renderizado del ciclo de vida de JavaServer Faces. El procesamiento de una solicitud se divide en 6 pasos principales, los cuales se muestran en la Figura 2.6. 2.4.3. Struts Es un marco de trabajo que implementa el patrón de la arquitectura MVC en Java (Modelo 2). Simplifica notablemente la implementación de una arquitectura según el patrón Modelo 2; separa muy bien lo que es la gestión del flujo de trabajo de la aplicación, del modelo de objetos de negocio y de la generación de interfaz. Figura 2.7 Esquema del marco de trabajo Struts. 27
Capítulo 2. Marco Teórico El controlador mostrado en la Figura 2.7 ya se encuentra implementado por Struts, aunque de ser necesario se puede heredar y extender o modificar, y el flujo de trabajo de la aplicación se puede programar desde un documento XML. Las acciones que se ejecutarán sobre el modelo de objetos de negocio, se implementan basándose en clases predefinidas por el marco de trabajo y siguiendo el patrón Facade [Gamma 1995]. La generación de interfaz se soporta mediante un conjunto de tags (etiquetas) predefinidas por Struts cuyo objetivo es evitar el uso de Scriplets (los trozos de código Java entre "<%" y "%>"), lo cual genera ventajas de mantenibilidad y de desempeño [Antoniucci 2004]. Logísticamente, Struts separa claramente el desarrollo de interfaz del flujo de trabajo y la lógica de negocio, permitiendo desarrollar ambas en paralelo o con personal especializado. También es evidente que potencializa el rehúso, el soporte de múltiples interfaces de usuario (HTML, shtm (Server HTML), WML, Desktop Applications, etc.) y de múltiples idiomas, localismos, etc. 28
Capítulo 3 Estado del arte En este capítulo se presenta un resumen de algunos de los trabajos de comercio electrónico relacionados con la presente tesis en los ámbitos nacional y mundial. 29
Capítulo 3. Estado del arte 3.1. Trabajos Relacionados A XML-Based Catalogs for B2B Electronic Commerce B. Omelayenko, D. Fensel. Division of Mathematics and Computer Science, Vrije Universiteit. [Omelayenko, 2001] Los mercados electrónicos orientados al comercio electrónico B2B reúnen una gran cantidad proveedores y consumidores en línea. Para que éstos puedan funcionar adecuadamente se requiere de la integración de múltiples catálogos de productos, proporcionados por los participantes en el mercado electrónico. Cada participante puede utilizar su propio formato para representar los productos en su catálogo de productos. Si un mercado electrónico es un intermediario entre n proveedores y m consumidores, entonces éste debe ser capaz de relacionar cada uno de los n catálogos de los proveedores con los m formatos de los consumidores, realizando n x m relaciones. Los valores de n y m pueden ser suficientemente altos como para hacer que el problema de creación y mantenimiento de las reglas de integración deje de ser trivial. Los diferentes proveedores tienden a usar esquemas de representación completamente diferentes, incluso para un concepto tan simple como lo es una dirección. Afortunadamente la mayoría de éstos usan la sintaxis XML en su codificación, pero las estructuras de las descripciones difieren grandemente y un número de variantes han sido desarrolladas e implementadas. Este trabajo de tesis se enfoca a los métodos para la aplicación de tecnologías XSLT en el intercambio de documentos B2B en base a resultados hechos en investigaciones previas. Con la utilización de un catálogo intermedio, al cual se ha llamado Catálogo Unificado, el mercado electrónico solamente tiene que realizar una sola relación entre el catálogo de cada proveedor o consumidor y el Catálogo Unificado y por lo tanto solamente requiere de n + m relaciones. 30
Capítulo 3. Estado del arte Existen 2 estrategias opuestas para la selección de los elementos para la inclusión en el Catálogo Unificado. 1. El Catálogo Unificado almacena la menor cantidad de atributos por cada producto. 2. El Catálogo Unificado almacena la mayor cantidad de atributos por cada producto. B e-cousal F. García. Departamento de Informática y Automática, Universidad de Salamanca. [García 2002] En este trabajo se presenta una propuesta de arquitectura de comercio electrónico dirigida a las pequeñas y medianas empresas, que basan su negocio en la venta por catálogos de productos. También propone el desarrollo de una herramienta de software que permite la definición, publicación y actualización de catálogos de productos, junto con una arquitectura para un servidor Web para permitir a los clientes el acceso a la herramienta de definición de catálogos. La arquitectura de comercio electrónico ofrece una plataforma uniforme que implementa los servicios comerciales principales para una estrategia de desarrollo de comercio electrónico, reduciendo la cantidad de recursos necesarios para la organización. La arquitectura propuesta se centra en negocios basados en la venta por catálogo de productos, aunque la arquitectura está definida de manera genérica para permitir la implementación de distintas políticas del lado del servidor. 31
Capítulo 3. Estado del arte Los objetivos de dicho trabajo son: 1. Incrementar la flexibilidad en el ambiente de negocios, para permitir que la organización adapte el modelo de negocio a sus necesidades. 2. Que la empresa pueda mantener su negocio electrónico de manera autónoma y así eliminar las dependencias de entidades externas a la organización. C) Desarrollo de un Prototipo de Comercio Electrónico Incorporando Sistemas de Pago. M. Bravo. Centro Nacional de Investigación y Desarrollo Tecnológico [Bravo 2003] En este trabajo de tesis, se propuso el desarrollo e implementación de un prototipo de comercio electrónico, de bajo costo, que incorpore sistemas de pago por Internet, y que esté orientado a las pequeñas y medianas empresas de México. En general, dicho trabajo se realizó un análisis de los sistemas de pago por Internet, con el objeto de determinar los requisitos establecidos por los bancos para el manejo de transacciones en línea. Como resultado de este análisis se desarrolló un nuevo prototipo, con el fin de demostrar la factibilidad de implementación de un sistema de comercio electrónico orientado a las pequeñas y medianas empresas que incorpore sistemas de pago en línea. Centra su atención en los procedimientos para realizar transacciones en línea con las diferentes instituciones bancarias, y para tal efecto se desarrolló un prototipo para simular el proceso real de las transacciones. 32
Capítulo 3. Estado del arte D) El comercio electrónico en la pequeña empresa mexicana A. Pérez, J. Leyva. Universidad de Sonora en Hermosillo [Pérez 2004] El presente trabajo de investigación consistió en un estudio de la situación actual del empresario de la pequeña empresa en el noroeste de México ante los negocios electrónicos y una evaluación de su nivel de capacitación para ingresar a esta nueva forma de transacciones comerciales. La metodología consistió en la aplicación de encuestas y entrevistas a los responsables de las empresas en una de las ciudades más importantes del Noroeste de México, que es la ciudad de Hermosillo en el estado de Sonora, en el sector comercial. Para la aplicación de las encuestas se formaron grupos de características comunes considerando el giro al que se dedican. A las empresas encuestadas se les preguntó, entre otros aspectos, las actividades y productos que manejan, el uso de correo electrónico en la empresa, compras efectuadas por Internet, elementos de publicidad en la red, ventas realizadas con apoyo de estos elementos, y seguridad en las compras por medios electrónicos. El estudio concluye que los empresarios en esta región, no cuentan con la información suficiente para ingresar a Internet como una nueva forma de proyectar su imagen. Se requieren además planes de capacitación para la utilización de esta nueva forma de realizar negocios y de ofertar productos y/o servicios. 33
Capítulo 3. Estado del arte 3.2. Tabla comparativa de trabajos relacionados Tabla 3.1. Tabla comparativa de trabajos relacionados CARACTERÍSTICA A COMPARAR TRABAJOS RELACIONADOS ACTUAL A B C D 1 Se desarrolló un prototipo 2 Herramienta de definición de catálogos 3 Módulo Administrativo 4 Multiplataforma 5 Basado en Web 6 Basado en XML 7 Modulo de pagos en línea 8 Configuración por medio de asistentes 9 Estructura del catálogo variable 10 Utiliza patrones de diseño, marcos de trabajo 11 Manejo de conexiones seguras 12 Categorías multinivel 13 Soporta varios tipos de moneda 14 Soporta varios idiomas 34
Capítulo 4 Arquitectura y diseño del sistema En este capítulo se presentan la arquitectura de los módulos del prototipo de tesis así como los detalles de implementación del mismo. 35
Capítulo 4. Arquitectura y diseño del sistema 4.1. Esquema general de operación del sistema Figura 4.1 Esquema general del sistema. Cabe mencionar la existencia de diferentes tipos de usuarios del prototipo, los cuales se muestran en la Figura 4.1. Por una parte están las PyMEs, las cuales accederán al sistema para publicar la información de su empresa y productos que comercializa, también están los usuarios de Internet, quienes podrán consultar la información que esté disponible de las empresas que han publicado su información dentro del prototipo; y finalmente están los administradores, quienes tendrán la responsabilidad de configurar y mantener la integridad del sistema. 4.2. Arquitectura detallada del sistema 4.2.1. Módulo de administración Las funciones del módulo de administración incluyen: generación de sitios de comercio electrónico, generación de reportes y estadísticas del estado de los múltiples sitios de comercio electrónico, y algunos aspectos de seguridad de la plaza virtual. 36
Capítulo 4. Arquitectura y diseño del sistema El módulo de administración (Figura 4.2) está diseñado para ser operado por el administrador del sistema, que tiene a su cargo la responsabilidad de configurar y mantener la integridad del sistema. Figura 4.2 Arquitectura del submódulo de creación de sitios de CE del módulo de administración. Para la creación de un sitio de comercio electrónico, el administrador del sistema debe acceder al módulo de administración y usar el asistente para la creación de sitios. Este toma como entrada los datos básicos de la empresa que desea contar con su sitio, y como salida se obtiene un sitio de comercio electrónico y los datos de autentificación para la empresa. Estos servirán para posteriormente acceder al módulo de catálogos, y así poder diseñar y editar sus páginas y su propio catálogo de productos. 4.2.2. Módulo de catálogos La arquitectura del módulo de catálogos se divide en tres secciones principales: edición, diseño y publicación. La función del submódulo de edición, mostrada en la Figura 4.3 es la de asistir al usuario (PyME) en la construcción del catálogo de productos de su propio sitio de comercio electrónico; primeramente en la edición de la 37