UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMATICA

TESIS DE GRADO

“IMPLEMENTACION DE ARQUITECTURA BASADA EN

PROVEEDORES DE SERVICIOS PARA APLICACIONES
EMPRESARIALES INTEGRADAS EN LA NUBE”

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMATICA

MENCION: INGENIERIA DE SISTEMAS INFORMATICOS

POSTULANTE: MAXIMILIANO REYES ULU CALLO

TUTOR METODOLÓGICO: Lic. JAVIER REYES PACHECO
ASESOR: Lic. BRIGIDA CARVAJAL BLANCO

LA PAZ – BOLIVIA
2015
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
 A mi Padre Celestial por la luz y la fortaleza,

a mi amada esposa Geovana e hija Ghirely,

a mi Sr. Padre Andrés Ulu y mi Sra. Madre Inés Calle

por la confianza y todo el apoyo brindado para lograr este anhelado paso,

decirles con mucha humildad, Familia Muchas Gracias!

 AGRADECIMIENTOS

Primeramente quiero agradecer de manera especial al Padre Celestial quien ilumina mis
pasos en todo momento y llena mi vida de bendiciones.

Quiero extender mis agradecimientos a los docentes:

Lic Javier Reyes Pacheco por el interés y la guía que ha mostrado en el desarrollo de esta
investigación, agradezco mucho el apoyo y sus buenos consejos en aquellos momentos de
incertidumbre.

Lic. Brigida Carvajal Blanco por ser una docente ejemplar, en las observaciones,
sugerencias y en todo el apoyo prestado para la conclusión del presente trabajo.

Asimismo extender mis agradecimientos:

A todos los docentes que me guiaron con su apoyo y sus enseñanzas.

Al personal de Biblioteca por brindarme su amistad y su apoyo en pos del conocimiento

a través del material bibliográfico existente.

A mis estimados compañeros con quienes emprendimos toda esta travesía en la carrera y
llegamos a formar una gran amistad: Irma, Cinthia, Jeaqueline, Zara, Maritza, Eva,
Karina, Ivonne, Ronald, Rubén, Reynaldo, Elio, Cristhian, Demis, Diego, Alberto, Adalid,
Rudy, Miguel y asimismo a Boris por su apoyo incondicional.

A mi estimada Carrera de Informática de la Universidad Mayor de San Andrés, lugar que

ha sido como mi segundo hogar, donde fui formado y tuve la oportunidad de ir
aprendiendo entre sus aulas.
 INDICE
CAPITULO 1..................................................................................................................................... 1
MARCO REFERENCIAL .................................................................................................................... 1
1.1. INTRODUCCION....................................................................................................................2

1.2. ANTECEDENTES ...................................................................................................................3

1.3. PROBLEMATICA .................................................................................................................10

1.3.1. Planteamiento del problema .................................................................................... 10

1.3.2. Definición del problema ............................................................................................ 12

1.4. OBJETIVOS .........................................................................................................................12

1.4.1. Objetivo general......................................................................................................... 12

1.4.2. Objetivos específicos.................................................................................................. 12

1.5. LIMITES Y ALCANCES ......................................................................................................12

1.6. HIPOTESIS ........................................................................................................................13

1.7. JUSTIFICACION ..................................................................................................................14

1.7.1. Justificación teórica.................................................................................................... 14

1.7.2. Justificación tecnológica ............................................................................................ 14

1.7.3. Justificación económica ............................................................................................. 14

1.8. APORTES ...........................................................................................................................15

1.9. DISEÑO METODOLÓGICO.................................................................................................15

1.9.1. Tipo de investigación ................................................................................................. 15

1.9.2. Método de investigación ........................................................................................... 15

1.9.4. Herramienta de investigación .................................................................................... 15

CAPITULO 2................................................................................................................................... 16
MARCO TEORICO ......................................................................................................................... 16
2.1. DISEÑO ARQUITECTONICO ............................................................................................17

2.1.1. El Modelo de “4+1” Vistas de la Arquitectura del Software ...................................... 18

2.1.1.1. La vista Lógica ..................................................................................................... 19

2.1.1.2. La vista de Procesos ............................................................................................ 20
2.1.1.3. La vista de Desarrollo .......................................................................................... 22
2.1.1.4. La vista Física ....................................................................................................... 23
2.1.1.5. Escenarios ........................................................................................................... 23
2.1.1.6. Correspondencia entre Vistas ............................................................................. 24
2.1.1.7. Utilizando UML como herramienta .................................................................... 25
2.2. INGENIERIA WEB .............................................................................................................26

2.3. PROVEEDORES DE SERVICO ...........................................................................................26

2.4. ARQUITECTURA ORIENTADA AL SERVICIO (SOA) ........................................................29

2.4.1. Características de SOA ............................................................................................... 30

2.4.4. SOA y servicios Web ................................................................................................... 31

2.5. ARQUITECTURA BASADA EN PROVEEDORES ...............................................................32

2.6. INTEGRACION DE APLICACIONES EMPRESARIALES (EAI) ...........................................33

2.6.1. Aplicaciones Empresariales ........................................................................................ 33

2.6.1.1. Características ..................................................................................................... 34

2.6.2. Gestión de Aplicaciones Empresariales ..................................................................... 35

2.6.3. Aplicaciones integradas ............................................................................................. 36

2.6.4. Entendiendo mejor la Integración de Aplicaciones Empresariales............................ 36

2.6.4.1. Fundamentos de la Integración .......................................................................... 37

2.6.4.2. Modelos de Integración ...................................................................................... 39
2.7. LA NUBE (CLOUD COMPUTING) ....................................................................................42

2.7.1. Características ............................................................................................................ 43

2.7.2. Modelos de entrega ................................................................................................... 43

 2.7.2.1. Infraestructura como un servicio (IaaS) .............................................................. 43
2.7.2.2. Plataforma como un servicio (PaaS) ................................................................... 44
2.7.2.3. Software como un servicio (SaaS) ....................................................................... 45
2.7.3. Modelos de despliegue .............................................................................................. 46

2.7.3.1. Nube Pública ....................................................................................................... 46

2.7.3.2. Nube Privada ....................................................................................................... 46
2.7.3.3. Nube Híbrida ....................................................................................................... 47
2.7.3.4. Nube Comunitaria ............................................................................................... 47
2.8. LA NORMA IS/IEC 62264-2 (2004) ................................................................................47

2.8.1. Modelo de jerarquía .................................................................................................. 48

2.8.2. Notación UML ............................................................................................................ 49

CAPITULO 3................................................................................................................................... 51
MARCO APLICATIVO..................................................................................................................... 51
3.1. ANALISIS DEL MÉTODO ..................................................................................................52

3.1.1. Características básicas requeridas para los proveedores de servicios ...................... 52

3.1.2. Proveedores de IaaS................................................................................................... 53

3.1.3. Proveedores de PaaS ................................................................................................. 54

3.1.4. Proveedores de SaaS .................................................................................................. 54

3.2. VISTA LÓGICA ..................................................................................................................55

3.2. VISTA DE DESPLIEGUE ....................................................................................................57

3.3. VISTA DE PROCESOS .......................................................................................................58

3.4. VISTA FISICA ....................................................................................................................60

3.5. ESCENARIOS .....................................................................................................................62

3.5.1. Vista Lógica a Vista de Procesos ................................................................................ 62

3.5.2. Vista Lógica a Vista de Despliegue ............................................................................. 63

3.5.3. Vista de Procesos a Vista Física .................................................................................. 64

 3.5.1. Vista de Despliegue a Vista Física .............................................................................. 65

3.6. PROPUESTA DE IMPLEMENTACION ..............................................................................65

CAPITULO 4................................................................................................................................... 74
DEMOSTRACION DE HIPOTESIS ................................................................................................... 74
4.1. OBTENCION DE DATOS ...................................................................................................75

4.2. REALIZANDO LA PRUEBA DE HIPOTESIS .......................................................................76

4.3. INDICADORES OBSERVADOS ..........................................................................................78

CAPITULO 5................................................................................................................................... 79
CONCLUSIONES Y RECOMENDACIONES....................................................................................... 79
REFERENCIA BIBLIOGRAFICA ........................................................................................................ 81
BIBLIOGRAFIA ............................................................................................................................. 82
ANEXOS ........................................................................................................................................ 85
ANEXO A : UML .........................................................................................................................85

ANEXO B : SLA ...........................................................................................................................90

ANEXO C : COTIZACION DE SERVIDORES ..................................................................................92

DOCUMENTOS.............................................................................................................................. 94
 INDICE DE FIGURAS

Figura 1.1: Arquitectura CORBA ………………………………………………......................................... 4

Figura 1.2: Arquitectura DCOM …………………………………………………………………………..…………. 5
Figura 1.3: Arquitectura J2EE …………………………………………………………..…………….………..…….. 6
Figura 2.1: Modelo de “4+1” vistas …………………………………………………………….……….…………. 19
Figura 2.2: Notación para la vista lógica ……………………………………………………..………………….. 20
Figura 2.3: Notación para la vista de procesos …………………………………………..….……..………… 21
Figura 2.4: Notación para la vista de desarrollo ……………………………………………………..………. 22
Figura 2.5: Notación para la vista física…………………………………………..……………….…..…………. 23
Figura 2.6: Arquitectura SOA ……………..…………………………………………………………………..……… 29
Figura 2.7: Representación de una arquitectura basada en proveedores ……………..……….. 33
Figura 2.8: Los tres modelos de entrega de la nube ………………………………………………..…….. 46
Figura 2.9: Esquema de modelos ……………………………..……………………………………………..…….. 48
Figura 2.10: Jerarquía funcional……………………………………………………………………………………….. 49
Figura 3.1: Uso de Diagrama de Clases para la Vista Lógica ……………………………….……..……. 55
Figura 3.2: Uso de Diagrama de Paquetes para Vista de Despliegue ………………….……..……. 57
Figura 3.3: Uso de Diagrama de Componentes para Vista de Despliegue ……………....………. 57
Figura 3.4: Uso de Diagrama de Actividades para la Vista de Procesos del Consumidor .… 58
Figura 3.5: Uso de Diagrama de Actividades para la Vista de Procesos del Proveedor ……. 59
Figura 3.6: Uso de Diagrama de Actividades para la Vista de Procesos entre Procesos ….. 59
Figura 3.7: Arquitectura basada en proveedores de servicio ………………………………………….. 60
Figura 3.8: Escenario de Vista lógica a Vista de Procesos ……………………………………………….. 62
Figura 3.9: Escenario de Vista lógica a Vista de Despliegue ……………………………………………. 63
Figura 3.10: Escenario de Vista de Procesos a Vista Física ……………………………………………….. 64
Figura 3.11: Escenario de Vista de Despliegue a Vista Física …………………………………………….. 65
Figura 3.12: Implementación actual Hotel Real Plaza ………………………………………………………. 66
Figura 3.13: Implementación propuesta al Hotel Real Plaza …………………………………………….. 67
Figura 3.14: Arquitectura de Oracle Cloud Data ………………………………………………………..……… 68
Figura 3.15: Arquitectura de Proveedores de servicio con Oracle Cloud Data …………………. 69
Figura 4.1: Gráfica de la prueba de Hipótesis …………………………………………………………………. 77
 INDICE DE TABLAS

Tabla 1.1: Relación causa – efecto ………………………………………………………………………………. 11

Tabla 1.2: Variables dependientes y variables independientes ……………………………………. 13
Tabla 2.1: Translación de las vistas a UML …………………………………………………………………… 25
Tabla 2.2: Tipos de proveedores de servicio ……………………………………………………………….. 28
Tabla 2.3: UML notación a usar…………………………………………………………………………………… 50
Tabla 3.1: Proveedores de IaaS …………………………………………………………………………………… 53
Tabla 3.2: Proveedores de PaaS ………………………………………………………………………………….. 54
Tabla 3.3: Proveedores de SaaS ………………………………………………………………………………….. 55
Tabla 3.4: Lista de precios vigentes a la fecha en Oracle …………………………………………….. 68
Tabla 3.5: Carga horaria de uso del sistema hotelero de Lunes a Viernes …………………… 71
Tabla 3.6: Carga horaria de uso del sistema hotelero en Sábado ………………………………… 72
Tabla 3.7: Carga horaria de uso del sistema hotelero en Domingo ………………………………… 72
Tabla 4.1: Costos de infraestructura sin escalamiento …………………………………………………… 75
Tabla 4.2: Costos de infraestructura con escalamiento …………………………………………………. 75
Tabla 4.3: Cálculos de media y varianza ……………………………………………………………………..... 76
 RESUMEN

La información forma parte de nuestro lenguaje natural y de nuestra vida diaria, en todas
partes nos vemos involucrados con la misma. CORBA, DCOM, y Java RMI disfrutaron
de un éxito considerable, hasta la aparición de entornos Web. Un sistema basado en Web
es un sistema vivo. Es como un jardín que sigue evolucionando, cambiando y creciendo.

La ingeniería Web ayuda a crear una infraestructura, brindar mantenimiento y apoya la

creatividad. Pero la parte interesante de este proceso lo es un proveedor de servicios, es
quien presta servicios a otras entidades.

La integración de aplicaciones corresponde al proceso de intercambiar procesos de

información entre programas software existentes o creados recientemente. Un
Middleware es un software que permite a las distintas aplicaciones interactuar entre sí,
pero, sin embargo se requiere una aplicación de varias capas técnicas para lograr la
integración de aplicaciones a un nivel más alto de abstracción.

La Nube es un modelo que permite desde la red acceder a un conjunto compartido de

recursos de computo, configurables y liberados a disposición del cliente con un mínimo
esfuerzo de gestión o la interacción con el proveedor de servicios. Consta de tres modelos
de entrega que son Iaas, Paas y Saas, que pueden ser desplegados en a través de una nube
pública, nube Privada o una nueve Comunitaria,

El proveedor de computación de nube posee y dirige la infraestructura de nube. La

existencia de muchos consumidores diferentes dentro de una arquitectura de nube se
refiere como un modelo de multitenencia.

La arquitectura presentada hace una conjunción de estos actores tecnológicos: los

proveedores de servicio, la Nube y el EAI.
 ABSTRACT

The information is part of our natural language and our daily life, everywhere we are involved
with it. CORBA, DCOM, and Java RMI enjoyed considerable success until the advent of Web
environments. A Web-based system is a living system. It is like a garden that continues to evolve,
change and grow.

The Web engineering helps create an infrastructure, providing maintenance and support
creativity. But the interesting part of this process is a service provider, one who serves others.

Application integration process corresponds to the process of exchanging information between

software programs existing or newly created. Middleware is software that allows different
applications to interact with each other, but nevertheless a layered application of various
techniques required to achieve application integration to a higher level of abstraction.

The Cloud is a model that allows access from the network to a shared set of computing resources,
configurable and released to the customer with minimal management effort or interaction with
the service provider. It has three delivery models that are IaaS, Paas and Saas, which can be
deployed through a public cloud, private cloud or a Community-nine,

The cloud computing provider owns and manages the cloud infrastructure. The existence of
many different consumers within a cloud architecture referred to as a multi-tenancy model.

The architecture presented makes a combination of these technological actors: service

providers, cloud and EAI.
CAPITULO 1
MARCO REFERENCIAL

RESUMEN

Este capítulo enmarca la parte inicial del proyecto, en donde

se describe los antecedentes, la problemática a resolver, los
objetivos, la justificación y la metodología a ser empleada
para lograr los objetivos propuestos.

1
1.1. INTRODUCCION

La información forma parte de nuestro lenguaje natural y de nuestra vida diaria, en todas
partes nos vemos involucrados con la misma, así también, los diferentes servicios de
información que comenzaron de forma manual y que hasta nuestros tiempos están
sufriendo cambios continuos a fin de mejorar los mecanismos con el uso de nuevas
tecnologías.

Remontarnos un poco en la historia de la computación, es volver a los años sesenta

donde se dio lugar a los procesos informáticos a través de una red global llamada
ARPANET (Advanced Research Project Agency Network) con la visión de que las
personas de diferentes partes del mundo se encuentren conectados y tengan la
posibilidad de acceder a los programas y datos en cualquier momento. Más adelante ya
por la década de los 80 se dio amplia aceptación a la tecnología del Internet y en los 90
surge la World Wide Web (WWW) con la finalidad de brindar una forma más sencilla
de acceder a los diferentes servidores que se encontraban en línea.

No es necesario detallar otros aspectos de la historia de la computación, pero si resaltar

algunos nuevos conceptos que se maneja con la aparición del Internet, comencemos
mencionado a LA NUBE (“The Cloud” en inglés), metáfora que es empleada para hacer
referencia a los diferentes servicios que se utilizan a través de Internet la cual se ha
desarrollado a lo largo de una serie de líneas, siendo así que la Web 2.0 es la evolución
actual mientras tanto se viene trabajando en las nuevas características para lanzar la Web
3.0; Salesforce.com en 1999 es el pionero en el concepto de la entrega de aplicaciones
empresariales a través de una página web simple, lo cual marco el camino para que tanto
especialistas como empresas tradicionales de software puedan publicar sus aplicaciones
a través de Internet.

2
Si bien, empresas como la cadena de Hoteles Radisson, la tienda estadounidense de
comercio electrónico Amazon, American Airlines, y otros, están cambiando sus
procesos de información a fin de brindar a sus clientes información oportuna, reservas
en línea, emisión de tickets de vuelo, compras en línea, reserva de mesa en un restaurante
u otros servicios para el cliente. Basados en ese cambio de procesos de información en
línea es que comenzamos el presente trabajo que contempla una arquitectura de
aplicaciones empresariales puestas en la nube.

1.2. ANTECEDENTES

En los primeros años de la computación distribuida, el paso de mensajes se lo realizaba

usando sockets (desarrollado por la década de 1980), ya sea para enviar o recibir
utilizaba el protocolo de control de transmisión (TCP) o el protocolo de datagramas de
usuario (UDP), el protocolo de transporte para la mensajería de bajo nivel se lo hacía
sobre el Protocolo de Internet (IP) de las redes.[4]

Los programadores tenían que pasar una cantidad significativa de tiempo para
especificar un protocolo de mensajería y el mapeo de las diversas estructuras de datos.
Como el desarrollo de aplicaciones de computación distribuida aumentó, era necesario
nuevos mecanismos y enfoques para facilitar la construcción de aplicaciones
distribuidas. La primera tecnología de computación distribuida para ganar uso
generalizado fue llamada procedimiento remoto (RPC), desarrollado en la década de
1980 por Sun Microsystems. RPC demostró ser una solución adecuada para el desarrollo
de las arquitecturas cliente / servidor de dos niveles.[4]

Como la computación distribuida se hizo más generalizado, la necesidad de desarrollar,

por ejemplo, las aplicaciones de N-Capas surgió y RPC no podía proporcionar la
flexibilidad y la funcionalidad requerida.[4]

3
La investigación en el área de objetos distribuidos permitió superar este problema con
la especificación de dos tecnologías que compiten: La arquitectura de ejecución de
aplicaciones CORBA (Common Objetct Request Broker Architecture) y el modelo de
objeto común distribuido DCOM (Distributed Common Object Model). Más adelante
se Java se convirtió en un nuevo competidor por medio de un método de invocaciones
remotas (RMI). [4]

Figura 1.1: Arquitectura CORBA

Fuente: [http://www.paginasprodigy.com/escomino/Sinapsys/img/corbaORB.jpg]

CORBA
CORBA es una arquitectura abierta estandarizada gestionado por OMG
(Object Management Group). La tecnología CORBA puede considerarse una
generalización de la tecnología llamada a procedimiento remoto (RPC) e
incluye varias mejoras sobre los objetos de datos y en las primitivas de datos.
El propósito de esta tecnología y la arquitectura era para permitir el desarrollo
de aplicaciones y servicios distribuidos que pueden comunicarse con
interoperabilidad con otras aplicaciones dispares través de la red. CORBA fue
desarrollado fundamentalmente para lograr una disciplina para implementar
la portabilidad e interoperabilidad de las aplicaciones a través de diferentes
plataformas de hardware, entornos operativos e implementaciones de
hardware dispares.[4]

4
 La tecnología CORBA mostrada en la Figura 1.1, utiliza un protocolo binario
llamado Internet Inter-ORB Protocol (IIOP) para comunicarse con objetos
remotos.[4]

Figura 1.2: Arquitectura DCOM

Fuente: [http://www.softwaretoolbox.com/dcom/assets/images/autogen/DCOM---Home-graphic.png]

DCOM
A mediados de la década de 1990, Microsoft Corporation presentó una
tecnología llamada COM que permitió el desarrollo de módulos de software
denominados componentes para la integración de aplicaciones a través de la
arquitectura cliente-servidor.
La tecnología DCOM mostrada en la figura 1.2, permitió la interacción entre
los componentes basados en la red sobre el Entorno de Computación
Distribuido (DCE).[4]

5
La Tecnología DCOM se basa esencialmente en una capa de objetos RPC,
que a su vez está en la cima de la DCE RPC que permite la comunicación
entre objetos remotos. DCOM utiliza un protocolo binario, denominado
objeto de llamada a procedimiento remoto (ORPC), para la comunicación
distribuida entre objetos remotos. Las Tecnologías como Object Linking and
Embedding (OLE), ActiveX, y Microsoft Transaction Server (MTS) son
algunos de los avances tecnológicos de Microsoft basados en las tecnologías
COM y DCOM.[4]

Figura 1.3: Arquitectura J2EE

Fuente: [http://users.dcc.uchile.cl/~jbarrios/J2EE/arq.gif]

6
J2EE

Desarrollado por el Dr. James Gosling de Sun Microsystems, la tecnología

Java se introdujo en 1995. Se basaba en una idea simple de que una Máquina
Virtual Java (JVM) se comportaría de la misma manera en cualquier
plataforma, y por lo tanto, las aplicaciones desarrolladas utilizando lenguaje
de programación Java se comportarían de forma fiable y consistente para
cualquier plataforma. El entorno de programación Java proporciona
características únicas a diferencia de cualquier otro lenguaje de programación,
es decir, la portabilidad e independencia de la plataforma. [4]
Java EE es la extensión del lado del servidor de Java. Las aplicaciones no son
sólo objetos de Java, también son componentes apropiados de servidor. Para
la creación de aplicaciones web, se utilizan componentes como Java Servlets
y JavaServer Pages (JSP) y se despliegan en servidores web, y estos servidores
web funcionan con JRE. Del mismo modo, para la creación de aplicaciones
empresariales, componentes tales como Enterprise JavaBeans (EJB) se
desarrollan y despliegan, opcionalmente con aplicaciones Web en servidores
de aplicaciones. Una vez más, estos servidores de aplicaciones también se
ejecutan en JRE.[4]
La plataforma J2EE como se muestra en la figura 1.3 es controlada por la
Java Community Process (JCP). El JCP es responsable del desarrollo de toda
la tecnología Java. Cualquier persona puede unirse a la JCP e influir en la
evolución de la plataforma Java. Las modificaciones de la plataforma
requieren un consenso entre los miembros del proceso de JCP. Esto garantiza
que no habrá cambios rápidos que reducirían la compatibilidad con el software
existente. Por otro lado, se da a los miembros la posibilidad de influir en su
desarrollo y dirección. Sun Microsystems (ahora parte de Oracle Corp.)
todavía tiene los derechos sobre la marca comercial de J2EE y requiere
licencias a pagar, pero es la JCP, no de Oracle, que controla la plataforma.[4]

7
 La especificación J2EE, controlada por el JCP, se lleva a cabo luego por
muchos fabricantes de servidores de aplicaciones diferentes que compiten en
un mercado muy grande. Esto significa que el cliente es libre de elegir el
servidor de aplicaciones y el vendedor y, en una fecha posterior, para cambiar
a un proveedor diferente si es necesario, pero cualquier software existente
debe ser portátil entre las implementaciones de diferentes proveedores.[4]

CORBA, DCOM, y Java RMI disfrutaron de un éxito considerable, pero fueron

perdiendo fuerza por las deficiencias y limitaciones cuando eran utilizados en entornos
Web. Por decirlo así:

 Ellos tienden a crear sistemas distribuidos fuertemente acoplados.

 Algunos son proveedores y especifican que se utilice una plataforma (por
ejemplo, COM / DCOM sólo se ejecuta en Windows).
 Los sistemas distribuidos desarrollados se ejecutan en entornos estrechamente
administrados.
 Algunos utilizan protocolos complejos de propiedad, para formatos de mensaje
y para la representación de datos específicos.[4]

La tecnología del Internet da otra perspectiva de recurrir a los servicios Web para la
creación y entrega de aplicaciones a través de la red. Este método permite que las
aplicaciones se comuniquen independientemente de la plataforma o el sistema
operativo. Lo positivo es que los desarrolladores pueden eliminar los principales
esfuerzos de las pruebas de portabilidad y calidad.

8
Arquitectura Orientada a Servicios (SOA)

Los Servicios Web son estándares para la búsqueda y la integración de componentes de

objetos a través del Internet; cuentan con componentes básicos que se pueden combinar
con otros y están disponibles en la Web para construir aplicaciones completas que se
puedan ejecutar como servicios de aplicaciones centrales. Este enfoque requiere de
combinaciones de protocolos de programa a programa, como la llamada a procedimiento
remoto (RPC) y las interfaces de programación de aplicaciones (API), junto con
arquitecturas como el modelo de objetos común (COM), El Modelo de Objetos de
Componentes Distribuidos (DCOM) y el CORBA.[4]

Pero, sin una red subyacente común, protocolos comunes para la comunicación de
programa a programa, y una arquitectura común para ayudar a las aplicaciones a declarar
su disponibilidad y servicios, se ha demostrado que es difícil de implementar plataformas
de comunicación de programa a programa entre los módulos de aplicación.

La respuesta moderna para la integración de aplicaciones es una Arquitectura Orientada

a Servicios (SOA); SOA con Web Services es una combinación de arquitectura y
tecnología para entregar consistentemente servicios robustos y reutilizables que apoyan
las necesidades de negocio de hoy en día y que se puede adaptar fácilmente para satisfacer
los cambiantes requisitos empresariales. Cuando una SOA con sus correspondientes
servicios está en su lugar, los desarrolladores pueden reutilizar fácilmente los servicios
existentes en el desarrollo de nuevas aplicaciones y procesos de negocio.

Las empresas actuales necesitan sistemas de TI con la flexibilidad para implementar

operaciones especializadas, para cambiar rápidamente acorde a los cambios de
operaciones comerciales. Esto implica interoperabilidad de servicios Web para salvar
características y funciones que se utilizan en las aplicaciones actuales como la seguridad,
la fiabilidad, las transacciones, gestión de metadatos, y la orquestación.

9
Como se ha podido observar, el uso de diferentes tecnologías con respecto al tratado de
la información y el proceso de integración de aplicaciones en la web, dio lugar a
diferentes soluciones, que si bien comenzaron siendo novedad en su momento, se fueron
convirtiendo en nuevos desafíos para los desarrolladores conforme cambiaba las
operaciones comerciales y se requería contemplar la escalabilidad de los mismos.

Una propuesta interesante que se maneja como solución es migrar la empresa a La Nube,
que propone ser masivamente escalable, y cuenta con muchos beneficios incorporados
de eficiencia, disponibilidad y de alta utilidad; contrario a ello surgen interrogantes como:
¿Cuánto de inversión será requerida para que una empresa opte por este servicio? ¿Qué
mecanismo se pueden aplicar para la integración de aplicaciones empresariales? ¿Qué
seguridad tengo con respecto a los datos de información? ¿Qué proveedores distribuyen
este servicio?, interrogantes que el presente trabajo pretende reflejar con respecto al uso
de esta tecnología; si bien La Nube promete ahorrar en costos, agilidad, innovación,
flexibilidad y simplicidad. Los ofrecimientos de distribuidores, en términos de servicio
de aplicaciones, plataformas e infraestructura natural, son continuos logros, y el ahorro
económico que es un buen atractivo en un ambiente económico competitivo.

1.3. PROBLEMATICA

1.3.1. Planteamiento del problema

En la tabla 1.1 se puede apreciar la relación causa y efecto.

10
 CAUSA EFECTO
1. Existen empresas que brindan el 1. El pago de servicio es único y realizar
servicio de Hosting para alojar alguna modificación implica un costo
portales o almacenamiento de aparte.
archivos.

2. Los servidores se encuentran 2. Una caída del servicio de internet

alojados en la misma empresa. ocasiona un corte en el servicio de
consulta de datos, ya sea para sucursales
implementadas, correos o aplicativos
móviles.

3. Existe un bajo interés por optar 3. La Nube constituye una tendencia nueva
nuevas tecnologías para el tratado que hace imaginar precios elevados al
de información. cual no desean ingresar por temor de
perder información importante o no.

4. El presupuesto tecnológico implica 4. Los equipos más importantes sufren

cambios a mediano o largo plazo. cambios a mediano o largo plazo por las
configuraciones que tienen o desean
evitar migrar su información a otro equipo
más optimizado.

5. La conexión de internet está 5. Se puede generar una sobrecarga de

limitada en base a lo presupuestado. consultas en el tráfico de internet y así el
servicio que brinda la empresa puede caer
en lentitud de respuestas.

6. Existe muchos proveedores de 6. Evitar nuevos gastos desecha las opciones

servicio que ofrecen diferentes brindadas por estos proveedores de
beneficios para garantizar su trabajo servicios.
como expertos en Tecnologías de
Información.

Tabla 1.1: Relación causa – efecto

11
 1.3.2. Definición del problema

Considerando los problemas planteados, se formula la siguiente pregunta:

“¿La arquitectura basada en proveedores de servicio para aplicaciones
empresariales integradas en la nube optimizará los gastos de inversión y permitirá
escalar la tecnología de información de una empresa?”

1.4. OBJETIVOS

1.4.1. Objetivo general

Desarrollar una arquitectura basada en proveedores de servicio para aplicaciones

empresariales integradas en la nube para optimizar los gastos de inversión y
permitirá el escalamiento de tecnología de información.

1.4.2. Objetivos específicos

- Realizar el estudio preliminar de diferentes arquitecturas orientadas al tratado de

información.
- Realizar el estudio preliminar de proveedores de servicio en la nube.
- Elaborar el planteamiento de la arquitectura propuesta.
- Proponer un caso de estudio

1.5. LIMITES Y ALCANCES

El presente trabajo contempla los siguientes alcances:

- Estudio de empresas que ofrecen los servicios Iaas, Paas y Saas.
- Estudio y elaboración de una arquitectura basada en proveedores de servicio.
Se excluye:
- Estudio de servicios de tipo Industrial.
- Estudio de modelos de gestión de proyectos.

12
1.6. HIPOTESIS

“ La arquitectura basada en proveedores de servicio en la nube representa

una buena reducción en los costos de inversión y permite escalar los
servicios de tecnología de información”

VARIABLES INDICADOR DESCRIPCIÓN

DEPENDIENTE  Cotizaciones de los Concebir un costeo

Reducción en los costos servicios en Dólares. acorde a una
de inversión y permite  Cotización de los implementación
escalar los servicios de servicios para Base de tecnológica, con la
tecnología de infor- Datos
posibilidad de escalar los
mación recursos y mantener la
operabilidad del servicio
respecto del tratado de
información.
Es la arquitectura que
INDEPENDIENTE  Interoperabilidad
 Mantenibilidad reúne diferentes aspectos
La arquitectura basada físicos y lógicos, en
 Usabilidad
en proveedores en la
 Escalabilidad donde los proveedores de
nube  Seguridad servicio en la nube juegan
 Fiabilidad un papel muy importante
en cuanto al servicio
tecnológico.

Tablas 1.2: Variables dependientes y variable independientes

13
1.7. JUSTIFICACION

1.7.1. Justificación teórica

Existen los enfoques de Nube como un Servicio y el enfoque de Integración de

aplicaciones empresariales, el presente trabajo pretende presentar una arquitectura
basada en proveedores de servicio con la perspectiva de aplicaciones empresariales
integradas en la Nube.

1.7.2. Justificación tecnológica

El empleo de la Nube es un concepto nuevo que recién toma curso en nuestro medio,
existiendo temor de adicionar y/o mejorar el servicio actual con el que cuentan,
dejando de lado los beneficios y mejoras tecnologías que conlleva contar con uno o
más proveedores.

Los cambios siempre conllevan a soluciones más viables; desde esta perspectiva las
empresas que brindan servicios en línea son los directos responsables de garantizar
tecnologías de punta así como de nuevas plataformas de desarrollo o de nuevas
aplicaciones listas para ser utilizadas en la medida que sea conveniente para la
empresa; considerándose que los beneficios son compartidos, por un lado la
institución proveedora mejora sus prestaciones tecnológicas y por otra parte son las
empresas que optimizan sus servicios acorde a sus requerimientos y posibilita a
minimizar sus gastos en cuanto a infraestructura tecnológica.

1.7.3. Justificación económica

Con el desarrollo del presente trabajo, se pretende poner a consideración el estudio

de proveedores de servicio que tienen su lista de costos en la web, reflejando una
comparativa de inversión en base a un servicio en la Nube.

14
 Si bien cada empresa contempla diferentes gastos en cuanto a compra y/o
mantenimiento de infraestructura tecnológica (No se considera el pago de sueldos,
impuestos y viáticos), la respuesta a la implementación juega un papel preponderante
a la hora de demostrar eficiencia y efectividad en el negocio, invertir en soluciones
de proveedores de servicios trae consigo mejoras referentes a minimizar gastos y
optimizar los recursos económicos en pos de la estabilidad empresarial.

1.8. APORTES

El aporte fundamental se constituye en el diseño de la arquitectura basada en proveedores

de servicio para aplicaciones integradas en la nube, por otra parte se pretende a través de
un estudio de entidades que ofrecen servicios en la nube proponer alternativas para
tomarlas en cuenta para posibles nuevas implementaciones o mejorar las ya existentes en
un entorno empresarial.

1.9. DISEÑO METODOLÓGICO

1.9.1. Tipo de investigación

Dentro la metodología de investigación de recurre al método científico descriptivo.

1.9.2. Método de investigación

Dentro los métodos a emplearse se tienen:

- Deductivo: para determinar algunos aspectos referentes a los proveedores de
servicio.

1.9.4. Herramienta de investigación

Una herramienta que será empleada para el desarrollo del presente trabajo es el
modelo 4 + 1 vistas (ver el punto 2.1.1 del capítulo 2 del Marco Teórico) que a través
de sus áreas de desarrollo permitirá una mejor representación del modelo propuesto.

15
CAPITULO 2
MARCO TEORICO

RESUMEN

Este capítulo presenta la parte teórica, la misma que es

referencia para lograr la solución de la problemática
planteada en el capítulo 1, para tal efecto se hace una
descripción de: Ingeniería Web, Proveedores de Servicio,
Aplicaciones Empresariales, La Nube e Integración de
Aplicaciones Empresariales.

16
2.1. DISEÑO ARQUITECTONICO

Antes de entender bien el concepto de diseño arquitectónico demos un vistazo al concepto

de diseño y de arquitectura.

Diseño:

“El diseño es lo que casi todo ingeniero quiere hacer. Es el lugar en el que las reglas
de la creatividad —los requerimientos de los participantes, las necesidades del
negocio y las consideraciones técnicas— se unen para formular un producto o
sistema. El diseño crea una representación o modelo del software, el modelo de
diseño proporciona detalles sobre arquitectura del software, estructuras de datos,
interfaces y componentes que se necesitan para implementar el sistema. ”. [1]

Arquitectura:

Para Jerrold Grochow: “La arquitectura de un sistema es un marco general que

describe su forma y estructura: sus componentes y la manera en la que ajustan entre
sí”. [1]

Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una
instancia de una arquitectura, similar a un objeto que es una instancia de una clase.
Por ejemplo, considere la arquitectura de cliente-servidor. Con esta arquitectura es
posible diseñar de muchos modos un sistema de software basado en red, con el uso
de una plataforma Java (Java EE) o Microsoft (estructura .NET). Entonces, hay una
arquitectura, pero con base en ella pueden crearse muchos diseños. Así, no es válido
mezclar “arquitectura” y “diseño”. [1]

Expuesto las definiciones de diseño y arquitectura, pasemos a ver la definición de diseño

arquitectónico:

17
Definición 1: El diseño arquitectónico representa la estructura de los datos y de los
componentes del programa que se requieren para construir un sistema
basado en computadora. Considera el estilo de arquitectura que adoptará
el sistema, la estructura y las propiedades de los componentes que lo
constituyen y las interrelaciones que ocurren entre sus componentes
arquitectónicos. [1]

Definición 2: Proceso de diseño inicial que identifica los subsistemas y establece un

marco para el control y comunicación de estos. [11]

Para este trabajo la definición de diseño arquitectónico será:

“El diseño arquitectónico es la representación estructural de un conjunto de

subsistemas integrados unos a otros mediante un flujo de información, empleando
una estructura de datos y diferentes componentes gráficos que representan una o
varias soluciones de un sistema planteado”.

2.1.1. El Modelo de “4+1” Vistas de la Arquitectura del Software

El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes.
Tal como se muestra en la Figura 2.1, cada vista se refiere a un conjunto de intereses de
diferentes stakeholders del sistema. [12]

Para cada vista definimos un conjunto de elementos (componentes, contenedores y

conectores), captamos la forma y los patrones con que trabajan, y captamos la
justificación y las restricciones, relacionando la arquitectura con algunos de sus
requisitos. [12]

Cada vista se describe en lo que llamamos “diagrama” (blueprint) que usa su notación
particular. Los arquitectos también pueden usar estilos de arquitectura para cada vista, y
por lo tanto hacer que coexistan distintos estilos en un mismo sistema. [12]

18
El modelo de 4+1 vistas es bastante genérico: se puede usar otra notación y herramientas
que las aquí descritas, así como también otros métodos de diseño, especialmente para las
descomposiciones lógica y de procesos.[12]

Figura 2.1: Modelo de “4+1” vistas

Fuente: [12]

2.1.1.1. La vista Lógica

La vista lógica apoya principalmente los requisitos funcionales –lo que el sistema debe
brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie
de abstracciones clave, tomadas del dominio del problema en la forma de objetos o clases
de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia.
Esta descomposición no solo se hace para potenciar el análisis funcional, sino también
sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del
sistema.[12]

Notación: La notación para la vista lógica se deriva de la notación de Booch como se

muestra en la figura 2.2. Esta se simplifica considerablemente de tal modo de tener en
cuenta solamente los items relevantes para la arquitectura.[12]

19
 Figura 2.2: Notación para la vista lógica
Fuente: [12]

Estilo: El estilo usado para la vista lógica es el estilo de orientación a objetos. La principal
guía para el diseño de la vista lógica es el intentar mantener un modelo único y coherente
de objetos a lo largo de todo el sistema, para evitar la especialización prematura de las
clases y mecanismos particulares o de un procesador. [12]

2.1.1.2. La vista de Procesos

La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como

la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución,
integridad del sistema, de tolerancia a fallas. La vista de procesos también específica en
cuál hilo de control se ejecuta efectivamente una operación de una clase identificada en
la vista lógica. [12]

La arquitectura de procesos se describe en varios niveles de abstracción, donde cada nivel

se refiere a distintos intereses. [12]

20
El nivel más alto la arquitectura de procesos puede verse como un conjunto de redes
lógicas de programas comunicantes (llamados “procesos”) ejecutándose en forma
independiente, y distribuidos a lo largo de un conjunto de recursos de hardware
conectados mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse
para apoyar la separación de la operación del sistema en línea del sistema fuera de línea,
así como también para apoyar la coexistencia de versiones de software de simulación o
de prueba. [12]

Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos
representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente
(por ejemplo: comenzar, recuperar, reconfigurar, y detener). [12]

Notación: La notación para la vista de procesos se expande de la notación originalmente

propuesta por Booch para las tareas de Ada y se centra solamente en los elementos
arquitectónicamente relevantes (véase la Figura 2.3). [12]

Figura 2.3: Notación para la vista de procesos

Fuente: [12]

21
2.1.1.3. La vista de Desarrollo

La vista de desarrollo se centra en la organización real de los módulos de software en el

ambiente de desarrollo del software. Toma en cuenta los siguientes requisitos internos
relativos a la facilidad de desarrollo, administración del software, reutilización de
elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de
programación que se use. [12]

La vista de desarrollo apoya la asignación de requisitos y trabajo al equipo de desarrollo,

y apoya la evaluación de costos, la planificación, el monitoreo de progreso del proyecto,
y también como base para analizar el reúso, portabilidad y seguridad. Es la base para
establecer una línea de productos. [12]

La vista de desarrollo de un sistema se representa en diagramas de módulos o subsistemas

que muestran las relaciones, que exporta e importa. La arquitectura de desarrollo
completa sólo puede describirse completamente cuando todos los elementos del software
han sido identificados. [12]

Notación: Tal como se muestra en la Figura 2.4, usamos una variante de la notación de
Booch limitándonos a aquellos items relevantes para la arquitectura. [12]

Figura 2.4: Notación para la vista de desarrollo

Fuente: [12]

22
2.1.1.4. La vista Física

La vista física toma en cuenta primeramente los requisitos no funcionales del sistema
tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance
(throughput), y escalabilidad. Los variados elementos identificados –redes, procesos,
tareas y objetos– requieren ser mapeados sobre los variados nodos. Por lo tanto, el mapeo
del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre
el código fuente en sí. [12]

Notación: para la arquitectura física. Los diagramas físicos pueden tornarse muy
confusos en grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo
de la vista de procesos (véase la figura 2.5). [12]

Figura 2.5: Notación para la vista física

Fuente: [12]

2.1.1.5. Escenarios

Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el
uso de un conjunto pequeño de escenarios relevantes –instancias de casos de uso más
generales–. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas
de interacción de objetos. [12]

23
Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos
principales:

 como una guía para descubrir elementos arquitectónicos durante el diseño de

arquitectura tal como lo describiremos más adelante. [12]
 como un rol de validación e ilustración después de completar el diseño de
arquitectura, en el papel y como punto de partido de las pruebas de un prototipo
de la arquitectura. [12]

Notación: La notación es muy similar a la vista lógica para los componentes (ver Figura
2.2), pero usa los conectores de la vista de procesos para la interacción entre objetos (ver
Figura 2.3). [12]

2.1.1.6. Correspondencia entre Vistas

Las distintas vistas no son completamente ortogonales o independientes. Los elementos

de una vista están conectados a los elementos de las otras vistas siguiendo ciertas reglas
y heurísticas de diseño. [12]

De la vista lógica a la vista de procesos: Identificamos varias características importantes

de las clases de la vista lógica:

 Autonomía: Se cuestiona si los objetos son activos, pasivos o protegidos. [12]

 Persistencia: ¿Los objetos son permanentes o temporales? ¿Qué hacen ante la
falla de un proceso o un procesador? [12]
 Subordinación: ¿La existencia o persistencia de un objeto depende de otro
objeto? [12]
 Distribución: ¿Están el estado y las operaciones de un objeto accesibles desde
varios nodos de la arquitectura física, y desde varios procesos de la arquitectura
de procesos? [12]

Por lo tanto, la arquitectura lógica tiene en cuenta sólo el aspecto funcional de los
requisitos.

24
De la lógica al desarrollo: Una clase se implementa generalmente como un módulo. Las
clases grandes se descomponen en múltiples paquetes. Colecciones de clases
íntimamente relacionadas – categorías de clases– se agrupan en subsistemas. [12]

Las vistas lógica y de desarrollo son muy cercanas, aunque se refieren a distintos asuntos.
Cuanto mayor es el proyecto, mayor es también la distancia entre estas dos vistas.
Similarmente para las vistas de procesos y física. [12]

De procesos a físico: Los procesos y grupos de procesos se mapean sobre el hardware

físico disponible en varias configuraciones para testing o distribución. [12]

Los escenarios se relacionan esencialmente con la vista lógica, en términos de cuáles

clases se usan y con la vista de procesos cuando las interacciones entre objetos involucran
más de un thread de control. [12]

2.1.1.7. Utilizando UML como herramienta

Considerar que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no
existía una clara relación entre ambos, en el ANEXO A se puede ver acerca de los
elementos pertenecientes a UML que serán utilizados, es así que se tiene la siguiente
translación que se presenta en la siguiente tabla:

VISTA UML

Escenarios Casos de Uso

Lógica Clases, de Estado y Colaboración

Desarrollo Componentes

Física Despliegue

Procesos Actividad, Estados, Secuencia

Tabla 2.1: Translación de las vistas a UML

25
2.2. INGENIERIA WEB

Ingeniería Web es la manera de desarrollar y organizar el conocimiento para desarrollar

y aplicar en una aplicación web, o para hacer frente a nuevos requisitos o desafíos.
También es una manera de gestionar la complejidad y diversidad de las aplicaciones
Web. [2]

Un sistema basado en la Web es un sistema vivo. Es como un jardín - que sigue

evolucionando, cambiando y creciendo. [2]

La ingeniería Web ayuda a crear una infraestructura que permita la evolución y

mantenimiento de una web sistema y que también apoyará la creatividad. [2]

Se trata de un enfoque integral y proactivo para el desarrollo de grandes sistemas basados

en la Web, y su objetivo es traer el caos actual en el desarrollo de sistemas basados en la
Web bajo control, minimizar los riesgos y mejorar la capacidad de mantenimiento y
calidad de los sistemas Web. [2]

Desde su origen y la promoción como una nueva disciplina en 1998, la ingeniería Web
está recibiendo creciente interés entre los actores de los sistemas basados en la web,
incluyendo desarrolladores, clientes, gobierno agencias, usuarios, académicos e
investigadores. Además, este nuevo campo ha atraído profesionales de otras disciplinas
relacionadas, tales como multimedia, ingeniería de software, sistemas distribuidos,
informática, y la recuperación de información. [2]

2.3. PROVEEDORES DE SERVICO

Un proveedor es una entidad de diverso orden que presta servicios a otras. En

informática, un proveedor es una entidad física o virtual que tiene el fin de ofrecer un
servicio a otra u otras entidades. Los tipos de proveedores pueden ser tan distintos como
una empresa que brinda servicios de Internet a clientes en un país, como un sistema
informático que pone aplicaciones y recursos al servicio de otros. [13]

26
En general, se conoce como proveedores a las empresas o particulares que ofrecen
servicios tecnológicos. Estos pueden ser acceso y conexión a Internet, telefonía móvil,
hosting de aplicaciones y sitios web, acceso a servicios y cuentas en determinados
softwares o sitios web, etc. [13]

El proveedor de servicios de Internet es también conocido como ISP o Internet Service

Provider. Se trata de empresas o individuos que conectan a usuarios de todas partes del
mundo a Internet o a una red en particular, brindando acceso y soporte de uso. Este tipo
de proveedores tienen un coste de uso mensual de acuerdo con el tipo y características
de conexión que el usuario desee. Por ejemplo, si desea una conexión vía telefónica o vía
fibra óptica, o si quiere menor o mayor velocidad, o si tal vez el usuario quiere conectarse
en forma inalámbrica. [13]

También se conoce como proveedor a un equipo o sistema informático que dispone de

servicios y recursos para el acceso de otros dispositivos. [13]

Este tipo de proveedores son virtuales, ya que no constituyen personas físicas, pero
cumplen un rol similar en facilitar el uso y acceso de un individuo o equipo a
posibilidades y servicios. [13]

A menudo estos proveedores funcionan mediante su configuración como tales, y no

necesariamente disponen de un costo extra, sino que son administrados de manera de que
un grupo de dispositivos puedan beneficiarse de los mismos recursos, ahorrando tiempo
y dinero. [13]

Para la empresa ITIL Foundation, destaca tres tipos de proveedores de servicio:

 Tipo I o proveedor de servicios interno.

 Tipo II o unidad de servicios compartidos.
 Tipo III o proveedores de servicio externos.

Aunque los aspectos generales de la gestión del servicio son comunes a todos ellos
existen obvias diferencias en los aspectos organizativos en cada caso. [14]

27
Cada tipo de proveedor de servicios tiene sus ventajas e inconvenientes que pasamos a
analizar. [14]

TIPO VENTAJAS DESVENTAJAS

I - Mayor control sobre los - Los recursos pueden no estar
servicios prestados. [14] optimizados. [14]
- Mayores niveles de - Dificultad a la hora de incrementar
personalización. [14] las capacidades. [14]
- Comunicación directa. [14] - Organizaciones más endogámicas y
menos flexibles. [14]
- Concentración de costes y riesgos.
[14]

II
- Se comparten costes y riesgos - Asumir actividades que no aportan
entre diferentes unidades. ventajas competitivas a la
[14] organización o empresa. [14]
- Posicionamiento más - Posibles conflictos de intereses
competitivo frente a entre diferentes unidades de
proveedores externos. [14] negocio.[14]
- Estandarización de procesos.
[14]
- Mayores opciones de
crecimiento [14]

III - Mayor flexibilidad y oferta. - Altos niveles de personalización de

[14] los servicios pueden resultar muy
- Se minimizan los riesgos costosos. [14]
pues estos son compartidos - El cliente puede caer cautivo de un
entre una amplia red de proveedor externo. [14]
clientes. [14]
- Procedimientos
estandarizados. [14]

Tabla 2.2: Tipos de proveedores de servicio

28
2.4. ARQUITECTURA ORIENTADA AL SERVICIO (SOA)

Una arquitectura orientada a servicios (SOA) como se muestra en la figura 2.6 es un estilo
de organización que guía todos los aspectos de la creación y utilización de servicios de
negocio a lo largo de su ciclo de vida (desde la concepción hasta la jubilación). El
concepto organizador clave de una SOA en sí es un servicio. Los procesos, principios y
métodos definidos por SOA están orientadas hacia los servicios; las herramientas de
desarrollo seleccionados por una SOA están orientados hacia la creación y el despliegue
de los servicios; y la infraestructura de tiempo de ejecución proporcionado por una SOA
está orientado a la ejecución y gestión de los servicios. [3]

Figura 2.6: Arquitectura SOA

Fuente: [http://sissoaction.sisinfomanagement.com/img/Ajax/definicionSOA1.jpg]

29
2.4.1. Características de SOA

 Dinámica, Visible y Conductor de Metadatos: Los servicios deben ser

publicados para que sean encontrados y consumidos sin la intervención del
proveedor. [3]
 Diseñado para múltiples estilos de invocación: Se incluyendo la puesta en cola
asíncrona, petición / respuesta, petición / devolución de llamada, petición /
sondeo, el procesamiento por lotes, y orientada a eventos de publicación /
suscripción. [3]
 Débilmente acoplados: Esto implica la articulación flexible de la interfaz y la
tecnología (sistemas operativos, servidores de aplicaciones, aplicaciones
empaquetadas, y middleware). [3]
 Contratos de servicio bien definidos: Estas definen las capacidades de servicio
y la forma de invocar el servicio de una manera interoperable.
 Base Standard: Los servicios deben estar basados en estándares abiertos. [3]
 Granularidad de Servicios y Contratos de servicio: Los servicios y los contratos
de servicios deben establecerse a un nivel de abstracción que tenga sentido para
los solicitantes de servicios como también proveedores de servicios. [3]
 Sin estado: Los servicios deben estar sin estado, ya que la escala es de manera
más eficiente que cualquier solicitud de servicio se pueden dirigir a cualquier
instancia de servicio. [3]
 Acuerdos de nivel de servicio predecibles (SLAs): Por lo general, los SLA
definen métricas para servicios tales como el tiempo de respuesta, el
rendimiento, la disponibilidad y asimismo los fallos (Para tener más información
acerca de los SLA, se puede revisar en el ANEXO B). [3]
 Servicios de Diseño con el rendimiento en mente: La invocación de servicio no
debe ser modelada en llamadas a funciones locales ya que la transparencia local
puede resultar en un servicio que está en otra máquina de la misma LAN u otra
red LAN o WAN. [3]

30
2.4.4. SOA y servicios Web

La arquitectura básica de servicios Web consta de especificaciones (SOAP, WSDL y

UDDI) que apoyan la interacción de un solicitante de servicio Web con un proveedor de
servicio web y el descubrimiento potencial de la descripción de servicios Web.

SOAP, originalmente definida como Simple Object Access Protocol es una

especificación de protocolo para el intercambio de información estructurada en la
implementación de Servicios Web en redes informáticas.

Se basa en XML como su formato de mensaje y por lo general se basa en otros protocolos
de la capa de aplicaciones, llamada a procedimiento más notablemente remoto (RPC) y
HTTP para la negociación y transmisión de mensajes. [3]

Las ventajas de utilizar SOAP sobre HTTP es que SOAP permite una comunicación más
fácil a través de servidores proxy y servidores de seguridad que la tecnología de ejecución
remota anterior y es lo suficientemente versátil como para permitir el uso de diferentes
protocolos de transporte. [3]

La Transferencia de estado representacional (REST del inglés Representational State

Transfer) es un estilo de arquitectura de software para sistemas hipermedia distribuidos
como la World Wide Web. REST se refiere a un conjunto de principios de arquitectura
de red, que describen cómo se definen y abordan los recursos. [3]

Los servicios Web REST se basan en HTTP como protocolo lo suficientemente rico
como para satisfacer completamente las necesidades de aplicaciones de servicios Web.
[3]

REST requiere menos software del lado del cliente para ser escrito que otros enfoques,
porque un solo navegador puede acceder a cualquier aplicación y cualquier recurso.[3]

31
2.5. ARQUITECTURA BASADA EN PROVEEDORES

Para comprender bien este apartado, se tiene identificado a los siguientes actores que son:

El Proveedor de servicios: representa una entidad que diseña y desarrolla una aplicación
o un módulo de software u otro servicio que interactúa con las consultas de los
consumidores de servicios por medio de la red. [20]

El Consumidor de servicios: es aquel que se beneficia de las funcionalidades de una

aplicación o un módulo de software u otro servicio a través de una interfaz adecuada.[20]

El Registro de servicios: Constituye el repositorio de servicios disponibles y pone a

disposición las interfaces de los proveedores de servicios para los consumidores que estén
interesados en utilizarlos. [20]

En base a lo citado se formula la siguiente definición:

“Representa un marco de separación entre los proveedores de servicio y los

consumidores de servicio que a través de implementaciones publicadas en la red y
almacenadas en un repositorio de servicio se consigue satisfacer necesidades por
medio de procesos que pueden ser automatizadas y disponibles para diferentes
plataformas para dicha arquitectura”.

32
 Figura 2.7 Representación de una arquitectura basada en proveedores
Fuente: Adaptación [20]

2.6. INTEGRACION DE APLICACIONES EMPRESARIALES (EAI)

En estos tiempos de cambio de mercado y la turbulencia, las empresas se enfrentan a la

creciente necesidad de interconectar los sistemas dispares para satisfacer la necesidad de
la empresa. Se estima que el 35% -60% de los recursos de TI de una organización se
dedica a la integración. La Integración de aplicaciones empresariales es la creación,
mantenimiento y mejora de vanguardia funcionalidad competitiva de soluciones de
negocio de la empresa mediante la combinación de la funcionalidad de las aplicaciones
heredadas existentes, off-the-shelf comercial (COTS) paquetes de software, y de nuevo
desarrollo de aplicaciones personalizadas a través de un middleware común. [3]

2.6.1. Aplicaciones Empresariales

Se tiene las siguientes definiciones:

Definición 1: Las aplicaciones empresariales son las aplicaciones de software

desarrolladas para gestionar las operaciones de negocio, activos y
recursos de la empresa. [3]

33
Definición 2: Una Aplicación Empresarial es una aplicación de software desarrollada
para administrar las operaciones, activos y recursos de una empresa. [15]

Definición 3: Una aplicación empresarial es un sistema que integra el manejo de diversas

entidades del negocio. Este tipo de sistema permite aumentar el rendimiento
de la empresa y bajar sus costos, ya que toda la información se encuentra
bajo un solo sistema, y muchas tareas pueden estar automatizadas, y puede
ser cualquier tipo de software ya sea libre, comercial, no libre etc [16]

Una definición adecuada para nuestro estudio sería:

Una aplicación empresarial constituye un sistema desarrollado para integrar las

operaciones, activos y recursos de una empresa, permitiendo contar con una base de
datos centralizada y que muchas tareas pueden estar automatizadas, encontrándose
en el mercado software libre, comercial, no libre, etc.

Como ejemplos podemos mencionar: programas de contabilidad y de ofimática, sistemas

de planificación de recursos empresariales(ERP), programas de gestión de clientes
(CRM), de recursos humanos, de servicio al cliente, etc.

2.6.1.1. Características

Las aplicaciones empresariales tienen en general las siguientes características:

 Involucran persistencia de datos

 Se manejan grandes cantidades de datos
 Existen varias interfaces de usuario, para distintos tipos de usuario
 En general se deben integrar con otras aplicaciones
 Se accede a los datos de forma concurrente

34
2.6.2. Gestión de Aplicaciones Empresariales

 Manejabilidad: Sistemas de aplicaciones empresariales se enfrentan a las

siempre cambiantes necesidades y entornos y deben ser capaces de adaptarse a
estos cambios de forma dinámica.
 Mantenibilidad: La mantenibilidad permite la utilización de componentes de
software con el tiempo. Análisis, diseño y los patrones de codificación ayudan a
desarrollar un lenguaje común y fomentar el uso de las mejores prácticas y
sencillas formas más intuitivas de conocimiento y aplicaciones de
mantenimiento. [3]
 Escalabilidad: La escalabilidad, en contraste con la capacidad de
mantenimiento, no implica un cambio real de las características de un
determinado software, sino que se dirige a la necesidad de mantener un
funcionamiento y el sistema más importante utilizable en términos de
crecimiento o fluctuante número de usuarios y el tráfico de las consultas
correspondientes y presentación de informes. [3]
 Interoperabilidad: La capacidad de las diferentes aplicaciones que trabajan
juntos es considerada una de las características más importantes de una
Arquitectura de Aplicaciones Empresariales. Muchas empresas de TI como
IBM, Microsoft, Sun Microsystems, y BEA están proporcionando todo un
arsenal de software basado en interfaces estándar que permitan una integración
perfecta. [3]
 Seguridad: Las empresas están dedicando recursos especiales para protegerse de
esta amenaza creciente. Los errores realizados en esta área a menudo no sólo
pueden causar pérdidas financieras directas, sino también puede tener un
impacto dramático en la reputación y el valor y la confianza de la empresa. [3]
 Fiabilidad: La fiabilidad se define como la capacidad de realizar y mantener las
funcionalidades distintas dentro de parámetros predefinidos por un período de
tiempo específico. [3]

35
  Usabilidad: Se define como la facilidad de comprensión y uso de un servicio, la
facilidad de uso también se ve afectada por la familiaridad, continuidad, y la
fuerza de los hábitos adquiridos [3]

2.6.3. Aplicaciones integradas

Definición 1: La integración de aplicaciones (algunas veces llamada integración de

aplicaciones empresariales o EAI) es el proceso de llevar los datos o una
función de un programa de aplicación, junto con la de otro programa de
aplicación. Donde ya existen estos programas, el proceso a veces se realiza
mediante el uso de middleware, ya sea embalado por un proveedor o escrito
sobre una base personalizado. Un desafío común para una empresa es la
integración de un programa existente (o herencia) con un nuevo programa
o con un programa de servicio Web de otra empresa. [17]

Definición 2: Combinación de tecnologías terrestres y espaciales para la provisión de

servicios de valor añadido guiados desde la perspectiva de los usuarios con
una garantía de sostenibilidad. [18]

Para nuestro estudio podemos contar con la siguiente definición:

La integración de aplicaciones corresponde al proceso de intercambiar procesos de

información entre programas software existentes o creados recientemente, los
mismos pueden ser de producción propia o desarrollados por diferentes proveedores,
además de contar con la posibilidad de correr bajo diferentes plataformas.

2.6.4. Entendiendo mejor la Integración de Aplicaciones Empresariales

EAI ofrece componentes para la integración de aplicaciones con las aplicaciones y

tecnologías externas dentro de la empresa y está diseñado para trabajar con productos de
terceros. Mediante el empleo de EAI efectivamente, una empresa puede aprovechar sus
activos existentes de información de toda la empresa, es decir, relaciones con los clientes:

36
  Para ofrecer nuevos productos y servicios de forma fácil y rápida
 Para agilizar su proceso interno y operaciones
 Para fortalecer las relaciones de suministro
 Para mejorar las relaciones con clientes

EAI permite la integración de toda la empresa con las diversas aplicaciones a través de
diferentes productos y tecnologías, con una vista de 360 ° en relación con el cliente a
través de múltiples canales de interacción. [3]

2.6.4.1. Fundamentos de la Integración

Los conceptos básicos relacionados con la EAI se describen aquí. Un EAI robusto y
flexible proporciona una combinación de métodos de integración y modos de
comunicación que están incorporados en los diversos modelos de integración que se
implementan dentro de la arquitectura EAI como se expone a continuación. [3]

Métodos de Integración

Los métodos de integración son enfoques utilizados para guiar una solicitud de un
emisor a un receptor. Los dos métodos principales de la integración son los
siguientes:

1) Mensajería: En este enfoque, el emisor construye un mensaje que contiene

la información sobre las acciones deseadas, así como los datos necesarios
para realizar las acciones. Los mensajes proporcionan una gran cantidad de
flexibilidad, porque la información de control se puede cambiar y extender
fácilmente; son independientes de las aplicaciones.
Sin embargo, para funcionar correctamente, los mensajes de integración
deben ser predefinidos precisamente para que los mensajes pueden ser
codificados y decodificados exactamente de la misma manera por todos los
remitentes y receptores. [3]

37
 2) Interfaz: En este enfoque, el emisor se comunica a través de una interfaz,
que define explícitamente las acciones que pueden ser invocados por una
aplicación. Las interfaces son difíciles de cambiar y ampliar; se encuentran
asociados a una aplicación particular. [3]
3) Conector: En este enfoque, la aplicación proporciona un punto de acceso
que permite que un mensaje o invocación en una interfaz pase a la
aplicación; un conector es más que una interfaz que proporciona
capacidades adicionales como el control de errores y la comprobación de la
validación, la conversión y transformación de datos en formato adecuado,
y la gestión de la información de estado que permite la entrega garantizada
o la recuperación adecuada. Muchas aplicaciones no tienen un punto de
entrada previamente predefinida o creada en la aplicación.
En esos casos, se puede utilizar archivos de datos, bases de datos, interfaces
de usuario, o la memoria como el punto de entrada para la inyección de
peticiones. [3]

Modos de Comunicación

La flexibilidad de los sistemas es críticamente dependiente de los modos de

comunicación que son utilizados por los sistemas. Suponiendo que una solicitud se
refiere a una comunicación de un emisor a un receptor, las dos opciones básicas
para las comunicaciones son los siguientes:

1) Comunicación simultánea o síncrona: Este requiere que el remitente de una

solicitud que espere hasta que haya una respuesta, que es el resultado de la
solicitud, esto se recibe antes de continuar con el procesamiento. Una
infraestructura de red fiable es esencial para este tipo de comunicación.[3]
Por ejemplo, los sistemas interactivos necesitan un tipo simultáneo de
comunicación. [3]
2) Comunicación asíncrona: Este permite al remitente continuar con el
procesamiento después de enviar la solicitud sin esperar respuesta alguna.

38
 Se utiliza cuando se requiere la comunicación de información sin la
necesidad de coordinar las actividades o respuestas. [3]

Opciones de Middleware

El Middleware es un software que permite a las distintas aplicaciones interactuar

entre sí, que facilita la comunicación de las solicitudes entre los componentes de
software mediante el uso de interfaces o mensajes predefinidos. Los cinco tipos
básicos de middleware son los siguientes:

1) Llamada de procedimiento remoto (RPC): Este se basa en la noción de

desarrollo de aplicaciones distribuidas que se integran en el nivel de
procedimiento, a través de una red. [3]
2) Acceso a Base de datos de middleware: Basado en la noción de desarrollo
de aplicaciones distribuidas que se integran a nivel de datos distribuidos ya
sea en archivos o bases de datos pero en toda la red. [3]
3) Mensajes Orientados a Middleware (MOM): Basado en la noción de
desarrollo de aplicaciones distribuidas que se integran a nivel de mensajes,
a través de la red. [3]
4) Tecnología de Objetos Distribuidos (DOT): Este se basa en la noción de
desarrollo de aplicaciones distribuidas que se integran a nivel de interfaz
pero lo que hace la aplicación es identificarlo como un objeto. [3]
5) Monitor de Procesamiento de Transacción (TPM): Basado en la noción de
desarrollo de aplicaciones distribuidas que se integran a nivel de
transacciones distribuidas en toda la red. [3]

2.6.4.2. Modelos de Integración

Un modelo de integración define el enfoque y configuraciones utilizado para integrar

aplicaciones de software dependiendo de la naturaleza y los métodos de la integración
prevista. Hay tres posibles puntos de integración, concretamente, de presentación, de
funcionalidad y de integración de datos. [3]

39
Integración de Presentación

En este modelo, la integración se logra mediante la implementación de una nueva

y uniforme interfaz de la aplicación de usuario, la nueva aplicación parecerá ser
una sola aplicación, aunque puede estar accediendo a varias y a otras aplicaciones
en el back-end. Por lo tanto, una sola presentación podría reemplazar un conjunto
de interfaces basadas en terminales y podría incorporar características adicionales,
funciones y flujos de trabajo para el usuario.

La Integración de Presentación es la más fácil de lograr y se puede automatizar casi

el 100%; Sin embargo, también es el más limitante de los tres modelos. [3]

Integración Funcional

En este modelo, la integración se lleva a cabo mediante la invocación de la

funcionalidad a otras aplicaciones o de la lógica de negocio de las aplicaciones
existentes mediante el uso de interfaces de nivel de código a las aplicaciones
existentes. Esto podría lograrse a nivel de un objeto o un procedimiento o través de
la interfaz de programación de aplicaciones (API) si existe para cada una de las
aplicaciones correspondientes. [3]

Tradicionalmente, las llamadas a procedimiento remoto (RPC), que se han

empleado para este tipo de integración, han proporcionado las definiciones de
acceso y servicios de comunicaciones básicas. Se cuenta con tres categorías de
procesamiento distribuido que son los siguientes:

1) Mensaje orientada Middleware (MOM): este logra la integración mediante

el establecimiento de la comunicación de mensajes entre aplicaciones por
medio de los mensajes colocados en MOM, que a su vez lleva a cabo en
una variedad de configuraciones, incluyendo la cola de mensajes y de paso
de mensajes. MOM es entonces responsable de la entrega al sistema de
destino. [3]

40
 2) Tecnología de Objetos Distribuidos (DOT): Se logra la integración al
proporcionar interfaces de objetos que hacen que las aplicaciones se vean
como objetos. Las aplicaciones pueden tener acceso a otras aplicaciones a
través de una red a través. CORBA de OMG, COM + de Microsoft y Java
2 Enterprise Edition de Sun (J2EE) son ejemplos de DOT. [3]

3) Los Monitores de Procesamiento de Transacciones (TPMS): estos logran

la integración mediante el apoyo crítico para la integridad de los recursos
distribuidos, tales como bases de datos, archivos y colas de mensajes a
través de arquitecturas distribuidas que permiten distintos tipos de
transacciones que se gestionan mediante una variedad de conceptos,
incluyendo dos el cometido de fases. Tuxedo de BEA es un ejemplo de
TPM. [3]

Integración de Datos

En este modelo, la integración se lleva a cabo sin pasar por la lógica de negocio de
aplicaciones existente y se accede directamente a los datos creados, procesados y
almacenados por cada una de las aplicaciones correspondientes. Por ejemplo, un
sistema de facturación basado en Oracle se puede integrar con un sistema de pedido
de un cliente basado en IBM utilizando la tecnología de puerta de enlace de base
de datos que integra la base de datos DB2 con la base de datos Oracle. [3]

El modelo de integración de datos proporciona una mayor flexibilidad que el

modelo de integración de presentación; se simplifica el acceso a datos de múltiples
fuentes y también permite que los datos a sean reutilizados a través de otras
aplicaciones. Sin embargo, la integración a nivel de datos requiere la reescritura de
cualquier funcionalidad requerida por cada una de las aplicaciones, lo que implica
un mayor esfuerzo para evitar inconsistencias, la estandarización, la prueba y la
depuración para cada una de las aplicaciones en forma permanente. Este modelo
de integración no es muy susceptible para cambios y mantenimiento. [3]

41
Integración de Procesos de Negocio

El logro de la integración de procesos de negocios a menudo se relaciona con la

reingeniería de procesos de negocio y no es un único problema técnico. Sin
embargo se requiere la aplicación de varias capas técnicas como la fundación e
integración aplicaciones a un nivel más alto de abstracción. [3]

SOA, BPEL, y tecnologías relacionadas hoy proporcionan nuevas oportunidades

para hacer que los sistemas integrados de información más flexible y adaptable a
los cambios en los procesos de negocio. De esta manera los sistemas de
información pueden obtenerse más ágilmente. [3]

Integración Business-to-Business (B2B)

Hay una creciente necesidad de permitir la integración entre empresas, a menudo

denotado como de integración empresa a empresa (B2B), o e-business. La
capacidad de respuesta inmediata, conseguido por la integración acoplada al back-
end (sistemas de información de la empresa) y los sistemas del front-end
(Presentación), y es un factor clave de éxito. [3]

2.7. LA NUBE (CLOUD COMPUTING)

Una definición clara lo tiene el Instituto Nacional de Estándares y Tecnología (NIST) el

cual dice:

“La Nube es un modelo para permitir adecuadamente, una petición accedida desde
de la red a un conjunto compartido de recursos de computo configurables (por ej.
redes, servidores, almacenamiento, aplicaciones, y servicios) que son rápidamente
aprovisionados y liberados a disposición del cliente con un mínimo esfuerzo de
gestión o la interacción con el proveedor de servicios. Este modelo promueve la
disponibilidad y está compuesto por cinco características principales, tres modelos
de entrega, y cuatro modelos de despliegue. [3]

42
2.7.1. Características

Las cinco características esenciales son:

1) Autoservicio a petición: Permite que los usuarios tengan la posibilidad

computacional (por ej. aplicaciones, servidor de tiempo y almacenamiento en
red) cuando y donde lo requieran. [3]
2) Acceso al ancho de red: Capacidades que están disponibles en la red y accesibles
a través de mecanismos estándar que promueven el uso de plataformas de cliente
heterogéneas sencillas o difíciles (por ej. Celulares, tablets, computadoras
portátiles y estaciones de trabajo). [3]
3) Conjunto de recursos: Permiten combinar recursos de computación heterogéneos
(por ej. Hardware, software, los servidores de procesamiento y el ancho de banda
de red) para servir a consumidores múltiples - tales recursos son asignados
dinámicamente. [3]
4) Elasticidad rápida: Y la escalabilidad que permite funcionalidades y recursos
rápidos, elásticos y automáticamente escalados, en base a la demanda de uso. [3]
5) Servicio controlado: Se refiere al control y optimizado en la asignación de
recursos de forma automática, permitiendo un fácil monitoreo, control y emisión
de reportes. [3]

2.7.2. Modelos de entrega

Los tres modelos de entrega se detallan a continuación:

2.7.2.1. Infraestructura como un servicio (IaaS)

IaaS del inglés Infrastructure as a Service, de acuerdo con NIST, está definido de la
siguiente manera: “Es la capacidad suministrada al consumidor como ser el
procesamiento, el almacenamiento, las redes y otros recursos de computación, donde el
consumidor puede utilizar y operar un software cualquiera, que puede incluir sistemas
operativos y aplicaciones. [3]

43
El consumidor no puede administrar o controlar la infraestructura de la nube pero tiene
control sobre los sistemas operativos, el almacenamiento, el despliegue de aplicaciones
y posiblemente un control limitado de componentes de conexión de red (por ej. Host
firewalls)”. [3]

El usuario de IaaS tiene facultad solo en la infraestructura del equipo físico permitido y
puede usarlo como si fuera su computadora propia en una red lejana y tiene control sobre
el sistema operativo y software alojados ahí. IaaS es ilustrado en la figura 1. el proveedor
de IaaS tiene control sobre el equipo físico verdadero, y el usuario de nube puede pedir
la asignación de recursos virtuales, que son asignado por el proveedor de IaaS. Por lo
tanto, IaaS es ideal para los usuarios que quieren el control completo sobre la pila de
software que operan.

Las plataformas de IaaS conocidas incluyen EC2 de Amazon, Rackspace, y RightScale.

Adicionalmente los distribuidores tradicionales como IBM, y Microsoft ofrecen
soluciones que pueden ser usados para construir IaaS privados. [3]

2.7.2.2. Plataforma como un servicio (PaaS)

PaaS del inglés Platform as a Service, NIST define PaaS de la siguiente manera: “Es la
capacidad suministrada al consumidor para desplegar aplicaciones creadas usando
lenguajes de programación y herramientas soportadas por el proveedor de la
infraestructura de nube creada o adquirida.” [3]

Las plataformas de PaaS son muy adecuadas para usuarios de nube que descubren que el
software estándar personalizado que están usando se ajusta al software estándar
personalizado proveído por uno de los distribuidores de PaaS. Esto permite que a ellos
se concentren en la aplicación. Azure, Google Apps, y Hadoop son algunas plataformas
de PaaS conocidas. Asimismo los distribuidores tradicionales como HP, IBM, y
Microsoft ofrecen las soluciones que pueden ser usados construir PaaS privados. [3]

44
2.7.2.3. Software como un servicio (SaaS)

SaaS del inglés Software as a Service, NIST la define de la siguiente manera: “Es la
capacidad suministrada al consumidor para usar las aplicaciones del proveedor corriendo
sobre una infraestructura en la nube. Las aplicaciones son accesibles por el cliente desde
diferentes dispositivos a través de una interfaz de cliente como ser un navegador de web
(por ej. el correo electrónico basado en Web). El consumidor no administra o controla la
infraestructura de nube incluyendo la red, los servidores, los sistemas operativos, el
almacenamiento o incluso la capacidad de las aplicaciones individuales, pero tiene la
posibilidad limitada de leves ajustes a una específica aplicación de usuario.” [3]

Cualquier aplicación que puede ser accedida usando un navegador de web puede ser
considerado como SaaS. Observe la figura 1 sobre el SaaS, el proveedor de SaaS controla
todas las capas aparte de la aplicación. Los usuarios que entran al sistema del servicio de
SaaS pueden ambos usar la aplicación y configurar la aplicación para su uso.[3]

Por ejemplo, los usuarios pueden usar Salesforce.Com para almacenar sus datos del
cliente. Las aplicaciones de SaaS prominentes incluyen Salesforce.Com para CRM,
documentación de Google para el compartimiento de documento, y sistemas de correo
electrónico de Web como Gmail, Hotmail, y Yahoo! Correo. Los distribuidores de IT
como HP e IBM también venden sistemas que pueden ser arreglados para poner SaaS en
una nube privada; SAP, por ejemplo, puede ser usado como un ofrecimiento de SaaS
dentro de una empresa u otra entidad. [3]

45
 Figura 2.8: Los tres modelos de entrega de la nube
Fuente: [3]

2.7.3. Modelos de despliegue

Los cuatro modelos de despliegue se detallan a continuación:

2.7.3.1. Nube Pública

Como su nombre indica, está asequible al público en general y es llevado por una
organización. La organización podría ser una empresa (como Google), académica, o un
departamento gubernamental.[3]

El proveedor de computación de nube posee y dirige la infraestructura de nube. La

existencia de muchos consumidores diferentes dentro de una arquitectura de nube se
refiere como un modelo de multitenencia. [3]

2.7.3.2. Nube Privada

Tiene un propósito exclusivo para una organización especial. Los recursos de la nube
pueden ser ubicados sobre o fuera de la premisa y pueden ser administrados y dirigidos
por la organización consumidora o una tercera parte. [3]

46
2.7.3.3. Nube Híbrida

Se forman cuando más de un tipo de infraestructuras de nube son utilizadas para una
situación particular. Por ejemplo, una organización puede utilizar una nube pública para
algún aspecto de su empresa, pero también tener una nube privada sobre la premisa para
los datos que son confidenciales. [3]

2.7.3.4. Nube Comunitaria

Son un modelo de nube donde los recursos existen para varias partes que tienen un interés
compartido o la misma causa. Investigadores y Organizaciones académicas la han creado
para dirigir experimentos científicos a gran escala (e- ciencia). [3]

2.8. LA NORMA IS/IEC 62264-2 (2004)

Esta parte del EIC 62264, en conjunción con la norma IEC 62264-1, especifica el
contenido de la interfaz genérica entre las funciones de control de fabricación y otras
funciones empresariales. Las interfaces consideradas son las interfaces entre los niveles
3 y 4 del modelo jerárquico definido en la norma IEC 62264-1. El objetivo es reducir el
riesgo, el coste y los errores asociados con la implementación de las interfaces. [19]

Desde el IEC 62264 se cubre muchos dominios y hay muchos estándares diferentes en
esos dominios, la semántica de la presente norma se describe en un nivel objetivo y
permitir a los otros estándares ser asignados a estas semánticas. Para ello este estándar
define un conjunto de elementos de contenido interfaces genéricas, junto con un
mecanismo para extender esos elementos para implementaciones. [19]

El alcance de esta parte de la norma IEC 62264 se limita a la definición de atributos de

los modelos de objetos de 62264 IEC - 1. [19]

Abordar con éxito el problema de la integración de sistemas de control de la empresa

requiere la identificación de los límites entre la empresa y las operaciones de fabricación
y de control de dominios (MO & C). [19]

47
El límite se identifica mediante modelos pertinentes que representan funciones, equipo
físico, la información en el dominio MO & C, y los flujos de información entre los
dominios. [19]

Múltiples modelos muestran las funciones y la integración asociados a los sistemas de

control y de la empresa. [19]

Figura 2.9: Esquema de modelos

Fuente: [19]

Esta norma proporciona modelos y la información en varios niveles de detalle y la

abstracción. Estos niveles se ilustran en la Figura 2.9, que sirve como un mapa para el
resto del documento. [19]

2.8.1. Modelo de jerarquía

La Figura 2.10 muestra los diferentes niveles de un modelo de jerarquía funcional:

planificación comercial y logística, operaciones de fabricación y control, y de lote,
continuos o de control discreto. [19]

48
El modelo muestra los niveles jerárquicos en el que se toman las decisiones. La interfaz
abordado en esta norma se encuentra entre el nivel 4 y nivel 3 del modelo de jerarquía.

Figura 2.10: Jerarquía funcional

Fuente: [19]

Los niveles 2, 1 y 0 corresponden a la línea de supervisión. El nivel 0 indica el proceso,

por lo general el proceso de fabricación o producción. Nivel 1 indica detección manual,
sensores, actuadores y utilizado para controlar y manipular el proceso. Nivel 2 indica las
actividades de control, manuales o automatizados, que mantiene el proceso estable o bajo
control. [19]

2.8.2. Notación UML

La siguiente tabla define los elementos pertenecientes al Lenguaje de Modelado

Unificado (UML). [19]

49
SIMBOLO DEFINICIÓN
Define un packaqe, una colección de modelos de
objetos utilizan clases, y otras modelos UML. En este
documento un paquete es utilizar para especificar un
modelo externo, como una regla de producción de
referencia modelo de OA a otra parte del modelo
Define una clase de objetos, cada uno con los tipos
sam de atributos. Cada objeto es único de
identificación o enumerable. No hay operaciones o
métodos se enumeran para las clases. Atributos con
un '-'before su nombre indica atributos que son
generalmente opcional en cualquier uso de la clase
Una asociación entre los elementos de una clase y
elementos de otra o la misma clase. Cada asociación
se indentified. Puede tener el número esperado o
rango de miembros de la subclase, cuando "n" indica
un número indeterminado. Por ejemplo 0. N significa
que pueden existir cero o más miembros de la
subclase ..

Generalización (flecha apunta a la superclase)

muestra que un elemento de la clase es un tipo
especializado de la superclase.

La dependencia es una asociación débil que muestra

que un elemento de modelado depende de otro
elemento de modelado. El tema en la cola depende
del tema en la cabeza de la relación.

Agregación (compuesto de) muestra que un elemento

de la clase se compone de elementos de otras clases

Compuesto muestra una forma fuerte de agregación,

que exige que se incluya una instancia de parte en a
lo sumo un material compuesto a la vez y que el
objeto compuesto tiene la responsabilidad exclusiva
de la disposición de sus partes.
.
Tabla 2.3: UML notación a usar

50
CAPITULO 3
MARCO APLICATIVO

RESUMEN

Este capítulo presenta el modelo de despliegue seleccionado

para el desarrollo del trabajo de investigación y utilizando
como herramienta a UML, a fin de representar la arquitectura
basada en proveedores de servicio para aplicaciones
empresariales integradas en la nube, tomando como base los
conceptos ya desglosados en el capítulo anterior.

51
3.1. ANALISIS DEL MÉTODO

La Nube conceptualizada en el capítulo 2.7 hace mención de tres modelos de entrega, en

esta sección mencionaremos a los proveedores de servicio que cuentan con estos
modelos, resaltando características importantes, no sin antes mencionar las
características con que debe contar los proveedores de servicios.

3.1.1. Características básicas requeridas para los proveedores de servicios

A continuación detallamos algunas de las características deseables para la elaboración de

este trabajo, notara que en las tablas 3.1, 3.2 y 3.3 están otras características que se aplican
de forma distinta para los tipos de servicios existentes en la nube.

 Escalabilidad: El proveedor de servicios debe poseer infraestructuras

computacionales, software y aplicaciones capaces de lograr escalabilidad.
 Integración: El proveedor de servicios debe contar con la posibilidad de brindar
integración ya sea en su infraestructura de hardware, software o entre
aplicaciones.
 Virtualización: Esta característica no siempre está presente en todos los
proveedores de servicio a razón de que existen aplicaciones que requieren contar
con infraestructura física bien definida, pero en caso de contar con dicha
característica el proveedor de servicios debe poseer infraestructuras que
garanticen una adecuada virtualización de servidores a fin de asignar recursos y
proveer servicios en forma eficiente, dinámica y elástica.
 Lista de Precios: El proveedor de servicios debe contar con un apartado de
información de costos por los servicios ofrecidos, esto permite a los consumidores
elaborar una cotización en base a sus requerimientos. Un aspecto que puedo
mencionar es que los proveedores de servicio cuentan con un agente en línea para
poder realizar las consultas adecuadas.

52
3.1.2. Proveedores de IaaS

A continuación en la siguiente tabla se presentamos una lista con proveedores que tienen
a disposición el servicio IaaS y asimismo cuentan con una lista de precios para realizar
las comparativas.

CARACTERISTICAS

Prueba del servicio

Almacenamiento
PROVEEDORES Lista de Precios
Virtualización

Transferencia
Escalabilidad
Integración

Procesador

Memoria
Softlayer de IBM     1 – 32 1 – 48 Gb 1Gb – 1,2 500 Gb 1 mes
[21] Núcleos Tb
Atlantic.net [22]    1 – 20 512Mb – 20 Gb – 2TB a
Núcleos 64 Gb 650 Gb 9TB
Amazon EC2 [23]     1 – 40 1 – 244 1 – 48000 1 Año
Núcleos Gb Gb
SSD: 32 –
6400 Gb
Elastichost [24]     10 Mhz – 128 – 2 Gb – 1 – 1000
20000 Mhz 8192 Mb 1862 Gb Gb
Microsoft azure     1 – 32 0,75 – 20 – 605 1 mes
[25] Núcleos 112 Gb Gb
SSD: 50 –
6144 GB
CenturyLink [26]     1 – 16 1 – 128 1 – 4000 1 mes
Núcleos Gb Gb
Rackspace [27]     6 a 32 24 – 128 730 Gb – 4 meses
Núcleos Gb 3000 Gb
vmware cloud     1 – 16 1 – 240 0 – 6Tb 3 meses
[28] Núcleos Gb SSD: de 0 a
6 TB
google cloud [29]     1 – 32 24 – 128 730 – 3000 2 meses
Núcleos Gb Gb
Joyent [30]     1 – 32 1 – 128 3 - 30720 10 Gb
Núcleos Gb Gb
Tabla 3.1: Proveedores de IaaS

53
3.1.3. Proveedores de PaaS

A continuación en la siguiente tabla se presentamos una lista con proveedores PaaS que
tienen a disposición su lista de precios.

PROVEEDOR PLATAFORMA DE BASE DE LISTA DE

DESARROLLO DATOS PRECIOS
Google App Engine [31]  Phyton  
Heroku[32]  Node  
 Rubi
 Java
 Php
 Phyton
 Go
 Scala
 clojure
Microsoft Azure [25]  Visual Studio Online  
Oracle [33]  
Tabla 3.2: Proveedores de PaaS

3.1.4. Proveedores de SaaS

A continuación en la siguiente tabla se presentamos una lista con proveedores que tienen
a disposición el servicio SaaS.

PROVEEDOR Detalle del Servicio

Google Apps [34]  Google Driver

 Gmail de tipo gratuito o con dominio personalizado
 Google Apps
 Google Maps
 Hangouts
 Editor de Texto
 Hoja de Calculo

Dropbox [35]  Servicio de almacenamiento de datos

 Cifrado AES de 256 bits y SSL (con Pago)
 Recuperación de archivos.
 Borrado remoto
 Auditorias de actividad de usuarios y uso compartido

54
 Apple Icloud [36]  Amazon Flexible Payments Service (Amazon FPS)
 Amazon DevPay

SalesForce [37]  Automatización de la fuerza de ventas y CRM

Tabla 3.3: Proveedores de SaaS

3.2. VISTA LÓGICA

En la figura 3.1, tenemos las entidades que mínimamente se requiere para lograr la
funcionalidad que necesitamos.

Figura 3.1: Uso de Diagrama de Clases para la Vista Lógica

Fuente: Elaboración Propia

55
A continuación se detalla las clases mostradas en la figura anterior:

 Las clases UsuarioSistema y TipoUsuarioSistema son responsables de la

administración de usuarios (invitado, cliente o administrador), así como de los
procesos pertinentes a la autenticación y autorización para el ingreso a los
servicios.
 La clase Plantilla es responsable de las plantillas de despliegue del modelo IaaS,
PaaS o SaaS.
 La clase Aplicación está relacionada con la clase Plantilla en vista de contener de
una a varias Plantillas.
 La clase Proveedor es la responsable de la prestación de servicios, como se
observa tiene relación con Aplicación y EstacionTrabajo.
 La clase SistemaOperativo y TipoSistemaOperativo son las responsables de la
administración de los sistemas operativos disponibles en la infraestructura.
TipoSistemaOperativo determina el sistema operativo, contándose con cinco
opciones: Windows, Linux, Mac, Solaris y Android.
 La clase EstacionTrabajo administra la información de cada una de las máquinas
físicas que componen la infraestructura base del modelo IaaS y
TipoEstacionTrabajo determina el tipo de estación de trabajo pudiendo ser entre
físico y virtual.
 La clase Seguridad está referida al nivel de seguridad con que cuenta el servicio,
como se puede observar esto tiene mayor impacto entre las clases
EstacionTrabajo y Aplicacion.

56
3.2. VISTA DE DESPLIEGUE

A continuación se muestra la Vista de Despliegue utilizando el Diagrama de Paquetes y

el Diagrama de Componentes.

Figura 3.2: Uso de Diagrama de Paquetes para Vista de Despliegue

Fuente: Elaboración en base a la Figura 2.8

Figura 3.3: Uso de Diagrama de Componentes para Vista de Despliegue

Fuente: Elaboración Propia

57
3.3. VISTA DE PROCESOS

A continuación se muestra en la figura 3.4 el Diagrama de Actividades para el

Consumidor de Servicios.

Figura 3.4: Uso de Diagrama de Actividades para la Vista de Procesos del Consumidor
Fuente: Elaboración Propia

A continuación se muestra en la figura 3.5 el Diagrama de Actividades para el Proveedor

de Servicios.

58
 Figura 3.5: Uso de Diagrama de Actividades para la Vista de Procesos del Proveedor
Fuente: Elaboración Propia

Ahora bien, el siguiente gráfico es fundamental para explicar las actividades que se
realizan a nivel de servicios.

Figura 3.6: Uso de Diagrama de Actividades para la Vista de Procesos entre Procesos
Fuente: Elaboración Propia

59
3.4. VISTA FISICA

La arquitectura buscada es la que se muestra en el siguiente gráfico.

Figura 3.7: Arquitectura basada en proveedores de servicio

Fuente: Elaboración propia

Ahora bien se detalla a continuación la gráfica generada:

 Capa CaaS: es la capa referida a Cloud como un servicio, ofreciendo las

posibilidades de Nube Privada, Nube Pública y Nube Comunitaria, asimismo
están incluidas las capas internas de Seguridad, Control de calidad y el
Middleware que se encarga del tratado de mensajes hacia la capa EIA, recurre a
los protocolos XML, SOAP o REST para interactuar con las capas internas del
EIA.

60
 Capa EIA: Corresponde a la capa de Integración de aplicaciones sobre los
servicios de la capa CLOUD, esta perspectiva permite organizar mejor los
procesos IaaS, PaaS y SaaS.
 Capa de Proveedores de servicio: Enmarca claramente el monitoreo y/o control
de ambas capas, a fin de garantizar un servicio acorde a los requerimientos de los
clientes.

61
3.5. ESCENARIOS

3.5.1. Vista Lógica a Vista de Procesos

A continuación se muestra el escenario correspondiente:

Figura 3.8: Escenario de Vista lógica a Vista de Procesos

Fuente: Elaboración propia

62
3.5.2. Vista Lógica a Vista de Despliegue

A continuación se muestra el escenario correspondiente:

Figura 3.9: Escenario de Vista lógica a Vista de Despliegue

Fuente: Elaboración propia

63
3.5.3. Vista de Procesos a Vista Física

A continuación se muestra el escenario correspondiente:

Figura 3.10: Escenario de Vista de Procesos a Vista Física

Fuente: Elaboración propia

64
3.5.1. Vista de Despliegue a Vista Física

A continuación se muestra el escenario correspondiente:

Figura 3.11: Escenario de Vista de Despliegue a Vista Física

Fuente: Elaboración propia

3.6. PROPUESTA DE IMPLEMENTACION

El Hotel Real Plaza (Ex Hotel Radisson La Paz) – ubicado en la Av. Arce #2177 es uno de los
hoteles más reconocidos en la ciudad de la Paz, pertenecía a la cadena de Hoteles Radisson hasta
el año 2014, , dentro de sus plataformas de soluciones tiene instalado el sistema hotelero de
Micros Fidelio (adquirido por Oracle el 23 de junio del 2014). En la figura 3.12 se muestra como
esta implementado actualmente el sistema.

65
 Figura 3.12: Implementación actual Hotel Real Plaza
Fuente: Elaboración propia

La Inversión realizada el Año 2008 y los pagos correspondientes se detallan a continuación:

 Compra de 3 servidores (HP Proliant ML 370G5, HP Proliant ML350 y PC HP básico

Interface) requeridos para la instalación del sistema Micros Fidelio, en donde 1
corresponde al servidor de aplicaciones, el segundo corresponde a la base de datos y el
tercero es la interface de la central telefónica y el servidor de aplicaciones.
 Inversión en Infraestructura: 24000 $us (dato obtenido de Contabilidad)
 Pago Licencia de Uso de Micros - Fidelio cada 6 meses: 7000 $us
 Pago servicio de Internet: 1200 Bs.- (2 megas Entel)
 Pago 16 Ip’s Publicos: 110 Bs.-

66
Se tiene previsto la actualización del sistema Opera, para lo cual se tiene los siguientes datos.

Inversión Requerida para la gestión 2016

 Compra de servidor: DELL PowerEdge T110 II SAS valor 2295.83 $us (cotización
adjunta en el ANEXO C)
 Pago Licencia de Uso de Micros – Fidelio cada 6 meses: 7000 $us
 Inversión y pago en un año es de 5295.83 $us.
 Pago actual del servicio de Internet: 1910 Bs (velocidad de internet 2MB)
 Pago de Ip público: 110 Bs

Una propuesta diferente es la de contar con el servicio Oracle Cloud el cual tendría la siguiente
propuesta gráfica.

Figura 3.13: Implementación propuesta al Hotel Real Plaza

Fuente: Elaboración propia

67
En el grafico 3.14 se muestra la arquitectura de Oracle Cloud, y en lafigura 3.15 la arquitectura
basada en proveedores de servicio en conjunción con la de Oracle.

Figura 3.14: Arquitectura de Oracle Cloud Data

Fuente: [http://static4.businessinsider.com/image/54982d4aecad0444177c3bc3-1200-
445/screen%20shot%202014-12-22%20at%202.12.18%20pm.png]

Inversión planteada con Data Cloud de Oracle para la gestión 2016

Computadora de Computadora con

Producto (por OCPU) propósito general súper memoria

Por Mes Por Hora Por Mes Por Hora

Standard Edition Service $600 $1,008 $700 $1,176

Enterprise Edition Service $3000 $5,040 $3100 $5,208

High Performance Service $4000 $6,720 $4100 $6,888

Extreme Performance Service $5000 $8,401 $5100 $8,569

Tabla 3.4: Lista de precios vigentes a la fecha en Oracle
Fuente: [https://cloud.oracle.com/en_US/database?tabID=1406491812773]

68
 Figura 3.15: Arquitectura de Proveedores de servicio con Oracle Cloud Data
Fuente: Elaboración Propia

El hotel trabaja 24 Horas al día y los 365 días del año, teniéndose las siguientes observaciones:

Calculo al mes:

 Para lo que se requiere el óptimo es en standard edition Service. Con High-Memory

Compute por mes de 700 $us
 Al cabo de 6 meses se pagaría: 4200 $us

69
  Al año sería: 8400 $us
 Ahorro a obtener: 2295.83 $us (no se compraría el servidor) + 5600 al año de ahorro.

Calculo por horas

 El tiempo estimado en promedio es variable teniéndose los siguientes movimientos de

consultas al sistema acorde las siguientes tablas.

HORARIO HORAS DETALLE ÁREAS

ACUMULADAS INVOLUCRADAS

3-4 1:00 Cierre de sistema  Auditor nocturno

4-6 3:00 Salidas por vuelos  Recepción

programados o  Ama de llaves
delegaciones

7:00-8:30 4:30 Salidas y/o ingresos  Recepción

 Ama de llaves

8:30 – 12:30 8:30 Horario de oficina  Sistemas

 Contabilidad
 Ventas
 Reservas
 Recepción
 Ama de llaves

12:30 – 14:30 10:30 Horario de almuerzo  Contabilidad

(turnante)
 Ventas (turnante)
 Recepción
 Reservas (turnante)
 Ama de llaves

14:30 – 18:30 14:30 Horario de Oficina  Sistemas

70
  Contabilidad
 Ventas
 Reservas
 Recepción
 Ama de llaves

18:30 – 21:00 17:00 Ingresos y/o salidas  Recepción

 Reservas
 Ventas (por casos
especiales)
 Ama de llaves

22:30-23:30 18:00 Ingresos  Recepción

 Ama de llaves

Tabla 3.5: Carga horaria de uso del sistema hotelero de Lunes a Viernes

HORARIO HORAS DETALLE ÁREAS

ACUMULADAS INVOLUCRADAS

3-4 1 Cierre de sistema  Auditor nocturno

4-6 3 Salidas por vuelos  Recepción

programados o  Ama de llaves
delegaciones

7:00-8:30 4:30 Salidas y/o ingresos  Recepción

 Ama de llaves

9:00 – 12:00 7:30 Horario de sábado  Sistemas (turnante)

 Contabilidad
(turnante)
 Ventas (turnante)
 Reservas
 Recepción
 Ama de llaves

71
12:00 – 14:30 10:00 Horario de almuerzo  Recepción
personal de turno  Reservas (turnante)
 Ama de llaves

14:30 – 16:00 11:30 Ingresos y/o salidas de  Recepción

huéspedes  Ama de llaves

18:30 – 21:00 14:00 Ingresos y/o salidas ligth  Recepción

checkout  Ama de llaves

22:30-23:30 15:00 Ingresos  Recepción

 Ama de llaves
Tabla 3.6: Carga horaria de uso del sistema hotelero en Sábado

HORARIO HORAS DETALLE ÁREAS

ACUMULADAS INVOLUCRADAS

3-4 1 Cierre de sistema  Auditor nocturno

4-6 3 Salidas por vuelos  Recepción

programados o  Ama de llaves
delegaciones

7:00-10:30 5:30 Salidas y/o ingresos  Recepción

 Ama de llaves
Limpieza de habitaciones

12:00 – 14:30 8:00 Horario de almuerzo  Recepción

personal de turno  Reservas (turnante)
 Ama de llaves

14:30 – 16:00 9:30 Ingresos y/o salidas de  Recepción

huéspedes  Ama de llaves

18:30 – 21:00 12:00 Ingresos y/o salidas ligth  Recepción

checkout  Ama de llaves

22:30-23:30 13:00 Ingresos  Recepción

 Ama de llaves
Tabla 3.7: Carga horaria de uso del sistema hotelero en Domingo

72
La suma de la carga horaria será:

 Lunes a viernes: 18 hrs de uso

 Sábado: 15 hrs de uso
 Domingo: 13 hrs de uso

Total de horas empleadas en la semana es = 46 hrs a la semana de uso

Total de horas al mes: (46 hr /7 días/) * 30 días = 197 horas al mes.

Así el cálculo de pago por consumo por horas en el plan standard edition Service. Con
High-Memory Compute 197 * 1,176 = 231.84 $us al mes

Al año se pagaría 2782,08 $us.

El ahorro con respecto de un pago por mes es => 8400 – 2782.08 = 5617.92

La propuesta está siendo considerada por el departamento de Sistemas, contabilidad y

Gerencia para la gestión 2016.

73
CAPITULO 4
DEMOSTRACION DE HIPOTESIS

RESUMEN

Este capítulo presenta la prueba de hipótesis, tomando como

referencia los datos referentes a los proveedores de servicio
descritos en tablas.

74
4.1. OBTENCION DE DATOS

A continuación elaboramos dos tablas en las cuales se detallan los requerimiento de un

servicio sin escalamiento, y para la tabla siguiente se contemplara costos con
escalamiento de procesador, memoria y/o disco duro, la elaboración de las mismas son
con datos reales de las ofertas que tienen actualmente a la fecha y se toma como
referencia equivalencias próximas para ambas tablas.

PROVEEDOR PROCESADOR RAM (Gb) HD (Gb) COSTO ($us al Mes)

Softlayer de IBM [21] 4 núcleos 2 500 158
Atlantic.net [22] 4 vCPU 2 160 SSD 79,97
Amazon EC2 [23] 4 vCPU 15 80 SSD 191,52
Elastichost [24] 1600 Mhz 8 40 SSD 171,74
Microsoft azure [25] 4 núcleos 7 120 140
CenturyLink [26] 4 vCPU 4 40 78,05
Rackspace [27] 6 Cores 24 730 674
vmware cloud [28] 6 vCPU 4 40 SSD 142,96
google cloud [29] 2 vCPU 7,5 375 SSD 133,23
Joyent [30] 2 vCPU 4 100 75,6
Tabla 4.1: Costos de infraestructura sin escalamiento

PROVEEDOR PROCESADOR RAM (Gb) HD (Gb) COSTO ($us al Mes)

Softlayer de IBM [21] 16 núcleos 16 500 351
Atlantic.net [22] 8 vCPU 32 350 SSD 319,88
Amazon EC2 [23] 16 vCPU 30 320 SSD 604,8
Elastichost [24] 6650 Mhz 8 501 283,28
Microsoft azure [25] 8 núcleos 14 605 357
CenturyLink [26] 8 vCPU 14 500 284,4
Rackspace [27] 8 Cores 24 730 674
vmware cloud [28] 8 vCPU 12 350 SSD 306,93
google cloud [29] 4 vCPU 15 750 SSD 266,45
Joyent [30] 16 vCPU 32 800 604,8
Tabla 4.2: Costos de infraestructura con escalamiento

75
4.2. REALIZANDO LA PRUEBA DE HIPOTESIS

Recordando la hipótesis planteada:

“La arquitectura basada en proveedores de servicio en la nube

representa una buena opción de inversión y permite escalar los
servicios”

Planteamos la hipótesis alterna y la nula.

 Hipótesis alterna (Ha): una arquitectura basada en proveedores de servicio Es una

buena opción de inversión y permite el escalamiento de los servicios.
 Hipótesis nula (Ho): una arquitectura basada en proveedores de servicio no es una
buena opción de inversión y no permite el escalamiento de servicios.

Costos Con Costos Sin

escalamiento escalamiento 𝑿𝟏 − ̅̅̅̅
𝑿𝟏 𝑿𝟐 − ̅̅̅̅
𝑿𝟐 (𝑿𝟏 − ̅̅̅̅
𝑿𝟏 )𝟐 ̅̅̅̅𝟐 )𝟐
(𝑿𝟐 − 𝑿
351 158 -54,254 -26,507 2943,49652 702,621049
319,88 79,97 -85,374 -104,537 7288,71988 10927,9844
604,8 191,52 199,546 7,013 39818,6061 49,182169
283,28 171,74 -121,974 -12,767 14877,6567 162,996289
357 140 -48,254 -44,507 2328,44852 1980,87305
284,4 78,05 -120,854 -106,457 14605,6893 11333,0928
674 674 268,746 489,493 72224,4125 239603,397
306,93 142,96 -98,324 -41,547 9667,60898 1726,15321
266,45 133,23 -138,804 -51,277 19266,5504 2629,33073
604,8 75,6 199,546 -108,907 39818,6061 11860,7346
̅̅̅̅
𝑿𝟏 ̅̅̅̅
𝑿𝟐 ∑(𝑿𝟏 − ̅̅̅̅
𝑿𝟏 ) 𝟐 ∑(𝑿𝟐 − ̅̅̅̅
𝑿𝟐 )𝟐

405,254 184,507 222839,795 280976,365

Tabla 4.3: Cálculos de media y varianza

76
Obteniendo el resultado de la ecuación de T Student.

̅̅̅1 − 𝑋
𝑋 ̅̅̅2 405.254 − 184.507
𝑡= 𝑡= t= 2,95
𝜎2 𝜎2 √24759.97 + 31219.5962
√ 1+ 2
𝑛1 𝑛2 10 10

Obteniendo los grados de libertad

2
𝜎2 𝜎2 24759.97 31219.5962 2
( 𝑛 1 + 𝑛 2) ( 10 + 10 )
𝐺𝑙 = 1 2
−2 𝐺𝑙 = 2 −2
𝜎2
2
𝜎2
2 24759.97 31219.5962 2
(𝑛 −1 1) (𝑛 −1 1) ( 10 − 1 ) ( 10 − 1 )
1 +
𝑛1 + 2𝑛 10 10
2

Gl = 13.99 = 14

Así el valor obtenido de t=2.95 con 14 grados de libertad, teniendo también el valor
crítico que es 2.131 con una probabilidad de 0.05.

Gráfica:

Figura 4.1: Gráfica de la prueba de Hipótesis

Fuente: Elaboración propia

77
Decisión:

Como la probabilidad obtenida no se ubica en la zona de rechazo, se rechaza Ho

y se acepta Ha.

Interpretación:

La arquitectura basada en proveedores de servicio en la nube representa una buena

opción de inversión y permite escalar los servicios

4.3. INDICADORES OBSERVADOS

 Interoperabilidad: Se cuenta con la posibilidad de tener aplicaciones integradas.

 Mantenibilidad: Se cuenta con la posibilidad de realizar mantenimiento tanto a
nivel infraestructura como a nivel de software, gracias el proceso de
virtualización con que cuentan la mayoría de los proveedores de servicio
observados.
 Usabilidad: Acorde al requerimiento del cliente, está garantizado el uso de
infraestructura, plataforma o software.
 Escalabilidad: Hacer un upgrade o un downgrade está sujeto al nivel de inversión
y/o la cantidad de datos tratados.
 Fiabilidad: Se cuenta con soporte en línea para garantizar el correcto
funcionamiento de la infraestructura o las aplicaciones contratadas.

78
CAPITULO 5
CONCLUSIONES Y RECOMENDACIONES

RESUMEN

Este capítulo presenta las conclusiones en función a los

objetivos planteados y la prueba de hipótesis garantizada en
el capítulo anterior.

79
Ya para concluir en el desarrollo de la tesis presentada se contempla las siguientes
conclusiones y recomendaciones.

Conclusiones:

 Está claro que se puede fusionar diferentes arquitecturas a fin de proyectar otra
como nueva solución.
 La complejidad de la información no está en la cantidad de datos, mas al contrario
se encuentra en la ordenación de los procesos.
 Los proveedores de servicio adecuan su infraestructura en base a los
requerimientos existentes.
 Una idea es la generación de muchas nuevas ideas así como una solución es la
alternativa para otras soluciones.

Recomendaciones:

 Una de las recomendaciones que considero muy importante es poder contar con
un servidor Cloud Universitario para desarrollo o investigación de nuevas
herramientas o aplicaciones.
 Los precios obtenidos de las empresas de servicio pueden sufrir cambios o dejar
de estar vigentes, se recomienda ingresar a los links referidos en bibliografía.

80
REFERENCIA BIBLIOGRAFICA

81
BIBLIOGRAFIA

[1] Pressman, R. S. (2010). Ingeniería del software-Un enfoque práctico.

México: McGRAW-HILL

[2] Suh, W. (2005). Web Engineering Principies and techniques. United States:
Jhn Wiley

[3] Kale, V. (2015). Guide to Cloud Computing For business and technology
managers. Recuperado de http://dl.acm.org/citation.cfm?id=2723821#

[4] Li, Q., Wang, Z., Li, W., Li, J., Wang, C., Du, R. (2013). Applications
integration in a hybrid cloud computing environment: modelling and
platform. Enterprise Information Systems. 7(3), 273-271

[5] Raj, P. (2013). Cloud Enterprise Architecture. Recuperado de

http://dl.acm.org/citation.cfm?id=2464847

[6] DUGGAN, D. (2012). Enterprise software architecture and design. United

States: Jhon Wiley

[7] Schmuller, J. (2001). Aprendiendo UML en 24 horas. México: Prentice Hall

[8] Alarcon, R. (2000). Diseño orientado a objetos con UML. Madrid: Grupo
Eidos

[9] Rumbaugh, J., Jacoboson, I., Booch, G. (1999). El lenguaje unificado de

modelado-Manual de referencia. España: Addison Wesley

[10] Kimmel, P. (2006). Manual de UML. México: McGraw-Hill

[11] Gomez, W. (2011, 24 de febrero). Diseño arquitectónico. Recuperado de

http://es.slideshare.net/wilsongomez/diseo-arquitectonico-7049434

[12] Kruchten, P. (2015, 13 de Julio). Planos Arquitectónicos: El Modelo de

“4+1” Vistas de la Arquitectura del Software. Recuperado de
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_
1.pdf

[13] Definición ABC (2007-2015).Diccionario [versión electrónica] . Definición

de Proveedor. Recuperado de
http://www.definicionabc.com/tecnologia/proveedor.php

82
[14] Itil Foundation (2015).Proveedores de servicios. Recuperado de:
http://itilv3.osiatis.es/estrategia_servicios_TI/introduccion_objetivos_p
roveedores_servicios.php

[15] Fing.Edu (2015). Taller de Sistemas de Información Geográficos

Empresariales (Clase 2). Recuperado de
http://www.fing.edu.uy/inco/cursos/tsi/TSIG/clases2012/Clase2_2012.
pdf

[16] Guardado, B., Garcia, N., Melara, G., Rubio, N., Umanzor, F. (2012).
Software Libre y Comercial de Aplicación para el área de
Administración de Empresas. Universidad De El Salvador. El Salvador.
Recuperado de https://es.scribd.com/doc/84636708/2/%C2%BFQue-
es-un-Software-o-Aplicacion-Empresarial

[17] Chang, R. (2005, septiembre). Application integration (enterprise

application integration or EAI) definition. Recuperado de
http://searchsoa.techtarget.com/definition/application-integration

[18] ESA (2009, noviembre). Aplicaciones Integradas: Una Oportunidad para

el Desarrollo Regional [Presentación]: Barcelona. Recuperado de
http://www.pcot.cat/web/pcotcontent/docs/jornades/20091113_dimens
io/aplicaciones_integradas_ESA.pdf

[19] IS/IEC 62264-2 (2004). Enterprise-Control System Integration, Part 1:

Models and Terminology. Recuperado de
https://law.resource.org/pub/in/bis/S05/is.iec.62264.2.2004.pdf

[20] Martin, I., Rodrige, J. (2013, noviembre 25). Arquitectura Orientada a

Servicios (SOA). Recuperado de
https://emergingtechuva.wordpress.com/2013/11/25/arquitectura-
orientada-a-servicios-soa/

[21] Softlayer de IBM (2015). Portal de Servicios. http://www.softlayer.com/es

[22] Atlantic.net (2015). Portal de Servicios Cloud. https://www.atlantic.net

[23] Amazon EC2 (2015). Portal de Servicios Cloud.

https://aws.amazon.com/es/ec2

[24] Elastichost (2015). Portal de Servicios Cloud. https://www.elastichosts.com

[25] Microsoft azure (2015). Portal de Servicios Cloud.

https://azure.microsoft.com/es-es

[26] CenturyLink (2015). Portal de Servicios Cloud. https://www.ctl.io

83
[27] Rackspace (2015). Portal de Servicios Cloud. http://www.rackspace.com/

[28] vmware cloud (2015). Portal de Servicios Cloud. http://vcloud.vmware.com/

[29] Google cloud (2015). Portal de Servicios Cloud. https://cloud.google.com

[30] Joyent (2015). Portal de Servicios Cloud. https://www.joyent.com

[31] Heroku (2015). Portal de Servicios Cloud. https://www.heroku.com/

[32] Oracle Cloud (2015). Portal de Servicios Cloud. .https://cloud.oracle.com

[33] Google Apps (2015). Portal de Servicios Cloud.

https://apps.google.com/intx/es-419/products/

[34] Dropbox (2015). Portal de Servicios Cloud. https://www.dropbox.com

[35] Apple iCloud (2015). Portal de Servicios Cloud.

http://www.apple.com/es/icloud/

[36] Salesforce (2015). Portal de Servicios Cloud. www.salesforce.com/es

84
ANEXOS

ANEXO A : UML

DIAGRAMA DE CLASES

Un diagrama de clases es un diagrama que muestra un conjunto de clases, interfaces,

colaboraciones y sus relaciones. Al igual que otros diagramas los diagramas de clases pueden
contener notas y restricciones. También pueden contener paquetes o subsistemas, los cuales
su usan para agrupar los elementos de un modelo en partes más grandes. A veces se colocarán
instancias en los diagramas de clases, especialmente cuando se quiera mostrar el tipo
(posiblemente dinámico) de una instancia, en la figura 3 se muestra las partes de una clase.

Figura 3 Partes de una clase

Fuente: [http://www.monografias.com/trabajos28/proyecto-uml/pro2.jpg]

Algunos aspectos que se deben considerar se detallan a continuación:

- Abstracción: Se refiere a quitar las propiedades y acciones de un objeto para dejar

solo aquellas que sean necesarias. Ejemplo: Tomar la decisión de que incluirá o
desechara de una lavadora, lo cual constituye una abstracción.

85
- Herencia: Un objeto es una instancia de una clase. Esta idea tiene una consecuencia
importante como instancia de una clase, un objeto tiene todas las características de la
clase de que que proviene. A eso se le conoce como herencia. No importa que
atributos y acciones decida usar de la clase Lavadora, cada objeto de la clase heredara
dichos atributos y operaciones. Ejemplo: la lavadora, el refrigerador, el horno
microondas y cosas por el estilo son subclases de la clase electrodomésticos.

- Polimorfismo: En ocasiones una operación tiene el mismo nombre en diferentes

clases. Por ejemplo, podrá abrir una puerta, una ventana, un periódico, un regalo o
una cuenta de banco, en cada uno de estos casos, realizara una operación diferente.
En la orientación a objetos, cada clase “sabe” como realizar tal operación. Esto es el
polimorfismo.

- Encapsulamiento: La esencia del encapsulamiento es que cuando un objeto trae

consigo su funcionalidad, esta última se oculta. Por ejemplo para la mayoría de la
gente que ve la televisión no sabe o no se preocupa d la complejidad electrónica que
hay detrás de la pantalla ni de todas las operaciones que tienen que ocurrir para
mostrar una imagen en la pantalla.

- Envío de mensajes: En un sistema los objetos trabajan en conjunto, esto se logra

mediante el envío de mensajes entre ellos. Un objeto envía a otro un mensaje para
realizar una operación y el objeto receptor ejecutara la operación.

- Asociaciones: Otro acontecimiento común es que los objetos se relacionan entre si

de alguna forma. Asimismo un objeto puede asociarse con otro en más de una forma,
por ejemplo si usted y su colaborador son amigos, usted tendría una asociación “es
amigo de”, así como “es colaborador de”.

- Agregación: Su computadora es una agregación o adición, otro tipo de asociaciones

entre objetos. Como muchas otras cosas que valdrían la pena tener, su equipo está
constituido de diversos tipos de componentes.

86
DIAGRAMA DE COMPONENTES

Un componente de software es una parte física de un sistema y se encuentra en la

computadora, no en la mente del analista. Una tabla, archivo de datos, biblioteca de vínculos
dinámicos, documentos y cosas por el estilo se consideran componentes.

Hay que mencionar que contiene componentes, interfaces y relaciones, en la figura 4 se

aprecia su representación gráfica.

Figura 4 Representación gráfica de componentes

Fuente: [7]

DIAGRAMA DE DESPLIEGUE

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema.

Esto muestra la configuración de los elementos de hardware (nodos) y muestra cómo los
elementos y artefactos del software se trazan en esos nodos.

Nodo: Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de

una caja en tres dimensiones, como a continuación.

Figura 5 Representación gráfica de nodo

Fuente: [7]

87
Instancia de Nodo: Una instancia de nodo se puede mostrar en un diagrama. Una instancia
se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos
puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los
dos puntos. El siguiente diagrama muestra una instancia nombrada de una computadora.

Estereotipo de Nodo: Un número de estereotipos estándar se proveen para los nodos,

nombrados «cdrom», «cd-rom», «computer», «disk array», «pc», «pc client», «pc server»,
«secure», «server», «storage», «unix server», «user pc». Estos mostrarán un icono apropiado
en la esquina derecha arriba del símbolo nodo.

Artefacto: Un artefacto es un producto del proceso de desarrollo de software, que puede

incluir los modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseño, etc.),
archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales
de usuario y más.

Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo

«artifact» y un icono de documento, como a continuación.

Asociación: En el contexto del diagrama de despliegue, una asociación representa una ruta
de comunicación entre los nodos. El siguiente diagrama muestra un diagrama de despliegue
para una red, mostrando los protocolos de red como estereotipos y también mostrando
multiplicidades en los extremos de la asociación.

Nodo como contenedor: Un nodo puede contener otros elementos, como componentes o
artefactos. El siguiente diagrama muestra un diagrama de despliegue para una parte del
sistema embebido y muestra un artefacto ejecutable como contenido por el nodo madre
(motherboard).

DIAGRAMAS DE ACTIVIDAD

Un diagrama de actividades ha sido diseñado para mostrar una visión simplificada de lo que
ocurre durante una operación o proceso. Es una extensión de un diagrama de estados. El
diagrama de estados muestra los estados de un objeto y representa las actividades como

88
flechas que conectan a los estados. El diagrama de actividades resalta, precisamente a las
actividades.

A cada actividad se le representa por un rectángulo con las esquinas redondeadas. El

procesamiento dentro de una actividad se lleva a cabo y, al realizarse se continua con la
siguiente actividad de una actividad se lleva cabo y, al realizarse, se continua con la siguiente
actividad, una flecha representa la transición de una a otra actividad. Al igual que el diagrama
de estado, el de actividad cuenta con un punto inicial (representado por un circulo relleno) y
uno final (representado por una diana), para mejor vista ver la figura 6.

Figura 6 Representación gráfica de asociaciones

Fuente: [7]

89
ANEXO B : SLA

ACUERDO DE NIVELES DE SERVICIO

Es un acuerdo negociado entre dos partes donde una de ellas es el cliente y la otra un
proveedor de servicios. Estos acuerdos pueden estar vinculados legalmente, o ser un contrato
informal (relaciones interdepartamentales). Constituye una herramienta que ayuda a ambas
partes a llegar a un consenso en términos del nivel de calidad del servicio, en aspectos tales
como tiempo de respuesta, disponibilidad horaria, documentación disponible, personal
asignado al servicio, etc.
También constituye un punto de referencia para el proceso de mejora continua, ya que el
poder medir adecuadamente los niveles de servicio es el primer paso para mejorarlos y de
esa forma aumentar los índices de calidad, KPI (del inglés Key Performance Indicator,
conocido como Indicador clave de desempeño o Indicador clave de rendimiento).
Los ANS definen un punto de entendimiento común sobre servicios, prioridades,
responsabilidades y garantías. Cada área de servicio debe tener un ANS definido, que
comprenda los niveles de disponibilidad, servicio, rendimiento u otros atributos del servicio,
como la facturación.
Los ANS se han utilizado desde finales de los años 80 por parte de operadores de
telecomunicaciones como parte de sus contratos con clientes empresariales. Esta práctica se
ha extendido hasta tal punto que actualmente es habitual que un usuario firme un contrato
con un proveedor de servicios que incluya una serie de ANS para prácticamente todos los
mercados.
Los departamentos de grandes corporaciones han adoptado también el sistema de acuerdos
de nivel de servicio respecto a los clientes internos, departamentos de la misma organización
ya que mediante este sistema se logra mejorar la calidad del servicio, así como se muestra
en la figura 7.

90
 Figura 7: Contexto de un SLA
Fuente: [http://es.wikipedia.org/wiki/Acuerdo_de_nivel_de_servicio]

Los ANS están, por su naturaleza, basados en los resultados del servicio recibido por el
usuario como elemento del acuerdo. Las organizaciones también pueden definir y
especificar el sistema por el que el servicio debe ser cumplido mediante una especificación
(especificación del nivel de servicio). Este tipo de acuerdo recibe el nombre de input SLA,
aunque este tipo de acuerdo ha quedado obsoleto ya que las organizaciones permiten a los
proveedores seleccionar el método de cumplimiento de los acuerdos.

91
ANEXO C : COTIZACION DE SERVIDORES

92
93
DOCUMENTOS

94
 La Paz, Diciembre de 2015

Señor
M. Sc. Edgar Palmiro Clavijo Cárdenas
DIRECTOR CARRERA DE INFORMATICA
FACULTAD DE CIENCIAS PURAS Y NATURALES
UNIVERSIDAD MAYOR DE SAN ANDRES
Presente

Ref: AVAL PARA LA DEFENSA DE TESIS DE GRADO

De mi mayor consideración:

Mediante la presente, me dirijo a su Autoridad, en calidad de Tutor Metodológico para

Informar que luego de haber realizado el seguimiento de la Tesis de Grado titulado:
“IMPLEMENTACIÓN DE ARQUITECTURA BASADA EN PROVEEDORES DE SERVICIOS PARA
APLICACIONES EMPRESARIALES INTEGRADAS EN LA NUBE” presentado por el Univ.
MAXIMILIANO REYES ULU CALLO con C.I. 4337403 L.P., para optar al título de Licenciatura en
Informática, Mención Ingeniería de Sistemas Informáticos.

En este sentido, presento mi conformidad y aval respectivo para la defensa pública de la

Tesis de Grado de acuerdo a Reglamento vigente en la Universidad Mayor de San Andrés.

Sin otro particular, me suscribo con las atenciones más distinguidas.

Lic. Javier Hugo Reyes Pacheco

TUTOR METODOLOGICO

c.c./ Arch
 La Paz, Diciembre de 2015

Señor
Lic. Javier Hugo Reyes Pacheco
TUTOR METODOLOGICO
Presente

Ref: CONFORMIDAD Y AVAL DE TESIS DE GRADO

De mi mayor consideración:

Tengo a bien dirigirme a su persona, para darle a conocer que luego de efectuar el
seguimiento a la estructura y contenido de la Tesis de Grado titulado: “IMPLEMENTACIÓN DE
ARQUITECTURA BASADA EN PROVEEDORES DE SERVICIOS PARA APLICACIONES EMPRESARIALES
INTEGRADAS EN LA NUBE”, elaborado por el Universitario: MAXIMILIANO REYES ULU CALLO, con
C.I. 4337403 L.P., en calidad de Asesor expreso mi conformidad con el contenido y la forma de
trabajo, dando mi Aval, para que el postulante pueda realizar la defensa de la Tesis de Grado,
para optar al título de Licenciado en Informática mención Ingeniería de Sistemas Informáticos, de
acuerdo a normas y reglamento vigentes.

Sin otro particular, me suscribo de su persona con las consideraciones más distinguidas.

Lic. Brígida Carvajal Blanco

ASESOR

c.c. Arch.