Arquitectura de software para el módulo de inventario del ERP cubano

Propuesta de Arquitectura Orientada a Servicios para el
Propuesta de Arquitectura Orientada a Servicios para el
Módulo de Inventario del ERP Cubano
Módulo de Inventario del ERP Cubano
RESUMEN
RESUMEN
En el presente trabajo se expone una propuesta de Arquitectura Orientada a Servicios para el Módulo de
Inventario del ERP Cubano, de modo que le posibilite al mismo ser: portable, seguro, escalable e
integrable con otros sistemas y que a la vez sea extensible a otros módulos del ERP. Para lograr el
objetivo propuesto de definir y describir la arquitectura de software se partió de un estudio de los
elementos que constituyen la misma y las tendencias actuales según los autores más prestigiosos del
tema, así como la experiencia del desarrollo del Sistema de Gestión de Inventarios y Almacenes (SIGIA).
El éxito de la definición y descripción de la arquitectura estará en dependencia principalmente de las
decisiones arquitectónicas que se tomen durante su desarrollo, la tecnología más adecuada que se decida
y aspectos del diseño que permitan un desarrollo favorable del propio sistema, donde se tengan en cuenta
las relaciones y configuraciones entre los componentes y que permita organizar la estructura del sistema
que se desarrolla brindando a todo el equipo de trabajo una idea clara de lo que se esta desarrollando.
PALABRAS CLAVES
PALABRAS CLAVES
Arquitectura de Software, estilo, patrón, componente, framework, Service Oriented Architecture (SOA),
servicio web, integración, Enterprise Resource Planning (ERP), XML, SOAP, UDDI, WSDL.
AUTORES
AUTORES
Yoan Arlet Carrascoso Puebla y Enrique Chaviano Gómez
III
1
1
INTRODUCCIÓN
TABLA DE CONTENIDO
TABLA DE CONTENIDO
RESUMEN
RESUMEN................................................................................................................................................................
................................................................................................................................................................ 1
1
INTRODUCCIÓN
INTRODUCCIÓN......................................................................................................................................................
...................................................................................................................................................... 3
3
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA.........................................................................................................
......................................................................................................... 7
7



 !
"#$ %
&'() *
+,-.


&/0 1
!"#$
&$"2()"#$"1
&"#$"34"'5$"
#
%#&'(#
 )(*$
+67' 8
 %+,
 !-,
+5"9"%
 '.(/
+&)$:;"""&
  0-#'
 $,1.('
 2))+,$
1<, &8
8 &
' +*
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN..........................................................................................................
.......................................................................................................... 42
42
 +
' +
3#
'5("+
$)+
%##
,(*"'%#$
 -%-$4
$5062
257#82
5829
453--#
95
/:*(*$
04
CAPÍTULO 3. AMBIENTE DE DESARROLLO Y CALIDAD EN LA ARQUITECTURA
CAPÍTULO 3. AMBIENTE DE DESARROLLO Y CALIDAD EN LA ARQUITECTURA............................................
............................................79
79
1
1
INTRODUCCIÓN
& %
&,0%
;-;+9
&"35#9%
&)#9"=*
&&>"#()""=
&1>"#()'?=&
&8>"#()3)$=+
&:3)"=1
;-5"42
&@3)",$=8
&,4)/$A9=
&&))""$$):"BC==
&+):.':3()=%
&13!D"%*
9"5$)"**
"3>"0""*&
 *+
&/A</A''*=
+/'' 
1/' 
$-8#
8' +
CONCLUSIONES
CONCLUSIONES.................................................................................................................................................
................................................................................................................................................. 115
115
RECOMENDACIONES
RECOMENDACIONES.........................................................................................................................................
......................................................................................................................................... 116
116
REFERENCIAS BIBLIOGRÁFICAS
REFERENCIAS BIBLIOGRÁFICAS.....................................................................................................................
..................................................................................................................... 118
118
REFERENCIAS BIBLIOGRÁFICAS
REFERENCIAS BIBLIOGRÁFICAS.....................................................................................................................
..................................................................................................................... 118
118
BIBLIOGRAFÍA
BIBLIOGRAFÍA.....................................................................................................................................................
..................................................................................................................................................... 122
122
BIBLIOGRAFÍA
BIBLIOGRAFÍA.....................................................................................................................................................
..................................................................................................................................................... 122
122
GLOSARIO
GLOSARIO................................................................................................................................................................
................................................................................................................................................................ I
I
BIBLIOGRAFÍA
BIBLIOGRAFÍA.........................................................................................................................................................
......................................................................................................................................................... II
II
E
DATOS DE CONTACTO
DATOS DE CONTACTO.........................................................................................................................................
......................................................................................................................................... 10
10
1
1
INTRODUCCIÓN
INTRODUCCIÓN
INTRODUCCIÓN
Con la desaparición del socialismo en la Unión de Repúblicas Socialistas Soviéticas y el
recrudecimiento del bloqueo de Estados Unidos hacia Cuba en la década de 1990, la economía
cubana quedó paralizada. Debido a esto el país se vio en la necesidad de realizar un proceso de
rediseño de la política económica. Desde entonces se comenzó a llevar a cabo un programa gradual
de medidas económicas que tenían como objetivo superar la situación de la nación al menor costo
social posible.
A raíz de las dificultades económicas a las que se estaba enfrentando el país, el estado cubano
comenzó a invertir en varios sectores estratégicos de la economía y empezó a destinar gran cantidad
de recursos a elevar el nivel de informatización de la sociedad, donde el ejemplo más fehaciente y
actual lo constituye la creación de la Universidad de las Ciencias Informáticas para producir software
de gran calidad e insertarlo en el mercado mundial. Como resultado de dicha estrategia, se han estado
obteniendo sistemas empresariales más eficientes y de mayor calidad, a la altura de las exigencias
tecnológica del momento.
A partir del perfeccionamiento empresarial, las empresas trabajan para lograr una mayor eficiencia en
su producción o en los servicios que brindan. De ahí la utilización de sistemas informáticos que
permitan la automatización de los procesos empresariales y de este modo, hacerlos mucho más
eficientes. Uno de los sistemas que posibilita esto, son los Enterprise Recources Planning (ERP), que
son sistemas de gestión de información que integran y automatizan en una única aplicación todos los
procesos de negocio de una empresa, entiéndase por esto: producción, ventas, compras, logística,
contabilidad, gestión de proyectos, inventarios, control de almacenes, pedidos, nóminas, recursos
humanos, entre otras.
Los ERP brindan soporte a los usuarios del negocio, un manejo eficiente de la información para la
toma de decisiones, tiempos rápidos de respuesta y una disminución de los costos totales de las
operaciones. (Martínez, et al., 2001).
Uno de los procesos más importantes en la planificación de recursos de una empresa son los sistemas
de inventario y por ello constituye una base sólida en el desarrollo de sistemas ERP.
En la economía de hoy día, el manejo de inventarios ha llegado a la cumbre de los problemas de la
administración de empresas debido a que es un componente fundamental de la productividad. Si se
mantienen inventarios demasiado altos, el costo podría llevar a una empresa a tener problemas de
liquidez financiera. Por otro lado, si se mantiene un nivel insuficiente de inventario, podría no atenderse
1
1
INTRODUCCIÓN
a los clientes de forma satisfactoria, lo cual traería como consecuencia reducción de ganancias y
pérdida de mercado (Sanchez, 2006). Por lo que se puede apreciar que llevar inventarios sanos
garantizará a cualquier empresa e industria una mayor confiabilidad a la hora de mover los productos
dentro del almacén.
En Cuba existen Sistemas de Gestión de Inventarios, entre ellos se tienen: El Sistema de Inventario
del Patrimonio Cultural y Natural (SIP), como su nombre lo indica fue creado con fines patrimoniales
como: el registro, el control y la conservación de los mismos. El Sistema Informatizado para el
Procesamiento del Inventario Forestal (INVENFOR 1.0), realizado con el fin de registrar y procesar los
datos obtenidos del inventario forestal en función de estimar los parámetros dasométricos de los
Rodales de forma tal que tribute a una planificación del manejo forestal más eficiente. Otros ejemplos
de sistemas son: DRIM, FONDUS, SI e IHMM 2000 de la empresa GET (Grupo de Electrónica para el
Turismo), este último con el objetivo de usarse en las instalaciones hoteleras.
Todos tienen algo en común, y es que la mayoría de estos sistemas están especializados para el
funcionamiento de determinadas empresas, de aquí que no sean flexibles, sino más bien, cerrados en
su diseño, difíciles de estandarizar el proceso de gestión de inventarios y la integración con otros
sistemas, elementos primordiales que se proponen resolver.
Razón ésta, por la que se hace preciso el desarrollo de un nuevo sistema de gestión de inventarios
que cumpla con las necesidades actuales de las empresas y del país como tal, dotado de la tecnología
más reciente, de modo que sea más flexible, moderno, amigable, confiable y seguro, y además que
sea capaz de integrarse con otros sistemas. Precisando de este que sea configurable a partir de las
necesidades particulares de los clientes, que cumpla con las nuevas regulaciones que establece el
Ministerio de Finanzas y Precios. En fin, que cumpla con todos los nuevos requerimientos que los
antiguos sistemas no brindan por haber quedados obsoletos.
Para el desarrollo satisfactorio de cualquier sistema de software y que a la vez el mismo garantice una
determinada calidad y bajos costes, se hace necesario la utilización de metodologías de desarrollo, las
que guían este proceso. Un elemento significativo en el proceso de desarrollo es la concepción de un
diseño de alto nivel, que permita organizar y comprender la estructura del sistema que se desarrolla y
brinde a todo el equipo una idea clara de lo que se está desarrollando.
Es un hecho que durante el proceso de desarrollo de software surgen situaciones que limitan y
dificultan el proceso en sí. Entre ellos se pueden ver: la escasa reutilización, la mala selección de
elementos de software, estilos arquitectónicos, patrones de arquitectura, protocolos de comunicación,
1
1
INTRODUCCIÓN
composición de elementos de diseño, asignación de funcionalidad a elementos del diseño,
herramientas, frameworks, problemas de sincronización y acceso a datos, programadores escribiendo
código de cualquier manera siempre y cuando cumpla con lo que quieren que haga el programa,
influyendo todo esto en cuestiones de escalabilidad, rendimiento y costo. Donde la solución a todos
estos problemas está en la correcta definición y descripción de una Arquitectura de Software.
La Arquitectura de Software surge de la necesidad de hacer los sistemas más modulares, que permitan
la reutilización de componentes, por lo que su implementación reduce considerablemente el coste.
Permite además mantener un bajo acoplamiento entre los elementos del sistema, pero con muy alta
cohesión, ya que se establece bien claro la estructura de los componentes, sus formas de comunicarse
y las relaciones que existen entre ellos.
Todo lo expuesto conllevó a la definición del siguiente problema:
¿Cómo tomar decisiones de diseño de alto nivel en el proceso de desarrollo del Sistema de Gestión de
Inventarios que le permita a este, ser escalable, seguro, portable e integrable con otros sistemas de
gestión empresarial?
La investigación se centra en el objeto de estudio: Proceso de Desarrollo del Sistema de Gestión de
Inventario. Para ello se plantea el siguiente objetivo general: Proponer una Arquitectura de Software
Orientada a Servicios que le permita al Sistema de Gestión de Inventario ser escalable, seguro,
portable e integrable con otros sistemas de gestión empresarial.
Definiendo como campo de acción: Arquitectura de Software para el Sistema de Gestión de
Inventario.
La investigación se realizó mediante las siguientes tareas para dar cumplimiento al objetivo propuesto:
Realización de un estudio del estado del arte de la Arquitectura del Software para conocer los
distintos enfoques de arquitectura, cómo evolucionaron, principales tendencias y definiciones,
así como estilos arquitectónicos más significativos que están teniendo auge en el desarrollo de
sistemas empresariales.
Identificación de patrones y estilos arquitectónicos a utilizar, fundamentar la utilización de estos,
así como su aplicación.
Definición de los marcos de trabajo (frameworks) y las herramientas de desarrollo a utilizar.
Definición y descripción de la Arquitectura.
Validación por criterio de especialistas.
1
1
INTRODUCCIÓN
Para realizar las tareas se emplearon los siguientes métodos:
Métodos Tricos
Histórico Lógico: Para determinar las tendencias actuales de desarrollo de los modelos y
enfoques arquitectónicos.
Analítico Sintético: Para llegar a conclusiones en la investigación a partir de la información
que se procese y precisar características del modelo arquitectónico propuesto.
Método Sistémico: Para definir los elementos del sistema y sus relaciones.
Métodos Empíricos
Medición: para la evaluación de los tiempos de respuesta en situaciones críticas del caso de
estudio.
Posibles resultados
Propuesta de Arquitectura de Software Orientada a Servicios para el Sistema de Gestión de
Inventarios que le permita a este, ser escalable, seguro, portable e integrable con otros sistemas de
gestión empresarial.
El presente trabajo está estructurado en tres capítulos
Capítulo 1: Fundamentación Teórica.
En este capítulo se realiza la fundamentación teórica de la investigación basándose en un estudio del
estado del arte de la Arquitectura de Software, así como de los distintos enfoques de arquitectura,
principales tendencias y definiciones. Se realiza un estudio de los estilos arquitectónicos más
significativos que están teniendo auge, exponiendo sus ventajas y desventajas. En fin todos aquellos
aspectos que permitirán modelar el marco teórico que fundamenta la investigación.
Capítulo 2:
En este capítulo se realiza la propuesta de solución al problema planteado en el diseño teórico de la
investigación, la misma viene dada por el artefacto Documento Descripción de Arquitectura que
propone la Universidad de las Ciencias Informáticas a emplear en los proyectos productivos.
Capítulo 3:
En este capítulo se realiza la especificación de las herramientas que brindarán soporte a la propuesta
arquitectónica realizada en el capítulo anterior para el Sistema de Gestión de Inventario. Además se
efectúa un análisis de la propuesta de solución desde el punto de vista de la calidad.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
1.1. Introducción
En este capítulo se realiza la fundamentación teórico de la investigación, un estudio del arte de la
Arquitectura de Software, así como de los distintos enfoques de arquitectura, principales tendencias y
definiciones. Un estudio de los estilos arquitectónicos más significativos que están teniendo auge en el
desarrollo de sistemas empresariales y de gestión, exponiendo sus ventajas y desventajas para
seleccionar el adecuado para el desarrollo del Sistema de Gestión de Inventarios. Un análisis de los
distintos niveles de abstracción de la Arquitectura de Software, los lenguajes de modelado
arquitectónico, el estilo Arquitectura Orientada a Servicio como desafío del presente y la calidad en la
Arquitectura de software.
1.2. Estado del arte de la Arquitectura de Software
La Arquitectura de Software es una práctica joven de apenas unos pocos años de trabajo constante.
Tiene sus orígenes en la década del 60, pero no fue hasta los años 90 que Dewayne Perry y Alexander
Wolf, la exponen en el sentido que hoy se conoce.
“La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término
“arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de
estándares, de entrenamiento formal (de los arquitectos de software) y de estilo. Es tiempo de re-
examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software y
de su administración, así como señalar las nuevas técnicas que han sido adoptadas.” (Perry, et al.,
1992)
Esta década se consideró como la década de la arquitectura de software, según profetizaron Perry y
Wolf. A partir de este momento la Arquitectura de Software comenzó a tener auge vertiginoso tanto en
la academia como en la industria.
1.2.1. Principales definiciones
1.2.1.1. Arquitectura de Software
La Arquitectura de Software es una disciplina reciente (Szyperski, 2000), pero no por ser una normativa
joven deja de tener la importancia que requiere. A medida que crece la complejidad de las
aplicaciones, y que se extiende el uso de sistemas distribuidos, los aspectos arquitectónicos del
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
desarrollo de software están recibiendo un interés cada vez mayor, tanto desde la comunidad científica
como desde la propia industria del software (Velasco, 2000).
En la actualidad existen un sin número de definiciones de Arquitectura de Software, pero ninguna que
sea adoptada completamente por la totalidad de los arquitectos del mundo. Aunque es válido aclarar
que ninguna definición reprocha a la otra, sino que es otro modo de ver la cosas.
Entre las definiciones más reconocidas de la academia se encuentra la de Paul Clements: “La
Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes
principales del mismo, la conducta de esos componentes según se la percibe desde el resto del
sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del
sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la
supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones” (Reynoso, 2006).
De manera similar Bass define de la siguiente forma: “La Arquitectura de Software de un sistema de
programa o computación es la estructura de las estructuras del sistema, la cual comprende los
componentes del software, las propiedades de esos componentes visibles externamente, y las
relaciones entre ellos.” (Pressman, 2002).
Por otra parte la definición que más reconocida internacionalmente por muchos arquitectos tributa a la
industria y pertenece a la IEEE 1471, la cual cita así: "La Arquitectura de Software es la organización
fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y
los principios que orientan su diseño y evolución." (Reynoso, 2006).
A pesar de la abundante cantidad de definiciones que existen de Arquitectura de Software, la gran
mayoría coincide en que esta se refiere a la estructura a grandes rasgos del sistema (alto nivel de
abstracción), estructura consistente en componentes y relaciones entre ellos. Por lo que se define
Arquitectura de Software como la estructura y organización de los elementos de software de un
Sistema Informático, cómo y bajo qué condiciones y configuraciones se van a comunicar dichos
elementos.
Se puede concluir que la Arquitectura de Software es: una disciplina independiente de cualquier
metodología de desarrollo, representa un alto nivel de abstracción del sistema y responde a los
requerimientos no funcionales ya que estos se satisfacen mediante el modelado y diseño de la
aplicación. De la misma forma se puede llegar a la conclusión de que la Arquitectura de Software no
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
es: diseño de software, una normativa madura, tratada de igual manera en la academia que en la
industria.
1.2.1.2. Estilo
En general cuando se habla de la arquitectura, de una forma o de otra se refiere a algo en específico
muy relacionado: las clasificaciones. El hecho es que no es solo como una cuestión clasificatoria, sino
que cada forma arquitectónica tiene gran relación y se asocia con herramientas, conceptos,
experiencias y problemas.
A estas clasificaciones se les ha llamado de varias formas, como: clases de arquitectura, tipos
arquitectónicos, arquetipos recurrentes, especies, paradigmas topológicos, marcos comunes y varias
docenas más. Desde hace más de una década esas cualificaciones arquitectónicas se vienen
denominando: estilos, o alternativamente patrones de arquitectura. Los estilos sólo se manifiestan en
arquitectura teórica descriptiva de alto nivel de abstracción; los patrones, por todas partes. (Reynoso,
et al., 2004)
Las primeras definiciones explícitas de estilo parecen haber sido propuestas por Dewayne Perry y
Alexander Wolf en octubre de 1992. Los mismos establecen el razonamiento sobre estilos de
arquitectura como uno de los aspectos fundamentales de la disciplina. Un estilo es un concepto
descriptivo que define una forma de articulación u organización arquitectónica. El conjunto de los
estilos cataloga las formas básicas posibles de estructuras de software, mientras que las formas
complejas se articulan mediante composición de los estilos fundamentales” (Perry, et al., 1992).
Según Pressman (Pressman, 2002), un estilo describe una categoría de sistema que abarca un
conjunto de componentes que realizan una función requerida por el sistema, un conjunto de
conectores que posibilitan la comunicación, la coordinación y cooperación entre los componentes, las
restricciones que definen como se integran los componentes para conformar el sistema, y los modelos
semánticos que facilitan al diseñador el entendimiento de todas las partes del sistema. El estilo
arquitectónico es también un patrón de construcción.
Los estilos conjugan componentes, conectores, configuraciones y restricciones (constraints). La
descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es
hacerlo en un Lenguaje de Descripción Arquitectónica (ADL) o en Lenguajes Formales de
Especificación (LFE).
Se puede concluir que:
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Un estilo contempla las cuatro “C” de la AS (elementos, conectores, configuraciones y
restricciones), por sus siglas en inglés.
Sirve para sintetizar estructuras de soluciones que luego serán refinadas a través del diseño.
Pocos estilos abstractos encapsulan una enorme variedad de configuraciones concretas.
Definen los patrones posibles de las aplicaciones, evitando errores arquitectónicos.
Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante
diferentes conjuntos de requerimientos no funcionales.
1.2.1.3. Patrón
“Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el
núcleo de la solución a ese problema, de tal manera que puedes usar esa solución un millón de veces
más, sin hacer jamás la misma cosa dos veces” (Fowler, et al., 2002).
Se podría ver a un patrón como una solución a un problema determinado, una codificación de algo
específico basado en un conocimiento específico acumulado por la experiencia.
Un sistema bien estructurado esta lleno de patrones” (Reynoso, 2005).
Se puede decir que cada vez que se utiliza un patrón se utiliza un poco de aquí y otro poco de allá. Se
verá la misma solución varias veces, pero nunca exactamente igual a ninguna otra.
Si se hace una primera clasificación de los patrones software atendiendo al nivel de abstracción de
éstos, pudieran quedar: los patrones arquitectónicos, de diseño o centrados en el código, entre otros.
Elementos de un Patrón (Reynoso, 2005):
Nombre
oDefine un vocabulario de diseño
oFacilita abstracción
Problema
oDescribe cuando aplicar el patrón
oConjunto de fuerzas: objetivos y restricciones
oPrerrequisitos
Solución
oElementos que constituyen el diseño (template)
oForma canónica para resolver fuerzas
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Consecuencias
oResultados, extensiones y tradeoffs
Patrón Arquitectónico
Según Buschmann los patrones de arquitectura se pueden ver como la descripción de un problema en
particular y recurrente de diseño, que aparece en contextos de diseño arquitectónicos específicos, y
representa un esquema genérico demostrado con éxito para su solución. El esquema de solución se
especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y
desarrollos, así como también la forma en que estos colaboran entre sí. (Buschmann, et al., 1996)
Los patrones arquitectónicos se definen sobre aspectos fundamentales de la estructura del sistema
software, donde se especifican un conjunto de subsistemas con sus responsabilidades y una serie de
recomendaciones para organizar los distintos componentes. Posteriormente, el diseño hará uso de
patrones de diseño para resolver problemas específicos.
Patrón de Diseño
Un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema
de software, o las relaciones entre ellos. Describe la estructura comúnmente recurrente de los
componentes en comunicación, que resuelve un problema general de diseño en un contexto particular
(Buschmann, et al., 1996).
Son menores en la escala de abstracción que los patrones arquitectónicos, además tienden a ser
independientes de los lenguajes y paradigmas de programación. Su aplicación tiene efectos sobre
subsistemas, debido a que especifica a un mayor nivel de detalle, sin llegar a la implementación, el
comportamiento de los componentes del subsistema.
1.2.1.4. Marco de trabajo
El concepto de marco de trabajo (framework) no es sencillo de definir, a pesar de que cualquiera con
experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté
utilizando su propio framework.
El concepto framework se emplea en muchos ámbitos del desarrollo de sistemas software. Se pueden
encontrar frameworks para el desarrollo de aplicaciones web, aplicaciones de escritorio, aplicaciones
médicas, para el desarrollo de juegos, y para cualquier ámbito que se le pueda ocurrir a uno.
En general, el término framework, se refiere a una estructura software compuesta de componentes
personalizables e intercambiables para el desarrollo de una aplicación. En otras palabras, un
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
framework se puede considerar como una aplicación genérica incompleta y configurable a la que se le
puede añadir las últimas piezas para desarrollar una aplicación concreta.
Por lo que resumiendo, un framework es el esqueleto de una aplicación que debe ser adaptado por el
programador según sus necesidades específicas para desarrollar una aplicación.
1.2.2. Tendencias
Aunque no existe hoy en día nada que avale explícitamente la existencia de escuelas de Arquitectura
de Software, ni una referencia que analice las particularidades de cada una, en al actualidad se
pueden distinguir a grandes rasgos unas seis corrientes. El pertenecer a una de estas corrientes no
representa algo determinista, ya que en distintos momentos algunos practicantes de la Arquitectura de
Software realizan diferentes trabajos operando en marcos distintos, o porque simplemente cambian de
concepción.
La división de escuelas de Arquitectura de Software que se propone es la siguiente:
1. Arquitectura como etapa de ingeniería y diseño orientada a objetos. Evidentemente sería la
de Grady Booch; para él, la Arquitectura de Software es la estructura lógica y física de un
sistema, forjada por todas las decisiones estratégicas y tácticas que se aplican durante el
desarrollo [Boo91]. Otras definiciones revelan que la Arquitectura de Software, en esta
perspectiva, concierne a decisiones sobre organización, selección de elementos estructurales,
comportamiento, composición y estilo arquitectónico susceptibles de ser descriptas a través de
las cinco vistas clásicas del modelo 4+1 de Kruchten. (Reynoso, 2006)
2. Arquitectura estructural, basada en un modelo estático de estilos, ADLs y vistas. Los
representantes de esta corriente son todos académicos, mayormente de la Universidad Carnegie
Mellon. Se trata también de la visión de la Arquitectura de Software dominante en la academia, y
aunque es la que ha hecho el esfuerzo más importante por el reconocimiento de la Arquitectura
de Software como disciplina, sus categorías y herramientas son todavía mal conocidas en la
práctica industrial. En el interior del movimiento se pueden observar distintas divisiones. Hay una
variante informal de “boxología” y una vertiente más formalista, representada por el grupo de
Mark Moriconi en el SRI de Menlo Park. En principio se pueden reconocer tres modalidades en
cuanto a la formalización; los más informales utilizan descripciones verbales o diagramas de
cajas, los de talante intermedio se sirven de ADLs y los más exigentes usan lenguajes formales
de especificación como CHAM y Z. En toda la corriente, el diseño arquitectónico no sólo es el de
más alto nivel de abstracción, sino que además no tiene por qué coincidir con la configuración
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
explícita de las aplicaciones; rara vez se encontrarán referencias a lenguajes de programación o
piezas de código, y en general nadie habla de clases o de objetos. Mientras algunos participantes
excluyen el modelo de datos de las incumbencias de la Arquitectura de Software (Shaw, Garlan,
etc), otros insisten en su relevancia (Medvidovic, Taylor). (Reynoso, 2006)
3. Estructuralismo arquitectónico radical. Se trata de un desprendimiento de la corriente anterior,
mayoritariamente europeo, que asume una actitud más confrontativa con el mundo UML. En el
seno de este movimiento hay al menos dos tendencias, una que excluye de plano la relevancia
del modelado orientado a objetos para la Arquitectura de Software y otra que procura definir
nuevos meta-modelos y estereotipos de UML como correctivos de la situación. (Reynoso, 2006)
4. Arquitectura basada en patrones. Si bien reconoce la importancia de un modelo emanado del
diseño orientado a objetos, no se encuentra tan rígidamente vinculada a UML en el modelado, ni
a CMM en la metodología. El texto sobre patrones que esta variante reconoce como referencia es
la serie POSA de Buschmann y otros, y secundariamente el texto de la Banda de los Cuatro
[Gof95]. El diseño consiste en identificar y articular patrones preexistentes, que se definen en
forma parecida a los estilos de arquitectura. (Reynoso, 2006)
5. Arquitectura procesual. Desde comienzos del siglo XXI, con centro en el SEI y con participación
de algunos de los arquitectos de Carnegie Mellon de la primera generación y muchos nombres
nuevos de la segunda: Rick Kazman, Len Bass, Paul Clements, entre otros. Intenta establecer
modelos de ciclo de vida y técnicas de elicitación de requerimientos, brainstorming, diseño,
análisis, selección de alternativas, validación, comparación, estimación de calidad y justificación
económica específicas para la Arquitectura de Software. (Reynoso, 2006)
6. Arquitectura basada en escenarios. Es la corriente más nueva. Se trata de un movimiento
predominantemente europeo, con centro en Holanda. Recupera el nexo de la Arquitectura de
Software con los requerimientos y la funcionalidad del sistema, ocasionalmente borroso en la
arquitectura estructural clásica. En esta corriente suele utilizarse diagramas de casos de uso
UML como herramienta informal u ocasional, dado que los casos de uso son uno de los
escenarios posibles. Los casos de uso no están orientados a objeto. Los autores vinculados con
esta modalidad han sido, aparte de los codificadores de ATAM, CBAM, QASAR y demás métodos
del SEI, los arquitectos holandeses de la Universidad Técnica de Eindhoven, de la Universidad
Brije, de la Universidad de Groningen y de Philips Research. (Reynoso, 2006)
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
1.2.3. Diferencia entre Arquitectura de Software y Diseño
La comunidad académica de Arquitectura de Software difiere sustancialmente de confundir diseño con
arquitectura, aunque algunos practicantes a la hora de referirse al tema dejan muy ambiguo la relación
que existe entre ambos campos.
En alguna medida, la arquitectura y el diseño sirven al mismo propósito. Sin embargo, la Arquitectura
de Software se centra en la estructura del sistema y en las interconexiones de los componentes,
distinguiéndose del diseño de software tradicional, tales como el diseño orientado a objetos, que se
concentra más en el modelado de abstracciones de más bajo nivel, tales como algoritmos y tipos de
datos. A medida que la arquitectura de alto nivel se refina, sus conectores pueden perder prominencia,
distribuyéndose a través de los elementos arquitectónicos de más bajo nivel, resultando en la
transformación de la arquitectura en diseño. (Reynoso, et al., 2004).
La Arquitectura de Software, es una disciplina relativamente nueva en materia de diseño de software y
en realidad abarca también las metodologías de diseño, así como metodologías de análisis. El
arquitecto de software contemporáneo, ejecuta una combinación de roles como los de analista de
sistemas, diseñador de sistemas e ingeniero de software. Pero la arquitectura es más que una
recolocación de funciones. El concepto de arquitectura intenta subsumir las actividades de análisis y
diseño en un framework de diseño más amplio y más coherente. Pero la arquitectura es algo más
integrado que la suma del análisis por un lado y el diseño por el otro. La integración de metodologías y
modelos, es lo que distingue la AS de la simple yuxtaposición de técnicas de análisis y de diseño.
(Albin, 2003).
La arquitectura concierne a un nivel de abstracción más elevado; se ocupa de componentes y no de
procedimientos; de las interacciones entre esos componentes y no de las interfaces; de las
restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos, los
procedimientos y los tipos. En cuanto a la composición, la de la arquitectura es de grano grueso, la del
diseño es de fina composición procedural; las interacciones entre componentes en arquitectura tienen
que ver con un protocolo de alto nivel (en el sentido no técnico de la palabra), mientras que las del
diseño conciernen a interacciones de tipo procedural (mensajes, llamadas a rutinas) (Perry, 1997).
Por lo que se puede concluir que la Arquitectura de Software no es diseño de software, ya que ocurre
en una etapa más temprana del desarrollo de un proyecto a un alto nivel de abstracción ocupándose
de componentes, conectores, configuraciones, restricciones, dejándole al diseño detallar elementos
arquitectónicos de más bajo nivel, más refinados como: procedimientos, algoritmos y tipos de datos.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
1.3. Niveles de Abstracción de la Arquitectura de Software
1.3.1. Estilos Arquitectónicos
1.3.1.1. Clasificación de Estilos
¿Cuántos y cuáles son los estilos?
En un estudio realizado por Mary Shaw y David Garlan (Garlan, et al., 1994), proponen la siguiente
taxonomía, en la que se entremezclan lo que antes se llamaba “arquitecturas” con los “modelos de
diseño”:
1. Tubería-filtros
2. Organización de abstracción de datos y orientación a objetos
3. Invocación implícita, basada en eventos
4. Sistemas en capas
5. Repositorios
6. Intérpretes orientados por tablas
7. Procesos distribuidos. Una forma particular de proceso distribuido es, por ejemplo, la
arquitectura cliente-servidor.
8. Organizaciones programa principal / subrutina.
9. Arquitecturas de software específicas de dominio
10. Sistemas de transición de estado
11. Sistemas de procesos de control
12. Estilos heterogéneos
En Software Architecture in Practice, un texto fundamental de Bass, Clements y Kazman (Bass, et al.,
1998), se proporciona una sistematización de clases de estilo en cinco grupos:
Flujo de datos (movimiento de datos, sin control del receptor de lo que viene “corriente arriba”)
oProceso secuencial por lotes
oRed de flujo de datos
oTubería-filtros
Llamado y retorno (estilo dominado por orden de computación, usualmente con un solo thread
de control)
oPrograma principal / Subrutinas
oTipos de dato abstracto
oObjetos
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
oCliente-servidor basado en llamadas
oSistemas en capas
Componentes independientes (dominado por patrones de comunicación entre procesos
independientes, casi siempre concurrentes)
oSistemas orientados por eventos
oProcesos de comunicación
Centrados en datos (dominado por un almacenamiento central complejo, manipulado por
computaciones independientes)
oRepositorio
oPizarra
Máquina virtual (caracterizado por la traducción de una instrucción en alguna otra)
oIntérprete
Los estilos a diferencia de patrones son unos pocos, y se agrupan en clases de estilos, siendo la
clasificación más actual, concisa y que se asume durante la investigación la siguiente (Reynoso, 2005):
Estilos de Flujo de Datos
oTubería y filtros
Estilos Centrados en Datos
oArquitecturas de Pizarra o Repositorio
Estilos de Llamada y Retorno
oModel-View-Controller (MVC)
oArquitecturas en Capas
oArquitecturas Orientadas a Objetos
oArquitecturas Basadas en Componentes
Estilos de Código Móvil
oArquitectura de Máquinas Virtuales
Estilos heterogéneos
oSistemas de control de procesos
oArquitecturas Basadas en Atributos
Estilos Peer-to-Peer
oArquitecturas Basadas en Eventos
oArquitecturas Orientadas a Servicios (SOA)
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
oArquitecturas Basadas en Recursos
1.3.1.2. Estilos más Populares
En la década de 1960 y 1970 era natural estructurar una aplicación en términos de los servicios
funcionales que ésta debía proveer. De hecho, las metodologías como el análisis y diseño estructurado
partían de una descomposición funcional jerárquica que luego se transformaba en procedimientos
dentro de la aplicación. Con el aumento de la complejidad de las aplicaciones y la necesidad de
hacerlas evolucionar, este enfoque no fue suficiente. En los 80s y 90s se popularizó el desarrollo de
software orientado-objetos que buscaba, entre otros objetivos, permitir la construcción de aplicaciones
más mantenibles. (Casallas, et al., 2005)
Hoy parecen no ser suficiente los objetos, no porque hayan dejado de ser buenos, sino porque el
problema ha cambiado. Estos cambios son consecuencia de los avances tecnológicos y el incremento
de las expectativas de los clientes. Por ejemplo, las características no funcionales se han vuelto más
críticas y el problema de la integración de aplicaciones ha llegado a ser prioritario. Se necesita contar
con arquitecturas flexibles y lo más independientes posibles de las herramientas que se utilicen. En el
(anexo 1) se muestra como han ido evolucionando las arquitecturas de los sistemas a lo largo de estos
años.
Arquitectura Orientada a Objetos
A este tipo de arquitectura se le conoce de varias maneras, entre ellas: Arquitecturas Basadas en
Objetos, Abstracción de Datos y Organización Orientada a Objetos.
Los componentes de este estilo son los objetos, o más bien instancias de los tipos de dato abstractos.
En la caracterización clásica de David Garlan y Mary Shaw, los objetos representan una clase de
componentes que ellos llaman managers, debido a que son responsables de preservar la integridad de
su propia representación. Un rasgo importante de este aspecto es que la representación interna de un
objeto no es accesible desde otros objetos. (Garlan, et al., 1994)
Según Billy Reinoso (Reynoso, et al., 2004), si hubiera que resumir las características de las
arquitecturas orientadas a objetos, se podría decir que:
Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y
polimorfismo. Son asimismo las unidades de modelado, diseño e implementación, y los objetos
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
y sus interacciones son el centro de las incumbencias en el diseño de la arquitectura y en la
estructura de la aplicación.
Las interfaces están separadas de las implementaciones. En general la distribución de objetos
es transparente, y en el estado de arte de la tecnología apenas importa si los objetos son
locales o remotos. El mejor ejemplo de orientación a objetos para sistemas distribuidos es
Common Object Request Broker Architecture (CORBA), en la cual las interfaces se definen
mediante Interface Description Language (IDL); un Object Request Broker media las
interacciones entre objetos clientes y objetos servidores en ambientes distribuidos.
En cuanto a las restricciones, puede admitirse o no que una interfaz pueda ser implementada
por múltiples clases. Hay muchas variantes del estilo; algunos sistemas, por ejemplo, admiten
que los objetos sean tareas concurrentes; otros permiten que los objetos posean múltiples
interfaces.
Ventajas:
Se puede modificar la implementación de un objeto sin afectar a sus clientes.
Un objeto es una entidad reutilizable en el entorno de desarrollo
Encapsulamiento.
Desventajas:
Para poder interactuar con otro objeto a través de una invocación de procedimiento, se debe
conocer su identidad.
Presenta problemas de efectos colaterales en cascada: si A usa B y C también lo usa, el efecto
de C sobre B puede afectar a A.
Granularidad muy fina para sistemas grandes.
Arquitectura en Capas
Garlan y Shaw definen el estilo en capas como una organización jerárquica tal que cada capa
proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la
inmediatamente inferior (Reynoso, et al., 2004). (Ver anexo 2)
En un estilo en capas, los conectores se definen mediante los protocolos que determinan las formas de
la interacción. Las restricciones topológicas del estilo pueden incluir una limitación, más o menos
rigurosa, que exige a cada capa operar sólo con capas adyacentes, y a los elementos de una capa
entenderse sólo con otros elementos de la misma; se supone que si esta exigencia se relaja, el estilo
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
deja de ser puro y pierde algo de su capacidad heurística (MSDN, 2004); también se pierde,
naturalmente, la posibilidad de reemplazar de cuajo una capa sin afectar a las restantes, disminuye la
flexibilidad del conjunto y se complica su mantenimiento.
A veces se argumenta que el cruce excesivo de muchos niveles involucra eventuales degradaciones
de performance; pero muchas más veces se sacrifica la pureza de la arquitectura en capas
precisamente para mejorarla: colocando, por ejemplo, reglas de negocios en los procedimientos
almacenados de las bases de datos, o articulando instrucciones de consulta en la capa de la interface
del usuario.
Ventajas
Modularidad (hasta cierto punto)
Soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los
implementadores la partición de un problema complejo en una secuencia de pasos
incrementales.
Proporciona amplia reutilización.
Soporta fácilmente la evolución del sistema; los cambios sólo afectan a las capas vecinas
Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes.
Desventajas
Es difícil razonar a priori sobre la separación en capas requerida
Formatos, protocolos y transportes de la comunicación entre capas suelen ser específicos y
propietarios
No todos los sistemas pueden estructurarse en capas.
Arquitectura basada en Componentes
Actualmente en el desarrollo de software hay una gran necesidad de hacer uso de la reutilización de
partes o módulos de software existente, que podrían ser utilizadas para la generación de nuevas
extensiones de las aplicaciones o las aplicaciones completas. Cuando se hable de reutilización en los
procesos de ingeniería, esta muy implícito el concepto de “componente”, pues a las partes eficientes
de software que pueden ser utilizadas para la construcción de aplicaciones se les conoce como
“componentes software”.
Son varias las definiciones este término (Componente de Software):
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Según Krutchen, un componente es una parte no trivial, casi independiente y reemplazable de
un sistema que cumple una función dentro del contexto de una arquitectura bien definida. Un
componente cumple con un conjunto de interfaces y provee la realización física de ellas.
(Brown, et al., 1998).
El Software Engineering Institute (SEI) de la Universidad Carnegie Mellon formuló una
definición con el propósito de consolidar las diferentes opiniones acerca de lo que debía ser un
componente de software: un componente es una implementación opaca de funcionalidad,
sujeta a composición por terceros y que cumple con un modelo de componentes (Bachmann,
et al., 2000).
Según Szyperski, un componente de software es una unidad de composición con interfaces
especificadas contractualmente y solamente dependencias explícitas de contexto. Un
componente de software puede ser desplegado independientemente y está sujeto a
composición por terceros. (Szyperski, 2002).
Se puede ver que la mayoría de las definiciones giran sobre lo esencial de un componente, que es una
implementación de un artefacto de software, que ejecuta una o varias funcionalidades, liberadas por
servicios, vistos como un conjunto de interfaces y provee la realización física de ellas.
Características:
Una de las características más importantes de los componentes es que son reutilizables. Para ello los
componentes deben satisfacer como mínimo el siguiente conjunto de características:
Identificable: un componente debe tener una identificación clara y consistente que facilite su
catalogación y búsqueda en repositorios de componentes.
Accesible sólo a través de su interfaz: el componente debe exponer al público únicamente el
conjunto de operaciones que lo caracteriza (interfaz) y ocultar sus detalles de implementación.
Esta característica permite que un componente sea reemplazado por otro que implemente la
misma interfaz.
Servicios son invariantes: las operaciones que ofrece un componente, a través de su interfaz,
no deben variar. La implementación de estos servicios puede ser modificada, pero no deben
afectar la interfaz.
Documentado: un componente debe tener una documentación adecuada que facilite su
búsqueda en repositorios de componentes, evaluación, adaptación a nuevos entornos,
integración con otros componentes y acceso a información de soporte.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
La evaluación dominante del estilo de componentes subraya su mayor versatilidad respecto del modelo
de objetos, pero también su menor adaptabilidad comparado con el estilo orientado a servicios
(Reynoso, et al., 2004).
Ventajas:
Reutilización del software. Lleva a alcanzar un mayor nivel de reutilización de software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los
componentes antes de probar el conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea
necesario, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organización, la calidad de una aplicación basada en
componentes mejorará con el paso del tiempo.
Desventajas:
Si no existen los componentes, hay que desarrollarlos y se puede perder mucho tiempo, así
como en que estos componentes pueden tener conflictos si de estos sale una nueva versión es
posible que haya que re-implementar estos componentes.
Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores
del sistema.
Arquitectura Orientada a Servicios (SOA)
Las Arquitecturas Orientadas a Servicios (SOA: Service Oriented Architecture) están formadas por
servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí,
estos servicios se basan en una definición formal independiente de la plataforma y del lenguaje de
programación (por ejemplo WSDL: Web Services Description Language). La definición de la interfaz
encapsula las particularidades de una implementación, lo que la hace independiente del fabricante, del
lenguaje de programación o de la tecnología de desarrollo (como Java o .NET).
Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reusables,
ya que la interfaz se define siguiendo un estándar; así, un servicio desarrollado en CSharp podría ser
usado por una aplicación Java.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Una de las características más resaltante de SOA, es que esta basada en contratos, donde el
proveedor establece las reglas de comunicación, el transporte, y los datos de estrada y salida que
serán intercambiados por ambas partes. Para ver mas características de SOA ver (anexo 3).
¿Qué es SOA?
SOA es una arquitectura conceptual.
Organiza funciones de negocio como servicios interoperables.
Permite reutilización de servicios para satisfacer necesidades de negocio.
SOA es basado en estándares.
Independencia de fabricantes.
SOA es una estrategia de IT a nivel empresarial.
SOA es un estilo de arquitectura en el cual se exponen los procesos de negocio del sistema a construir
como servicios independientes de alta cohesión y bajo acoplamiento que encapsulan dichos procesos
y pueden ser invocados a través de interfaces bien definidas.
¿Qué no es SOA
SOA como tal no es:
Metodología de Desarrollo de Proyectos.
Metodología de Arquitectura Empresarial.
SOA como estilo arquitectónico
Componente: Servicio
Conectores: Antes, RPC – Ahora, paso de mensajes.
Configuración: Distribuido
Restricciones (Constraint): Bajo acoplamiento, independencia de modelo de programación,
independencia de plataforma, transporte y protocolo por acuerdo de industria
Ventajas
Mejorar toma de decisiones.
oPanorámica unificada. Más información con mejor calidad.
Mejorar productividad de empleados.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
oAcceso optimo a sistemas. No limitación de TIC
Potenciar relación con los clientes y proveedores.
oMayor capacidad de respuesta a los clientes.
Aplicaciones más productivas y flexibles.
Aplicaciones más seguras y manejables.
Desventajas
Los tiempos de llamado no son despreciables, gracias a la comunicación de la red, tamaño de
los mensajes, entre otros. Esto necesariamente implica la utilización de mensajería confiable.
La respuesta del servicio es afectada directamente por aspectos externos como problemas en
la red, configuración, entre otros.
Debe manejar comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes
fuera de secuencia, etcétera.
1.3.2. Patrones Arquitectónicos
Existe una categorización muy utilizada dividida en 2 de los sistemas de patrones de arquitectura más
extendidos, siendo los mismos: el de Pattern Oriented Software Architecure (POSA) (Buschmann, et
al., 1996) y el de Pattern of Enterprise Application Architecture (PEAA) (Fowler, et al., 2002).
Categorías de POSA
En el libro de referencia de patrones de arquitectura POSA, se divide a los patrones de la siguiente
forma:
From Mud to Structure: Estos patrones ayudan a evitar una abundancia de componentes u
objetos. En particular, soportan una descomposición controlada de una tarea del sistema en
sub-tareas que cooperan.
Distributed Systems
Interactive Systems
Adaptable Systems
En el (anexo 4) se muestra la distribución de los patrones de POSA en las categorías enunciadas y
seguidamente en el (anexo 5) se muestra una breve explicación de algunos de ellos.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Categorías de PEAA
En PEAA (Fowler, et al., 2002), describen una gran cantidad de patrones orientados a la arquitectura
de aplicaciones empresariales.
En PEAA se definen las siguientes categorías de patrones:
Layering: Patrones para dividir un sistema en capas.
Organización de la lógica del dominio: Formas de organizar los objetos del dominio.
Mapping to Relational Databases: Se relaciona con la comunicación entre la lógica del
dominio y los repositorios de datos. Incluye el mapeo entre modelos de objetos y bases de
datos relacionales.
Web Presentation: La presentación Web es uno de los desafíos que han tenido que sortear en
los últimos años las aplicaciones empresariales. Los clientes delgados Web proveen muchas
ventajas, siendo una de las principales la facilidad de distribución (no es necesario instalar
software en los equipos cliente). Esta categoría incluye una serie de patrones para gestionar la
presentación Web. (Welicki, 2007)
Concurrency: Manejo de la concurrencia. Las aplicaciones actuales basadas en tecnologías
Web tienen grandes necesidades de gestión de la concurrencia.
Sesion State: Patrones para el manejo de la sesión en servidores Web.
Distribution Strategies: Distribución de objetos en múltiples emplazamientos, basada en
conocimientos empíricos en clientes.
En el (anexo 6) se muestra la distribución de los patrones definidos en PEAA en las categorías antes
expuestas.
Los términos patrón de arquitectura y estilo de arquitectura suelen confundirse y muchos de los
estudiosos de la disciplina parecen no estar bien claros al respecto. Con la intención de hacer una
comparación clara entre estilo arquitectónico y patrón arquitectónico, en (anexo 7) se presenta algunas
de las diferencias entre estos conceptos, construida a partir del planteamiento (Buschmann, et al.,
1996).
1.3.3. Relación entre los Niveles de Abstracción
En (anexo 8) se muestra la relación de abstracción existente entre los conceptos de estilo
arquitectónico, patrón arquitectónico y patrón de diseño.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Los estilos y patrones ayudan al arquitecto a definir la composición y el comportamiento del sistema de
software, y una combinación adecuada de ellos permite alcanzar los requerimientos de calidad
permitiendo de esa manera que el sistema de software a construir perdure en el tiempo.
Ahora bien, la organización del sistema de software debe estar disponible para todos los involucrados
en el desarrollo del sistema, ya que establece un mecanismo de comunicación entre los mismos. Esto
se logra mediante la representación de la arquitectura en formas distintas, obteniendo así una
descripción de la misma de forma tal que puede ser entendida y analizada por todos los involucrados,
con miras a obtener un sistema de calidad. Estas descripciones pueden establecerse a través de las
vistas arquitectónicas, las notaciones como UML y los lenguajes de descripción arquitectónica
(Bengtsson, 1999).
Las vistas arquitectónicas, a través de distintos niveles de abstracción, resaltan varias cuestiones que
conciernen a los involucrados en el desarrollo. Por lo que resulta interesante analizar estas
perspectivas de una arquitectura, y la forma en que éstas ayudan a todos los involucrados en el
proceso de desarrollo a razonar sobre los atributos de calidad del sistema.
1.3.4. Marcos de Trabajo
En la sección 1.2.1.4 se ha dado una breve definición sobre lo que es un framework por lo que esta
sección se intentará abordar más sobre los mismos.
Los objetivos principales que persigue un framework son: acelerar el proceso de desarrollo, reutilizar
código ya existente y promover buenas prácticas de desarrollo como el uso de patrones, entre otros.
La labor del usuario del framework debe ser, por un lado, de seleccionar, instanciar, extender y
reutilizar los componentes que este proporciona, y por otro, completar la arquitectura del mismo
desarrollando componentes específicos, que deben ser acoplados en el framework, logrando así
desarrollar diferentes aplicaciones siguiendo las restricciones estructurales impuestas por el
framework.
¿Qué ventajas tiene utilizar un framework?
Las que se derivan de utilizar un estándar; entre otras:
El programador no necesita plantearse una estructura global de la aplicación, sino que el
framework le proporciona un esqueleto que hay que “rellenar”.
Facilita la colaboración. Cualquiera que haya tenido que pelearse con el código fuente de otro
programador, o incluso con el propio, sabrá lo difícil que es entenderlo y modificarlo; por tanto,
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos
colaborativos.
Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto
para facilitar el desarrollo.
Aunque el uso de los frameworks sea una buena práctica para el desarrollo de un sistema software no
significa que haya que utilizar obligatoriamente uno, ya sea conocido o no, ni nada por el estilo. Esto va
a estar en dependencia de la magnitud del proyecto y de la experiencia que se tenga por parte del
equipo de desarrollo y el arquitecto.
Según uno de los principios de la programación segura, ¿Por qué no utilizar un framework ya definido,
y aprovechar el trabajo de otros desarrolladores?, o sea, ¿Por qué reinventar la rueda? Si se tiene algo
que probado, que funciona, y está en explotación, no hay necesidad de hacer algo que haga lo mismo,
esto es poco útil y solo puede traer complicaciones como la pérdida de tiempo.
Es cierto que la utilización de un framework implica cierto coste inicial (curva de aprendizaje), pero esto
es algo que se compensa a la larga durante el desarrollo de un proyecto software.
1.4. SOA: Desafío del presente
La Arquitectura Orientada a Servicios es un concepto de arquitectura de software que define la
utilización de servicios como construcciones básicas para el desarrollo de aplicaciones. Es una
arquitectura de una aplicación donde las funcionalidades se definen como servicios independientes,
con interfaces accesibles, bien definidas, que pueden ser llamadas en secuencias dadas para formar
procesos de negocios.
“SOA ha surgido como la mejor manera de afrontar el desafío de hacer más con menos recursos.
Promete hacer la reutilización y la integración mucho más fáciles, ayudando a reducir el tiempo de
desarrollo y aumentando la agilidad organizacional. No sorprendentemente, el 80% de las
organizaciones de IT están implementando aplicaciones usando SOA con web services subyacentes.
SOA proporciona mayor flexibilidad para afrontar los cambios tanto en el ambiente de negocios como
en la infraestructura tecnológica” (Reynoso, 2005).
Gartner, proveedor líder de investigación y análisis de la industria global de tecnologías de información
(TI), en el 2003 plantea: Hacia 2008, SOA será la práctica prevalente de ingeniería de software,
acabando con los 40 años de dominación de las arquitecturas monolíticas (probabilidad 0.7)” (Natis,
2003).
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
1.4.1. Razones para usar SOA
Existen varias razones para que una empresa adopte un enfoque SOA, y más concretamente un
enfoque SOA basado en servicios web:
Reutilización: El factor fundamental en el cambio a SOA es la reutilización de los servicios de
negocio. Las funciones de negocio, dentro de una empresa y con los business partners1,
pueden ser expuestos como servicios web y ser reutilizadas para cubrir nuevas necesidades de
negocio.
Interoperabilidad: El objetivo de una arquitectura débilmente acoplada es que los clientes y
servicios se comuniquen independientemente de la plataforma en que residan. Los protocolos
de comunicación con servicios web son independientes de la plataforma, lenguaje de
codificación y sistema operativo por lo que facilitan la comunicación con los business partners.
Escalabilidad: Como los servicios de SOA están débilmente acoplados, las aplicaciones que
usan esos servicios escalan fácilmente. Esto es debido a que existe muy poca dependencia
entre las aplicaciones clientes y los servicios que usan.
Flexibilidad: Es otra de las características que proporciona el acoplamiento débil entre los
servicios. Cualquier cambio en la implementación de uno de ellos no afectaría al resto siempre
que se mantenga la interfaz.
Eficiencia de coste: Las arquitecturas SOA se basan en la exposición de servicios ya
existentes para ser reutilizados. Al usar servicios web, para exponer estos servicios, se
reutilizan la infraestructura web existente en virtualmente todas las organizaciones por lo que se
limita considerablemente el coste.
1.4.2. Elementos de SOA
Esta arquitectura presenta una forma de construir sistemas distribuidos que entreguen a la aplicación
funcionalidad como servicios para aplicaciones de uso final u otros servicios.
En el anexo 9 se muestran los elementos que podrían observarse en una arquitectura orientada a
servicios. En el mismo se pueden diferenciar dos zonas, una que abarca los aspectos funcionales de la
arquitectura y otra que abarca aspectos de calidad de servicio. A continuación se describen los
elementos brevemente (Endrei, et al., 2004):
Funciones
1 Business partners: Persona o empresa que es copropietaria de la empresa o compañía, en otras palabras, es
un socio de la compañía al que le pertenece parte de ella.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
oTransporte: es el mecanismo utilizado para llevar las demandas de servicio desde un
consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el proveedor
hacia el consumidor.
oProtocolo de comunicación de servicios: es un mecanismo acordado a través del cual un
proveedor de servicios y un consumidor de servicios comunican qué está siendo solicitado y
qué está siendo respondido.
oDescripción de servicio: es un esquema acordado para describir qué es el servicio, cómo
debe invocarse, y qué datos requiere el servicio para invocarse con éxito.
oServicios: describe un servicio actual que está disponible para utilizar.
oProcesos de Negocio: es una colección de servicios, invocados en una secuencia
particular con un conjunto particular de reglas, para satisfacer un requerimiento de negocio.
oRegistro de Servicios: es un repositorio de descripciones de servicios y datos que pueden
utilizar proveedores de servicios para publicar sus servicios, así como consumidores de
servicios para descubrir o hallar servicios disponibles.
Calidad de Servicio
oPolítica: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio
hace el servicio disponible para consumidores.
oSeguridad: es un conjunto de reglas que pueden aplicarse para la identificación,
autorización y control de acceso a consumidores de servicios.
oTransacciones: es el conjunto de atributos que podrían aplicarse a un grupo de servicios
para entregar un resultado consistente.
oAdministración: es el conjunto de atributos que podrían aplicarse para manejar los
servicios proporcionados o consumidos.
Las colaboraciones en SOA siguen el paradigma publicar, descubrir e invocar, donde un consumidor
de servicios realiza la localización dinámica de un servicio consultando el registro de servicios para
hallar uno que cumpla con un determinado criterio. Si el servicio existe, el registro proporciona al
consumidor la interfaz de contrato y la dirección del servicio proveedor. (Endrei, et al., 2004)
En el anexo 10 se ilustra las entidades (roles, operaciones y artefactos) en una Arquitectura Orientada
a Servicios donde estas colaboran.
Cada entidad de las que se muestra en el diagrama del (anexo 10) puede tomar el rol de consumidor,
proveedor y/o registro:
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Un consumidor de servicios es una aplicación, un módulo de software u otro servicio que
requiere un servicio, y ejecuta el servicio de acuerdo a un contrato de interfaz.
Un proveedor de servicios es una entidad direccionable a través de la red que acepta y
ejecuta consultas de consumidores, y publica sus servicios y su contrato de interfaces en el
registro de servicios para que el consumidor de servicios pueda descubrir y acceder al servicio.
Un registro de servicios es el encargado de hacer posible el descubrimiento de servicios,
conteniendo un repositorio de servicios disponibles y permitiendo visualizar las interfaces de los
proveedores de servicios a los consumidores interesados.
Las operaciones son:
Publicar. Para poder acceder a un servicio se debe publicar su descripción para que un
consumidor pueda descubrirlo e invocarlo.
Descubrir. Un consumidor de servicios localiza un servicio que cumpla con un cierto criterio
consultando el registro de servicios.
Ligar e Invocar. Una vez obtenida la descripción de un servicio por parte de un consumidor,
éste lo invoca de acuerdo a la información en la descripción del servicio.
Finalmente, los artefactos en una arquitectura orientada a servicios son (Alvez, et al., 2006):
Servicio. Un servicio que está disponible para el uso a través de una interfaz publicada y que
permite ser invocado por un consumidor de servicios.
Descripción de servicio. Una descripción de servicio especifica la forma en que un
consumidor de servicio interactuará con el proveedor de servicio, especificando el formato de
consultas y respuestas desde el servicio. Esta descripción también puede especificar el
conjunto de precondiciones, pos-condiciones y/o niveles de calidad de servicio.
Analizando lo anteriormente planteado se puede concluir que el elemento básico en este tipo de
arquitectura es el servicio, pero únicamente con este artefacto no se podría diseñar una SOA. Para
conformar una SOA se necesita básicamente la conjunción de operaciones, servicios, mensajes y
procesos de negocio.
1.4.2.1. Tipos de Servicios
Servicios básicos: pueden estar centrados en datos o en lógica y encapsulan funcionalidades
como cálculos complejos, acceso a datos y reglas complejas de negocio.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Servicios intermediarios: servicios adaptadores, fachadas, etcétera. Suelen ser servicios sin
estado.
Servicios de proceso: servicios de negocio que encapsulan la lógica de proceso. Suelen
conservar estado y pueden residir en herramientas BPM.
Servicios públicos: servicios accesibles por terceros (fuera de la organización).
Un servicio de negocio es un componente reutilizable de software, con significado funcional
completo, y que está compuesto por (ver anexo 11):
Contrato: especificación de la finalidad, funcionalidad, forma de uso y restricciones del servicio.
Interfaz: mecanismo de exposición del servicio a los usuarios.
Implementación: debe contener la lógica o el acceso a datos.
1.4.3. Servicios Web
Las Arquitecturas Orientadas a Servicios, en contraste con las Arquitecturas Orientadas a Objetos,
están formadas por servicios de aplicación altamente interoperables y débilmente acoplados. Donde
estos servicios se pueden ver como la evolución en complejidad de un componente distribuido,
diferenciándose en que son (Alvez, et al., 2006):
Mucho menos acoplados con sus aplicaciones cliente que los componentes.
Menor granularidad que los componentes.
No son diseñados e implementados necesariamente como parte de una aplicación end-to-end.
Son controlados y administrados de manera independiente.
Expone su funcionalidad a través de protocolos abiertos e independientes de plataforma.
Incluso arriesgando el rendimiento y consumo de recursos.
Son transparentes de su localización en la red, de esta manera garantizan escalabilidad y
tolerancia a fallos.
Por lo general, los servicios incluyen tanto lógica de negocios como manejo de datos, relevantes a la
solución del problema para el cual fueron diseñados. Un servicio funciona como una aplicación
independiente, teniendo sus propias reglas de negocio, datos, procedimientos de administración y
operación, políticas de escalabilidad, seguridad, tolerancia a fallos, manejo de excepciones y
configuración. Expone toda su funcionalidad utilizando una interfaz basada en mensajes, por lo que la
comunicación con el servicio, es realizada mediante mensajes y no llamadas a métodos. Estos
mensajes deben contener o referenciar toda la información necesaria para ser entendidos.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Los servicios web comunican aplicaciones, lo cual permite que se comparta información
independientemente de cómo se hayan creado, cuál sea el sistema operativo o la plataforma en que se
ejecutan y cuáles sean los dispositivos utilizados para obtener acceso a ellas. La comunicación se
caracteriza por el intercambio de mensajes XML y por ser independientes del protocolo de
comunicación. Para lograr esta independencia, el mensaje XML se envuelve de manera apropiada
para cada protocolo gracias a la creación del protocolo de transporte SOAP (Simple Object Access
Protocol: Protocolo de Acceso a Objetos Simples). (Alvez, et al., 2006)
El Lenguaje de Descripción de los Servicios Web (WSDL: Web Services Description Languaje),
expresado en XML, describe cómo acceder al servicio, de qué funciones dispone, qué argumentos
necesita y qué devuelve cada uno.
La otra tecnología fundamental implicada es la de Descripción Universal, Descubrimiento e Integración
(UDDI: Universal Description, Discovery, and Integration). UDDI es un directorio de servicios web
donde se puedan publicar los servicios ofrecidos, dar características del tipo de servicio, y realizar
búsquedas.
En resumen, SOAP define un protocolo XML para la interoperabilidad básica entre servicios, WSDL
introduce un lenguaje común para describir servicios y UDDI provee la infraestructura requerida para
publicar y descubrir servicios programáticamente. Juntas, estas especificaciones permiten a las
aplicaciones interactuar siguiendo un modelo débilmente acoplado e independiente de la plataforma
subyacente.
1.4.3.1. Tecnologías asociadas
WSDL
El lenguaje de descripción de servicios web, nació en septiembre de 2000 de la mano de Microsoft,
IBM y Ariba, y constituye un estándar para la descripción de servicios del World Wide Web Consortium
(W3C), organización que guía el desarrollo en la web. (Endrei, et al., 2004)
En esencia, WSDL es un contrato entre el proveedor del servicio y el cliente mediante el que el
proveedor del servicio indica (Alvez, et al., 2006):
Qué funciones que se pueden invocar
Qué tipos de datos utilizan esas funciones
Qué protocolo de transporte se utilizará para el envío y recepción de los mensajes (típicamente,
pero no únicamente, mensajes SOAP).
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Cómo acceder a los servicios. En esencia, mediante qué URL se utilizan los servicios.
SOAP
Es un protocolo simple para el intercambio de información estructurada en un entorno distribuido y
descentralizado. Define como dos objetos en diferentes procesos pueden comunicarse por medio del
intercambio de datos XML. Utiliza XML para definir un framework extensible de mensajería proveyendo
un formato de mensaje que puede ser intercambiado sobre una variedad de protocolos subyacentes.
El framework fue diseñado para ser independiente de cualquier modelo de programación o cualquier
semántica específica de alguna implementación (W3C, 2007).
El hecho de que SOAP use XML tiene sus ventajas como la facilidad de comprensión por las personas,
pero a la vez tiene sus inconvenientes debido a que los mensajes son más largos.
UDDI
Es un elemento central del grupo de estándares involucrados en la tecnología servicios web. Es el
mediador a través del cual se conocen los posibles clientes con los proveedores de los servicios.
Define un método estándar para publicar y descubrir servicios en el contexto SOA (Alvez, et al., 2006).
La especificación de UDDI nació casi a la vez que la de WSDL, de la mano de las mismas compañías.
La versión actual es la 3.0, especificación que data de agosto de 2003, siendo gestionada por
Organization for the Advancement of Structured Information Standards (OASIS). La implementación de
estas especificaciones se denomina “Registro UDDI”, el cual proporciona un conjunto de servicios web
de registro y consulta vía SOAP.
El propósito funcional de un registro UDDI es la representación de datos y metadatos acerca de
servicios web. Tanto para ser usado en una red pública como dentro de la infraestructura interna de
una organización, un registro UDDI ofrece un mecanismo basado en estándares para clasificar,
catalogar y manejar servicios web de forma de que puedan ser descubiertos y consumidos por otras
aplicaciones.
Estructuras de datos en UDDI
La información almacenada en un registro UDDI es un conjunto de las denominadas “estructuras de
datos UDDI”. Estas estructuras, en XML, definidas en la especificación, son las que el cliente
intercambiará con el registro UDDI. Cada instancia de estas estructuras se identifica de manera única
con un identificador denominado Universal Unique Identifier (UUID) (OASIS, 2004).
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Las principales estructuras de alto nivel son las siguientes (Alvez, et al., 2006):
BusinessEntity. Contiene información básica de la empresa: persona de contacto, una
clasificación de la empresa conforme a alguna de las taxonomías definidas, así como una
descripción en lenguaje natural de las actividades de la empresa.
PublisherAssertion. Una empresa puede declarar su relación con otras empresas, por ejemplo,
como socios o como clientes. Cada una de estas relaciones se modela como una
PublisherAssertion.
BusinessService. Este elemento muestra los servicios ofrecidos por una empresa. Estos
servicios pueden ser servicios web o no. Una BusinessEntity se compone de uno o varios
elementos businessService, y un elemento businessService puede ser usado por varios
elementos BusinessService.
BindingTemplate. Este elemento contiene referencias a descripciones técnicas (por ejemplo,
URLs apuntando a manuales técnicos) y a las URL de acceso de los servicios web. Cada
elemento BusinessService puede tener uno o varios elementos BindingTemplate.
TModel. Este elemento describe la manera de interactuar con el servicio web y su
comportamiento. Entre sus datos se encuentra la URL donde se encuentra el documento
WSDL. También pueden aparecer aquí las categorías en las que se puede englobar el servicio
(pueden ser distintas de las que podían aparecer en BusinessEntity).
1.4.4. Composición de Servicios
En situaciones en las que un sistema de software, para completar un proceso de negocio, tiene que
interactuar con otros sistemas independientemente de su distribución física y heterogeneidad, las
Arquitecturas Orientadas a Servicios son más que útiles.
De las Arquitecturas Orientadas a Servicios y más precisamente del uso de servicios web surge un
nuevo concepto denominado composición de servicios. Esta composición no solo permite modelar el
proceso de negocio sino que también maximiza las potencialidades que SOA brinda a través de la
integración de datos y aplicaciones.
La composición de servicios implica encontrar un mecanismo que permita a dos o más de ellos
cooperar entre para resolver requerimientos que van más allá del alcance de sus capacidades
individuales. Algunos de los requisitos básicos que se deben cumplir son (Alvez, et al., 2006):
Interacciones asincrónicas con servicios: de manera de dar la posibilidad de crear procesos
que transcurran durante largos períodos de tiempo.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Interacciones simultáneas entre servicios: esto introduce el procesamiento en paralelo lo
cual redunda en un aumento considerable de la eficiencia.
Manejo de excepciones: un proceso basado en múltiples servicios puede fallar en su
ejecución si al menos uno de sus componentes falla. Se debe tener en cuenta la ocurrencia de
errores y proveer mecanismos para manejarlos.
Integridad transaccional: un proceso de larga duración puede eventualmente fallar, en este
caso puede requerirse que parte de las acciones ya efectuadas se deshagan.
Dos términos comúnmente usados para referirse a la colaboración entre servicios son orquestación y
coreografía. Ambos están directamente relacionados con la composición pero se enfocan en aspectos
complementarios de la interacción entre servicios.
Orquestación
Un proceso se puede considerar una orquestación de servicios cuando es controlado totalmente por
una única entidad. Este proceso define completamente las interacciones con los servicios
componentes y la lógica requerida para conducir correctamente esas interacciones. Este tipo de
proceso puede entenderse como privado y ejecutable ya que solo la entidad que está orquestando el
proceso conoce el flujo de control e información que sigue el proceso que se está orquestando. De
esta manera se crea un proceso que utiliza diferentes servicios manipulando la información que fluye
entre ellos, convirtiendo, por ejemplo, los datos de salida de algunos servicios en datos de entrada de
otro. Aquí, cada entidad que participa implementa y controla su propio proceso (Cubillos, et al., 2004).
Coreografía
Un proceso es una coreografía de servicios cuando define las colaboraciones entre cualquier tipo de
aplicaciones componentes, independientemente del lenguaje o plataforma en el que estén definidas las
mismas. Un proceso de coreografía no es controlado por uno solo de los participantes. A diferencia de
la orquestación, la coreografía puede verse como un proceso público y no ejecutable. Público porque
define un comportamiento común que todas las entidades participantes deben conocer, y no ejecutable
porque está pensado para verse más bien como un protocolo de negocio que dicta las reglas para que
dichas entidades puedan interactuar entre sí (Cubillos, et al., 2004).
1.4.5. SOA & Web Service
Una SOA a menudo es malinterpretada y confundida con los servicios web. SOA es un acercamiento al
diseño de sistemas, dirige como los recursos tecnológicos serán integrados y que servicios serán
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
expuestos. A su vez los servicios web son una metodología de implementación que usa estándares
específicos y protocolos de lenguaje para ejecutar la solución SOA.
Una Arquitectura Orientada a Servicios es un método de diseñar y construir soluciones de software
poco acopladas que expongan sus funciones del negocio como servicios de software accesibles a
través de programación para ser usadas por otras aplicaciones a través de la publicación de interfaces.
Los servicios web representan una implementación de una Arquitectura Orientada a Servicios pero no
todas las aplicaciones SOA pueden ser consideradas servicios web, tal es el caso de Representational
State Transfer (REST).
A pesar de esto los servicios web son la tecnología actual, y al parecer, la tecnología que ha llegado
para quedarse. De hecho WSDL sigue desarrollándose, y todas las tecnologías más allá del lenguaje
de descripción que tiene que ver con servicios web siguen haciéndolo de manera muy vertiginosa.
Por otra parte las Arquitecturas Orientadas a Servicios son un concepto mucho más amplio que los
servicios web, aunque estos sean la implementación actual.
Un servicio web es SOA si (Reynoso, 2005):
Las interfaces se basan en protocolos de web (HTTP, SMTP, FTP)
Los mensajes se basan en XML.
1.4.6. Modelo de Madurez de SOA
¿Qué es un modelo de Madurez?
Permite medir el estado actual de una arquitectura empresarial respecto a la utilización de
SOA.
Permite establecer una ruta de evolución.
¿Por qué un Modelo de Madurez?
Habilita aprendizaje por capas incluyendo buenas prácticas
Forma la base para comunicar y extender capacidades.
Ayuda en la construcción de itinerarios.
Forma la base para crear una adopción incremental de SOA.
El modelo de madurez propuesto en esta sección consta de cinco niveles: servicios iniciares, servicios
arquitecturados, servicios de negocio, de colaboración, de métricas de negocio y optimizados de
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
negocio. Estos niveles van a permitir ir escalando en ganancia de una SOA ya que en este tipo de
arquitecturas se va de menos a más (Ver anexo 12). Este modelo de madurez es propuesto por
Progress Software Corporation una reconocida empresa de software dedicada al suministro de
plataformas de aplicaciones de negocios, entre ellas, infraestructuras SOA y de integración. Tiene
productos en el mercado del software reconocidos como: SONIC ESB, entre otros.
1.5. ADLs y UML
ADL
Los Lenguajes de Descripción de Arquitectura (ADL: Architecture Description Language) permiten
modelar una arquitectura antes que se lleve a cabo la programación de las aplicaciones que la
componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular su
comportamiento. Los mismos son bien reconocidos por la comunidad académica de Arquitectura de
Software, sin embargo parecen no gozar de la misma aceptación en la practica industrial, al no
utilizarlos en sus proyectos de software.
Estos suministran construcciones para especificar abstracciones arquitectónicas y mecanismos para
descomponer un sistema en componentes y conectores, especificando de qué manera estos
elementos se combinan para formar configuraciones y definiendo familias de arquitecturas o estilos.
(Reynoso, et al., 2004)
Los ADLs están caracterizados por la abstracción que proveen al usuario, además la mayoría de las
vistas provistas por estos lenguajes contienen información predominantemente arquitectónica y el
análisis provisto por el lenguaje se fundamenta en información de nivel arquitectónico.
Algunas de las ventajas que proponen los ADLs son:
Es posible hacer la descripción del comportamiento y sus elementos asociados, tales como el
tipo de eventos que producen, o a los que responden, incluyendo descripciones o
documentación de alto nivel.
Facilidad con la que puede introducirse y mantenerse la información referente al sistema.
Los componentes pueden ser refinados en la medida que sea necesario, para distintos tipos de
análisis.
A pesar de todo lo anterior expuesto se puede decir que los ADLs son convenientes, pero no han
demostrado aún ser imprescindibles, sobre todo por la permanencia de UML, ahora con la versión 2.0
(Reynoso, et al., 2004).
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
UML
El Lenguaje de Modelado Unificado (UML: Unified Modeling Language) está especializado en construir,
especificar, visualizar y documentar los elementos que se producen en el proceso de desarrollo de
software de Sistemas de Software Orientados a Objetos. Está compuesto por diversos elementos
gráficos que se combinan para conformar diagramas y debido a que es un lenguaje, cuenta con reglas
para combinar tales elementos. Ofrece soporte para clases, relaciones, comportamiento por
interacción, empaquetamiento, entre otros. Estos elementos se pueden representar mediante varios
diagramas ofrecidos por este lenguaje que son: de clases, de objetos, de casos de uso, de secuencia,
de colaboración, de estados, de actividades, de componentes y de desarrollo.
UML a pesar de no calificar en absoluto como ADL, se ha probado que puede utilizarse no tanto como
un ADL por derecho propio, sino como metalenguaje para simular otros ADLs, y en particular C2 y
Wright (Reynoso, et al., 2004).
En UML se identifican:
Elementos (abstracciones que constituyen los bloques básicos de construcción)
Relaciones (Ligan los elementos)
Diagramas (Representación gráfica de un conjunto de elementos)
UML provee una notación para la descripción de la proyección de los componentes de software en el
hardware, correspondiendo con la vista física del modelo 4+1 de Kruchten para la descripción de
arquitecturas de software (Kruchten, 1999).
En UML existe soporte para algunos de los conceptos asociados a las arquitecturas de software, como
los componentes, los paquetes, las librerías y la colaboración por lo que se puede decir que los
elementos básicos de la arquitectura se pueden modelar muy bien con UML. Pero para una
representación total de la arquitectura harían falta otras herramientas y lenguajes, pues la
representación total no es solo la comunicación que existe entre sus componentes, también se deben
documentar y justificar todo lo realizado para lograr un buen diseño arquitectónico.
1.6. Calidad en la Arquitectura de Software
La Arquitectura de Software de los Sistemas de Software a ser construidos, se convierte en un factor
de importancia para lograr que éste tenga un alto nivel de calidad. El poseer una buena Arquitectura de
Software es de suma importancia, ya que ésta es el corazón de todo Sistemas de Software y
determina cuáles serán los niveles de calidad asociados al sistema.
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
De lo anterior se puede deducir que los objetivos de evaluar una arquitectura es saber si puede
habilitar los requerimientos, atributos de calidad y restricciones para asegurar que el sistema a ser
construido cumple con las necesidades de los stakeholders y en qué grado lo hace. Además de
analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al
sistema de software resultante.
Cabe señalar que los requerimientos no funcionales también son llamados atributos de calidad. Un
atributo de calidad es una característica de calidad que afecta a un elemento. Donde el término
característica se refiere a aspectos no funcionales y el término elemento a componente (Gómez,
2007).
Técnicas de Evaluación
Existen un grupo de técnicas para evaluar que se clasifican en cualitativas y cuantitativas (Brey, et al.,
2005) (ver anexo 13):
Técnicas de cuestionamiento o cualitativas. Utilizan preguntas cualitativas para preguntarle a la
arquitectura
oCuestionarios. Abiertas. Temprana
oChecklists. Especifico del Dominio de la aplicación.
oEscenarios. Especificas del Sistema. Arquitectura avanzada.
Measuring techniques. Sugiere hacerle medidas cuantitativas a la arquitectura.
oUtiliza métricas arquitectónicas, como acoplamiento, cohesividad en los módulos,
profundidad en herencias, modificabilidad.
oSimulaciones, Prototipos, y Experimentos
Por lo regular, las técnicas de evaluación cualitativas son utilizadas cuando la arquitectura está en
construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya
ha sido implantada (Gómez, 2007).
¿Por qué cualidades puede ser evaluada una Arquitectura?
A grandes rasgos, Bass establece una clasificación de los atributos de calidad en dos categorías
(Camacho, et al., 2004):
Observables vía ejecución: aquellos atributos que se determinan del comportamiento del
sistema en tiempo de ejecución. La descripción de algunos de estos atributos se presenta en el
(anexo 14).
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
No observables vía ejecución: aquellos atributos que se establecen durante el desarrollo del
sistema. La descripción de algunos de estos atributos se presenta en el (anexo 15).
¿Qué resultados produce la evaluación de una Arquitectura?
Una vez que se ha efectuada la evaluación se debe elaborar un reporte. Que debe presentarse como
un documento preliminar, con la finalidad de que se corrija por las personas que participaron en la
evaluación. El contenido del reporte responde a dos tipos de preguntas (Gómez, 2007):
¿Se ha diseñado la arquitectura más apropiada para el sistema?
¿Cuál de las arquitecturas propuestas es la más apropiada para el sistema a construir?
Además de responder estas preguntas, el reporte también indica:
El grado en que se cumplieron los atributos de calidad.
Lista priorizada de los atributos de calidad requeridos para la arquitectura que está siendo
evaluada.
Riesgos y no riesgos.
Hoy en día existen varios métodos para realizar evaluaciones a una Arquitectura de Software que
verifican el cumplimiento o no de ciertos atributos de calidad, siendo unos más específicos que otros,
como es el caso de: Architecture Trade-off Analysis Method (ATAM), Bosch (2000), Active Design
Review (ADR), Active Reviews for Intermediate Design (ARID), Losavio (2003).
Existen otros métodos de evaluación de arquitectura que evalúan un atributo de calidad específico,
como: Architecture Level Modifiability Analysis (ALMA), Performance Assessment of Software
Architecture (PASA), Scenario based Architecture Level Usability Analysis (SALUTA) y Survivable
Network Analysis (SNA).
Independientemente de cuan especifico o no pueda ser el método de evaluación la gran mayoría tiene
algo en común y es que utilizan la técnica de escenarios como vía de constatar en qué medida la
arquitectura responde a los atributos de calidad requeridos por el sistema.
Un método de evaluación no es mejor que otro, sino que evalúa mejor, en ciertas condiciones, un
atributo de calidad dado. Por lo que se concluye que en dependencia de las condiciones y lo que se
desea evaluar, será el método de evaluación empleado (que no tiene que ser solo uno).
Relación entre la Arquitectura de Software y Atributos de Calidad
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
Durante el proceso de desarrollo de todo sistema de software se toman decisiones de diseño
arquitectónico que permiten alcanzar ciertos y determinados atributos de calidad. Para esto el
arquitecto se debe cuestionar frecuentemente cuál será el impacto que esa decisión causara sobre
otros atributos de calidad.
Cada decisión incorporada en una arquitectura de software puede afectar potencialmente los atributos
de calidad (Bass, et al., 2000). Por lo que se puede decir que al tomar dichas decisiones generalmente
se tienen consecuencias como:
Formulación de argumentos que expliquen cómo la decisión tomada permite alcanzar los
atributos de calidad propuestos.
Preguntas referentes al impacto de tomar dicha decisión, sobre otros atributos de calidad.
La relación que existe entre los Atributos de Calidad y la Arquitectura de Software tiene diversos
beneficios (Camacho, et al., 2004):
Realza en gran medida el proceso de análisis y diseño arquitectónico, ya que el arquitecto
puede reutilizar análisis existentes y determinar acuerdos explícitamente en lugar de hacerlo
sobre la marcha.
Una vez que el arquitecto entiende el impacto de los componentes arquitectónicos sobre uno o
varios atributos de calidad, estaría en capacidad de reemplazar un conjunto de componentes
por otro cuando lo considere necesario.
Una vez que se codifica la relación entre arquitectura y atributos de calidad, es posible construir
un protocolo de pruebas que habilitará la certificación por parte de terceros.
1.7. Conclusiones parciales
A partir de los objetivos propuestos para este capítulo, se puede concluir lo siguiente:
A lo largo de este capítulo se ha expuesto los principales aspectos dentro de la disciplina como:
concepción de las principales definiciones, tendencias actuales, estilos más novedosos y reinantes en
el mundo de las aplicaciones empresariales, exponiendo sus características, ventajas y desventajas.
Se analizaron los patrones arquitectónicos y niveles de abstracción de la arquitectura que ayudaron a
comprender conceptos como: estilos arquitectónicos y marcos de trabajo. También se ha abordaron
temas como la calidad en la Arquitectura de Software definiéndose los principales atributos de calidad
y métodos empleados para constatar en que medida la arquitectura cumple con los parámetros de
calidad que se establezcan. De igual forma se analizaron las Arquitecturas Orientadas a Servicios
1
1
FUNDAMENTACIÓN TEÓRICA
FUNDAMENTACIÓN TEÓRICA CAPÍTULO 1
CAPÍTULO 1
como máximo exponente del presente que permitió adoptarlo para aplicarlo en la propuesta de
solución ya que brindará una mayor flexibilidad al sistema ante el negocio cambiante que experimentan
las empresas hoy en día y a la facilidad de integración que brinda este tipo de arquitectura.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN
CAPÍTULO 2: PROPUESTA DE SOLUCIÓN
2.1. Introducción
En este capítulo se realiza la propuesta de solución al problema planteado en el diseño teórico de la
investigación, la misma viene dada por el artefacto Documento Descripción de Arquitectura que
propone la Universidad de las Ciencias Informáticas a emplear en los proyectos productivos. Siendo
dicho artefacto de gran importancia ya que proporciona, entre otras cosas, una vista arquitectónica del
sistema a todos los implicados en el mismo.
2.2. Descripción de la Arquitectura
2.2.1. Introducción
2.2.1.1. Propósito
Este documento identifica la arquitectura propuesta para el Sistema de Gestión de Inventario a partir
las 4+1 vistas arquitectónicas propuestas por la metodología RUP, las mismas facilitan la comprensión
de la arquitectura propuesta y aportan argumentos para la identificación de los elementos claves del
sistema en desarrollo, proporcionando información al cliente sobre las decisiones arquitectónicas en la
construcción del producto.
Ademas este documento persigue los siguientes propositos fundamentales:
Proporcionar una comprensión arquitectónica global del sistema a los stakeholders, mediante el
uso de de vistas arquitectónicas, de modo que se muestre los aspectos más significativos del
sistema.
Proporcionar soporte para toma de decisiones arquitectónicamente significativas que deban ser
tomadas en el desarrollo del sistema.
Organizar el desarrollo del sistema.
Fomentar la reutilización.
Hacer evolucionar el sistema.
2.2.1.2. Alcance
El alcance del presente documento se extiende a todo el Sistema de Gestión de Inventarios, a todos
los integrantes del proyecto encargados de desarrollarlo ya que el mismo influye en la toma de
desiciones arquitectónicas, y a todos los implicados en el desarrollo del sistema como: clientes, para
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
que comprendan con suficiente detalle qué se esta haciendo y cómo, de modo que facilite su
participación.
2.2.2. Representación Arquitectónica
A partir del estudio de los estilos arquitectónicos realizado en el capítulo 1 y de las características
particulares del sistema a desarrollar, siendo el mismo un módulo del ERP cubano; como parte de las
decisiones arquitectónicas para definir la propuesta de arquitectura se decidió utilizar para el Sistema
de Gestión de Inventarios una Arquitectura Orientada a Servicios. El por qué de esta decisión viene
dado por diferentes razones:
Porque las Arquitecturas Orientadas a Servicios permiten responder más rápidamente a las
condiciones cambiantes del negocio empresarial, promoviendo y permitiendo la reutilización, la
interconexión de tecnologías existentes en vez de consumir tiempo y costos en la reinvención.
Un Sistema de Gestión de Inventarios está formado por un conjunto de procesos que se
ejecutan y que son reutilizables para otros módulos como el de contabilidad, comerciales,
logística, entre otros.
Por otra parte el Sistema de Gestión de Inventarios, al formar parte del ERP, necesitará
intercambiar gran cantidad de información e interactuar con otros módulos del mismo.
Es un estilo arquitectónico que se basa fundamentalmente en estándares de desarrollo de los
servicios web como: XML, WSDL y SOAP, garantizando la interoperabilidad entre distintos
servicios y aplicaciones que colaboran con la agilidad del negocio. Tiene la ventaja de ser un
modelo arquitectural escasamente acoplado, lo cual le dota de una enorme flexibilidad para la
definición, implementación, sustitución, evolución de los servicios y las funcionalidades que
contiene.
Las Arquitecturas Orientadas a Servicios básicamente siguen la filosofía de un proveedor-consumidor,
auxiliándose de un repositorio UDDI que brinda servicios de directorio, por llamarlo de alguna manera,
ya que los proveedores publican las descripciones de los servicios en el repositorio de servicios, que
para la solución se propone usar JUDDI que es una implementación libre de UDDI para java, y cuando
el consumidor necesite de algún servicio consultará ese repositorio para encontrar la información
necesaria para localizar dicho servicio, si existe, para su posterior invocación. La propuesta de solución
no estará exenta de ese principio tan básico de este tipo de arquitecturas, que muestra como
colaboran las aplicaciones en una Arquitecturas Orientadas a Servicios.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Figura 1. Colaboración en una Arquitecturas Orientadas a Servicios
La propuesta de solución, según el modelo de madurez analizado en el capítulo anterior, estará
enmarcada en un primer nivel con elementos del segundo, como son: la UDDI y WS-Security,
garantizándose de esta forma la integración del sistema con cualquier otra aplicación o servicio que
necesite información de los inventarios, así como la seguridad de los servicios web.
El sistema propuesto estará estructurado en subsistemas y módulos definidos de forma vertical que
colaboran entre mediante interfaces y una estructuración por niveles lógicos (capas) de forma
horizontal posibilitando así el intercambio de datos, al servirse el nivel superior del inferior y este a su
vez brinda sus servicios a su inmediato superior, donde la capa de servicios compartidos expondrá los
procesos de negocio mediante servicios web.
La estructuración del sistema en capas viene dada por las ventajas que propicia como son: la
flexibilidad, escalabilidad, reutilización, capacidad de mantenimiento, entre otras, que coinciden, en
gran parte, con las variables que se proponen los autores resolver con dicha solución.
Figura 3. Arquitectura en Capas de la Propuesta SOA
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Capa de Presentación
Esta capa es la encargada de gestionar los datos de entrada y salida mediante las interfaces de
usuario, que van a permitir la interacción del sistema con los usuarios potenciales. En otras palabras,
maneja el contexto del usuario e interactúa con la capa de negocio donde está implementada toda la
lógica de la aplicación.
A partir de los Requisitos no Funcionales de los clientes y de las facilidades que brinda el diseño
arquitectónico propuesto, la capa de presentación del Sistema de Gestión de Inventarios puede ser
desarrollada en cualquier ambiente, tanto Web como Desktop. Finalmente se decidió desarrollar la
capa de presentación sobre la Web haciendo uso del framework MyFaces. De esta forma se busca
abaratar la solución mediante el uso de clientes ligeros, los cuales no ejecutan demasiadas labores de
procesamiento para la ejecución de la aplicación misma.
Es válido destacar que la decisión de realizar la aplicación web también viene dada por el concepto de
no dejar que el cliente realice demasiadas tareas, solo lo necesario para que lleve a cabo su trabajo y
dejar que en el lado del servidor se realicen las operaciones importantes: almacenamiento de datos,
transacciones, reglas del negocio y la lógica del programa.
Entre las ventajas de las aplicaciones basadas en la web se pueden mencionar:
Compatibilidad multiplataforma
Actualizaciones al sistema son más rápidas y fáciles, pues basta con realizar los cambios sobre
el servidor donde este corriendo la aplicación y todos los clientes dispondrán de ella una vez
que accedan al sistema.
Acceso inmediato vía cuenta online.
Facilidad de prueba.
Menores requerimientos de memoria local.
Precio ya que consumen menor cantidad de recursos.
Múltiples usuarios concurrentes.
Por otra parte, si bien es cierto que la arquitectura cliente servidor de la web ha ofrecido muchas
ventajas, también es cierto que carece de la riqueza gráfica de las aplicaciones de escritorio que
cuentan con controles inteligentes que dan mayor fluidez al trabajo del usuario, esto ha sido resuelto
con varias estrategias o tecnologías tales como AJAX, FLASH, Web 2, entre otras. Así que en vez de ir
perdiendo fuerza debido a la pobreza en sus interfaces gráficas, la web busca alternativas que le
permitan ofrecer todas sus ventajas pero con la posibilidad de ofrecer controles visuales más
amigables al trabajo del usuario.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Patrones
oPresentación
Nombre: Modelo – Vista – Controlador (MVC)
Problema: La lógica de un interfaz de usuario cambia con más frecuencia que los
almacenes de datos y la lógica de negocio. Si se realiza un diseño ofuscado, es decir,
un pastiche que mezcle los componentes de interfaz y de negocio, entonces la
consecuencia será que, cuando se necesite cambiar el interfaz, se tendrá que modificar
trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error.
(Lago, 2007).
Solución: Se trata de realizar un diseño que desacople la vista del modelo, con la
finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas
impactan en menor medida en la lógica de negocio o de datos.
Elementos del patrón:
Modelo: datos y reglas de negocio.
Vista: muestra la información del modelo al usuario.
Controlador: gestiona las entradas del usuario.
Figura 4. Estructura del patrón Modelo – Vista – Controlador (Lago, 2007)
Capa de Servicios
Una característica peculiar de las arquitecturas en capas es que las capas inferiores brinden las
funcionalidades que necesitan las capas inmediatamente superiores, y a la vez estas, solo puedan
acceder a las funcionalidades proporcionadas por las capas inmediatamente inferiores. Visto de esta
manera, la capa de servicios es la encargada proporcionar las funcionalidades que necesita la capa de
presentación. Además es la responsable de gestionar toda la lógica de negocio de la aplicación y a la
vez representa el contenedor lógico donde se ubican los servicios compartidos.
Las transacciones y operaciones de negocio serán realizadas por los servicios web que son los
encargados de exponer toda la funcionalidad del sistema. De tal forma que los procesos de negocio
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
del sistema de gestión de inventario serán expuestos mediante servicios web compartidos que podrán
ser accedidos por otros servicios o sistemas que necesiten información de los inventarios.
Para el desarrollo de cada servicio web se utilizarán los estándares de la industria, entre ellos los: XML
como formato estándar para los datos que se vayan a intercambiar, SOAP como protocolo para el
intercambio de datos, WSDL para la descripción de la interfaz pública de los servicios web, WS-
Security para la autenticación de los actores y la confidencialidad de los mensajes enviados y
finalmente la UDDI para publicar la información de los servicios web y comprobar qué servicios web
están disponibles.
Otro aspecto común a todos los servicios que se desarrollen, será crearle una fachada al negocio.
Crear esta fachada tiene como objetivo diferenciar los objetos del negocio de los objetos que necesitan
los servicios web, ya que es una mala práctica usar los mismos objetos para las dos cosas, debido a
que, quien quiera que utilice el servicio web no tiene por qué conocer más allá de la información
necesaria para utilizarlo.
A lo largo de esta capa habrá un conjunto de configuraciones y utilidades comunes para todos los
servicios que se desarrollen, que se encargan, entre otras cosas, de la interconexión entre las
diferentes capas vía XML.
Las Arquitecturas Orientadas a Servicios se distinguen por exponer la lógica del negocio mediante
servicios web que deben poder ser accedidos por todas aquellas aplicaciones que necesiten de ellos.
La vía más utilizada hoy en día para acceder a estos servicios es a través de un registro UDDI,
mediante el cual las aplicaciones pueden publicar y descubrir dichos servicios para su invocación.
JUDDI
Es una implementación libre de la especificación UDDI para java en cuestiones de servicios web. Entre
sus principales características están: que es open source, independiente de plataforma, brinda soporte
para JDK 1.3.1 hasta JDK 1.5, puede usarse con cualquier base de datos relacional que soporte
Structured Query Language (SQL) estándar como: MySQL, DB2, Sybase, JDataStore, HSQLDB. Es
desplegable en cualquier servidor de aplicación de java que soporte la especificación Servlet 2.3 como:
Jakarta Tomcat, JOnAS, WebSphere, WebLogic, Borland Enterprise Server, JRun. Es de fácil
integración con sistemas de autenticación existentes. Soporta configuración desplegable de clúster de
registros de JUDDI. (Apache, 2007).
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
La gran mayoría de las empresas que utilizan UDDI lo hacen en conjunto con un Bus de Servicios
Empresarial (ESB: Enterprise Service Bus), ya que este facilita la integración con otras aplicaciones,
sirve de mediador para la orquestación de servicios, maneja seguridad, en fin constituye un
componente que ofrece gran valor.
Hoy en día muchas empresas desarrollan su propio ESB para adaptarlo a las prestaciones de sus
modelos, pero este proceso implica mucho tiempo y esfuerzo. Por otra parte utilizar un ESB genérico
es complicado puesto a que la curva de aprendizaje es lenta, se necesita escribir mucho código y
desarrollar componentes para enlazarlos con otros que no son los desarrollados por el fabricante
original.
El Sistema de Gestión de Inventario en esta primera versión, manejará la lógica transaccional
internamente dentro de los servicios web a nivel de servicio de negocio con el framework Spring, por lo
que no se necesitará de un mediador (ESB), ni de un Lenguaje de Ejecución de Procesos de Negocio
(BPEL: Business Process Execution Language). Esto es algo costoso en el tiempo, pero en la medida
en que se vaya ganando en madurez de SOA se podrá incluir estos componentes que aportan gran
funcionalidad, flexibilidad y potencialidad al sistema.
De este modo se aprovechará las ventajas de integración que ofrece la UDDI ya que cualquier sistema
de cualquier entidad que necesite comunicarse o interactuar con el módulo de inventario podrá hacerlo
a través del repositorio de servicios, el cual brinda información sobre las funcionalidades ofrecidas y
cómo acceder a ellas.
Algunos de los beneficios que se derivan del uso de UDDI son (Mateu, 2003):
Posibilita compartir, buscar y reutilizar servicios web, así como otros recursos programables.
Define cómo interactuar con el servicio escogido, una vez localizado éste.
Permite llegar a nuevos clientes y facilita y simplifica el acceso a los clientes ya existentes.
Describe los servicios y componentes o métodos de negocio de forma automática (o
automatizable) en un entorno seguro, abierto y simple.
Contribuye al aumento de la confiabilidad de las aplicaciones, así como la mejora del proceso
de administración de estas.
Contribuye al aumento de la productividad en menor tiempo, ya que permite reutilizar recursos
ya elaborados.
Vista interna de un servicio web
Los servicios web proporcionados por la capa de servicios, que expondrán toda la funcionalidad del
sistema, serán también desarrollados en capas. A partir esta organización estructural en capas se
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
propone la utilización de un framework por cada una de ellas, pues contienen funcionalidades bien
definidas para un determinado dominio de la aplicación, un conjunto de componentes implementados e
interfaces, que se pueden utilizar, redefinir y crear nuevos. De modo que se puedan crear los
componentes necesarios por cada capa del servicio web.
Motor de Servicios Web: Apache Axis2 1.3
Capa de Negocio: Spring 2.0.
Capa de Acceso a Datos: Hibernate 3.2.0
Figura 5. Vista interna de un Servicio Web
Los niveles lógicos definidos de forma horizontal abstraen al nivel superior de un grupo de
funcionalidades. El nivel más bajo se encarga de la lógica de acceso a datos el cuál reutiliza las
funcionalidades del framework Hibernate. En este nivel se encuentran: los Objetos de Negocio, los
Ficheros de Mapeo y los Objetos de Acceso a Datos que se comunican con la base de datos mediante
las Fábricas de Sesiones vía XML.
El nivel intermedio se auxilia del framework Spring. Contiene los JavaBeans y los servicios encargados
de realizar las operaciones de negocio, para esto se auxilian de los Objetos de Acceso a Datos donde
mediante la inyección de dependencia se le inyecta la implementación del DAO correspondiente vía
XML. Paralelamente a esto se emplea Acegi, que es un módulo de Spring, para gestionar la seguridad
de forma no intrusiva mediante la programación orientada a aspectos.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Finalmente Axis2 se integra con Spring como motor de servicios web y herramienta para la
comunicación de los servicios web remotos.
Los frameworks utilizados brindan la ventaja de integrarse perfectamente unos con otros mediante
XML, posibilitando así, que fluya la comunicación entre ellos y la integración entre los componentes de
las diferentes capas.
Patrones
oNegocio
Nombre: Service Locator (Localizador de Servicio) (Microsystem, 2006)
Problema: En más de una ocasión un cliente deberá hacer uso de JNDI ya sea para
obtener una conexión a la base de datos, una referencia a la clase home de un
Enterprise Bean, o una referencia a los canales de mensajería. Al ser algo común para
muchas componentes, tiende a aparecer código similar múltiples veces y la creación
repetida del objeto InitialContext que puede tomar cierto tiempo.
Solución: Consiste en utilizar un objeto Service Locator para abstraer toda la utilización
JNDI y para ocultar las complejidades de la creación del contexto inicial, de búsqueda y
recreación de objetos home EJB. Varios clientes pueden reutilizar el objeto Service
Locator para reducir la complejidad del código, proporcionando un único punto de
control. (Alur, et al., 2001)
Elementos del patrón:
Client: Este es el cliente del Service Locator y representa a cualquier parte de la
aplicación que necesite acceder a un servicio determinado.
ServiceLocator: El ServiceLocator abstrae el API de los servicios de búsqueda
(nombrado), las dependencias del vendedor, las complejidades de la búsqueda, y la
creación de objetos de negocio, y proporciona una interface simple para los clientes.
InitialContext: El objeto InitialContext es el punto de inicio para los procesos de
búsqueda y creación.
ServiceFactory: El objeto ServiceFactory representa un objeto que proporciona
control del ciclo de vida para objetos BusinessService.
BusinessService: BusinessService es un rol que cumple el servicio que el cliente ha
solicitado. El objeto BusinessService se crea, se busca o se elimina mediante el
objeto ServiceFactory.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Figura 6. Estructura del patrón Service Locator (Microsystem, 2006)
Acceso a Datos
oNombre: Data Access Object (Objeto de Acceso a Datos) (DAO) (Microsystem, 2006).
Problema: Este patrón surge de la necesidad de gestionar una diversidad de fuentes de
datos, aunque su uso se extiende al problema de encapsular no sólo la fuente de datos,
sino además ocultar la forma de acceder a los datos. Se trata de que el software cliente
se centre en los datos que necesita y se olvide de cómo se realiza el acceso a los datos
o de cual es la fuente de almacenamiento.
Solución: Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los
accesos a la fuente de datos. El DAO maneja la conexión con la fuente de datos para
obtener y almacenar datos. Los componentes de negocio que tratan con el DAO utilizan
un interface simple expuesta por el DAO para sus clientes. Como el interface expuesto
por el DAO no cambia cuando cambia la implementación de la fuente de datos
subyacente, este patrón permite al DAO adaptarse a diferentes esquemas de
almacenamiento sin que esto afecte a sus clientes o componentes de negocio.
Elementos del patrón:
BusinessObject: Representa los datos del cliente. Es el objeto que requiere el
acceso a la fuente de datos para obtener y almacenar datos.
DataAccessObject: Es el objeto principal de este patrón. El mismo abstrae la
implementación del acceso a datos subyacente al BusinessObject para permitirle un
acceso transparente a la fuente de datos.
DataSource: Representa la implementación de la fuente de datos.
TransferObject: Representa un TransferObject utilizado para el transporte de datos.
Además puede ser usado por un DataAccessObject para devolver y recibir los datos
del cliente.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Figura 7. Estructura del patrón Data Access Object (DAO) (Microsystem, 2006)
Capa de Persistencia
La capa de persistencia es la encargada de gestionar el almacenamiento de los datos en el sistema
gestor de base de datos. Siendo los componentes de acceso a datos una parte fundamental en el
desarrollo del sistema.
La persistencia será manejada mediante software ORM (Object Relational Mapping) como frameworks
de persistencia. Los ORM proporcionan:
Mapear clases a tablas: propiedad columna, clase a tabla.
Persistir objetos.
Recuperar objetos persistidos.
Recuperar una lista de objetos.
Sistema Gestor de Base de Datos (SGBD)
El Módulo de Inventarios, como todo Software de Gestión que es, necesita un repositorio de
información, donde almacenar los datos necesarios para realizar las distintas operaciones.
La estructuración del sistema en Capas permite que se abstraiga la lógica de negocio del
almacenamiento de los datos, la capa de acceso a datos contiene toda la lógica de acceso, ya sea
consultas y procedimientos almacenados, dejando a la Base de Datos como simple almacén de datos
sin ninguna lógica.
El cambio en el SGBD no costaría un esfuerzo en el desarrollo del sistema. Además se implementaría
los mismos disparadores (Triggers) para mantener la seguridad y la confiabilidad en los datos, y los
roles de usuario para cada una de las opciones.
Finalmente para terminar con la representación de la arquitectura el artefacto Documento Descripción
de la Arquitectura se apoyará también en las 4+1 vistas de Philippe Krutchen, que responden a la
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
tendencia: “Arquitectura como etapa de ingeniería y diseño orientada a objetos”. Siendo estas: la Vista
de Caso de Uso, Vista Lógica, Vista de Procesos, Vista de Implementación, Vista de Despliegue.
Para la modelación de estas vistas se utilizó UML y Visual Paradigm como herramienta de modelado.
2.2.3. Objetivos y Restricciones Arquitectónicas
Las metas y las restricciones del sistema en cuanto a seguridad, portabilidad, escalabilidad e
integrabilidad significativas para la arquitectura son:
Requerimientos de Hardware
Estaciones de Trabajo
oTener periféricos Mouse y Teclado.
oTarjeta de red.
o256 Mb de memoria RAM.
oUninterruptible Power Supply (UPS).
Servidor UDDI
oTener periféricos Mouse y Teclado.
oMicroprocesador con 1Mb de cache L2, 1 GB de memoria RAM.
o2 GB de espacio libre en disco.
oTarjeta de red.
oUninterruptible Power Supply (UPS).
Servidor de Aplicaciones Apache
oTener periféricos Mouse y Teclado.
oMicroprocesador con 1Mb de cache L2, 1 GB de memoria RAM.
o2 GB de espacio libre en disco.
oTarjeta de red.
oUninterruptible Power Supply (UPS).
Servidor de SW
oTener periféricos Mouse y Teclado.
oMicroprocesador con 1Mb de cache L2, 2 GB de memoria RAM.
o2 GB de espacio libre en disco.
oTarjeta de red.
oUninterruptible Power Supply (UPS).
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Servidor de Base de Datos
oTener periféricos Mouse y Teclado.
oMicroprocesador con 1Mb de cache L2, 2 GB de memoria RAM.
oDisco Duro con capacidad de 160 GB o más.
oTarjeta de red.
oUninterruptible Power Supply (UPS).
Requerimientos de Software
Estaciones de Trabajo
oSistema Operativo: Windows 98 o superior, Debian, Ubuntu.
oNavegador Web: Internet Explorer 5.0 o superior, Mozilla Firefox 2.0 o superior.
Servidor UDDI
oSistema Operativo: Windows 98 o superior, Debian, Ubuntu.
oGestor de Base de Datos: PostgreSQL 8.2
oServidor Web: Apache Tomcat 6.0.13
Servidor Apache
oSistema Operativo: Windows 98 o superior, Debian, Ubuntu.
oServidor de Aplicaciones: Apache 2.2.4
Servidor de SW
oSistema Operativo: Windows 98 o superior, Debian, Ubuntu.
oMáquina Virtual de Java: Java Development Kit (JDK) versión 1.6
oServidor Web: Apache Tomcat 6.0.13
Servidor de Base de Datos
oSistema Operativo: Windows XP o superior, Ubuntu, preferentemente Debian.
oGestor de Base de Datos: PostgreSQL 8.2
Redes
La red existente en las instalaciones debe de soportar la transacción de paquetes de
información de al menos unas 10 máquinas a la vez.
Para hacer más fiable la aplicación debe de estar protegida contra fallos de corriente y de
conectividad, para lo que se deberá parametrizar los tiempos para realizar copias de seguridad.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Implementar las transacciones de paquetes en la red con el protocolo TCP/IP que permite la
recuperación de los datos.
Seguridad
Se hará un adecuado uso desde la seguridad brindada por el repositorio de servicios Web
(JUDDI), donde estarán publicados y serán descubiertos los mismos, mediante el mecanismo
de autenticación y otorgamiento de tokens implementados en jUDDI para el acceso de los
usuarios.
La comunicación de servicios web mantendrá su integridad y confidencialidad con el estándar
ws-security a través del modulo Rampart del framework Axis2.
Los servicios ofrecidos por el sistema no podrán ser ejecutados por sistemas no autorizados,
de manera que exista un sistema de autenticación para los servicios web que sea transparente
al usuario de las aplicaciones.
Tanto la comunicación entre los componentes de la plataforma como el manejo de datos del
sistema deberán encontrarse cifrados mediante algoritmos de encriptación, específicamente el
manejo de la seguridad de claves de acceso de usuarios.
La seguridad también será manejada desde la propia arquitectura de despliegue que se
propone, ya que para cualquier servicio o aplicación externa acceder al repositorio de servicios
y a los servidores web se deberá atravesar un firewall de software configurado de tal manera
que por defecto deniegue todas las entradas, aceptando sólo las direcciones que se
especifiquen explícitamente y el puerto por el cual se podrán conectar. A la base de datos sólo
podrán acceder los servidores web, de modo que en el fichero de configuración del SGBD
PostgreSQL se le definirá que servidores específicos interactuarán con él, que en este caso
serán los servidores web. Por otra parte, al Sistema de Gestión de Inventario,
independientemente de la autenticación, sólo podrán acceder aquellas máquinas clientes que
se especifiquen explícitamente, pues para acceder al mismo habrá que atravesar un firewall de
software configurado de la misma forma que anteriormente mencionado, denegando todo
excepto lo que se le especifique explícitamente.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Figura 8. Propuesta de Despliegue
Parte de la seguridad corre por parte de la tecnología Java utilizada para el desarrollo de la
aplicación con el framewok de seguridad Acegi que es un módulo de Spring.
Se deberá utilizar usuarios de base de datos con roles bien definidos para cada una de las
operaciones del sistema.
Debe quedar constancia de quién, desde dónde, y cuándo se realizó una operación
determinada en el sistema.
Para garantizar la seguridad de la Base de Datos, no se permitirán privilegios de administración
a ningún usuario.
La asignación de usuarios y sus opciones sobre el sistema se garantizará desde el modulo de
Administración del sistema.
Programación de disparadores (Triggers) en la Base de Datos para no permitir la manipulación
de los datos directamente en el SGBD.
El sistema deberá generar copias de seguridad, periódicas y automáticas, de los datos
contenidos en el mismo.
Bajo petición de un usuario experto el sistema deberá permitir realizar copias de seguridad del
sistema en el momento indicado.
Se deberá permitir restaurar por parte de técnicos especializados la información del sistema a
partir de una copia de seguridad anterior.
El sistema gestionará los datos concurrentemente, de manera que al actualizar un registro, se
comprobará si los datos que se quieren modificar no han sido modificados previamente por otro
sistema.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Portabilidad, escalabilidad, integrabilidad
El sistema deberá poder ser utilizado desde cualquier plataforma de software (Sistema
Operativo).
El sistema deberá hacer un uso racional de los recursos de hardware de la máquina, sobre todo
en las PC clientes.
La documentación de la arquitectura deberá ser reutilizable para poder documentarla como una
familia de productos.
Se desarrollará cada pieza del sistema en forma de componentes (elementos) con el fin de re-
utilizarlos para futuras versiones del sistema.
El sistema deberá exponer toda su funcionalidad mediante servicios web que se registrarán en
el directorio UDDI, garantizando así la integración de cualquier otro sistema o servicio que
necesite información del Sistema de Gestión de Inventarios.
Los servicios web serán desarrollados cumpliendo con los estándares definidos por la W3C y
OASIS como: XML como formato estándar para los datos que se vayan a intercambiar, SOAP
como protocolo para el intercambio de datos, WSDL para la descripción de la interfaz pública
de los servicios web, WS-Security para la autenticación de los actores y la confidencialidad de
los mensajes enviados y finalmente la UDDI para publicar la información de los servicios web y
comprobar qué servicios web están disponibles, la influencia de estos RNF recaen
directamente sobre la capa de negocios la cuál presta estos servicios directamente.
El sistema podrá ser escalado fácilmente de forma vertical mejorando los requerimientos de
hardware de los servidores, por ejemplo: aumentando la memoria RAM, cambiando el
microprocesador por otro de mayor rendimiento, etcétera, y horizontalmente mediante balances
de carga a través de clústeres de servidores en la medida que crezca la demanda.
Restricciones de acuerdo a la estrategia de diseño
El diseño de las aplicaciones se hará utilizando la Programación Orientada a Objetos (POO).
Encapsulación de la lógica por clases.
Se utilizará las ventajas de tecnología que brinda el framework Axis2 como motor de servicios
web.
Se utilizará las tecnologías que brindan los frameworks definidos para cada una de las capas
de la aplicación:
oPara la capa de presentación: MyFaces, aplicación Web.
oPara la capa de lógica del negocio: los objetos del negocio, framework Spring, la Inversión
de Control (IoC: Inversion of Control), la programación Orientada a Aspectos y el módulo
Acegi de Spring para la seguridad.
oPara la capa de Acceso a Datos: framework Hibernate.
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Herramientas de desarrollo
Para el modelado Visual Paradigm el cual demanda como mínimo 256 MB de RAM y
recomendado 512 MB de RAM.
Para implementación se empleará como IDE de desarrollo Eclipse 3.3.1 el cual demanda como
mínimo 768 MB de RAM y recomendado 1.0 GB de RAM al integrarlo con los plug-ins
necesarios y un procesador Intel Pentium IV a 2.4 GHz o superior.
Para implementación los plug-ins serán:
oJBossTools y WTP-SDK, para desarrollar la capa de presentación y los servicios web.
oSprind-ide, para implementar el Framework Spring 2.0.
oHibernate Tools, el cual facilita la ingeniería inversa y reversa de los ficheros de mapeo
entre clases java y tablas de Base de Datos.
oJUnit el cual facilita las pruebas de unidad.
oSVNeclipse el cual facilita la integración con Subversión
Como servidor de Base Datos PostgreSQL. (512 MB de RAM).
Como servidor de control de versiones Subversión.
2.2.4. Tamaño y Rendimiento
En esta sección se realiza una descripción de las características y dimensiones importantes del
software que afectan directamente a la arquitectura propuesta, así como también algunas restricciones
de rendimiento para la puesta en marcha del Sistema de Gestión de Inventario.
Crecimiento de los datos
El Sistema Gestor de Base de Datos seleccionado para la propuesta arquitectónica es PostgreSQL
el cual presenta entre sus características: juegos de caracteres internacionales, tipos de
codificación de caracteres multi-byte, Unicode, y es consciente de localización para su
clasificación, caso de sensibilidad, y de formato. Es altamente escalable, tanto en la enorme
cantidad de datos que puede manejar y en el número de usuarios concurrentes que puede tolerar.
(PostgreSQL, 2008)
En la siguiente tabla se muestran algunas limitantes de PostgreSQL:
Límite Valor
Tamaño máximo de la Base de Datos Ilimitada
Tamaño máximo de tabla 32 TB
Tamaño máximo de fila 1.6 TB
Tamaño máximo de campo 1 GB
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
Máximo de filas por tabla Ilimitada
Máximo de columnas por tabla 250 - 1600 depende del tipo de dato de las columnas
Máximo de llaves por tabla Ilimitada
Tabla 1. Potencialidades de PostgreSQL (PostgreSQL, 2008)
Independientemente de la capacidad de almacenamiento y potencialidades de PostgreSQL se
hace necesario analizar el crecimiento de los datos que manipulará el sistema. Para hacer esta
estimación se utilizará como referencia la base de datos del Sistema de Inventario de la empresa
Cubalse (una de las empresas más grandes del país que trabaja con el clasificador de productos
nacional y bajo las actuales regulaciones del Ministerios de Finanzas y Precios), en la cual se
observó que en peor de los casos se hacían alrededor de las 100 operaciones diarias. A partir de
este dato se estima entonces que en las peores situaciones la base de datos del Sistema de
Gestión de Inventario, que cuenta con 60 tablas persistentes, crezca unos 24 MB diario. Para más
información (anexo 16).
Tiempo de respuesta
PostgreSQL contribuye con los tiempos de respuesta del sistema puesto a que presenta una serie
de funcionalidades como las que se presentan a continuación que favorecen el rendimiento de las
transacciones a la base de datos:
oRecorridos de Mapas de Bits: los índices son convertidos a mapas de bits en memoria
cuando es apropiado, otorgando hasta veinte veces más rendimiento en consultas
complejas para tablas muy grandes. Esto también ayuda a simplificar la administración de
bases de datos reduciendo significativamente la necesidad de índices multi-columna. (Post-
greSQL, 2008).
oParticionamiento de Tablas: El optimizador de consultas es capaz de evitar recorrer
secciones completas de tablas grandes, a través de una técnica conocida como Exclusión
por Restricciones. Similar a las características de Particionado de Tablas de otros sistemas
gestores de datos, esta característica mejora tanto el rendimiento como la gestión de datos
para tablas de varios gigabytes. (PostgreSQL, 2008).
oBloqueos Compartidos de Registros: El modelo de bloqueos, mejor que a nivel de registro,
de PostgreSQL soporta niveles de concurrencia aún mayores que las versiones anteriores,
a través de la adición de candados compartidos a nivel de registro para llaves foráneas.
Estos candados compartidos mejoran el rendimiento de inserción y actualización para
1
1
PROPUESTA DE SOLUCIÓN
PROPUESTA DE SOLUCIÓN CAPÍTULO 2
CAPÍTULO 2
muchas aplicaciones Procesamiento de Transacciones En Línea (OLTP: OnLine Transaction
Processing) de gran concurrencia. (PostgreSQL, 2008).
También gran parte de los tiempos de respuesta del sistema serán manejados por el servidor de
aplicaciones Apache el cual implementará un balance de carga entre un clúster de servidores web
(Tomcat) donde estarán desplegados los servicios que contienen toda la lógica de negocio de la
aplicación. Esto posibilitará un mejor rendimiento por parte de los servicios web al estar
desplegados en varios servidores influyendo también en los tiempos de respuesta del Sistema de
Gestión de Inventarios.
Niveles Concurrencia
Los niveles de concurrencia del sistema serán manejados desde el Sistema Gestor de Base de
Datos PostgreSQL, el cual maneja la concurrencia mediante un modelo de control de concurrencia
que evita el bloqueo de los lectores ante acciones de los escritores y viceversa.
Multiversion Concurrency Control (MVCC)
Es una tecnología que PostgreSQL usa para evitar bloqueos innecesarios. MVCC está
considerado mejor que el bloqueo a nivel de fila porque un lector nunca es bloqueado por un
escritor. En su lugar, PostgreSQL mantiene una ruta a todas las transacciones realizadas por
los usuarios de la base de datos. PostgreSQL es capaz entonces de manejar los registros sin
necesidad de que los usuarios tengan que esperar a que los registros estén disponibles.
A diferencia de los sistemas de base de datos tradicionales que usan bloqueos para el control
de la concurrencia de dato, PostgreSQL mantiene la concurrencia de datos mediante el uso de
un modelo de multi-versión (Multiversion Concurrency Control, MVCC). Esto significa que
mientras consultas la base de datos cada transacción ve una versión de la base de datos, tal y
como lo fue unos instantes antes, sin tener en cuenta el estado actual de los datos
subyacentes. De esta forma se evita la visualización de datos inconsistentes que pueden ser a
causa de otra operación de actualización, de una transacción concurrente sobre la misma fila
de datos, proporcionando transacciones aisladas para cada consulta a la base de datos.
(PostqreSQL, 2005)
La principal ventaja de utilizar el modelo de control de concurrencia MVCC, en lugar de
bloqueo, es que en MVCC los bloqueos adquiridos para consultas de lecturas de datos no
entren en conflicto con los bloqueos adquiridos para la escritura de datos, por lo que la lectura
nunca bloquea a la escritura y viceversa.