s.e.p. s.e.s. d.g.e.s.t. - cenidet...figura 2.2 arquit ectura del carrito de compras ..... 9 figura...

S.E.P. S.E.S. D.G.E.S.T.

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO

TECNOLÓGICO

c e n i d e t

ARQUITECTURA DE UN SISTEMA DE COMERCIO ELECTRÓNICO PARA PEQUEÑAS Y MEDIANAS EMPRESAS

T E S I S QUE PARA OBTENER EL GRADO DE: MAESTRO EN CIENCIAS EN CIENCIAS DE LA COMPUTACION

PRESENTA CARLOS BAEZA RIVERA

DIRECTOR DE TESIS DR. JOAQUÍN PÉREZ ORTEGA

CODIRECTOR DE TESIS M.C. JOSÉ ANTONIO ZÁRATE MARCELEÑO

CUERNAVACA, MORELOS AGOSTO 2005

II

Dedicatorias

Dedico ésta tesis primeramente a mis padres Juana Rivera Gutiérrez y Antonio

Baeza Castillo que en las buenas y en las malas nunca me han dejado a la deriva

y me han dado su apoyo incondicional. Además, de ser un ejemplo de conducta y

dedicación.

A mi esposa Miriam Paloma Serrano Morales por el apoyo que me ha brindado en

los momentos difíciles. Y por estar conmigo durante todo este tiempo.

A mi hija Karla Elizabeth Baeza Serrano que es lo mejor que he hecho en mi vida

y que siempre estará conmigo.

A mis suegros Elizabeth Morales Rivas y Fernando Serrano Cedillo que de una u

otra forma han colaborado para que logre mis aspiraciones profesionales.

III

Agradecimientos

A Dios por permitirme estar todavía dando guerra.

A todos los miembros del comité de revisión: M.C. Felipe de Jesús Alaniz

Quezada, M.C. Mario Guillen Rodríguez, M.C. Juan Gabriel González Serna.

A mi director y codirector de tesis: Dr. Joaquín Pérez Ortega y M.C. José Antonio

Zárate Marceleño.

A mi director de tesis Dr. Joaquín Pérez Ortega en especial, por haber dirigido

ésta tesis y darme sus valiosas sugerencias, su tiempo y su guía.

Al Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) por

permitirme estudiar la maestría.

Al Consejo del Sistema Nacional de Educación Tecnológica (COSNET), por darme

su apoyo financiero que me permitió hacer realidad una meta más en mi vida.

A todos mis compañeros y amigos que siempre me han brindado su ayuda y me

han dado ánimos para terminar mi maestría y salir adelante.

IV

Resumen

“América Latina tiene un futuro prometedor en el ámbito del Comercio

Electrónico” remarcan titulares en revistas y sitios de Internet, ese es un hecho

que se puede pronosticar de cuerdo a las estadísticas del crecimiento del

Comercio Electrónico en ésta zona del mundo. México refleja éste crecimiento, es

el segundo país después de Brasil en hacer la mayor cantidad de compras en

línea en América Latina.

El Comercio Electrónico se ha convertido en una herramienta valiosa para las

empresas que desean crecer y traspasar fronteras. Aquellas empresas que no

estén preparadas para adoptar éste nuevo modelo de negocios podrían quedar al

margen de éste crecimiento y no sólo eso, podrían estancar su desarrollo e

incluso ser absorbidas por aquellas que han modernizado su estructura

organizacional para adoptar los nuevos modelos de negocios con el fin de mejorar

sus procesos productivos y de ventas.

La mayoría de las grandes empresas ya adoptaron éste modelo de negocios, sin

embargo, hay un sector productivo de gran importancia al cual se le necesita

impulsar, la pequeña y mediana empresa (PYME). Éste sector tiene la

característica de contar con recursos económicos y tecnológicos limitados en

muchos de los casos.

Crear soluciones viables de Comercio Electrónico para la PYME, ayudarían en

gran medida a impulsar la competitividad y el crecimiento de éste sector

económico.

En este trabajo se ataca esta problemática desde varios ángulos:

V

1. Tecnológico. Proporcionando una arquitectura de software que sea

escalable, fácil de modificar y flexible,

2. Económico. Utilizando tecnologías y software de bajo costo o sin costo

alguno. Sin que por ello exista una limitación en el funcionamiento del

prototipo o su desempeño,

3. Funcional. Proporcionando un prototipo que cuente con todas las

características de un sitio de Comercio Electrónico, como son: cesta de

compras, catálogos en línea, registro de usuarios, protección de datos

confidenciales, y el proceso de pedido de productos.

La implementación y prueba exitosa de este prototipo lo pone como una

alternativa viable para la PYME, bajo dos esquemas diferentes. Como sistema a

implementar directamente en la empresa o utilizándolo sobre un hosting en el cual

residan varios sitios de Comercio Electrónico lo cual reduciría considerablemente

el gasto económico a la empresa. Además, muestra que es factible el desarrollo

de sistemas de Comercio Electrónico de bajo costo para la PYME.

Aunque el prototipo esté diseñado para un sitio de Comercio Electrónico, no

significa que se necesite realizar todo el proceso de compra hasta llegar al pago

en línea. Algunos negocios lo podrían utilizar para tener presencia en Internet y

publicitar tanto su empresa como sus productos y servicios. Llegando a más

clientes potenciales y sentando las bases para que a futuro se incluya la compra

en línea.

VI

Tabla de contenido

Pág.

Resumen …………………………………………………………………………… IV

Lista de figuras ………………….………………………………………………….. IX

Lista de tablas ………………………………………………………………………. XI

Glosario de acrónimos.……………………………………………………………... XII

Capítulo 1. Introducción……………………………………………………………. 1

1.1 Definición del problema.…………………………………………………….. 2

1.2 Objetivos…………………………………………………………………....... 3

1.3 Relación con otros trabajos……………………………………………….... 4

1.4 Organización del documento……………………………………………….. 4

Capítulo 2. Estado del arte…………………………………………………………. 6

2.1 El MVC arquitectura para el desarrollo de aplicaciones Web………...... 7

2.2 Trabajos en el área del Comercio Electrónico..………………………….. 14

Capítulo 3. Comercio Electrónico………………………………………………….. 18

3.1 Definición……………………………………………………………………… 20

3.2 Antecedentes históricos…………………………………………………….. 20

3.3 Beneficios del Comercio Electrónico..…………………………………….. 23

3.3.1 El Comercio Electrónico contra el comercio tradicional…………..... 25

3.3.2 Desventajas del Comercio Electrónico……………………………….. 25

3.4 Modalidades del Comercio Electrónico……………..…………………….. 26

3.5 El Comercio Electrónico en México…...…………………………………… 27

3.6 Pequeñas y medianas empresas…………………………………………... 28

3.6.1 Dificultades a las que se enfrenta la PYME…………………………. 29

3.6.2 Importancia del Comercio Electrónico para la PYME………………. 29

3.6.3 Impacto del Comercio Electrónico……………..……………………... 30

VII

3.6.3.1 Impacto del Comercio Electrónico sobre el empleo…………… 32

3.6.3.2 Impacto del Comercio Electrónico sobre la economía………… 32

Capítulo 4. Tecnologías y software de código abierto y de bajo costo………... 34

4.1 Tecnologías para el desarrollo Web……………………………………….. 35

4.1.1 J2EE de Sun como base para el desarrollo Web…………………… 36

4.1.2 HTML…………………………………………………………………….. 40

4.1.3 Hojas de estilo en cascada……………………………………………. 40

4.1.4 JavaScript……………………………………………………………….. 40

4.2 Software libre y de fuente abierta………………………………………….. 41

4.2.1 Licencias de software de fuente abierta……………………………… 42

4.2.2 Beneficios del software de fuente abierta……………………………. 44

4.3 Herramientas de fuente abierta para la construcción de un sitio Web… 44

4.3.1 Linux como servidor……………………………………………………. 45

4.3.2 PostgreSQL……………………………………………………………… 45

4.3.3 Apache Tomcat…………………………………………………………. 46

Capítulo 5. Arquitectura del sistema………………………………………………. 48

5.1 Patrones………………………………………………………………………. 49

5.1.1 Patrón de diseño arquitectónico MVC……...………………………… 50

5.1.1.1 Beneficios del MVC……………………………………………….. 52

5.2 Diseño de la arquitectura de software……………………………………... 52

5.2.1 El Modelo………………………………………………………………… 54

5.2.2 El Controlador..…………………………………………………………. 57

5.2.3 La Vista/Presentación..………………………………………………… 60

5.3 Gestión del catálogo….……………………………………………………… 63

5.4 Implementación………………………………………………………………. 65

5.4.1 El cliente…………………………………………………………………. 66

5.4.2 El servidor Web…………………………………………………………. 66

5.4.3 Configurar el manejador de base de datos………………………….. 71

VIII

5.4.4 Cargar y correr el sistema……………………………………………... 72

Capítulo 6. Pruebas…………………………………………………………………. 75

6.1 Escenarios de prueba..……………………………………………………… 76

6.2 Casos de prueba en el prototipo.………………………………………….. 76

6.2.1 Prueba 1: El catálogo..…………………………………………………. 77

6.2.2 Prueba 2: El carrito de compras……………….……………………… 80

6.2.3 Prueba 3: Registro de usuarios……………………………………….. 84

Capítulo 7. Conclusiones…………………………………………………………… 91

7.1 Comentarios finales………………………………………………………….. 92

7.2 Trabajos futuros……………………………………………………………… 93

Referencias…….……………………………………………………………………. 95

IX

Lista de Figuras

Pág.

Figura 2.1 Modelo 2 ....................................................................................... 8

Figura 2.2 Arquitectura del carrito de compras .............................................. 9

Figura 2.3 Flujo de trabajo del carrito de compras ........................................ 10

Figura 2.4 Arquitectura de desarrollo propuesta por ObjectStorm ................ 11

Figura 2.5 Diagrama en UML del patrón para el manejo de los catálogos .... 13

Figura 2.6 Estructura general de la arquitectura propuesta ........................... 14

Figura 2.7 Diagrama de clases del prototipo ................................................. 16

Figura 3.1 Crecimiento del Internet en México .............................................. 27

Figura 4.1 Estructura de una llamada a un Servlet ........................................ 37

Figura 4.2 Ejemplo de un página Web creada con JSP ................................ 39

Figura 4.3 Ejemplo del resultado de un trozo de código en HTML ................ 40

Figura 4.4 Mapeo de una petición en Tomcat ............................................... 47

Figura 5.1 La arquitectura MVC …................................................................. 50

Figura 5.2 Ciclo de servicio de la capa Web .................................................. 51

Figura 5.3 Modelo 2 ....................................................................................... 51

Figura 5.4 Arquitectura del prototipo de Comercio Electrónico ..................... 53

Figura 5.5 Modelo de tres capas ………………………………………………... 55

Figura 5.6 Elementos que componen el Modelo ........................................... 55

Figura 5.7 Diagrama en UML que muestra el enlace entre algunas clases

del Modelo …………………………………………………………….

57

Figura 5.8 El Controlador ............................................................................... 58

Figura 5.9 Proceso realizado por el Controlador ante la petición de un

catálogo ………………………………………………………………..

59

Figura 5.10 Páginas del prototipo de Comercio Electrónico …………………... 61

Figura 5.11 Código de una página JSP y su resultado en un navegador ........ 62

Figura 5.12 Escenario básico del sitio de Comercio Electrónico ..................... 65

Figura 6.1 Catálogo de monitores antes y después de la actualización ……. 79

X

Figura 6.2 Carrito de compras con cuatro productos agregados ………..….. 82

Figura 6.3 Carrito de compras después de borrar dos productos ................. 83

Figura 6.4 Cambio de protocolo antes de pasar a la pantalla de login de

usuarios ………………………………………………………………..

85

Figura 6.5 Error generado al teclear un login y contraseña inexistente ……. 86

Figura 6.6 Errores generados por campos dejados en blanco ....…………… 88

Figura 6.7 Mensaje generado por la introducción de datos incorrectos

página de envío ……………………………………………………….

88

Figura 6.8 Pantalla de confirmación del registro de información de usuario . 90

Figura 7.1 Arquitectura del prototipo de Comercio Electrónico ..................... 92

XI

Lista de Tablas

Pág. Tabla 3.1 Comparación del Comercio Electrónico contra el comercio

tradicional ....................................................................................

25

Tabla 3.2 Desventajas del Comercio Electrónico .......................... ............ 26

Tabla 4.1 Comparación Servlets contra CGI ........................... .................. 38

Tabla 5.1 Estructura jerárquica de un LCD en el estándar de clasificación

UNSPSC ……………………………………………………………..

64

Tabla 5.2 Algunos atributos del archivo server.xml ............................ ....... 71

Tabla 5.3 Variables del sistema contenidas en el archivo “web.xml” .......... 74

Tabla 6.1 Elementos a actualizar en el catálogo de productos ……………. 78

Tabla 6.2 Elementos agregados al carrito de compras …………………….. 81

Tabla 6.3 Resultado esperados ante la inserción los productos ………….. 81

Tabla 6.4 Elementos a eliminar del carrito de compras ……………………. 82

Tabla 6.5 Resultado esperado ante la eliminación de productos …………. 83

XII

Glosario de acrónimos

PYME Pequeñas y Medianas Empresas.

MVC Modelo-Vista-Controlador, por sus siglas en inglés (Model-View-

Controller).

SSL Capa de Comunicación Segura, por sus siglas en inglés (Secure

Sockets Layer).

EJB JabaBeans Empresariales, por sus siglas en inglés (Enterprise

JavaBeans).

ISP Proveedor de Servicios de Internet, por sus siglas en inglés (Internet

Service Provider).

J2EE Edición Empresarial de la Plataforma Java, por sus siglas en inglés

(Java 2 Enterprise Edition).

ARM Administración de las Relaciones con el Cliente, por sus siglas en

inglés (Customer Relationship Management).

ASP Proveedor de Servicios de Aplicación, por sus siglas en inglés

(Application Service Providers).

EDI Intercambio Electrónico de Datos, por sus siglas en inglés

(Electronic Data Interchange).

DARPA Agencia de Proyectos de Investigación Avanzada de Defensa, por

sus siglas en inglés (Defense Advanced Research Project Agency).

ARPANET Por sus siglas en inglés (Advanced Research Projects Agency

Network).

NSF Fundación Nacional de Ciencia, por sus siglas en inglés (National

Science Fundation).

CERN Centro Europeo para la Investigación Nuclear, por sus siglas en

francés (Centre Européen pour la Recherche Nucléaire).

NCSA Centro Nacional para Aplicaciones de Súper Computo, por sus

siglas en inglés (National Center for Supercomputing Applications).

TIC Tecnologías de la Información y la Comunicación.

XIII

PIB Producto Interno Bruto.

TI Tecnología de la Información.

CGI Por sus siglas en inglés (Common Gateway Interfase).

JDBC Conectividad de Base de Datos con Java, por sus siglas en inglés

(Java Database Connectivity).

HTML Lenguaje para Marcado de Hipertexto, por sus siglas en inglés

(Hypertext Markup Language).

HTTP Protocolo de Transferencia de Hipertexto, por sus siglas en inglés

(Hyper Text Markup Language).

IP Protocolo de Internet, por sus siglas en inglés (Internet Protocol).

JSP Páginas de Servidor de Java, por sus siglas en inglés (JavaServer

Pages).

SSL Capa de Conexión Segura, por sus siglas en inglés (Secure Sockets

Layer).

TCP Protocolo de Control de Transmisión, por sus siglas en inglés

(Transmision Control Protocol).

LCD Monitor de Cristal Líquido, por sus siglas en inglés (Liquid Crystal

Display).

URL Localizador de Recursos Uniforme/Universal, por sus siglas en

inglés (Uniform Resource Locator).

UNSPCS Estándar de Clasificación de Productos y Servicios de la Naciones

Unidas, por sus siglas en inglés (United Nations Standard Products

and Services Code).

XHTML Extensible HTML, por sus siglas en inglés (Extensible HiperText

Markup Language).

XML Lenguaje de Marcas Extensible, por sus siglas en inglés (Extensible

Markup Language).

1

Capítulo 1

Introducción

En este capítulo se define el problema a bordar y los objetivos de la tesis.

Capítulo 1. Introducción

2

Tal como los cimientos y la estructura metálica de un edificio son la base

para su construcción y sobre la cual se colocaran sus demás elementos, así de

igual forma, la arquitectura de un sistema de software es la base sobre la cual se

inicia su desarrollo. De la arquitectura elegida o creada se deducirán diversas

conclusiones, tales como: si es robusta, fácilmente extensible y de fácil

mantenimiento. Sin embargo, existen factores que influyen en la adopción o

creación de una arquitectura y que deben ser tomados en cuenta para obtener el

comportamiento y los resultados esperados. Por ejemplo, no sería factible que se

incorporaran componentes que involucraran el uso de software de un costo

significativo si la arquitectura está dirigida a optimizar los gastos de

implementación.

El diseño o adopción de la arquitectura correcta es importante, nos permite saber

el comportamiento del sistema, los componentes o módulos principales que

integran el sistema, así como, la interrelación entre ellos. Con el conocimiento de

estos elementos es más sencillo definir el software y tecnologías de desarrollo, así

como, el software necesario para la implementación.

El presente trabajo expone una arquitectura para el desarrollo de sistemas de

Comercio Electrónico, la cual va dirigida a un sector en especial que es el sector

de la PYME. El hecho de enfocar el trabajo a un sector en especial está motivado

por el potencial que tiene en nuestro país, ya que conforma el 98 % de las

empresas activas, sin embargo, a pesar de la importancia que tiene este sector,

muchas de las empresas que lo conforman no tienen acceso por diversas razones

a tecnologías o modelos de negocios que podrían mejorar su situación

organizacional y económica.

1.1 Definición del problema

El creciente desarrollo del Internet, así como, sus tecnologías han dado un

fuerte impulso al desarrollo de mercados digitales así como a nuevos modelos de


3

negocios. Las grandes firmas estuvieron entre las primeras en hacer la transición

a ésta economía digital, sin embargo existe un sector, que es el sector de la PYME

que en muchos de los casos no ha podido incorporarse a este nuevo modelo de

negocios el Comercio Electrónico [Davis99]. Algunos de los factores que han

contribuido a este hecho son los siguientes:

• Carencias relacionadas con la infraestructura,

• Disponibilidad de personal con conocimientos de tecnologías de la información,

• La falta de recursos financieros,

• Acceso limitado a la información y la especialización en el área del Comercio

Electrónico,

• En general las aplicaciones TI (Tecnología de la Información) son más usadas

por los grandes negocios debido a sus altos costos y su poca adaptación a las

necesidades de las PYME’s.

Analizando tal situación, el presente trabajo proporciona un mecanismo para que

la PYME cuente con una alternativa más para su incorporación al Comercio

Electrónico.

1.2 Objetivos

Son varios los objetivos que tiene la tesis, entre los cuales se encuentran:

1) Proponer una arquitectura para un sistema de Comercio Electrónico que

integre componentes de bajo costo y que esté orientada a la PYME.

2) Desarrollar un prototipo basado en la arquitectura propuesta, con la

finalidad de mostrar la factibilidad de la solución,

3) Asimilar y usar componentes de bajo costo para el desarrollo del prototipo.


4

Todo esto con la finalidad de que el sector de la PYME tenga otra opción de

acuerdo a sus posibilidades de entrar a esta nueva estrategia de comercio, como

lo es el Comercio Electrónico.

1.3 Relación con otros trabajos

El proyecto es el comienzo de una serie de trabajos que se han iniciado en

el CENIDET, en el área de Comercio Electrónico. Otros de los trabajos que se

están realizando en esta área son: Sistemas de pago en el Comercio Electrónico y

un portal para el Web.

1.4 Organización del documento

En esta sección se describen de manera general los capítulos de este

documento. En resumen los capítulos subsecuentes contienen la siguiente

información:

Capítulo 2. Estado del arte

En este capítulo, se muestran diversas investigaciones hechas sobre el Comercio

Electrónico.

Capítulo 3. Comercio Electrónico

En este capítulo, se dan los conceptos básicos del Comercio Electrónico, así como

sus características principales, además, se da una panorámica general de lo que

es el Comercio Electrónico y como ha repercutido en la sociedad y cuales son los

beneficios de adoptarlo.

Capítulo 4. Tecnologías y software de código abierto y de bajo costo


5

Existen muchas tecnologías para el desarrollo Web, propietarias y no, aquí

únicamente se analizan las tecnologías usadas para el desarrollo de la tesis, se da

una descripción breve de sus características y el porque de su uso. También se

habla del software usado para el desarrollo e implementación del sistema.

Capítulo 5. Arquitectura del sistema

En este capítulo, se muestra el patrón de diseño utilizado para el desarrollo de la

arquitectura, se analizan cada uno de los elementos que conforman la arquitectura

y se dan los pasos para la implementación del sistema.

Capítulo 6. Pruebas

Se describen cada una de las pruebas de funcionamiento que se le realizaron al

sistema.

Capítulo 7. Conclusiones

En este capítulo se dan los comentarios finales del trabajo de investigación y se

muestran trabajos futuros que podrían realizarse en esta misma línea de

investigación.

6

Capítulo 2

Estado del arte

En este capítulo se analizan varios trabajos realizados al área del Comercio

Electrónico a nivel nacional e internacional.


7

El estado del arte de toda investigación además de mostrarnos los estudios

más significativos nos da una referencia del nivel en que se encuentra una

investigación, es decir, nos indica si la investigación está en la frontera del

conocimiento, si está haciendo una aportación a un área del conocimiento, si

utiliza una estrategia de solución diferente, etc. De ahí surge la necesidad de

incluir un apartado del estado del arte en una investigación. A continuación se

describirán algunos trabajos relacionados con el Comercio Electrónico así como

arquitecturas para este tipo de sistemas.

2.1 El MVC arquitectura para el desarrollo de aplic aciones Web

Desde los principios de la computación se han buscado soluciones

computacionales a problemas específicos y repetitivos. Tal el caso del MVC patrón

arquitectónico creado por los desarrolladores de Smalltalk para la construcción de

interfaces de usuario en Smalltalk-80 [Krasner88]. Las partes que componen el

MVC son el Modelo que compone el núcleo de la funcionalidad del sistema, la

Vista es la presentación en pantalla con la que interactúa el usuario y el

Controlador que se encarga de manejar como el usuario interactúa con los objetos

de la Vista y decide que hacer en el Modelo y la Vista de acuerdo a los eventos

generados por el usuario.

Los beneficios que proporciona el uso del MVC son escalabilidad y facilidad de

mantenimiento además de incrementar la flexibilidad y rehúso de un sistema de

software.

A pesar de que el MVC fue concebido originalmente para la construcción de

interfaces de usuario, sus características lo han colocado como una solución para

el desarrollo de aplicaciones Web y lo podemos constatar leyendo las

recomendaciones que hace Sun Microsystems para el desarrollo de aplicaciones

Web usando sus tecnologías [Singh02]. Una implementación del MVC utilizando


8

las tecnologías de Sun (Servlets, JSP y Javabeans) se encuentra en el Modelo 2

de Java Server Pages mostrado en la siguiente figura:

Figura 2.1 Modelo 2

Desde su recomendación el MVC ha sido análisis de diversos trabajos

relacionados con el desarrollo de sistemas de Comercio Electrónico y de

aplicaciones Web en general. Por ejemplo, Gary Bollinger y Bharathi Natarajan

[Bollinger00] en su trabajo utilizan el MVC para la construcción de un carrito de

compras para el Comercio Electrónico y muestran las ventajas de su uso por la

clara separación de cada uno de sus componentes, lo que permite la evolución,

rehúso y desarrollo por separado de cada uno de ellos.

El escenario es una tienda de productos en línea simplificada. Donde el cliente

selecciona productos para agregar al carrito de compras, posteriormente navega

por una serie de formularios para comprar los artículos. En la Figura 2.2 se

muestra la combinación de todos los elementos.

En el diagrama que muestra la arquitectura (Figura 2.2), se puede reconocer los

tres elementos de MVC aplicados a la construcción del carrito de compras. El

Servlet cliente controla el marco de trabajo de la aplicación. Mantiene el estado de

la cesta de compras (implementado por el bean cesta) y la ruta de de respuesta a

(controlador) Servlet

(vista) JSP

N A V E G A D O R

(Modelo)

JavaBean

1

2 3

4

5

Instancia

Petición

Respuesta

Servidor de aplicación Fuente de

datos


9

los clientes a través de una serie de páginas JSP. El carrito de compras es

asociado a la cesión del cliente.

El Bean cesta implementa un manejo simple de los datos (Modelo) del carrito.

Contiene un método para obtener el total de las compras del cliente y para

actualizar su contenido. Cada elemento es almacenado con los siguientes

atributos: clave, nombre del producto, precio, y número de elementos comprados.

Figura 2.2 Arquitectura del carrito de compras

La página inicial donde el cliente navega en busca de un producto es

inventario.jsp. Después de seleccionar un producto a comprar se muestra la

página compra.jsp. Finalmente cuando el usuario confirma la compra la aplicación

muestra confirmación.jsp.

Cliente Lógica de aplicación

Motor de servlet

JVM

Servletcliente Servidor Web

Bean cesta

Bean recibo

inventario.jsp compra.jsp confirmacion.jsp

Motor de JSP

Petición

Respuesta

HTTP


10

Figura 2.3 Flujo de trabajo del carrito de compras

La utilización del MVC no sólo se ha dado en el desarrollo de soluciones

específicas para el Comercio Electrónico, también, se ha utilizado en arquitecturas

empresariales de gran envergadura como es el caso del sistema de e-business de

ObjectStorm [ObjectStorm01] el cual tiene las siguientes características:

a) Un sistema construido sobre una arquitectura escalable. De este modo,

componentes (p.e. hardware, software y mejoras al sistema) pueden ser

agregados o removidos de forma dinámica para mantener un alto nivel

de funcionalidad y calidad de ejecución para los usuarios del sistema,

b) Un sistema capaz de mantener una alta disponibilidad de todos los

componentes,

c) Una arquitectura de sistema que se enfoca en la necesidad de facilidad

de integración con productos de terceros y compañías externas,

d) Una arquitectura de sistema basada en modelos de arquitectura de

componentes estándares de la industria para mejorar la habilidad de

diseñar y cargar soluciones arquitectónicas de n-capas, alrededor de

tecnologías de componentes tales como Java Server Pages (JSP) y

Enterprise Java Beans (EJB),

e) Un sistema que incluye funcionalidad estándar: balance de carga,

recuperación a fallas, administración de transacciones, administración

de la seguridad y administración de operaciones,

f) Una arquitectura de sistema que es independiente de la plataforma y del

sistema operativo,

Agregar a carrito

Navegador

Servletcliente

Nuevo\Actualizar

Navegador Navegador Navegador

Servletcliente Servletcliente

inventario.jsp compra.jsp confirmaci.jsp

Actualizar Comprar

Compra

Comprar del carrito Confirmar compra

Confirma

Muestra recibo


11

g) Un sistema de arquitectura abierta y de fácil extensibilidad,

h) Un sistema que puede ser hospedado en un ISP,

i) Una arquitectura de sistema que puede ser implementada en fases.

Ésta arquitectura usa el paradigma de la programación orientada a objetos

aplicado a las Java Server Pages (JSP), con las que se desarrolló el Object Server

Pages (OSP) tag library de ObjectStorm. ObjectStorm promueve el uso del MVC

para el desarrollo, con la finalidad de separar el código java del HTML.

Figura 2.4 Arquitectura de desarrollo propuesta por ObjectStorm

El Comercio Electrónico ha tenido un crecimiento constante desde sus inicios, por

lo que existen una variedad de patrones y arquitecturas aplicadas a la

implementación de sistemas Web enfocados al Comercio Electrónico, sin

embargo, no están bien documentadas [Widhani02].

Se han desarrollado trabajos relacionados con arquitecturas para el desarrollo de

sistemas de Comercio Electrónico, por ejemplo, André Widhani [Widhani02] con

otros colaboradores desarrollaron un patrón para el manejo de los catálogos en los

sitios de Comercio Electrónico, entre los requerimientos que se buscan y que este

patrón soluciona son:

Bean de lógica

Redirección

Redirección

Servidor

Datos

del sistema Respuesta

Acción de usuario

Acción de usuario

Respuesta del sistema Cliente

delgad o

Servidor Web

Cliente delgado

Java Bean

Java

Beans

Java Bean

<OSP> (Vista)

(Controlador) (Controlador)

(Modelo)

<Swing> (Vista)


12

• Soporte para categorías anidadas,

• Posibilidad de asignar los artículos a múltiples categorías,

• Soporte inteligente para variaciones de un producto base (por ejemplo: un

elemento que está disponible en diferentes tamaños),

• Los atributos de los productos deben ser suficientemente flexibles para

soportar peculiaridades de los productos, pero también debe ser fácil la

asignación de atributos comúnes a todos los productos,

• Compatibilidad con los principales esquemas de clasificación, como

UN/SPSC o Ecl@ss.

La solución propuesta por este trabajo se muestra en la Figura 2.5, donde el

catálogo sirve como nodo raíz, debajo este nodo raíz tiene un número de

categorías, las cuales pueden estar anidadas y los productos están ligados a

categorías. Hay propiedades que todos los productos tienen en común, a éstas se

les llaman atributos fijos. Los Atributos de tipo de producto son los atributos que

ciertos tipos de productos tienen en común. Un ejemplo de un atributo de tipo de

producto son el número de páginas para un producto de tipo libro.

Un producto base puede tener variaciones entre otros productos, en color,

tamaño, etc., es decir variaciones en sus propiedades así como en el precio.

Variaciones:

• Se debería asignar el precio a una variación del producto, no al producto

base, puesto que existen diferencias de precio entre ellas. En caso de ser el

mismo precio, se asocia al producto base para no repetir los precios en

cada variación,

• También pueden ser necesario atributos que sean definidos de forma libre,

a éstos se les llama atributos personalizados.


13

Figura 2.5 Diagrama en UML del patrón para el manejo de los catálogos

García [García01] en su trabajo muestra una arquitectura para el Comercio

Electrónico enfocada a las pequeñas y medianas empresas. Entre los objetivos

que se persiguen en este trabajo están los de introducir al sector de las PYME´s a

este nuevo modelo de negocios por Internet, introduciendo los principales

servicios para un desarrollo estratégico del Comercio Electrónico, reduciendo la

cantidad de recursos necesarios para la organización.

El enfoque principal del producto es la venta por catálogo en Internet, la cual es

soportada por dos componentes principales: un servidor Web de Comercio

Electrónico y una herramienta visual de diseño de catálogos. La herramienta de

diseño permite la definición, publicación y actualización de catálogos de productos

y el servidor Web permite acceder ellos. La Figura 2.6 muestra las entidades más

representativas, con los principales flujos de comunicación.

Catálogo

Atributos fijos

Atributos personalizados

Tipos de producto

Categorías

Variación del prod.

Productos Atributos de tipo producto

Variación de propiedad Variación de valores.

0..* 1

1 0..*

Asociación

Agregación


14

Figura 2.6 Estructura general de la arquitectura propuesta

2.2 Trabajos en el área del Comercio Electrónico

Existen otros trabajos que se enfocan en la creación de soluciones que

tienen que ver más con el funcionamiento, características o desarrollo de un sitio

de Comercio Electrónico en su totalidad, por ejemplo Héctor Castillo [Castillo02]

en su trabajo de tesis, hace un análisis de los resultados negativos que han

obtenido algunas empresas al tratar de incursionar en el Comercio Electrónico y

da una solución computacional a algunos de ellos.

Los resultados que arrojó este análisis son que muchos de los negocios “.com” no

tienen éxito por no tener un concepto claro del negocio, y por el desconocimiento

generalizado sobre las estrategias más básicas para comunicar y dar servicio de

forma adecuada en Internet. Otros de los principales problemas se basan en el

diseño del sitio desde el punto de vista comercial y funcional.

Compras

Banco

Cliente final

Sistema de pago Diseño de e-catálogos

Herramienta visual para el diseño de catálogos

Administración del comercio

Servidor de e-comercio

Publicación

Organización proveedora


15

Enfocado al diseño de un sitio Web se dan las siguientes directivas: estética,

grandes ideas, utilidad, facilidad de búsqueda y personalización. Como estrategia

general: crear un sitio de Comercio Electrónico donde se de una interrelación y

comunicación efectiva de la empresa con otras empresas. Esta estrategia general

se divide en:

• Una estrategia de diseño sobre el contenido y la funcionalidad del sistema.

• Estrategia para la implementación del sistema.

La estrategia de diseño sobre el contenido y la funcionalidad deberá contemplar

los siguientes aspectos:

• Dar confianza de venta y de compra entre las empresas.

• Que el sistema sea explícito en cada una de sus secciones.

• Que el sistema sea interactivo.

• Que sea fácil de operar.

La estrategia para la implementación del sistema de Comercio Electrónico deberá

contemplar lo siguiente:

• El equipo donde residirá el sistema de Comercio Electrónico.

• La conectividad.

• La base de datos que soportará la administración de la información.

• El servidor Web.

• La seguridad.

• La reingeniería de los procesos del negocio.

La última parte del trabajo muestra el resultado de una fase de análisis previa que

no detallaremos por la extensión de ésta, a continuación se muestra el diagrama

final de clases del sistema.


16

Otros trabajos realizados en México en el área del Comercio Electrónico son:

� Proceso unificado aplicado al desarrollo de un sistema de Comercio

Electrónico con J2EE [Ortega02]

Este trabajo utiliza el proceso unificado para el desarrollo de un sistema de

Comercio Electrónico que se implementará con el Java 2 Enterprise Edition

(J2EE) y el objetivo que persigue es el desarrollo de un sistema de Comercio

Electrónico llamado sistema de ventas café el cual se ocuparía para la venta

de CD’s, DVD´s y libros.

Figura 2.7 Diagrama de clases del prototipo

Presenta un Presenta un Envía

Envía Esta en

Vendida por

Vendido por

Vendida a

Pedido por Contiene

Cotizado en

Contiene

Especificado por

Especificado por

Cotizado

Se encuentra en en


17

Este sistema contiene un catálogo de productos en el cual el cliente puede

seleccionar sus productos también cuenta con un carrito de compras y un

módulo generador de pedidos.

� Arquitectura para un sistema de información con aplicación en Comercio

Electrónico [Pérez01]

El objetivo de esta tesis de maestría es definir una arquitectura para un sistema

de información que integre diferentes tipos de formatos de datos, tomando en

cuenta a las empresas, sus necesidades y las tecnologías de información

necesarias para poder integrarse y permitir la incursión en el Comercio

Electrónico.

En este trabajo se abordan los siguientes elementos relacionados con el

objetivo descrito:

• Muestra un panorama general de los sistemas multibase de datos en el

Web; su arquitectura, diseño y los componentes que lo integran,

• El Comercio Electrónico y su relación con los sistemas multibase de datos.

• Soluciones CRM (Customer Relationship Management) y ASP (Application

Service Providers) para el Comercio Electrónico,

• Tecnologías de información para el Comercio Electrónico,

• Análisis de las tecnologías Java, ASP, Corba y XML.Arquitectura para un

sistema de información de Comercio Electrónico con distintas fuentes de

datos,

• Un enfoque especial en la PYME.

Los trabajos mostrados en este capítulo son una pequeña recopilación de la

cantidad considerable de investigaciones que existen y están relacionadas con el

Comercio Electrónico, sin embargo, nos da una panorámica de las investigaciones

y soluciones que se están proponiendo en esta área de investigación.

18

Capítulo 3

Comercio Electrónico

En este capítulo se mencionan aspectos del Comercio Electrónico tales como:

definición, antecedentes, características y modalidades. También, se muestran

algunas características de la PYME y el impacto del Comercio Electrónico sobre la

PYME.

Capítulo 3. Comercio electrónico

19

La evolución del mundo tecnológico cada vez es más rápida y junto con él

también evoluciona la forma de vida de las personas. En la historia existen

muchos ejemplos de este acontecimiento tenemos el caso de la máquina de vapor

que le dio el impulso decisivo a la Revolución Industrial cambiando de forma

definitiva, la manera en como se realizaban muchos procesos industriales, así

como, la forma de vida de la gente que se encontraba alrededor de este

acontecimiento, convirtiendo simples poblaciones en ciudades industrializadas y

por consecuencia cambiando el estilo de vida campirano a un estilo de vida más

socializado acorde a una ciudad industrializada. Otro de los grandes

descubrimientos que sin duda ha cambiado el estilo de vida de las personas es la

electricidad, que desencadenó una cantidad interminable de invenciones que

permiten a las personas vivir más cómodamente y realizar sus actividades

cotidianas de forma más sencilla o en algunos casos automatizarlas, tal es la

revolución que ha causado la electricidad, que actualmente las personas

consideran a muchos de los aparatos y máquinas que funcionan a base de

electricidad indispensables.

El Internet como parte de la evolución tecnológica que se gesta día con día,

también ha causado un gran impacto en la sociedad, la comunicación de asuntos

empresariales, de negocios, personales e incluso amorosos se da sobre el Internet

con el simple hecho de sentarse frente a una computadora e interactuar con un

navegador u otro tipo de herramientas creadas para este fin. De igual manera

muchas otras tareas se pueden realizar sobre este medio. Las empresas al darse

cuenta de las ventajas del uso del Internet, así como de su potencial, iniciaron su

incursión en la red, primero utilizándola como medio de publicidad y

posteriormente como medio para realizar transacciones comerciales. El Internet no

sólo permite a la empresa la venta de productos sino también de servicios, este

hecho a sido bien explotado por las empresas ofreciendo éstos al consumidor

final.


20

El impacto que tiene el Internet como el Comercio Electrónico lo podemos percibir

al ver la cantidad de personas que acceden al Internet, compran artículos, buscan

información, o realizan otro tipo de actividad como parte de su vida cotidiana.

3.1 Definición

Existen muchas definiciones para el Comercio Electrónico de las cuales

únicamente se mencionarán algunas:

• Comercio Electrónico es un amplio concepto que cubre cualquier

transacción comercial que es efectuada por medio de recursos electrónicos

y podría incluir medios tales como fax, telex, EDI, Internet y el teléfono

[Melissa98].

• Es la posibilidad de realizar transacciones comerciales empleando medios

electrónicos

• El intercambio de información de negocios, mantener relaciones de

negocios y realizar transacciones de negocios mediante redes de

telecomunicación [Bidgoli01].

3.2 Antecedentes históricos

Para conocer los antecedentes del Comercio Electrónico es necesario

conocer la historia del Internet que es uno de los medios más importantes sobre el

cual se realiza este tipo de modalidad comercial y es el que se utilizó en el

proyecto de tesis.

La historia del Internet se puede dividir en tres fases. La primera fase fue la “fase

militar” cuyo objetivo era desarrollar una red de computadoras la cual fuera lo

suficientemente robusta para la transmisión de datos, aun si uno o más nodos


21

hubiesen sido incapacitados por un ataque nuclear. En 1969 investigadores y

científicos de la DARPA (Defense Advanced Research Project Agency) del

Pentágono puso en funcionamiento una red experimental creada para apoyar la

investigación del Departamento de Defensa, nombrada ARPANET (Advanced

Research Projects Agency Network). En la década de los 70’s la red fue

expandida para incluir universidades, laboratorios militares y laboratorios de

investigación. A finales de los 70’s la red contaba con alrededor de 100

computadoras conectadas.

La “fase científica” del Internet inicio en 1983 cuando las autoridades de la USA

deciden remover los sitios militares de la ARPANET. Los sitios restantes de

universidades y de instalaciones de investigación académica que se encontraban

en la red fueron colocados en la NSF (National Science Fundation). En 1985 y

1986 la NSF conecta seis supercomputadoras centrales para crear la NSFNET. El

uso principal del Internet fue el académico, además de ser su principal fuente de

innovación. La NSFNET fue habilitada para conectar redes regionales, nacionales

e internacionales, además de que proporcionaba servicios como el intercambio de

archivos y comunicación a las universidades y centros de investigación, con lo que

el número de computadoras enlazadas a la NSFNET se fue incrementando. La

expansión se facilitó grandemente con la adopción del estándar TCP/IP, que es un

protocolo de red que se adoptó en el año de 1983. Para finales de la década el

número de computadoras enlazadas al Internet se incrementó a 100,000.

Alrededor de este tiempo la CERN (por sus siglas en francés Centre Européen

pour la Recherche Nucléaire; Centro Europeo para la Investigación Nuclear) en

Europa y varios laboratorios de física de USA inician el uso del Internet para el

intercambio de datos de prueba y documentos. Sin embargo, algunos de los

problemas con los que se encontraban los usuarios del Internet fueron: como

encontrar, retornar y leer información del Internet. Hacia fines de 1989 Tim

Berners-Lee propone un sistema de hipertexto de red para la CERN.

Coincidentemente, Rober Cailliau ha propuesto un proyecto de hipertexto para el


22

manejo de documentación dentro del CERN. En 1990 los dos trabajos unidos se

presentan como un trabajo más refinado para un sistema de hipertexto y a finales

de ese año el prototipo básico del sistema fue probado, marcando el inicio del

WWW (World-Wide Web). El sistema prototipo incluía un navegador WWW, un

servidor de información y una librería implementando las principales funciones

para que los desarrolladores construyeran su propio software.

Este prototipo fue muy sofisticado, además, de estar únicamente disponible para

máquinas NeXT las cuales no eran de amplio uso. Posteriormente se crea Mosaic

en el año de 1993 por la NCSA (National Center for Supercomputing Applications),

el cual contaba con una interfaz amigable, además de poder correr sobre

plataformas UNIX, Macintosh y PC. Convirtiéndose en el primer navegador Web

gráfico popular.

El rápido crecimiento del Internet da inicio a la “fase comercial”. Lo que fue un

proyecto académico se convirtió, en la última gran novedad en los campus y las

grandes empresas. Un importante paso fue la creación del Commercial Internet

Exchange (CIE) en 1991 que se encargaba de regular el tráfico del los ISP’s

comerciales y fue un importante ímpetu para el crecimiento de los ISP

comerciales. El 30 de abril de 1995, la NSFNET fue convertida en varios sitios

comerciales. El poder administrativo de la NSF se transfirió a un nuevo cuerpo

llamado el InterNIC, el cual provee direcciones de red y otros servicios de soporte

básicos. Es en este mismo año cuando se gestan los inicios del Comercio

Electrónico [Windrum99, Slater02].

En 1995 Internet tenía más de 4 millones de sistemas conectados y el número

oficial de direcciones .com superaba al número de páginas educativas y de

investigación juntas, es en este año donde se puede decir que fue el inicio del

Comercio Electrónico. Dado los antecedentes principales del Internet, queda una

pregunta por responder y que se deduce hasta cierto grado de lo ya descrito ¿Qué

es el Internet? Aquí se exponen algunas definiciones.


23

• La inmensa colección de redes de computadoras que forman y actúan

como una sola red grande, para el transporte de datos y mensajes a través

de distancias que pueden ser desde la misma oficina o algún lugar en el

mundo.

• Una red global de computadoras usadas para el intercambio de datos

[Deitel01].

• Sistema de computadoras conectadas en red pública en todo el mundo

[Frias00].

3.3 Beneficios del Comercio Electrónico

Varias de las características ventajosas del Comercio Electrónico son

heredadas del medio que utiliza en este caso el Internet. El Internet puede

aumentar la velocidad y la exactitud de las comunicaciones entre proveedores,

distribuidores y consumidores. El Comercio Electrónico puede realzar la cadena

de valor al identificar nuevas oportunidades para reducir costos. Los siguientes

son algunos ejemplos:

• Reducción de costos: por el uso del e-mail para la notificación a clientes en

lugar del correo tradicional.

• Generación o mejora de ingresos: la venta a usuarios remotos usando el sitio

Web de la compañía.

• Mejora de los productos o servicios: ofrecer los servicios al cliente en línea o

identificación de nuevos canales de venta.

• Obtener conocimiento adicional de clientes potenciales.

• Mejora el servicio al cliente.

• Mejora la relación con los proveedores.

• Mejora las relaciones con la comunidad financiera.

• Incrementa flexibilidad y facilidad de compra


24

Muchas empresas están tomando ventaja del Comercio Electrónico para reducir

costos, mejorar sus ingresos e incrementar los servicios al cliente.

El Comercio Electrónico crea nuevas oportunidades para mantener de forma

sencilla la cooperación ente diferentes grupos: sucursales de una compañía

multinacional pueden compartir información para lanzar una campaña de

mercadeo; compañías trabajan juntas para diseñar y construir un nuevo producto

o servicio o compartir información de negocios para mejorar las relaciones con el

cliente.

En una encuesta realizada por SVM E-Business Solutions determinó que los

negocios electrónicos forman parte importante de las operaciones actuales y

futuras de las empresas de manufactura en Estados Unidos. El 77% indicó que

durante el 2004 los negocios electrónicos fueron extremadamente importantes

para su negocio actual, y el 83% indica lo mismo para los próximos 12 a 18 meses

[Deltaasesores05].

Las áreas en las cuales se han obtenido beneficios según los resultados de la

encuesta son:

72% Mejor comunicación con clientes

44% Mejor posición competitiva

44% Mejoría en la eficiencia, ahorro de tiempo

43% Aumento en ingresos

35% Reducción de costos / ahorros

28% Aumento en utilidades

28% Mejoría en la comunicación con empleados

26% Aumento en la productividad

24% Mejoría en la comunicación con socios de negocios/Proveedores

10% Poco o ningún beneficio obtenido


25

3.3.1 El Comercio Electrónico contra el comercio t radicional

Aquí se muestran algunas de las diferencias entre el comercio tradicional y

el Comercio Electrónico.

Actividad Comercio tradicional Comercio Electrónico

Horario Restringido de 9 A.M. a 5 P.M.

de lunes a sábado por ejemplo.

Las 24 horas y los 7 días de la

semana

Venta En la localidad donde se

encuentra

En el país y con la opción de vender

fuera del país

Atención a los clientes Llamadas telefónicas de los

clientes

Correo electrónico o llamadas

telefónicas

Volumen de ventas e

inventario

Vende x número de productos y

mantiene 1 o varios en almacén

Puede vender cualquier cantidad de

productos. No necesita mantener

productos en inventario.

Contacto con

proveedores

Pedidos por teléfono Pedidos vía correo electrónico, un

sistema automatizado o teléfono

Promoción Periódico, páginas amarillas o

el boca a boca

Motores de búsqueda, prensa,

enlace en los sitios de los

proveedores, correo electrónico y

sitios especializados en promoción

Información de los

productos

Revistas y folletos Catálogos en línea del sitio Web

Verificar disponibilidad

del producto

Teléfono, fax y revista E-mail, sitio Web

Tabla 3.1 Comparación del Comercio Electrónico contra el comercio tradicional

3.3.2 Desventajas del Comercio Electrónico

Cada modelo de negocios presenta ventajas y desventajas. Algunas de las

desventajas del Comercio Electrónico se muestran en la siguiente tabla.


26

Tabla 3.2 Desventajas del Comercio Electrónico

Problemas de ancho de banda

Problemas de seguridad

Accesibilidad (No todos están conectados al Web)

Aceptación (No todos aceptan esta tecnología)

Carencia de comprensión de los objetivos y estrategias de negocios

3.4 Modalidades del Comercio Electrónico

Aunque existe una cantidad creciente de modalidades de Comercio

Electrónico, únicamente se mencionarán algunas de las más importantes. Todas

las clasificaciones del Comercio Electrónico que se hacen se basan en la

naturaleza de la transacción.

B2C (Business-to-consumer)

Intercambio de información, bienes o servicios entre una organización y sus

clientes. Establecimiento de una relación mercantil digital entre fabricantes,

proveedores de servicios o distribuidores y consumidores finales. Un ejemplo de

este tipo de comercio es Amazon.com.

B2B (Business-to- Business)

Transacciones electrónicas entre negocios. Este tipo de Comercio Electrónico

proporciona a los negocios nuevos canales de comunicación, intercambio,

selección de información y facilita la implementación de estrategias de

cooperación.

C2C (Consumer-to-Consumer)

Transacciones de negocios entre individuos usando el Internet y tecnologías Web.

Mediante el C2C consumidores venden directamente a otros consumidores, a

través de anuncios clasificados o por publicidad individual de venta de productos o


27

0.3 0.6 11.5

2.33.2

4.6

6.4

14.9

0

2

4

6

8

10

12

14

16

1997 1998 1999 2000 2001 2002 2003 2004 2005

Millones de usuarios

servicios en el Web o a través de sitios de subasta tales como eBay.com

[Bidgoli01].

3.5 El Comercio Electrónico en México

El Comercio Electrónico en México y en el resto del mundo depende del

número de usuarios del Internet, ya que es el mercado potencial al que se le

puede ofrecer o vender un producto o servicio, la gráfica 3.2 nos muestra este

rubro en México.

Cifras generadas por la Asociación Mexicana de Internet nos dicen que en el 2005

el número de usuarios de Internet en México se había incrementado a 14,900,000.

Tal como se puede ver, el número de usuarios aumenta año con año y no sólo en

México también en el resto del mundo.

Figura 3.1 Crecimiento del Internet en México

El crecimiento constante en el número de usuarios de Internet junto con otros

factores a traído como consecuencia un incremento en las compras en línea, por

Fuente: http://www. nua.ie,


28

ejemplo las ventas al detalle por la red en Estados Unidos alcanzaron los 69 mil

200 millones de dólares, un crecimiento de 23.5 por ciento comparado con 2003.

El Comercio Electrónico en América latina sobrepasó los 3,200 millones de

dólares en el 2004, de acuerdo con un reporte de la consultora de audiencias en

Internet ComsCore.

El futuro también parece prometedor para el mercado del Comercio Electrónico en

México. A nivel nacional se facturaron 250 millones de dólares por compras vía

electrónica. El gobierno trata de impulsar este movimiento aprobando leyes que

regulen este tipo de modalidad comercial.

3.6 Pequeñas y medianas empresas (PYME)

Sin lugar a dudas, el sector de las PYME’s es uno de los más importantes

en México, sin embargo, éste se enfrenta a una serie de retos que le han impedido

en muchos casos crecer o en algunos casos desaparecer ante la competencia.

A pesar de las limitaciones que tienen las PYME´s en México, éstas representan

un sector clave para la economía. Esto se puede observar [SubPYME] en las

siguientes cifras:

a) Del total de empresas que existen en México, el 98% de ellas pertenecen a

este sector.

b) Las PYME´s en México representan el 50% de la población

económicamente activa.

c) El sector de las PYME´s produce el 48% del producto interno bruto.

Las cifras nos dan una perspectiva de la gran importancia de la PYME en México y

de la trascendencia que pueden tener las soluciones a problemas de este sector

económico.


29

3.6.1 Dificultades a las que se enfrenta la PYME

1) Carencias relacionadas con la infraestructura,

2) Disponibilidad de personal con conocimientos de tecnologías de la

información,

3) La legislación,

4) Los métodos de pago,

5) Los recursos financieros disponibles,

6) Falta de interés de los gobiernos por las cuestiones relacionadas con el

Comercio Electrónico,

7) Acceso limitado a la información y la especialización en el área del

Comercio Electrónico,

8) En general las aplicaciones IT (Tecnología de la Información – Information

Technology) son más usadas por los grandes negocios debido a sus altos

costos y su poca adaptación a las necesidades de las PYME’s.

3.6.2 Importancia del Comercio Electrónico para la PYME

En el ámbito comercial para mantenerse a la par de los competidores es

necesario ir adoptando las nuevas tecnologías que le permitan al negocio

competir, mantenerse a la vanguardia, crecer y en muchos de los casos obtener

beneficios económicos. El que un negocio o empresa no adopte de forma rápida

estas tecnologías podría significar el no poder competir ante sus rivales

comerciales, estancarse o ser excluido de la economía internacional.

La mayoría de las grandes firmas ya han hecho la transición a la nueva economía

digital que como hemos mencionado se denomina “Comercio Electrónico”. Sin

embargo, el sector de la Pequeña y Mediana Empresa en la mayoría de los casos

no cuenta con los recursos tecnológicos, humanos y financieros que le permitan

hacer una migración exitosa a este nuevo modelo de negocios.


30

Entre los beneficios potenciales del Comercio Electrónico están: tener acceso a un

mercado más grande, reducción de costos administrativos, optimización de

inventarios, venta de productos o servicios a cualquier hora del día, además de las

ventajas mencionadas anteriormente (ver la sección 3.3 beneficios del Comercio

Electrónico).

3.6.3 Impacto del Comercio Electrónico

Es importante destacar que el Comercio Electrónico no está ligado a un giro

comercial como lo podría ser el informático. El Comercio Electrónico se puede

aplicar en el turismo, ventas por catálogo, servicios, etcétera.

Los beneficios del Comercio Electrónico mostrados en el apartado 3.3 “beneficios

del Comercio Electrónico”, son los mismos para el sector de la PYME como para

las grandes empresas, así mismo para los países en vías de desarrollo como para

los países desarrollados.

El impacto que tiene Comercio Electrónico sobre las empresas y organizaciones

también se hace patente en los siguientes rubros [ALADI01] que se muestran a

continuación:

Aumento en la infraestructura: La incorporación del Comercio Electrónico

permite crear una base de infraestructura tecnológica que se puede extender

conforme la empresa lo vaya necesitando, permitiendo una actualización

tecnológica más rápida y sencilla.

Un aumento a la competitividad: La oferta de productos o servicios puede ser

interna y externa. También se aumenta la competitividad al estar más cerca de los

clientes, con estrategias de soporte pre y postventa, además de dar una


31

información más amplia de los productos, las guías de uso y responder de forma

rápida a los clientes, mejorando la calidad del servicio al cliente.

Productos y servicios personalizados: La información relacionada con el

producto o servicio puede ser detallada de acuerdo a los gustos del cliente

(producto a la medida), pero a precios de mercado masivo.

Cadenas de entrega más cortas o inexistentes: Las cadenas de entrega se

reducen cuando los productos son vendidos directamente por el fabricante,

eliminando los intermediarios reduciendo el precio del producto como el tiempo de

entrega. En algunos casos la cadena de entrega o distribución puede suprimirse

tal como en el caso de los libros electrónicos, música, vídeos, etc.

Reducción de costos: Mientras que el costo de las transacciones con

intervención humana se mide en dólares una transacción electrónica puede ser de

centavos, disminuyendo drásticamente el costo de ésta.

A parte de estos beneficios que aplican a empresas y organizaciones que adoptan

el Comercio Electrónico existen otros que incluyen a la sociedad, esto se ha

concluido del análisis y observación del impacto que ha tenido el Comercio

Electrónico no sólo en las organizaciones, sino también en la sociedad de países

donde es ampliamente usado y difundido como es el caso de los Estados Unidos.

Un estudio de la UNCTAD [ONU01] muestra que el Comercio Electrónico parece

tener un efecto positivo en la productividad y el crecimiento de los países. Esto

significaría que países como México se pudiese recuperar un poco del retraso

respecto de los países en desarrollo. Permite mejorar la competitividad externa y

aumentar su producción, los sueldos y el nivel de bienestar. Lo cual puede

convertir al Comercio Electrónico en un importante instrumento de desarrollo.


32

El impacto del Comercio Electrónico sobre un país se refleja en aspectos tan

importantes como es el empleo, la economía y ni que decir de la forma de vida de

las personas.

3.6.3.1 Impacto del Comercio Electrónico sobre el e mpleo

De acuerdo al incremento en el número de empleos y por consiguiente el

decremento en la tasa desempleo que se ha observado en países donde el uso de

las TIC (Tecnologías de la Información y la Comunicación) así como del Internet

es altamente intensivo tales como Dinamarca, Finlandia e Irlanda, se puede decir

que el Comercio Electrónico tiene un impacto positivo sobre el empleo [ALADI01].

Aunque el número de casos observados es bajo para obtener una conclusión

definitiva es un indicio positivo.

Otro de los efectos es la creación de una nueva modalidad de empleo denominado

“teletrabajo”, que es el empleo relacionado con la informática y las

comunicaciones. Que como es de esperarse, la oferta de este tipo de empleo

aumenta conforme la adopción de las nuevas tecnologías de la información se

incrementa.

3.6.3.2 Impacto del Comercio Electrónico sobre la e conomía

De acuerdo a un estudio [ONU01] hecho en los Estados Unidos, demuestra

que las TIC provocan un crecimiento efectivo y sostenido del PIB (Producto

Interno Bruto), al mismo tiempo que parece mantener el control inflacionario. En

Estados Unidos las TIC motivaron el 25 % del crecimiento económico entre 1992 y

1997 y un 33 % en 1999.


33

Auque el uso de tecnologías de la información supone un impacto benéfico para la

economía, la inversión en ésta no significa que este beneficio se genere de forma

automática, lo que en realidad lo produce es el uso adecuado de estas

tecnologías. Existen factores culturales e institucionales por mencionar algunos

que frenan el uso de las tecnologías de la información. Estos son los factores que

hay que superar dándole un mayor impulso al uso de las tecnologías de la

información.

El uso intensivo de las tecnologías de la información, también permite el

crecimiento de la industria de los contenidos y de la distribución de información,

las cuales dan como resultado una sociedad que utiliza de forma intensiva la

información en su vida económica, cultural, social y política, constituyendo una

economía de la información.

Lo dicho anteriormente se puede resumir diciendo que el uso intensivo las

tecnologías de la información en un país (informatización) explica en parte la

evolución positiva de la economía ya que puede ser aun más relevante la

importancia creciente de la información y su explotación, como recurso económico

(informacionalización).

34

Capítulo 4

Tecnologías y software de código abierto y de

bajo costo

En este capítulo se habla de las tecnologías usadas para el desarrollo del

prototipo, así como, características y conceptos del software libre. También, se da

una descripción de las herramientas de software libre usadas en el prototipo.


35

Desde los inicios del Internet se han ido creando una vasta colección de

tecnologías así como de software para el desarrollo Web. En los inicios del

Internet teníamos el HTML como tecnología predominante para el desarrollo Web,

y la codificación de las páginas se hacían con herramientas rudimentarias

comparadas con las actuales. Sin embargo, con el HTML no era suficiente, ya que

sólo permitía la codificación de páginas estáticas y para el desarrollo de sitios más

complejos se requerían que las páginas fueran dinámicas, tal es el caso de

páginas que despliegan información contenida en una base de datos por esta

razón se creo el CGI (Common Gateway Interfase).

Las tecnologías han seguido evolucionando, entre las tecnologías que

actualmente tiene mucha aceptación para el desarrollo de sistemas en general

como Web fueron desarrolladas por Sun y tienen como base el lenguaje de

programación Java.

4.1 Tecnologías para el desarrollo Web

A pesar de la evolución de las tecnologías para el desarrollo Web el HTML

sigue teniendo un lugar importante en la creación de páginas Web, así también,

han surgido tecnologías del lado del cliente que permiten tener un mejor control

del funcionamiento, presentación y diseño de las páginas, tales como, javascript,

active X y las hojas de estilo en cascada (CCS). En la programación del lado del

servidor se cuenta con una amplia gama de tecnologías que se pueden usar para

el desarrollo de aplicaciones Web tradicionales o distribuidas, por ejemplo: ASP,

PHP, Perl, Servlets, JSP, EJB (Enterprise Java Beans) y Corba. Aunque existen

una gran variedad de tecnologías no se hablará de todas ellas, ya que esa no es

la finalidad de esta investigación.

En los subsecuentes temas de este capítulo se hablará un poco más de las

tecnologías usadas en el desarrollo del prototipo.


36

4.1.1 J2EE de Sun como base para el desarrollo Web

Es necesario comentar que para el proyecto de tesis se eligieron las

tecnologías para el desarrollo Web del Java 2 Platform Enterprise Edition (J2EE)

desarrollado por Sun. Los Servlets, JSP y los Enterprise Javabeans forman parte

de esta plataforma.

La plataforma J2EE se ha establecido como un nuevo modelo de desarrollo para

aplicaciones distribuidas [Singh02]. Con características diseñadas para facilitar el

proceso de desarrollo de aplicaciones distribuidas, la plataforma J2EE ofrece

varios beneficios:

• Arquitectura y desarrollo simplificados,

• Libertad de elección en servidores, herramientas y componentes,

• Integración con sistemas de información existentes,

• Escalabilidad al conocer variaciones en los requisitos,

• Modelo de seguridad flexible.

La arquitectura se desarrolló sobre la capa Web. La capa Web típicamente ejecuta

las siguientes funciones en una aplicación J2EE:

1) Habilita la lógica de negocios Web – La capa Web maneja la interacción

entre el cliente Web y la lógica de negocios de la aplicación,

2) Genera contenido dinámico – Los componentes de la capa Web generan

contenido dinámico de diversos formatos incluyendo HTML, imagen, sonido

y video,

3) Presenta datos y recoge entradas – Los componentes de la capa Web

traducen acciones PUT y GET del http de tal forma que la lógica de negocio

la entienda y presente resultados como contenido Web,

4) Controla el flujo de las pantallas – Determina cual es la próxima pantalla

que se desplegará.


37

Ya se habló un poco de las características del J2EE, ahora vamos a describir de

forma breve cada una de las tecnologías usadas en el desarrollo del prototipo

incluyendo las que forman parte del J2EE. A continuación se da una breve

descripción de cada una de estas tecnologías.

Servlets.

Los Servlets pueden ser usados para extender la funcionalidad de algún

servidor. Los Servlets son usados comúnmente con el servidor Web, donde toman

el lugar de los scripts CGI. La estructura general de funcionamiento de un Servlet

se muestra en Figura 4.1.

Figura 4.1 Estructura de una llamada a un Servlet

Algunas de las ventajas del uso de los Servlets con respecto a Perl son las que se

muestran en la tabla 4.1:

Características CGI/Perl JSP/Servlet

Portable / plataformas Web Si Si

Portable / plataformas hardware / SO No Si

Corre múltiples sesiones concurrentes sin

generar procesos separados. No Si

Cliente Servidor

Proceso interno en servidor

(servlet, CGI, etc.)

Flujo de entrada

Flujo de salida

Solicita servicio

Respuesta en HTML


38

Protección contra pérdidas de memoria. Si Si

Lenguaje de Scripting C, Perl Java

Seguridad de tipo Débilmente Fuertemente

Mantiene estado entre peticiones No Si

Mantiene conexión persistente a BD’s No Si

Interfaz de BD portable Ad hoc Si, JDBC

Corre código confiable de forma segura No Si

Mantenimiento extenso Difícil Fácil

Tabla 4.1 Comparación Servlets contra CGI

JSP

JSP (Java Server Pages) son páginas usadas para suministrar contenido

dinámico al usuario usando lógica y datos (XML, bases de datos) del lado del

servidor. El código JSP está embebido dentro del lenguaje de marcado como

puede ser HTML, XML, etc., al contrario de los Servlets donde el código del

lenguaje de marcado va dentro del código del Servlet.

Las páginas JSP típicamente están compuestas de:

• Componentes estáticos HMTL/XML,

• Tags JSP especiales,

• Partes de código opcional llamado “scriptlets”.


39

Figura 4.2 Ejemplo de un página Web creada con JSP

JavaBeans

Un JavaBean es un modelo de componente portable independiente de la

plataforma escrito en el lenguaje de programación java y que permite a los

desarrolladores escribir componentes reutilizables. Las características típicas que

identifican a un Bean son:

- Introspección: Permite a las herramientas de desarrollo analizar como

trabaja el Bean.

- Personalización: Permite a los desarrolladores personalizar la apariencia y

el comportamiento de un Bean.

- Eventos: Permite a los Beans comunicarse y conectarse a la vez.

- Propiedades: Permite a los desarrolladores personalizar y programar con

Beans.

- Persistencia: Las modificaciones hechas a un bean permanecerán

intactas para un uso futuro.

Elemento JSP

Plantilla de texto

Elemento JSP

Elemento JSP

Elemento JSP

Plantilla de texto

Plantilla de texto

Plantilla de texto


40

4.1.2 HTML

El HTML (Acrónimo de HyperText Markup Language) es un formato de

texto etiquetado, el cual es un subconjunto derivado del SGML. El HTML es

esencialmente un lenguaje de formateo, el cual describe elementos estructurales

de una página, tales como tablas, líneas, hojas de estilo, y otros elementos.

También es usado para el formateo de piezas individuales de contenido, como

texto y gráficos.

Código

<table cellspacing=”0” cellpading=”0”

border=”0”>

<tr>

<td>cell 1</td>

<td>cell 2</td>

</tr><tr>

<td>cell 3</td>

<td>cell 4</td>

</tr></table>

Figura 4.3 Ejemplo del resultado de un trozo de código en HTML

4.1.3 Hojas de Estilo en Cascada (CSS)

Es un simple mecanismo de estilo que se puede aplicar a la hoja y permite

a los autores y lectores agregar estilos a un documento HTML. Ofrece un amplio

control de estilo sobre la presentación de páginas Web [Bos98].

4.1.4 JavaScript

Hay que recordar que javascript no es java, javascript es compacto, es un

lenguaje de script basado en objetos y guiado por eventos diseñado

específicamente para el desarrollo de aplicaciones cliente-servidor en el Internet.

Apariencia final en el navegador


41

Al ser un lenguaje de tipo script significa que no es un lenguaje compilado. El

navegador es el que se encarga de interpretar el código JavaScript. El Netscape

así como el Explorer soportan el uso de código javascript.

4.2 Software libre y de fuente abierta

El software libre o de código abierto ha tenido una gran influencia en el

desarrollo del Internet, así como, el Internet ha sido de gran beneficio para el

desarrollo, conocimiento y uso de este tipo de software, ejemplos sobran, tenemos

el caso de uno de los servidores Web más usados como es el Servidor Web

Apache y de uno de los sistemas operativos de red más estables, Linux, por

mencionar sólo algunos ejemplos de este tipo de software. Pero, ¿que es el

software libre o de código abierto?, a continuación se definen varios de los

conceptos más utilizados y que en ocasiones han sido causa de confusión. Las

descripciones abarcan las características más significativas del software y el

aspecto del costo del producto.

Software propietario. Es software que no es libre. Su uso, modificación y

distribución está prohibida [INEI 2002].

Freeware. Software que no tiene un costo asociado pero que por lo general no

incluye el código fuente.

Shareware. Software que se puede probar antes de comprarlo, si el software

satisface las expectativas se espera que el usuario registre el software. La versión

de prueba del software puede ser:

1) Una versión incompleta del producto que se ofrece,

2) Una versión que permite su uso por un período de tiempo, por ejemplo

30 días, después de los cuales deja de funcionar.


42

3) Una versión con todas sus características completas la cual genera un

aviso de registro en un determinado tiempo o por alguna acción

ejecutada.

El término significa literalmente programa compartido e indica que cualquiera

puede descargar el programa y empezar a emplearlo sin desembolso previo. Esto

no significa que su empleo sea gratuito, la licencia de uso indica con claridad en

cada caso los términos de empleo [INEI 2002].

Dominio público. Software sin restricciones. El desarrollador abandona todos los

derechos sobre el software.

Software libre. Software sin costo y sin código fuente.

Fuente abierta. Software que incluye el código fuente así como la versión

ejecutable del programa.

Un aspecto importante que cabe aclarar del software libre, es que éste presenta

una peligrosa ambigüedad en el idioma inglés “free software”, ya que la palabra

free en inglés puede significar “libre” como gratis. Por esta razón se creó el

termino “fuente abierta” que evita esta ambigüedad. Hay que aclarar que esta

ambigüedad no se presenta en el idioma español.

4.2.1 Licencias de software de fuente abierta

Antes de hablar de los diferentes tipos de licencias comenzaremos

aclarando que una licencia bajo la cual se distribuye un programa, especifica

exactamente los derechos que el usuario tiene sobre él. Éste es uno de los puntos

que ha impulsado el crecimiento del software de fuente abierta, decimos esto ya

que en la mayoría de los programas propietarios, la licencia limita (o anula) los


43

derechos de copia, modificación, distribución, alquiler o uso en varias máquinas.

Este tipo de restricciones para el software son evitadas en las licencias para

software de fuente abierta. Entre las licencias más comúnes de software de fuente

abierta están las siguientes:

BSD (Berkeley Software Distribution, Distribución d e Software de Berkeley),

Esta licencia cubre el software BSD que se libera. Es un tipo de licencia permisiva,

no impone casi ninguna condición, incluyendo cobrar por las distribuciones

binarias y no obliga a incluir el código fuente. Es decir, casi se puede hacer

cualquier cosa con el software hasta utilizarlo para productos propietarios. Una de

las condiciones que impone esta licencia, es el reconocimiento de los autores.

GPL (GNU General Public License, Licencia Pública G eneral de GNU). La

GNU fue pensada cuidadosamente para promocionar el software de código abierto

y prohíbe algunas acciones que permitan la integración de software GPL en

programas propietarios. Algunas de sus principales características son:

- Permite la distribución binaria, pero solamente si se suministra el código

fuente,

- Permite la redistribución del código fuente,

- Permite modificaciones sin restricciones, pero el trabajo resultante también

debe estar protegido por la GPL,

- Únicamente es posible la integración con software también protegido por la

GPL.

LGPL (GNU Lasser General Public License, Licencia M enos Pública General

de GNU). similar a la licencia GPL con la diferencia de que permite la integración

con software propietario.

MPL (Mozilla Public License, Licencia Pública de Mo zilla). Es la licencia que

preparó Netscape para distribuir el código de Mozilla, es muy parecida a la GPL.


44

4.2.2 Beneficios del software de fuente abierta

Aunque existen diferentes licencias bajo la cual se registra el software de

fuente abierta existen características benéficas que tienen en común:

1) Usar el software como se desee, en tantas computadoras como se desee y

en cualquier situación técnicamente apropiada,

2) Adecuar el software a sus necesidades. Esto incluye mejorarlo, corregir

errores, aumentar su funcionalidad o simplemente estudiarlo,

3) Redistribución del software a otros usuarios, que podrán a su vez utilizarlo

de acuerdo a sus necesidades y con los beneficios ya mencionados,

4) Los usuarios deben tener acceso al código fuente. El código fuente de un

programa es necesario para ver su funcionamiento, corregir sus errores,

modificarlo a nuestras necesidades y extender su funcionamiento.

4.3 Herramientas de fuente abierta para la construc ción de un sitio Web

Hemos hablado del software de fuente abierta y de las licencias que lo

avalan, así como, de sus características principales. Un factor significativo del

software de fuente abierta para los usuarios y en especial para la PYME es su

bajo costo o costo nulo. Este factor es importante, ya que, como se dijo en el

Capítulo 1, el sector de las PYME no cuenta con muchos recursos económicos.

Otro factor que impulsó el uso de software de código abierto en este proyecto es la

funcionalidad, todo el software usado en este proyecto de tesis demostró tener la

funcionalidad requerida para un sistema de Comercio Electrónico.

Falta detallar cual fue el software de fuente abierta usado en el proyecto de tesis y

porque se usó. En los siguientes temas se hablara del software que se uso en el

proyecto de tesis.


45

4.3.1 Linux como servidor Web

Linux es un sistema operativo de fuente abierta que ha logrado una gran

reputación debido a su flexibilidad, escalabilidad, fiabilidad y estabilidad. La

reputación de este sistema operativo ha traspasado las barreras del ámbito

estudiantil y de investigación a ser una plataforma empresarial de gran aceptación

por los profesionales de la tecnología de la información.

Las soluciones creadas con Linux son variadas en el área de los servidores, desde

servidores de impresión, de red, hasta clusters con Linux. Todas estas soluciones

están implementadas por grandes empresas como IBM, SUN, DELL, etc., lo que

demuestra la gran aceptación que ha tenido Linux en el mundo empresarial.

Las soluciones con Linux no se limitan al mundo empresarial, la mayoría de las

distribuciones han acercado a Linux a los usuarios sin muchos conocimientos

técnicos en el área y lo han logrado mediante interfaces más amigable e intuitiva

al usuario.

En lo que respecta al presente estudio el sistema operativo Linux es una solución

viable como plataforma para la PYME debido a las características ya mencionadas

anteriormente y también por el costo reducido (o sin costo) comparado con otros

sistemas operativos propietarios.

4.3.2 PostgreSQL

PostgreSQL es un manejador de base de datos objeto-relacional, debido a

que soporta características de objetos como con las clases y la herencia y el ya

conocido modelo relacional de bases de datos. Está basado en POSTGRES,

Versión 4.2, desarrollado por la Universidad de California en el Departamento de

Ciencias de la Computación de Berkeley.


46

PostgreSQL es un descendiente de fuente abierta del código original de Berkeley.

Tiene amplio soporte del estándar SQL:2003 y ofrece muchas características

modernas:

• Consultas complejas,

• Llaves foráneas,

• Disparadores,

• Vistas,

• Integridad transaccional,

• Control de concurrencia multiversión.

También puede ser extendido por el usuario de varias formas, por ejemplo

adicionando:

• Tipos de datos,

• Funciones,

• Operadores,

• Lenguajes procedurales,

• Métodos de indexación.

Y debido a su licencia BSD, PostgreSQL puede ser usado, modificado y distribuido

por cualquier persona sin cargo alguno y para cualquier propósito sea éste

privado, comercial o académico [PostgreSQL].

4.3.3 Apache Tomcat

Tomcat es un contenedor de Servlets. Un contenedor de Servlets es una

aplicación que hospeda Servlets, proporcionando la ruta de comunicación entre el

servidor Web y el Servlet. El contenedor de Servlets es responsable de mapear

peticiones entrantes a un Servlet registrado, para manejar los recursos


47

identificados por el URI y pasa el mensaje de petición al Servlet. Después que la

petición es procesada el contenedor es responsable de convertir el objeto de

respuesta creado por el Servlet en un mensaje de respuesta que envía de regreso

al cliente. Esto se ilustra en la Figura 4.4

Figura 4.4 Mapeo de una petición en Tomcat

Tomcat es desarrollado en un ambiente de participación abierta y lanzado bajo

una Licencia de Software Apache [Apache], la cual se puede consultar en la

siguiente dirección www.apache.org/licenses/ y que es compatible con GPL.

Actualmente se encuentra en su versión 2.0

/ventas/report?mes=jun

Contenedor de Servlets

/report?mes=jun

Contexto: /cat

Contexto: /hr Ruta de contexto: /ventas

Mes=jun

Mapeo: /report/*

Mapeo: /log/* Servlet

Contexto del Servlet

48

Capítulo 5

Arquitectura del sistema

En este capítulo, se da una pequeña introducción a los patrones de diseño y se

describe la arquitectura del sistema con el uso del MVC. También se muestra el

manejo del catálogo y la implementación del prototipo.


49

Un arquitecto diseña una casa de acuerdo a las necesidades del cliente y a

las condiciones del medio ambiente que rodea al lugar donde se construirá.

Selecciona el estilo de la casa, el número de recamaras, así como su ubicación.

Además, diseña pasillos y escaleras que intercomunicaran todos los sitios de la

casa. De igual forma, al diseñar una arquitectura de software se toman en cuenta

varios factores como pueden ser funcionalidad, desempeño, escalabilidad, etc.

Algunas de las características que se buscaron en la construcción de la

arquitectura, fue que separara cada uno de los componentes principales de un

sistema Web, de tal forma, que fueran fáciles de mantener y extender.

Posiblemente la primera idea que se nos viene a la mente es la de diseñar una

arquitectura que cumpla con las características que deseamos, pero, no es la

única opción que podemos usar también podemos apoyarnos de soluciones que

hayan abordado el mismo problema.

En la búsqueda y en el diseño de una arquitectura podemos auxiliarnos de los

patrones de diseño. Existen una gran variedad de patrones de diseño, utilizados

para la solución de diversos tipos de problemas. La razón de mencionar a los

patrones de diseño es motivado por el uso de un patrón de diseño arquitectónico

en el desarrollo del prototipo. Pero, ¿Qué son los patrones?

5.1 Patrones

Los patrones proveen soluciones a problemas recurrentes en un dominio

específico de la aplicación. Estos tienen como beneficios:

1) Ahorra tiempo y costo debido a que el problema no fue atacado

correctamente,

2) Incrementa la calidad y robustez de la solución actual,

3) Ayuda a un diseñador a conseguir un diseño correcto de forma rápida.


50

Existen diversos tipos de patrones. Patrones que resuelven problemas que están

muy relacionados con el paradigma de programación de algún lenguaje en

específico y patrones arquitectónicos que describen una parte significativa de la

vista de un sistema. Un ejemplo de este tipo de patrones es el MVC.

5.1.1 El patrón de diseño arquitectónico MVC

El MVC es el patrón de diseño arquitectónico recomendado para

aplicaciones Web interactivas [Singh02]. El MVC se divide en tres partes básicas

que son el Modelo, la Vista y el Controlador, las cuales están enlazadas. Cada una

de las partes del patrón realiza una función específica. El Modelo se encarga de

manipular los datos de la aplicación, por ejemplo: información de productos,

pedidos y datos del cliente. La Vista se encarga de la parte de la presentación de

la aplicación que interactúa con el usuario, es decir, como es desplegada ante el

usuario. Por ejemplo: tipo de fuente, imágenes, posición de la información, datos

de entrada, etc. El Controlador se encarga de procesar las peticiones y enlaza el

Modelo y la Vista.

Figura 5.1 La arquitectura MVC

Vista Controlador Modelo Petición de usuario

Siguiente página Actualización del

modelo

Consulta de datos actualizados

Retorno de datos solicitados

BD DBMS


51

La Figura 5.1 nos muestra cada una de las interrelaciones entre las partes de la

arquitectura MVC. El flujo de la comunicación inicia cuando el usuario realiza una

petición y termina con una página Web que contiene la solicitud del cliente o un

mensaje de error en caso de presentarse.

En un nivel más alto de abstracción la capa Web realiza los siguientes procesos

en este orden específico: interpreta la petición del cliente, despacha la petición a la

lógica del negocio, selecciona la próxima vista a desplegar y genera la próxima

vista.

Figura 5.2 Ciclo de servicio de la capa Web

Una aplicación MVC se simplifica grandemente utilizando la arquitectura del

Modelo 2, que enlaza todos los componentes utilizando tecnologías J2EE de la

siguiente forma [Seshadri99]:

Figura 5.3 Modelo 2

(controlador) Servlet

(vista) JSP

B R O W S E R

(Modelo) JavaBean

1

2 3

4

5

instancia

Petición

Respuesta

Servidor de aplicación Fuente de datos

Interprete de peticiones

del cliente

Generación de vista

Despacha a la lógica del negocio

Selecciona próxima vista

Hacia el cliente


52

Como se puede ver el Modelo 2 utiliza el patrón de diseño MVC, aplicado a las

tecnologías de Sun como son JSP, Servlets y JavaBeans.

5.1.1.1 Beneficios del MVC

El patrón de diseño arquitectónico MVC provee una serie de beneficios:

a) Evita problemas que se presentan cuando se mantienen juntos el Modelo y

la Vista. Generalmente el Modelo es la parte más estable del sistema,

mientras que, la Vista cambia constantemente, estas particularidades hacen

que al estar juntos los cambios sean más difíciles de realizar,

b) En ambientes de desarrollo en grupo, es de gran ayuda ya que separa el

trabajo. Mientras un grupo se dedica al desarrollo de un módulo como

puede ser el “Modelo” otro se dedica al diseño de la aplicación por ejemplo,

c) Disminuye la duplicación de código,

d) Centraliza el control,

e) Hace la aplicación más fácilmente modificable.

5.2 Diseño de la arquitectura de software

Una arquitectura de software actúa como mediador entre el análisis de

requerimientos y la fase de definición. Además, no sólo está comprometida con la

estructura y el comportamiento, también con el uso, funcionalidad, desempeño,

rehúso, comprensión, restricciones económicas y tecnológicas. Una de las

definiciones más frecuentemente usadas para arquitectura de software es la que

se cita a continuación: “La arquitectura de software de un programa o sistema de

cómputo es la estructura(s) del sistema, el cual consta de componentes, las

propiedades visibles externamente de estos componentes, y las relaciones entre

ellos” [Bass99].


53

Una característica distintiva es su alto nivel de abstracción. Una arquitectura de

software describe un sistema en un nivel extenso, subsecuentes fases muestran el

diseño con más detalle. Otra de las características distintivas es que no sólo tiene

una sola cara sino que puede verse desde diferentes vistas o perspectivas

[Booch99]: vista de caso de uso, vista de diseño, vista funcional, vista de

despliegue y vista de proceso.

En el diseño de la arquitectura se pueden seguir dos rutas, crearla desde el

principio o utilizar una arquitectura ya creada que se haya aplicado con éxito en

una aplicación similar. Generalmente si se aplica una arquitectura ya creada, no

cubre o satisface por completo los requerimientos de un sistema específico, pero

puede servir como guía para un diseño propio u en otro de los casos se le podrían

hacer algunas modificaciones o adiciones que cubran por completo con los

requerimientos del sistema.

A continuación se muestra un diagrama con un nivel de abstracción más bajo

donde se ve el diseño más detallado de la arquitectura.

siteController

secSiteController

catalogController

itemArticulo

articuloBn

itemCliente Base de

datos

Petición

Respuesta

Vista

Selecciona el controlador que

responda a la acción del cliente

carController

loginController

regLoginController

pedidoControllerElige la próxima vista

Cliente

Controlador Modelo

DBMS

Figura 5.4 Arquitectura del prototipo de Comercio Electrónico

La arquitectura sigue los lineamientos del Modelo 2, tal como se puede ver.

Separando cada una de las partes de la arquitectura. El funcionamiento de la

arquitectura completa inicia cuando el usuario hace alguna petición al servidor

� �


54

Web. Dependiendo de la petición hecha, ésta es direccionada por el siteController

o secSiteController a alguno de los Controladores que se encarga de manejar la

petición hecha por el usuario. El Controlador en la mayoría de los casos necesita

realizar algún tipo de proceso con componentes del Modelo (javabeans). Los

componentes necesitados se instancian, después de lo cual, el Controlador realiza

el procesamiento con estos y selecciona la próxima Vista a desplegar. Estas

Vistas son páginas .jsp o .html que conforman la parte de la Vista o presentación

de la arquitectura, la Vista se encargara de mostrar los datos ya procesados al

usuario, para lo cual usa los javabeans que el Controlador pone a su disposición,

además de otros elementos que le ayuden a construir una interfaz adecuada con

los datos solicitados por el usuario.

A continuación se dará una descripción más detallada de cada uno de las partes

de la arquitectura.

5.2.1 El Modelo

El “Modelo” representa los datos del negocio y la lógica del negocio u

operaciones que administran el acceso y la modificación de los datos. Este

acceso a los datos en un sistema desarrollado con java se logra a través de un

puente de enlace entre la aplicación y la base de datos, este puente lo suministra

el JDBC (Java Database Connectivity). El JDBC permite la ejecución de

operaciones sobre la base de datos desde la aplicación.

El Modelo puede ser consultado por todas las Vistas asociadas con él, por medio

del Controlador [Mahemoff99]. El “Modelo” está representado en el Modelo 2 por

los javabeans.


55

Figura 5.5. Modelo de tres capas

El “Modelo” consta de un conjunto de componentes (javabeans) del sistema y un

pool de conexiones, el cual administra las conexiones a la base de datos. La

mayoría de estos componentes requiere de acceso a la base de datos, aquellos

que no, se encargan de manejar datos del sistema, de sesión de usuario o sirven

de apoyo para otros javabeans.

Figura 5.6 Elementos que componen el Modelo

datosLogin Pool

BD

Petición de conexión

Acceso por medio de conexión

Retorno de conexión disponible

itemArticulo

articuloBn

itemCliente

tipoCambioBn

pedidoBn

Lógica del negocio

DBMS

Apertura de conexiones

Máquina cliente Applet Java o

navegador HTML

Servidor de aplicación (java)

JDBC

DBMS

Peticiones HTML, RMI o CORBA

Protocolo propietario DBMS

Máquina servidor

Servidor de base de datos


56

La forma en como interactúan los componentes del Modelo que requieran de una

conexión con la base de datos y el pool de conexiones se puede dividir en varios

pasos.

Paso 1: El pool de conexiones hace una petición al manejador de base de

datos pidiéndole abrir el número conexiones que se le hayan

especificado en el archivo de configuración del contenedor (Tomcat)

llamado web.xml, una vez obtenidas las conexiones el pool está listo

para administrarlas.

Paso 2: El bean que requiera de una conexión a la base de datos, la solicita al

pool el cual le retorna una conexión disponible o en caso de no tener,

coloca la petición en una cola de espera hasta que se libere alguna

conexión.

Paso 3: El bean realiza el proceso deseado sobre la base de datos con la

conexión obtenida y posteriormente la libera, para que el pool la sigua

administrando.

El primer paso únicamente se realiza una sola vez, cuando el contenedor se

arranca. Los pasos 2 y 3 se repetirán cada vez que se necesite información

contenida en la base de datos.

La Figura 5.7 muestra el enlace entre los componentes del Modelo, en un

diagrama de clases en UML.

El pool de conexiones utiliza un patrón de diseño conocido como singleton, la

finalidad de utilizar un singleton para el pool de conexiones, es la de mantener una

sola instancia del pool de conexiones para toda la aplicación y evitar el crear

nuevas instancias del pool, cada vez que un javabean necesite de una conexión

con la base de datos. El pool de conexiones es cargado al iniciarse el servidor

Web por el Servlet llamado servletInit. Para que el servletInit sea reconocido como

un Servlet que se cargará al arrancar el servidor Web se debe configurar el

archivo web.xml de Tomcat.


57

5.2.2 El Controlador

El Controlador enlaza la interacción del usuario de la Vista, las acciones de

aplicación y la lógica del negocio (Modelo). El Controlador traduce las entradas del

usuario en operaciones sobre el Modelo de datos y selecciona la próxima Vista a

desplegar, basado en las entradas del usuario y las acciones sobre el Modelo

[Vedati02].

El Controlador maneja las peticiones hechas por el usuario, generalmente estas

peticiones solicitan información almacenada en la base de datos, tal como un

catálogo de productos, datos del cliente, etc. Por lo cual el Controlador debe tener

Javabean categorías

Figura 5.7 Diagrama en UML que muestra el enlace entre algunas clases del

modelo.

|


58

disponibles los JavaBeans con los datos necesarios para la capa de presentación

o Vista del sitio.

Dentro del esquema del Modelo 2, el Controlador se implementa con los Servlets.

Como son los Servlets los que se encargan del manejo del Controlador, se tiene

toda la funcionalidad del lado del servidor (control de sesiones, seguridad,

conectividad con la base de datos, etc).

En el diseño e implementación del sistema el Controlador está compuesto por dos

Controladores principales, los cuales direccionan la petición del usuario a un

Controlador específico que pueda responder a la petición. De estos dos

Controladores principales, uno maneja las peticiones hechas bajo una conexión

http normal (siteController) sin ningún tipo de seguridad y el otro maneja las

peticiones hechas por el usuario, que requieren una conexión segura https

(secSiteController), con soporte SSL (secure socket layer). En el siguiente

apartado se mostraran las páginas del sitio que utilizan una conexión segura https

y las que utilizan una conexión http normal.

Figura 5.8 El Controlador

Los Controladores específicos están diseñados para responder a acciones

específicas hechas por el usuario. Por ejemplo, si el usuario selecciona un

catController

loginController

carController

pedidoControler regController

siteController

secSiteController

carrController Acción()

regController Acción()

Petición/ respuesta Acciones a eventos

específicos Modelo

Controlador

Vista


59

producto para agregarlo al carrito de compras, el Controlador que respondería a

tal petición sería el carController o si seleccionara una categoría del menú el

Controlador que manejaría tal petición sería el catalogoController y así

respectivamente. Los Controladores no necesariamente deben responder a una

sola acción, también pueden agrupar acciones asociadas a un elemento, como

puede ser el carrito de compras y las acciones asociadas a este elemento podrían

ser borrar, agregar o actualizar los datos del carrito de compras.

La Figura 5.8 muestra como están conectados cada uno de los elementos del

Controlador. Como se puede ver el Controlador es una parte muy importante de la

arquitectura, ya que es el que enlaza la Vista y el Modelo.

Figura 5.9 Proceso realizado por el Controlador ante la petición de un catálogo

La forma en la que está construido el Controlador permite que el agregar una

nueva acción o proceso al sistema, únicamente se tendría que registrar en el

siteController o en el secSiteController y crear el Servlet que maneje tal acción.

Petición de usuario

siteControle catalogControler

carControler articuloBean

° ° °

BD

Select * from articulo Where ar_unspsc like

’432119 %’

DBMS

SSeerrvviiddoorr ddee bbaassee ddee ddaattooss

SSeerrvviiddoorr WWeebb

itemArticulo

itemArticulo

itemArticulo

Modelo

Controlador

Catálogo de monitores

CCll iieennttee

El controlador catalogControler envia al cliente la página del catálogo de monitores y crea un objeto de sesión de tipo articuloBean con los datos de este catálogo los cuales serán desplegados en la página.


60

Este método de funcionamiento, hace que el Controlador sea un módulo fácil de

mantener y extender, una cualidad importante para un módulo de tal importancia.

El número de Controladores no es algo establecido es determinado en la etapa de

diseño. En la Figura 5.9 se muestra el proceso que se llevaría a cabo cuando un

cliente hiciera clic en el catálogo de monitores.

5.2.3 La Vista/Presentación

La capa de presentación se encarga de mostrar la información solicitada

por el cliente, tal como se dijo anteriormente es la parte que interactúa con el

cliente. Existen una serie de guías en cuanto al diseño y usabilidad de un sitio

Web que hacen referencia a aspectos tales como:

• Disposición y estilo,

• Color,

• Fuentes,

• Accesibilidad,

• Navegación,

• Funcionalidad,

• Claridad visual.

La capa de presentación está constituida de un conjunto de páginas Web las

cuales pueden ser estáticas o dinámicas. Las páginas Web estáticas son

utilizadas generalmente para la presentación de datos que no cambiarán

regularmente. Las páginas dinámicas son utilizadas para la presentación

elementos que cambian continuamente, tales como: los datos de un catálogo de

productos, datos meteorológicos, etcétera. Lenguajes tales como JSP, PHP, ASP

y Perl son la base para su desarrollo. En el trabajo se utilizaron los dos tipos de

páginas. Las dinámicas para mostrar datos como los del catálogo de productos,


61

registro de usuario y pedidos de productos y las estáticas que son la minoría para

las páginas de agradecimiento y contacto con la empresa.

Figura 5.10 Páginas del prototipo de Comercio Electrónico

En la construcción de páginas Web comúnmente se utilizan lenguajes de script del

lado del cliente (Applets java, Javascript y Active x), lenguajes de script del lado

del servidor (ASP, JSP, PHP, Perl y Servlets), lenguajes de marcado (HTML),

elementos de estilo de la página (CSS) y plugins creados con herramientas

propietarias (Flash y Shockwave).

Los elementos que se utilizaron en la capa de presentación del trabajo y que ya se

describieron en el Capítulo cuatro, son los siguientes: HTML, JSP, javabeans,

JavaScript y CSS.

Como se puede ver en la Figura 5.11 el catálogo está formado por un conjunto de

páginas que llevan el nombre del catálogo que representan y son cargadas

dinámicamente gracias a los objetos de sesión que contienen los datos del

index.jsp

catalogo.jsp detalleprod.jsp

confirmacion.jsp

factura.jsp pedido.jsp

login.jsp

eddtscompra.jsp eddtsventa.jsp

carrito.jsp Registro_login.jsp datoscompra.jsp

= Página con conexión segura (SSL)

agradecimiento.html

contacto.html

datosenvio.jsp


62

catálogo solicitado. Estos objetos son cargados por el Modelo y guardados como

objeto de sesión por el Controlador. La Figura 5.10 muestra este proceso, el objeto

que contiene los datos del catálogo es pasado como objeto de sesión por el

“catalogoController” con el nombre de “catálogo” y los datos que contiene son

desplegados en la página.

Figura 5.11 Código de una página JSP y su resultado en un navegador

El ejemplo muestra la parte del código de una página .jsp que despliega los datos

del catálogo de monitores y su resultado en el navegador.

<jsp:useBean id="catalogo" class="org.cym.bean.articuloBn" scope="session"/> <% itemArticulo articulo, art2;

int k=0; for (int i=0; i<catalogo.getNumArticulos(); i++)

{ articulo = catalogo.getArticulo(i);

k = i; i++; art2 = catalogo.getArticulo(i); %>

<table border="0" width="519" cellspacing="0" cellpadding="0" background="images/fon_r.gif"> <tr> <td ><img border="0" src="<%=articulo.getRutaFoto()+"s.gif"%>" width="106" height="101"></td>

<td><%=articulo.getNombre()%></td> <td valign="top"><img border="0" src="<%=art2.getRutaFoto()+"s.gif"%>" width="106" height="101"></td>

<td><%=art2.getNombre()%></td> </tr> </table> <img border="0" src="images/1.gif" width="114" height="18"> <A href='<%=response.encodeURL("/site/webControl?action=carrito&itemID="+k+"&operacion=agregar")%>'> <img border="0" src="images/comprar.gif" width="116" height="18"></A> <A href='<%=response.encodeURL("/site/webControl?action=carrito&itemID="+i+"&operacion=agregar")%>'>

Se obtiene el objeto de sesión “catalogo”

Se hace un ciclo for para desplegar cada uno de los elementos del catálogo


63

5.3 Gestión del catálogo

Una de las característica del catálogo es la organización de los productos

en grupos usando el estándar de clasificación de las Naciones Unidas UNSPSC

(United Nations Standard Products and Services Code), que es uno de los

estándares más usados en el Comercio Electrónico y que establece un marco de

referencia para la clasificación de bienes y servicios.

Los beneficios que resultan del uso de un estándar de clasificación como el

UNSPSC son significativos [Granada01], entre los que podemos contar los

siguientes:

1) Proporciona un esquema de clasificación jerárquica. Una organización

jerárquica permite que las compañías se enfoquen en un nivel de detalle

específico a sus propósitos. Desde categorías con un nivel de detalle muy

general hasta categorías más específicas, llegando a los códigos

individuales dentro de éstas,

2) Es un estándar abierto,

3) Un estándar de clasificación es necesario para el comercio moderno entre

empresas. Muchas de estas empresas utilizan el UNSPSC para la

clasificación de sus productos y servicios convirtiéndose así en un mercado

estandarizado,

4) Permite un mejor manejo de inventario,

5) Facilita el comercio entre compradores y vendedores,

6) Evita errores de inventario debidos a esquemas de clasificación ambiguos,

7) Facilita el análisis de ventas.

La codificación UNSPSC es jerárquica, su estructura es la siguiente:

XX Rama XX Familia XX Clase XX Bien o servicio XXXXXXXX = 8 dígitos por código de identificación.


64

Donde un bien o servicio pertenece a una clase la que a su vez pertenece a una

familia y ésta a una rama. Por ejemplo, un monitor de cristal líquido tiene la

siguiente clasificación 43211902 y tiene la siguiente estructura jerárquica:

Rama 43000000 Telecomunicaciones y radiodifusión de tecnología de la

información

Familia 43210000 Equipo informático y accesorios

Clase 43211900 Pantallas de ordenador

Articulo 43211902 Monitores o pantallas de visualización en cristal líquido (LCD)

Tabla 5.1 Estructura jerárquica de un LCD en el estándar de clasificación

UNSPSC

Sobre esta base se pueden adicionar nuevos niveles de detalle a conveniencia de

la empresa.

El prototipo utiliza para la codificación de los productos: el UNSPSC, la marca y un

identificador para el producto.

No. de dígitos o caracteres 8 3 5

UNSPSC Marca Id

Código de una memoria flash Kingston 32101622 Kin 128m

b

Aunque el código completo del producto está dado por estos tres elementos, en la

base de datos están separados, con la finalidad de facilitar el ordenamiento, la

búsqueda y el análisis de datos.

De tal forma que cuando un usuario del sitio da clic en algún catálogo la petición

enviada al servidor Web incluye la clasificación UNSPSC del catálogo y cuando se

selecciona únicamente un producto incluye el código completo.


65

5.4 Implementación

La implementación del prototipo puede tener varios escenarios, un

escenario básico para la implementación del prototipo se muestra en la siguiente

figura.

Figura 5.12 Escenario básico del sitio de Comercio Electrónico

Como se puede ver, este escenario es muy básico, se tienen los clientes con un

navegador, el Internet funciona como medio de comunicación entre el sitio Web y

el cliente y por último un servidor que tiene los siguientes papeles: DNS (Domain

Name Server), servidor Web, servidor de base de datos y sitio de Comercio

Electrónico. Se pueden tener diversos tipos de escenarios para la implementación

del sistema, por ejemplo otro escenario podría ser un servidor dedicado para el

servidor de base de datos y para el DNS y dejar juntos el servidor Web y el sitio de

Comercio Electrónico.

Los pasos a seguir para la implementación y puesta en marcha del sistema de

Comercio Electrónico son los siguientes:

1. Configuración del cliente,

2. Compra de un dominio,

Servlets, JSP, Java

Servidor Web Apache Tomcat 4.0.4

Sistema de Comercio Electrónico

Internet

DBMSDBMSDBMSDBMS

Cliente (Explorer, Netscape)

Red Hat 7.1

Autenticidad y seguridad

PostgreSQL

Servidor WebServidor WebServidor WebServidor Web


66

3. Configuración del DNS,

4. Configuración del servidor Web para responder a peticiones de páginas JSP,

5. Configurar el SSL,

6. Configurar el manejador de base de datos,

7. Cargar y correr el sistema.

Asumimos que los pasos 2 y 3 ya se realizaron con anterioridad por lo que sólo se

describirán los pasos restantes.

5.4.1 El cliente

Para que el sitio de Comercio Electrónico se pueda visualizar en cualquier

computadora de un cliente, se necesita del navegador Internet Explorer versión 5

o posterior y por supuesto una conexión a Internet.

5.4.2 El servidor Web

Los detalles de implementación que se explicarán a continuación aplican

tanto a un servidor que realice todas las tareas antes mencionadas como a

servidores dedicados que se encarguen de una tarea en especial tal como puede

ser un servidor de base de datos.

Es importante aclarar que las versiones de las tecnologías o software que se

recomiendan son las que se deben instalar y usar o usar versiones posteriores a

éstas ya que contienen características que se requieren para el buen

funcionamiento del sistema

El servidor Web estará montado sobre una máquina con un sistema operativo de

red Linux Red Hat 7.1 o posterior, también asumimos que ya se tiene el dominio


67

del sitio y el DNS configurado. Una vez cubiertos estos requisitos, el siguiente

paso es instalar java.

Instalación de java

La versión del JDK (Java Developer Kit) que se recomienda para la

implementación es la 1.4.0 o posterior. El proceso de instalación del JDK 1.4.0 se

encuentra en el sitio de java, http://java.sun.com/j2se/1.4/install-linux.html y de

este mismo sitio se consigue el JDK para Linux. Los pasos para la instalación son

los siguientes:

1. Bajar del Internet el JDK 1.4.0 en su formato binario: j2sdk-1_4_0-rc-linux-

i386-rpm.bin

2. Ejecutar el siguiente comando en una ventana de terminal:

./ j2sdk-1_4_0-rc-linux-i386-rpm.bin

Este binario genera un archivo .RPM como el siguiente j2sdk-1_4_0-rc-

linux-i386-rpm

3. El archivo RPM que es la terminación de los archivos que utilizan el sistema

de paquetes de Linux se puede instalar utilizando la herramienta gráfica

kpackage de redhat o con el siguiente comando:

rpm -iv j2sdk-1_4_0-rc-linux-i386-rpm

Este comando instala el JDK en la siguiente ruta /usr/java/j2sdk1.4.0

4. Agregar las siguientes variables de ambiente en el archivo “/etc/profile”:

JAVA_HOME=/usr/java/ j2sdk1.4.0

JDK_HOME=/usr/java/j2sdk1.4.0

Una vez instalado el JDK se procede a instala en contenedor de Servlets Tomcat.

Se debe realizar en esta secuencia ya que el Tomcat necesita que el JDK ya esté

instalado.


68

Instalación de Jakarta Tomcat

Los pasos para instalar Tomcat 4.0.4 en su versión comprimida son los siguientes:

1. Se baja el Tomcat 4.0.4 del Internet en su formato RPM o comprimido y se

copia en el directorio donde se instalará, por ejemplo “/usr/local/” y se

descomprime de la siguiente forma:

gzip --d jakarta-tomcat-4.0.4.tar.gz

Al descomprimir el archivo se genera un archivo con extensión .tar

2. El archivo .tar generado se descomprime nuevamente de la siguiente

forma:

tar -xpvf jakarta-tomcat-4.0.4.tar

Este archivo al descomprimirse instala el Tomcat por completo, en la

carpeta donde se encuentra el archivo .tar si fue la carpeta “usr/local”

sugerida se creará dentro de la carpeta “/usr/local/jakarta-tomcat-4.0.4” con

todos los archivos de Tomcat.

3. Agregar la siguientes variables de ambiente en el archivo “/etc/profile”:

CATALINA_HOME=/usr/local/jakarta-tomcat-4.0.4

Instalado el JDK 1.4.0 y el Tomcat 4.0.4 el archivo “/etc/profile” contendrá las

siguientes líneas de configuración:

JAVA_HOME=/usr/java/j2sdk1.4.0

JDK_HOME=$JAVA_HOME

CATALINA_HOME=/usr/local/jakarta-tomcat-4.0.4

PGDATA=/usr/local/pgsql/data

PATH=$JAVA_HOME/bin:$JDK_HOME/bin:$CATALINA_HOME/bin:$PATH

export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC

JAVA_HOME JDK_HOME CATALINA_HOME PGDATA


69

Para echar a andar el tomcat se ejecuta un archivo de comandos shell que se

encuentra en $CATALINA_HOME/bin y tiene el nombre de “startup.sh”:

./startup.sh

Para detener el tomcat se ejecuta el script “shutdown.sh”:

./shutdown.sh

Aunque el servidor Web ya puede procesar peticiones a páginas desarrolladas con

Servlets y JSP por el puerto 8080 que es el puerto por defecto, falta habilitar el uso

de SSL bajo el protocolo HTTPS que se usa en algunas partes del sito que

requieren de una conexión segura.

Configurar SSL en Tomcat

Actualmente Tomcat opera con el formato estándar de java “Java KeyStore” (JKS)

para la creación de certificados, éste se puede crear mediante el uso de la utilería

keytool la cual es incluida en el JDK.

Para crear un nuevo KeyStore de forma rápida, conteniendo un certificado único

con firma propia, ejecute lo siguiente en la línea de comandos de una ventana de

terminal:

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

(El algoritmo de seguridad RSA debe ser el preferido para asegurar compatibilidad

con otros servidores y componentes.)

Este comando creará un archivo nuevo en el directorio home del usuario bajo el

cual está corriendo con el nombre ".keystore". Para especificar una ubicación

diferente se debe reflejar este cambio en el archivo de configuración server.xml y

sustituir el comando anterior por el siguiente:

70

Al ejecutar cualquiera de los dos comandos, se solicitará una contraseña para el

keystore. La contraseña por defecto es “changeit” si deseas introducir una

contraseña diferente también la debes especificar en el archivo de configuración

server.xml.

Posteriormente se te solicitará información acerca del certificado tal como el

nombre de la compañía, nombre del contacto, etc. Esta información es la que se

desplegará cuando el usuario acceda a una página segura en la aplicación.

Finalmente se te solicitará el key password, que es la contraseña específica para

el certificado. Debes usar la misma contraseña que fue usada para la contraseña

del keystore.

Si todo el proceso fue exitoso se tiene un archivo de keystore con un certificado

que puede ser usado por el servidor.

La siguiente tarea es configurar el SSL en el archivo

CATALINA_HOME/conf/server.xml donde $CATALINA_HOME representa el

directorio donde se instaló el Tomcat 4. Este archivo contiene un ejemplo del

elemento <Connector> para un conector SSL, tal como el que se muestra aquí:

<-- Define an SSL HTTP/1.1 Connector on port 8443 --> 

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA \ -keystore /path/to/my/keystore


71

Este elemento está comentado por defecto, para habilitar el SSL únicamente hay

que remover las etiquetas de comentario. Una vez removidas estas etiquetas

Tomcat tendrá el soporte para SSL. El puerto por defecto por el cual está

escuchando Tomcat para una conexión segura es el 8443.

En caso de haber elegido una ubicación diferente para el archivo del certificado o

no haber escrito la contraseña por defecto entonces se necesitan modificar o

agregar los siguientes atributos al archivo server.xml:

Atributo Descripción

keystoreFile Específica nombre de ruta absoluta o relativa con respecto a la variable de ambiente $CATALINA_BASE.

keystorePass Agrega este atributo si la contraseña no es la contraseña por defecto (changeit).

Tabla 5.2 Algunos atributos del archivo server.xml

Después de hacer los cambios pertinentes se reinicia el Tomcat de forma normal

para que los cambios surtan efecto. A partir de este momento Tomcat soportará

conexiones seguras por el puerto 8443.

Para más información acerca de la configuración de Tomcat visita el siguiente

enlace http://jakarta.apache.org/tomcat/index.html donde encontrarás toda la

información de este proyecto.

5.4.3 Configurar el manejador de base de datos

El manejador de base de datos que se uso en el trabajo de investigación es

PostgreSQL que ya viene instalado con el sistema operativo Red Hat 7.1, de tal

forma que únicamente faltaría arrancar los demonios que lo hacen entrar en

funcionamiento. Esta operación se puede realizar de forma manual o utilizando

una herramienta gráfica, se recomienda la segunda ya que es más sencilla. Una


72

de las herramientas gráficas que se puede utilizar y que viene instalada con Red

Hat 7.1 es el editor de arranque SysV.

El demonio de PostreSQL llamado postgresql se encuentra en la lista. Para

arrancarlo se selecciona y se pulsa el botón X. Una vez iniciado el demonio de

PostgreSQL podemos realizar operaciones con el manejador de la base de datos.

Una de las operaciones que necesitamos realizar es la de restaurar la base de

datos del sistema que se encuentra respaldada con el nombre “bd”.

En una ventana de terminal ejecutamos el siguiente comando:

su postgres

Ahora ya como usuarios postgres podemos ejecutar el comando siguiente:

psql dbname < infile

Donde dbname es el nombre de la base de datos donde se restaurara el respaldo

e infile es el archivo de respaldo de la base de datos de tal forma que si el nombre

de la base de datos donde se restauraran los datos es “catalogo” el comando a

ejecutar sería el siguiente:

psql catalogo < db

Este comando restaura la base de datos.

5.4.4 Cargar y correr el sistema

La parte final del proceso de implementación y puesta en marcha del

sistema es la de cargar y poner a funcionar el sistema.

Para el proceso de carga únicamente se necesita copiar la aplicación contenida en

el directorio “sis-eco” al directorio wep-apps de Tomcat. El directorio contiene la

siguiente estructura de directorios:


73

Antes de poder arrancar el sistema de Comercio Electrónico, se requiere

configurar unos cuantos aspectos del sistema de Comercio Electrónico en el

archivo “web.xml” que se encuentra en el directorio web-inf de la aplicación. Este

archivo contiene una serie de etiquetas las cuales encierran variables utilizadas

por el sistema. Las variables se modificarán de acuerdo a la configuración que se

haya hecho en el servidor. El formato en el que se encuentran las etiquetas y las

variables es la siguiente:

<context-param>

<param-name>url</param-name>

<param-value>jdbc:postgresql:incom</param-value>

</context-param>

Donde <context-param> es una etiqueta especial que encierran la variable o

parámetro que se utilizará en el sistema, <param-name> encierra el nombre de la

variable y <param-value> el valor de la variable que es el único dato que se debe

configurar. Hay aspectos de formato que se deben respetar al configurar los

parámetros, tales como:

• Toda etiqueta tiene una etiqueta de cierre, por ejemplo: <param-

name>url</param-name> donde la etiqueta de cierre tiene el símbolo “/”

antes del nombre.

• En las etiquetas <param-name> y <param-value>, no deben existir

espacios entre la etiqueta inicio el contenido y la etiqueta de cierre.


74

A continuación se mostrarán las variables del sistema y lo que deben contener:

Nombre Contenido/valor

driver El nombre del driver de la base de datos. La etiqueta se deja con el

valor por defecto.

url El nombre de la base de datos para el sistema. El valor por defecto es

“jdbc:postgresql:incom” donde “incom” es el nombre de la base de

datos y es el único valor que se debe cambiar si el nombre de la base

de datos es diferente respetando el formato que tiene el párrafo.

user Usuario de la base de datos. Si no se ha especificado usuario de la

base de datos el usuario por defecto es “postgres”.

password Contraseña para usar la base de datos. Si no se ha especificado una

contraseña se deja vacía la etiqueta.

inconexión Número de conexiones a la base de datos que se abrirán

automáticamente al arrancar el sistema. Se recomienda dejar el valor

por defecto, en caso contrario su valor debe ser menor o igual al de

“maxConexion”.

maxConexion Número máximo de conexiones concurrentes a la base de datos que se

permitirán. Para la versión instalada con Red Hat 7.1 el número máximo

es de 99. Se recomienda dejar el valor por defecto.

secport Puerto por el cual Tomcat escucha peticiones sobre una conexión

segura con SSL. Ver apartado de configuración de SSL con Tomcat.

webserver URL del servidor Web por ejemplo www.cym.com .

Tabla 5.3 Variables del sistema contenidas en el archivo “web.xml”

Después de realizar las tareas mencionadas y asumiendo que los pasos de

configuración mencionados anteriormente ya se realizaron, se reinicia el Tomcat.

Si toda la configuración se realizó de forma correcta el sistema se cargara y podrá

ser accedido en la dirección del sitio por el puerto 8080. Por ejemplo, si el sitio

tiene la el nombre www.cym.com la forma de acceder a la aplicación sería:

www.cym.com:8080/index.jsp .

75

Capítulo 6

Pruebas

En este capítulo se detalla todo el proceso de pruebas al que fue sometido el

prototipo del sitio de Comercio Electrónico.


76

Dentro de la Ingeniería de software existen una serie de etapas en el

desarrollo del software y una de ellas es la etapa de pruebas. En esta etapa se

analizará el funcionamiento del sistema en un escenario específico, si el sistema

pasa las pruebas de forma satisfactoria se podrá decir que el sistema funciona

correctamente.

A continuación, se mostrará el escenario sobre el cual se probó el prototipo del

sistema de Comercio Electrónico así como todos los elementos involucrados.

6.1 Escenario de prueba

Debido a que el prototipo es un sistema de Comercio Electrónico, las

pruebas se realizaron con el sistema funcionando sobre un servidor Web. Detalles

de implementación y puesta en marcha del sistema se pueden ver en el tema de

implementación del Capítulo 5.

6.2 Casos de prueba en el prototipo

En las siguientes secciones se describen diferentes casos de prueba

aplicados al prototipo, el objetivo de cada prueba, los resultados esperados, los

datos de entrada, así como los resultados obtenidos.

Se hicieron pruebas de los siguientes componentes del prototipo de Comercio

Electrónico: catálogo, carrito de compras y el registro de usuarios. Las pruebas a

estos componentes pueden diferir en la forma en como se estructuran ya que

difieren en cuanto a su funcionalidad.


77

6.2.1 Prueba 1: El catálogo

El catálogo es la parte de un sitio de Comercio Electrónico con la que

interactúa más un usuario ya que es donde busca los productos que desea o

simplemente navega para ver los productos que oferta el sitio, así como sus

detalles, tales como: el precio, variedad, marca, garantía, etc.

Se podría decir que el catálogo es el elemento más dinámico de un sitio de

Comercio Electrónico, no sólo por la interacción con el usuario, sino también,

porque continuamente se está actualizando debido a las constantes variaciones

en los precios de los productos en el mercado, lanzamientos de nuevos productos

o líneas de productos, la salida de productos del mercado u otro tipo de razones

motivadas por el mercado o por políticas de la empresa. Por lo tanto, en el

catálogo se agregan productos, se eliminan productos y se actualizan datos de los

productos de forma frecuente para estar al día con los cambios que se requieran.

Es de esperarse entonces que al realizar este tipo de operaciones el catálogo no

sufra cambios en su comportamiento y que los cambios hechos sobre él se

reflejen en el sitio.

Objetivo de las pruebas:

Verificar la funcionalidad de las operaciones de eliminar, insertar y actualizar los

productos especificados en los datos de entrada, para comprobar que el catálogo

sigue funcionando de forma correcta y que además refleje los cambios hechos en

el catálogo del sitio.

Resultados esperados:

Se espera que el prototipo continúe funcionando de forma correcta ante las

operaciones de inserción, eliminación y actualización de productos que se hagan

sobre la tabla de productos y que muestre los resultados de estas operaciones en


78

el navegador al desplegar la categoría que contiene los productos insertados,

eliminados o actualizados de forma correcta.

Prueba de eliminación, inserción y actualización de productos del catálogo

Una da las características del catálogo es que cuando un usuario hace una

petición de algún catálogo en específico, los datos se carga directamente de la

base de datos. De tal forma, que cuando se agrega, se elimina o se actualiza un

producto en la base de datos, los cambios son reflejados ante el cliente cuando se

carga nuevamente el catálogo que fue modificado. Por esta razón únicamente se

muestra un ejemplo de actualización de datos.

Datos de entrada:

Los productos y campos que sufrieron modificaciones en la tabla de productos se

muestran a continuación:

ar_ext ma_kid ar_unspsc Pro_nombre

N1701 BNQ 4321190100 MONITOR BENQ NGR 17"

B1501 LG-

4321190100 MONITOR LG 15"

Tabla 6.1 Elementos a actualizar en el catálogo de productos

Resultados obtenidos

La actualización de los dos productos se reflejo inmediatamente después de ser

ingresados en la base de datos con simplemente recargar la página del catálogo

de monitores.


79

Figura 6.1 Catálogo de monitores antes y después de la actualización

Antes

Después


80

Conclusiones

La inserción, eliminación y actualización de los productos sobre la base de datos

se reflejó la siguiente vez que los usuarios cargaron los productos del catálogo

afectado, sin necesidad de hacer alguna modificación en el sistema o las páginas

Web. Además, el sistema no mostró ningún cambio en su funcionamiento después

de haberse realizado estas operaciones.

6.2.2 Prueba 2: El carrito de compras

El carrito de compras se encarga de almacenar los productos que el usuario

seleccionó en el catálogo de productos con la finalidad de comprarlos. Las

operaciones que el carrito soporta son el borrado e inserción de productos así

como la modificación de la cantidad de los productos.

Cabe destacar que la comprobación de las operaciones matemáticas mostradas

en cada uno de los apartados de “resultados esperados” fueron hechas con la

ayuda de la hoja de cálculo Excel que forma parte del paquete Office de Microsoft.

Objetivo de la prueba:

Comprobar que el carrito de compras cuenta con las siguientes características

a) Realiza las operaciones correctamente de acuerdo al costo e IVA del

producto,

b) Almacena de forma correcta los producto elegidos,

c) No existe corrupción de datos ante operaciones de inserción, eliminación y

actualización.

Datos de entrada:


81

Los datos de entrada mostrados en la tabla serán los mismos para las todas las

operaciones que se realizaron sobre el carrito.

Nombre del producto Costo sin IVA

U/MEM FLASH USB 2.0 CJA 512MB 1,017.55

GAB M.TOR-ATX/4B BCO/GRI (BC2759) A+U 329.64

MONITOR SAMSUNG SYNCMASTER 17" 1,465.63

DIMM DDR 512MB PC400 HYPER-X KINGS 2,271.97

Tabla 6.2 Elementos agregados al carrito de compras

Agregar productos al carrito

Datos de entrada:

Los productos agregados son los de la lista de la tabla 6.2


La siguiente tabla muestra los resultados que debe arrojar el carrito de compras:






Subtotal 5,084.80

IVA 762.72

Total 5,847.52

Tabla 6.3 Resultado esperados ante la inserción los productos


82

Resultados obtenidos:

Los resultados de la prueba se muestran en la Figura 6.2

Figura 6.2 Carrito de compras con cuatro productos agregados

Eliminación y actualización de productos del carrit o

Datos de entrada:

Debido a que el proceso de eliminación y actualización de los datos es similar

únicamente se realizo el proceso de eliminación. Los productos que se eliminaron

fueron los siguientes





Tabla 6.4 Elementos a eliminar del carrito de compras


83


La siguiente tabla muestra los resultados que debe arrojar el carrito de compras:



Subtotal 2,271.97

IVA 340.80

Total 2,612.77

Tabla 6.5 Resultado esperado ante la eliminación de productos


Después de la eliminación de tres de los productos del carrito los resultados de la

prueba se muestran en la Figura 6.3

Figura 6.3 Carrito de compras después de borrar dos productos


84

Conclusiones

El carrito de compras demostró un buen funcionamiento después de realizar todas

las operaciones que se permiten, como son: agregar, borrar y actualizar

productos. Además, los cálculos que se muestran en la página del carrito son

correctos.

6.2.3 Prueba 3: Registro de usuarios

El proceso de registro de usuarios únicamente tiene lugar cuando el usuario

va comprar productos en el sitio, una vez que el usuario ya se ha registrado ya no

lo tendrá que hacer nuevamente. En caso de que el usuario desee comprar

nuevamente únicamente tendrá que dar su login y contraseña misma que escribió

cuando se registro.

Se puede comprobar que el registro de usuario se llevó a cabo correctamente si el

mismo usuario vuelve a comprar en el sitio y puede acceder a la forma de pago

por medio de su login y contraseña.

Cambio de protocolo


Comprobar que el proceso completo de login y registro de usuario se realiza sobre

una conexión segura.



85

Como los datos del usuario son confidenciales, antes de iniciar el proceso de

registro debe haber un cambio de protocolo de http a https que es el protocolo que

usa SSL y que permite trabajar bajo una conexión segura.


Tal como lo muestra la Figura 6.4 hay un cambio de protocolo antes de pasar a las

pantallas de login y registro de usuarios, la finalidad de cambiar del protocolo http

a https es la de proteger los datos confidenciales del usuario mediante una

conexión segura con SSL .

Figura 6.4 Cambio de protocolo antes de pasar a la pantalla de login de usuarios

Conclusiones:

Todo el proceso de login y registro de usuario se realiza sobre una conexión

segura protegida por SSL.


86

Verificación del login


Comprobar que el proceso de login funciona correctamente evitando el acceso a

usuarios no registrados y permitiéndolo a usuarios que si lo están.


Un usuario registrado puede continuar con el proceso de pedido, escribiendo su

login y contraseña correctos. Un usuario no registrado primero debe registrarse.


Figura 6.5 Error generado al teclear un login y contraseña inexistente

El sistema no permitió el acceso a usuarios no registrados tal como se ve en la

Figura 6.5


87

Conclusión:

El sistema no permite el acceso a la forma de pago sin antes registrarse.

Registro de información de compra y facturación


Verificar que la forma de registro de compra y facturación comprueben los datos

del registro para evitar los errores de dedo o intencionales y analizar el buen

funcionamiento de este proceso.


Correcta comprobación de los datos introducidos y el buen funcionamiento del

registro de datos.


El sistema verifica la información que se introduce en el registro de compra y envía

un mensaje solicitando que se llenen los campos requeridos si no se ha hecho.

Si el usuario comete errores en la introducción de datos, los registros con error se

ponen en blanco y se enviar un mensaje en la forma indicando que se necesitan

llenar los campos que sean requeridos (indicado por un asterisco *) para continuar

con el procesos de compra, este mismo mensaje es desplegado si se omite el

llenado de los campos de datos que son requeridos.

De igual forma si se introducen datos incorrectos o se dejan campos requeridos en

blanco en la forma de información de envío. Se genera el mismo mensaje de la


88

página de datos de compra hasta que los datos se hayan introducido

correctamente.

Figura 6.6 Errores generados por campos dejados en blanco en el registro de

datos de compra.

Figura 6.7 Mensaje generados por errores en la introducción de datos en la página

de envío


89

Conclusiones:

El proceso de registro de información de compra y de envío, verifica los datos que

se introduce con el fin de evitar errores que puedan afectar el proceso de compra

y realiza este proceso de forma correcta.

Modificación de datos de usuario


Comprobar que el usuario puede modificar los datos de su registro

Resultados esperados

Que el usuario pueda modificar los datos de su registro

Resultados obtenidos

Los datos de un usuario registrado se modificaron satisfactoriamente como

muestra la pantalla de confirmación del registro, mostrada en la siguiente figura:


90

Figura 6.8 Pantalla de confirmación que muestra los datos registrados en las

páginas de compra y envío

Conclusiones:

La actualización satisfactoria del registro de un usuario demuestra que este

proceso es soportado eficientemente por el sistema.

91

Capítulo 7

Conclusiones

En este capítulo se dan los comentarios finales del trabajo de investigación, y se

proponen trabajos futuros como continuación a los trabajos realizados en el área

del Comercio Electrónico.


92

7.1 Comentarios finales

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

Comercio Electrónico de bajo costo orientado a la PYME. Los objetivos que se

cubrieron en el trabajo de investigación fueron los siguientes:

1) De acuerdo a un estudio de las arquitecturas para el desarrollo de sistemas

Web, se determinó la utilización del MVC propuesto por Sun para el

desarrollo de aplicaciones Web con JSP y Servlets, tal como se puede ver

en el Capítulo 5 Tema 5.1.1. Esta arquitectura ofrece características tales

como: escalabilidad y una clara separación de cada uno de los

componentes del sistema Web (Modelo, Vista y Controlador),

Figura 7.1 Arquitectura del prototipo de Comercio Electrónico

2) Se seleccionó software libre para el desarrollo e implementación del

prototipo, de acuerdo a lo mencionado en el Capítulo 4 (tecnologías y

software de código abierto y de bajo costo). Verificando que proporcionaban

la funcionalidad y características necesarias para la construcción de

sistemas Web con JSP y Servlets.

� �


93

3) En base a una investigación de los diversos estándares de clasificación se

seleccionó el estándar de clasificación UNSPSC, debido a que es un

estándar de clasificación abierto y ampliamente usado en sistemas de

Comercio Electrónico en el mundo y que está ganando más adeptos.

Además, proporciona un esquema de clasificación jerárquica y facilita el

análisis de ventas. Entre otras características que se encuentran descritas

en el apartado 5.3.

4) Se desarrolló un prototipo en base a la arquitectura MVC y al software

seleccionado, tal como se describe en el Capítulo 5.

5) Se probó en forma satisfactoria la funcionalidad del prototipo desarrollado.

Las pruebas se llevaron a cabo en el Laboratorio de Sistemas Distribuidos

del CENIDET, en donde se implementó y probó el Prototipo del Sistema de

Comercio Electrónico realizándosele pruebas funcionales a los siguientes

elementos del sistema: catálogo, carrito de compras, conexión segura y

registro de datos de compra y envío. Como se muestra en el Capítulo 6.

Con la prueba de funcionalidad del prototipo de Comercio Electrónico se

comprobó que el software libre proporciona todos los elementos necesarios para

el desarrollo e implementación de un sitio de Comercio Electrónico y que es

factible el desarrollo de sistemas de Comercio Electrónico de bajo costo orientado

a la PYME.

7.2 Trabajos futuros

Continuando con esta línea de investigación se propone un estudio de la

seguridad en los sitio de Comercio Electrónico, un factor de gran importancia para

ésta área de investigación. La falta de seguridad en un sitio de Comercio


94

Electrónico puede causar: caídas en el sistema, pérdida, corrupción y robo de

información importante y confidencial.

Referencias

95

Referencias

[ALADI01] Asociación Latinoamericana de Integración (ALADI):

Situación actual y perspectivas del Comercio Electrónico en

la región. (28 de mayo del 2001).

[Bass99] Bass, Len; Clements, Paul; Kazman, Rick: Software

Architecture in practice. Addison-Wesley, E.U.A. (1999).

[Bidgoli01] Bidgoli Hossein: Electronic commerce principles and practice.

Academic Press, E.U.A. (2001).

[Bollinger00] Bollinger Gary y Natarajan Bharathi: Build an E-Commerce

Shopping Cart. Javapro, Sitio Web:

http://www.devx.com/javapro, (2000).

[Booch99] Booch, Grady; Rumbaugh, James; Jacabson, Ivar: The

unified modeling language user guide. Addison-Wesley,

E.U.A. (1999).

[Bos98] B. Bos; H. W. Lie; C. Lilley; e I. Jacobs: Cascading Style

Sheets, level 2. Sitio Web: http://www.w3.org/TR/1998/REC-

CSS2-19980512, (12 de mayo 1998).

[Castillo02] Castillo Vergara Héctor: Desarrollo de un prototipo de

solución de Comercio Electrónico. Tesis de licenciatura.

Universidad Nacional Autónoma de México, México (1

febrero del 2002).

[Deltaasesores05] Deltaasesores: Beneficios de negocios Electrónicos. Sitio

Web: http://www.deltaasesores.com/esta/EST315.html,

Referencias

96

Colombia (Febrero 2005).

[Davis99] Davis, Charles W.: Development of electronic commerce in

Spanish-speaking Latin America. Faculty of Business

University of New Brunswick, Saint John, Canada (1999).

[Deitel01] H. M. Deitel, P. J. Deitel, K. Steinbuhler: E-Business and E-

Commerce for managers. Prentice Hall, E.U.A. (2001).

[Frias00] Frias Garza Jeann José: Estudio y desarrollo de la seguridad

en el Comercio Electrónico entre dos entidades productivas a

través de Internet. Tesis de maestría. Instituto Tecnológico y

de Estudios Superiores de Monterrey, Universidad Virtual,

Campus Ciudad de México, México (2000).

[García01] F. J. García, Mª N. Moreno, J. A. Hernández: E-Cousal: An

E-Commerce architecture for small and medium enterprises.

Tesis de licenciatura. Departamento de Informática y

Automática – Facultad de Ciencias, Universidad de

Salamanca, España (2001).

[Granada01] Granada Research: Using the UNSPSC, why coding and

classifying products is critical to success in Electronic

Commerce. Granada Research (2001)

[Mahemoff99] Mahemoff, Michael J.; Johnston, Lorraine J.: Handling

multiple domain objects with Model-View-Controller. 32nd

International Conference on Technology of Object-Oriented

Languages, Melbourne, Australia (Noviembre 1999).

[Melissa98] Melissa De Zwart: Electronic commerce: promises, potencial

and proposals. Universidad de Monash, UNSW Law Journal,

Referencias

97

1998.

[ObjectStorm01] ObjectStorm: Architecture Specification For The

Development Of Objectstorm E-Business Systems.

ObjectStorm Inc, Sitio Web: http://www.objectstorm.net.

E.U.A. (2001).

[ONU01] Organización de las Naciones Unidas: Informe Sobre

Comercio Electrónico y Desarrollo 2001. Conferencia De Las

Naciones Unidas Sobre Comercio Y Desarrollo, Naciones

Unidas, Nueva York y Ginebra (2001).

[Ortega02] Ortega León Raymundo: Proceso unificado aplicado al

desarrollo de un sistema de Comercio Electrónico con J2EE.

Tesis de licenciatura. Universidad Nacional Autónoma de

México, México (2002).

[Pérez01] Pérez Gutiérrez Eduardo: Arquitectura para un sistema de

información con aplicación en Comercio Electrónico. Tesis de

maestría. Tecnológico de Monterrey campus Cuernavaca,

Cuernavaca, Morelos, México (2001).

[Seshadri99] Seshadri, Govind: Understanding JavaServer Pages Model 2

Architecture. Java World, sitio Web:

http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-

jspmvc_p.html, 1999.

[Singh02] Singh Inderjeet, Stearns Beth, Johnson Mark, and the

Enterprise Team: Designing Enterprise Applications with the

J2EE TM Platform, Second Edition. Addison Wesley, E.U.A.

(2002).

Referencias

98

[Slater02] William F. Slater: Internet History and Growth. Internet

Society (2002).

[SubPYME] Subsecretaría de la Pequeña y Mediana Empresa, Secretaría

de Economía, Sitio Web: http://www.economia.gob.mx,

México.

[Vedati02] Vedati, Krishna: Design Once and Render Everywhere?,

Covigo. 2002.

[Widhani02] Widhani André, Böge Stefan, Bartelt Andreas, and

Lamersdorf Winfried: Software Architecture and Patterns for

Electronic Commerce Systems. University of Hamburg,

Department of Computer Science, Distributed and

Information Systems Group (VSIS). 2002.

[Windrum99] Windrum Paul: The MERIT report on innovation networks in

E-Commerce. SEIN (noviembre 1999).

s.e.p. s.e.s. d.g.e.s.t. - cenidet...figura 2.2 arquit ectura del carrito de compras ..... 9 figura...

Documents